codecparsers: h264: fix identification of EOSEQ and EOS NALs.

An end_of_seq() [EOSEQ] or end_of_stream() [EOS] NAL unit is really
one byte long because this shall include the NalHeaderBytes (1) too.
The NALU.offset starts from the first byte of the header.

This is the proper fix to commit d37f842. In practice, this fixes
parsing of FRExt1_Panasonic_D and FRExt2_Panasonic_C, that include
additional frames after an EOSEQ.

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

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This commit is contained in:
Gwenole Beauchesne 2014-07-01 15:46:17 +02:00
parent 86080cb5cc
commit 22b68b60ec

View file

@ -1087,7 +1087,7 @@ gst_h264_parser_identify_nalu_unchecked (GstH264NalParser * nalparser,
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");
nalu->size = 0;
nalu->size = 1;
return GST_H264_PARSER_OK;
}
@ -1117,7 +1117,7 @@ gst_h264_parser_identify_nalu (GstH264NalParser * nalparser,
gst_h264_parser_identify_nalu_unchecked (nalparser, data, offset, size,
nalu);
if (res != GST_H264_PARSER_OK || nalu->size == 0)
if (res != GST_H264_PARSER_OK || nalu->size == 1)
goto beach;
off2 = scan_for_start_codes (data + nalu->offset, size - nalu->offset);