[Bug 730783] bytereader: Improve the performance to find start code for H.264 and H.265

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=730783
  GStreamer | gstreamer (core) | git

--- Comment #8 from Sungho Bae <baver.bae at lge.com> 2014-05-30 06:55:05 UTC ---
(In reply to comment #3)
> Note for H264 header parsing performance, h264parse does not keep it's parsing
> context, hence re-parse the same buffer over and over. I think there is a bug
> for that, which I can't find now, but I'm sure I've created it. As the h264
> header parsing is pretty performant already (with the byte skipping algorithm),
> I'd focus on fixing this first, before going into having to maintain assembly
> code.

I am not familiar with h264parse.
As far as I know, h264parse uses extension fields for avc which does not have
start code prefix to find the start of each nal unit.
In the case of mp4 container, it supports to explicitly denote the size of each
nal unit by a field.
but, many of h264 streams adopt the start code based format and those need byte
scanning algorithm to find start code. 
one of examples is a ts container format.

In addition, h264parse concentrates on the way to parse a nal unit depending on
its nal type. but, gst_byte_reader_masked_scan_uint32() is used to extract nal
units from media files before parsing them.
Therefore, because the purpose of gst_byte_reader_masked_scan_uint32() differs
from h264parse's, I think this patch is useful although h264parse plugin
exists.

I know you adopted Boyer-Moor bad character heuristic to _scan_for_start_code()
function to gstreamer repository. I thought your algorithm was good. so, I
investigated and proposed the improved idea.


You wrote as follows:
> h264parse does not keep it's parsing context, hence re-parse the same buffer over and over.

I am not familiar with h264parse. but, I will review h264parse plugin as much
as I can. In case of extracting a nal unit from start code based media stream,
it is needed two points of start codes: the first indexes of the current nal
unit and the next nal unit.

+----------+--------------------+----------+---------------+--------+
| 0x000001 |  current nal unit  | 0x000001 | next nal unit | ....   |
+----------+--------------------+----------+---------------+--------+
                 ^----  it is placed between two start codes

If h264parse has a bug, I guess the bug is related to the above.
but, I'm not sure because I haven't yet reviewed.

Thanks.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.