Hi Nicolas! 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. Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel