[Bug 674238] [mpegvideoparse] Seeks to I frames instead of the sequence header right before the I frame

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=674238
  GStreamer | gst-plugins-bad | 0.11.x

--- Comment #1 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2012-05-09 14:13:47 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.