GNOME Bugzilla – Bug 674238
mpegvideoparse: Seeks to I frames instead of the sequence header right before the I frame
Last modified: 2018-11-03 13:11:47 UTC
Currently mpegvideoparse seeks to I frames instead of the sequence header right before the I frame, which usually comes directly before the I frame. As the sequence header could change for every I frame, the parser should use this as key units. The current behaviour requires caching of the sequence header inside decoders and assuming that it didn't change. As a result, when this caching does not happen, accurate seeking is impossible because the decoder has to skip over until the next sequence header in front of the next I frame.
Yesterday I went across a failing mpegvideoparser test, that was about the codec data. The codec data actually contains the sequence header (the test assumes the the 4 byte packet header was not there, while it's there, but imho this is a test bug), so the decoder does not have to cache it. The "hard" part though is that to know if the header must be played or not, the decoder need to remember if reset was called, and if so it must check the forth byte of the frame, if it's GST_MPEG_VIDEO_PACKET_SEQUENCE (0xb3). In some cases, this may require extending a buffer with the header, which may cost a copy, but it's only on seek, with encoded data. Some optimisation might be possible (e.g. ignore hard reset, and compare sequence header on next frame to make the right decision, instead of letting the base class guess). Note that while the sequence header is in the caps, I would not be surprise if it's not always the right sequence. Currently I see no code in the parsers to index the sequences, or lookup for the current sequence. But in most cases, the sequence does not change during playback, especially for DVD, and is always obtained during preroll.
Nicolas, regarding codec_data => bug #702806
bug #702806 will fix the an important use case, as we have only 1 demuxer, it's probably the only case. I didn't know that was broken, but it's probably the #1 issue here. For the record, codec data is moved to caps by the demuxer, but the parser fails to skip the start code in it and reject it.
Looks like this issue may still exist in master, but downgrading severity since if I'm not mistaken this only applies to plain ES streams with no demuxer involved.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/69.