GNOME Bugzilla – Bug 720618
h264parse: Scan from start of the frame at each handle_frame
Last modified: 2015-08-08 17:59:32 UTC
when parsing byte-stream (e.g. from TS demuxed stream), h264parse will need to scan for start code. It does so using gst_byte_reader_masked_scan_uint32() which is optimized for this kind of start code, but will resume the scanning from the same point, over and over. We could reduce the amount of time spend in the parser by keeping track of the last scan position in that buffer, skipping that size minus a 3 or 4 bytes safety, I don't remember what was the minimum. The mpeg2 video parser has already been fixed to do that.
That's not true, at least not any-more. /* check for initial skip */ if (h264parse->current_off == -1) { pres = gst_h264_parser_identify_nalu_unchecked (nalparser, data, current_off, size, &nalu); switch (pres) { case GST_H264_PARSER_OK: if (nalu.sc_offset > 0) { *skipsize = nalu.sc_offset; goto skip; } break; case GST_H264_PARSER_NO_NAL: *skipsize = size - 3; goto skip; break; default: g_assert_not_reached (); break; } } So we not properly set skipsize to the sc_offset (start code offset), if found and skip (size - 3) if not.