Commit 6af387cd authored by Matej's avatar Matej Committed by Sebastian Dröge

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
parent 821c3edc
......@@ -1226,15 +1226,18 @@ gst_h264_parser_identify_nalu_unchecked (GstH264NalParser * nalparser,
nalu->valid = TRUE;
nalu->sc_offset = offset + off1;
/* sc might have 2 or 3 0-bytes */
if (nalu->sc_offset > 0 && data[nalu->sc_offset - 1] == 00)
nalu->sc_offset--;
nalu->offset = offset + off1 + 3;
nalu->data = (guint8 *) data;
set_nalu_datas (nalu);
/* sc might have 2 or 3 0-bytes */
if (nalu->sc_offset > 0 && data[nalu->sc_offset - 1] == 00
&& (nalu->type == GST_H264_NAL_SPS || nalu->type == GST_H264_NAL_PPS
|| nalu->type == GST_H264_NAL_AU_DELIMITER))
nalu->sc_offset--;
if (nalu->type == GST_H264_NAL_SEQ_END ||
nalu->type == GST_H264_NAL_STREAM_END) {
GST_DEBUG ("end-of-seq or end-of-stream nal found");
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment