[Bug 762489] New: rtpjpegdepay may push buffers before setting output caps

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762489

            Bug ID: 762489
           Summary: rtpjpegdepay may push buffers before setting output
                    caps
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: george.kiagiadakis at collabora.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 321893
  --> https://bugzilla.gnome.org/attachment.cgi?id=321893&action=edit
unit test

When rtpjpegdepay starts receiving a stream, it will set the output caps only
when the fragment offset is 0, which signifies the beginning of a JPEG image.
In case reception starts from a fragment of an image that is not the first
fragment (offset=0), then rtpjpegdepay will still collect the rest of the image
and push it downstream but without setting the output caps.

I have written a unit test (attached) that illustrates the problem. The test
ensures that the output of jpegpay will be fragmented by setting mtu to a low
value, it drops the first buffer using a pad probe and requires that the
plugged decodebin (the decodebin will internally plug rtpjpegdepay) has caps
set on the exposed decode pad. When a buffer is pushed before caps, decodebin
exposes the pad prematurely and the assertion fails.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.