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

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.9.1

--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
I think this has been fixed independently by

commit e20a6877375ea41eb36abd44dc487960c52a88fb
Author: Nirbheek Chauhan <nirbheek at centricular.com>
Date:   Tue Mar 15 03:25:26 2016 +0530

    rtpjpegdepay: Don't send invalid frames downstream after packet loss or a
DISCONT

    After clearing the adapter due to a DISCONT, as might happen when some
packet(s)
    have been lost, the depayloader was pushing data into the adapter (which
had no
    header due to the clear), creating a headerless frame out of it, and
sending it
    downstream. The downstream decoder would then usually ignore it; unless
there
    were lots of DISCONTs from the jitterbuffer in which case the decoder would
reach
    its max_errors limit and throw an element error. Now we just discard that
data.

The test passes.


commit 03e2655f7090f743bbf4f71b5ca5b191c4b2d376
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Mon Apr 4 17:42:03 2016 +0100

    tests: add unit test for jpeg depayloader packet loss handling

    Make sure it always outputs something that looks like a valid
    JPEG frame, ie. starts with an SOI marker and ends with an EOI
    marker.


Should probably pick it into 1.8 too.

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