On 2019-03-18 23:26 +0100, Alexander Strasser wrote: > On 2019-03-18 00:24 +0100, Nicolas George wrote: > > Alexander Strasser (12019-03-18): > > > I tested the EAGAIN version and it worked. I also tested returning a > > > > ffmpeg.c uses the non-blocking mode. > > That would explain it. I now tested, the FFERROR_REDO approach, > and I think it works fine. As I don't have it available anymore, > I can't test with the device that gave me the errors. So I modified > the code to create the error condition. > > Using FFERROR_REDO would work for blocking mode as well as non-blocking, > right? > > It handles the error on a lower level inside the libs and doesn't > bubble up to the lib user AFAICT. > > > > > zero-sized packet, like in the case where V4L flags the data as corrupt, > > > that worked too. See commit 28f20d2ff487aa589643d8f70eaf614b78839685 > > > > > > Do you think the zero-sized packet would be better than returning > > > FFERROR_REDO? > > > > I think it depends on what happens exactly with that frame? What is the > > partial packet returned? Is there a timestamp? Etc. > > As mentioned above I can't dump more data to get a clue. I guess > the frame was just truncated and the timestamps were correct. > > As we wouldn't pass on frame data to the user anyway, I would actually > prefer the FFERROR_REDO version.
I sent a new patch changing the returned error code to FFERROR_REDO. This patch can be considered rejected. Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel