[Bug 711627] New: mpegvparse: Incorrect repositioning of start code location when input buffer is empty

[GStreamer (bugzilla.gnome.org)]

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

           Summary: mpegvparse: Incorrect repositioning of start code
                    location when input buffer is empty
    Classification: Platform
           Product: GStreamer
           Version: 1.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: g.rutz at cablelabs.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=259209)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=259209)
Proposed fix

I have a test stream (MPEG PS) in which pictures within are GOP are terminated
by a new picture start code and picture_header.  During processing of this
stream, a particular input buffer to mpegvparse ends with the picture start
code meant to terminate the previous frame.  However, there is code in
mpegvparse that looks deeper into the picture header (into the temporal
sequence number) to determine if the next picture is actually the bottom field
of an interlaced frame.  In my case, these bytes are not available in the
current buffer, so we must iterate through the chain call again to get more
data.  When this happens, mpegvparse repositions the start_code offset back to
before the previous start code so that processing can be done again:

gstmpegvideoparse.c:667

      GST_LOG_OBJECT (mpvparse, "need more data");
      /* resume scan where we left it */
      mpvparse->last_sc = size - 3;
      /* request best next available */
      off = G_MAXUINT;
      goto exit;

In my case, changing "size - 3" to "size - 4" fixes the problem.  I think this
is because the start_code is always 4 bytes, and "size" (at this point in the
code) always refers to the location in the input buffer that is just after the
last processed start_code.

Patch included.  I can provide the content file that exhibits this bug, but I
have to do it through private channels (preferably Dropbox or Google Drive).

-- 
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.