Changes in:  gst-plugins-bad

 gstreamer:d92361ba5228970af718f068b96600177a1195d5
 gst-plugins-base:b5d26f3907d2b96f064b95488b672c36ce072c71
 gst-plugins-good:ada6ea668b00d1c9836a401b8e964578b0420ab1
 gst-plugins-ugly:4fb63af272099ef1d3ff619a0bde97389100dbc0
 gst-plugins-bad:6af387cd5ab2c946025e5499903e75ee87b063a9
 gst-ffmpeg:1aa253cd3bdf34968f8333da83e90afe3306cf0e
 gnonlin:dd148c43ad4c8d09a659093024e210949e5eb1e0
 gst-editing-services:289b04f170ddfa28ec4bc01794a8ef444b61a8b4
 gst-python:c889037e40bb3568ef8cd9456123d744b25a919b

====== gst-plugins-bad =============

 commit 6af387cd5ab2c946025e5499903e75ee87b063a9
Author: Matej Knopp <matej.knopp@gmail.com>
Date:   Thu Dec 12 17:49:24 2013 +0100

    h264parser: not all startcodes should have 3-byte 0 prefix

    The parser assumes that every time there is a 0 before the startcode,
    it is part of the startcode. But that's not true.

    From the specification

    Byte stream NAL unit syntax
    zero_byte is a single byte equal to 0x00.
      When any of the following conditions are fulfilled, the zero_byte syntax
      element shall be present.
      – the nal_unit_type within the nal_unit( ) is equal to 7 (sequence parameter
        set) or 8 (picture parameter set)
      – the byte stream NAL unit syntax structure contains the first NAL unit of an
        access unit in decoding order, as specified by subclause 7.4.1.2.3.

    The problem with doing this for all startcodes is that a trailing zero can mess
    up timestamps. The trailing zero gets prepended to the startcode, which will
    carry the PTS and DTS of previous buffer.

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