[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 #9 from Edward Hervey <bilboed at bilboed.com> 2014-05-30 07:19:56 UTC ---
The problem that Nicolas is pointing out is the following:

Say your full stream is what you mentioned and it comes into h264parse as two
buffers

+----------+--------------------+----------+---------------+--------+
| 0x000001 |  current nal unit  | 0x000001 | next nal unit | ....   |
+----------+--------------------+----------+---------------+--------+
\______________________________/ \________________________/ ...
          First Buffer               Second Buffer

What Nicolas meant that it doesn't keep context is that, for each buffer,
h264parse will look for the first start_code (trivial), and then the next one
(as you mentioned, to know how big the NALU is).

+----------+--------------------+
| 0x000001 |  current nal unit  |
+----------+--------------------+
                                ^
                                ^
   h264parse scans all the way to the end of the buffer...
but then doesn't remember it already scanned when the next buffer comes round

2nd buffer comes in, 1st one is still in the parser, we now have:

+----------+--------------------+----------+---------------+
| 0x000001 |  pending nal unit  | 0x000001 | next nal unit |
+----------+--------------------+----------+---------------+
           ^                    ^
           A                    B

h264parse will resume parsing from offset A instead of resuming it from offset
B... resulting in scanning *twice* the nal unit

-- 
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.