Oliver Collyer
2016-09-02 10:09:58 UTC
Hi all
Iâve been trying to workaround some issues in FFmpeg relating to this error flag being passed from V4L2.
In particular this bug here:
https://trac.ffmpeg.org/ticket/4988 <https://trac.ffmpeg.org/ticket/4988>
The long and short of it is that this error comes through several times at the start of a capture and FFmpeg struggles to handle it properly, despite previous attempts at fixing (such as this one https://trac.ffmpeg.org/ticket/4030 <https://trac.ffmpeg.org/ticket/4030>)
Iâve also reproduced this outside of FFmpeg using the capture example that is part of the V4L2 API:
https://www.linuxtv.org/downloads/v4l-dvb-apis/capture-example.html <https://www.linuxtv.org/downloads/v4l-dvb-apis/capture-example.html>
Further, I have the following two devices in my possession and both produce the error, so it doesnât seem to be related to the specific hardware, unless they are making the same mistake:
Magewell XI100DUSBHDMI
Inogeni DVI2USB3
Significantly, the error does not seem to occur the first time after the USB device is connected, however it appears 100% of the time thereafter.
Now while software like FFmpeg is supposed to be able to cope with this error, clearly this has been problematic in the past; for example currently FFmpeg can throw away these buffers with errors in but it would appear that the time delay while the capture device sorts itself out knocks the timestamps out of sync with the FFmpeg output thus causing tons of FFmpeg warnings.
So I wondered about the possibility of getting this fixed properly in the driver - presumably when the capture session is terminated something isnât being shutdown properly/released and this causes the errors at the start of every subsequent capture?
I am happy to test any potential fixes, or try a later driver if someone can tell me how I would go about that.
Regards
Oliver
PS I did a search to see if this issue had been discussed before and couldnât find anything in the archives other than some discussion when the flag was implemented.
Iâve been trying to workaround some issues in FFmpeg relating to this error flag being passed from V4L2.
In particular this bug here:
https://trac.ffmpeg.org/ticket/4988 <https://trac.ffmpeg.org/ticket/4988>
The long and short of it is that this error comes through several times at the start of a capture and FFmpeg struggles to handle it properly, despite previous attempts at fixing (such as this one https://trac.ffmpeg.org/ticket/4030 <https://trac.ffmpeg.org/ticket/4030>)
Iâve also reproduced this outside of FFmpeg using the capture example that is part of the V4L2 API:
https://www.linuxtv.org/downloads/v4l-dvb-apis/capture-example.html <https://www.linuxtv.org/downloads/v4l-dvb-apis/capture-example.html>
Further, I have the following two devices in my possession and both produce the error, so it doesnât seem to be related to the specific hardware, unless they are making the same mistake:
Magewell XI100DUSBHDMI
Inogeni DVI2USB3
Significantly, the error does not seem to occur the first time after the USB device is connected, however it appears 100% of the time thereafter.
Now while software like FFmpeg is supposed to be able to cope with this error, clearly this has been problematic in the past; for example currently FFmpeg can throw away these buffers with errors in but it would appear that the time delay while the capture device sorts itself out knocks the timestamps out of sync with the FFmpeg output thus causing tons of FFmpeg warnings.
So I wondered about the possibility of getting this fixed properly in the driver - presumably when the capture session is terminated something isnât being shutdown properly/released and this causes the errors at the start of every subsequent capture?
I am happy to test any potential fixes, or try a later driver if someone can tell me how I would go about that.
Regards
Oliver
PS I did a search to see if this issue had been discussed before and couldnât find anything in the archives other than some discussion when the flag was implemented.