GNOME Bugzilla – Bug 739968
v4l2src: outputs bogus DTS
Last modified: 2015-06-04 13:19:18 UTC
v4l2src doesn't explicitly set any DTS on outgoing buffers, which means basesrc sets a default DTS (0, or segment start). There's no way to prevent basesrc from that behaviour at the moment, which means that all v4l2src streams start with a buffer where DTS = 0. For encoded formats, that means that (for example) h264parse starts producing a stream withmonotonically increasing DTS from 0, and some arbitrarily offset PTS time range - leading to strange muxing. For raw video, v4l2src can just set DTS = PTS on the output stream, but that won't work for encoded formats with frame reordering, and I'm not sure what v4l2src should do - or if we should change basesrc to not set that first DTS.
Hmm, that's bad from basesrc, I always thought the DTS was to be set as NONE, which would be the correct value. DTS=PTS would be incorrect as you stated. http://linuxtv.org/downloads/v4l-dvb-apis/buffer.html According to the spec, from v4l2src point of view, the timestamp is the time when the image was captured. Note, this is generally just an approximation, but it clearly states that the driver can only give PTS. In presence of b-frames, PTS will go forth an back, hence bad clock detection code will fail, and the system (in dev branch only) vs wall clock detection may fail too. Few changes seems needed.
(note also that the first DTS in B-frame enable H264 stream is negative. We should let the parser fix it for us and only set what we know.)
A simple solution might be to simply make basesrc only set that initial DTS if the first buffer has both DTS *and* PTS unset.
If it does not break other sources, I'm fine with that.
I believe this is fixed (at least for raw cases) through https://bugzilla.gnome.org/show_bug.cgi?id=747731 ?
Yes, should be