Hi Marton, hi Nicolas! On 2019-03-21 10:07 +0100, Nicolas George wrote: > Marton Balint (12019-03-21): > > Maybe just set the packet corrupt flag and log an error, but return the > > partial buffer? > > I think it may be the best solution. But it would be interesting to know > how the tools react to it.
I agree that it might be the most sophisticated solution. But it is not so clear how this would work out with ffmpeg and all other client apps. It might also be more tricky/involved to implement correctly. Personally I don't want to invest much more time into this ATM. I would really like to achieve to prevent aborting the capture in case of a frame once in a while being returned too short. I believe it would be a big win that can hopefully be implemented without causing harm. After considering the 3 variants I have implemented so far I am now at the following conclusion: 1. Return AVERROR(EAGAIN) => this is not an option because it is not expected when using blocking mode 2. Return FFERROR_REDO => this could be used, but has the not completely unlikely downside to not return to the caller for a very long time. That is in the case the driver starts emitting too short frames in a row for a long time. 3. Return zero-sized packets => This works and is consistent with how we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR). See commit 28f20d2ff487aa589643d8f70eaf614b78839685 . Choosing from the above 3 options, IMHO 3 is the best. If someone decides to improve it at a later point, one could improve the V4L2_BUF_FLAG_ERROR case too. Do you think that going with 3 now is fine? If yes I would send that patch for review. Thanks for your comments! Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
