[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 #14 from Sungho Bae <baver.bae at lge.com> 2014-06-09 05:01:42 UTC ---
(In reply to comment #13)
> Some notes, make sure to look at other parsers if you want to fix that. It was
> fixed a long time ago in MPEG2 Video, iirc by Mark. Ideally, I'd like the
> h264parser library, and other library to have consistent signature.

Thanks for your advice. I will look into MPEG2 Video, iirc by Mark.
If you know the related git repository name such as gst-plugin-bad or -good,
let me know it.

> 
> A second note, would be nice to share your test script, so we can reproduce.
> Will make the thing a little more scientific. Also, we have unit tests for this

Of course, I think I must make you reproduce the test.
After removing unnecessary codes, I will upload the test source and script.

> generic method in tests/check/libs/bytereader.c . I think they could be
> improved, but can already catch up if anything isn't completely reliable. You
> can run it using:
> 
> make -C tests/check libs/bytereader.check
> 
> And to debug it:
> 
> make -C tests/check libs/bytereader.gdb
> 

I tested as follows:

# ./bytereader
Running suite(s): GstByteReader
100%: Checks: 11, Failures: 0, Errors: 0

I confirmed that it works correctly using the above unit test program.

> I wouldn't create a new bug. This is about improving H264 parsing speed. Why we
> push so hard on the other case, is that it will optimize for all architectures
> without affecting the readability and maintainability of the code.
> 
> We also have bunch or other plan for this mask scan method where we can have
> higher gain, https://bugzilla.gnome.org/show_bug.cgi?id=675772
> 
> Final notes, thanks for your time and effort looking into this. We really
> appreciate that you are taking the time and making this effort in making
> GStreamer more efficient. Our review process can be exhausting sometimes, but I
> think you can understand that the last thing we'd like is to have code we don't
> fully understand, or too much assembly to maintain. So it's important for us to
> ask questions, take the time to reproduce, double check there is not error.
> Specially in core methods.

I fully understand your opinions.

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