GNOME Bugzilla – Bug 702357
codecparser: optimize scanning for start code
Last modified: 2013-08-10 22:59:47 UTC
Use the same improvement as 920053dae6957ded976b18ff8e111a242a077617 which was only done for mpeg video. Makes scanning for start codes 4.5 times faster, and overall h264 parsing 4 times faster. (When not working in passthrough obviously).
Created attachment 246903 [details] [review] codecparser: optimize scanning for start code
Created attachment 246906 [details] [review] h264parser: Use parserutils header Doesn't add anything so far, just a separate commit to isolate unique macro symbols.
Created attachment 246907 [details] [review] codecparsers: Make all parsers use fast start code method This was added in 920053dae6957ded976b18ff8e111a242a077617 but only in the mpeg video parser. We now make mpeg video (1,2,4), h264 and vc1 parser make use of it. Makes scanning for start codes 4.5 times faster, and overall h264 parsing 4 times faster. (When not working in passthrough obviously).
Wouldn't it be easier to special case gst_byte_reader_masked_scan_uint32() depending on the input?
Not really, this is very specific to some formats only.
(In reply to comment #5) > Not really, this is very specific to some formats only. What do you mean? in your patches you replace calls to gst_byte_reader_masked_scan_uint32() with a mask of 0xffffff00 and value 0x00000100 with a call to your specialized version. I'm suggesting to move the spcialized version to gst_byte_reader_masked_scan_uint32() and switch to it when you get the mask and value as input.
So after the mpeg fix, I started implement bigger stepping in masked_scan_uint32() in the generic code, but just never finished it. Adding a special case for mask that start with fixed values in the range of 2 to 4 bytes seems easier solution.
Another note, there is two copies of the _masked_scan_uint32(), there is one in GstAdapter too.
That's bug #675772 btw. Didn't you have patches for that somewhere, Nicolas?
Sorry, I have lost my initial draft, I'll comment about the alog on the other bug.
Created attachment 251133 [details] [review] [PATCH] bytereader: Accelerate MPEG/H264 start code scanning Accelerate MPEG/H264 start code scanning using Boyer-Moor bad character heuristic. https://bugzilla.gnome.org/show_bug.cgi?id=702357 --- libs/gst/base/gstbytereader.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
Note, I have tried making agenericly accelerated version, but it seemed impossible to achieve de required preprocessing described in Boyer-Moore algorithme because of the masking. If someone would like to have a look, the implementation of half the algorithme (bad heuristic only) is there: http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=boyer-moore Note that other format uses fixed code (with mask of 0xFFFFFFFF or 0xFFFFFF00), these two case has simple 4 characters alphabet, and could clearly gain having an accelerated path. This could accelerate Matroska binary search. I've looked in the code, and there is no mpeg/h264 or VC1 parser using the GstAdapter, so it's not really worth porting this optimisation to the adapter.
Comment on attachment 251133 [details] [review] [PATCH] bytereader: Accelerate MPEG/H264 start code scanning commit de75bca9b387c404a29cb057046d0db1d601794c Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Thu Aug 8 12:08:31 2013 +0200 bytereader: Accelerate MPEG/H264 start code scanning Accelerate MPEG/H264 start code scanning using Boyer-Moor bad character heuristic. https://bugzilla.gnome.org/show_bug.cgi?id=702357