On 2019-03-17 18:25 +0100, Nicolas George wrote: > Alexander Strasser (12019-03-17): > > I had found that when capturing video for some hours from > > USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.), > > sometimes when invoking the ioctl DQBUF, the returned buffer is not > > filled with the size we expect for the raw video frame. > > Which seems like a kernel bug, does it not?
Seems like a kernel bug, yes. Probably driver specific. Though I am not 100% sure it is strictly a bug. Might be that this is the best a driver for a particular hardware can do. In any case at least 2 different and probably more devices exhibited the described behaviour, which was never a permanent failure. I suspect some drivers will always exhibit this behavior sometimes. That's why I think we should handle this particular case more graceful. > > To avoid this, return AVERROR(EAGAIN) instead. > > Returning EAGAIN when not in non-blocking mode is invalid. FFERROR_REDO > would be the correct code in that case. Maybe using EAGAIN wasn't a good choice :( Using FFERROR_REDO sounds promising. I will try that. I tested the EAGAIN version and it worked. I also tested returning a 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? Thanks for your comments! Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
