We would add the offset a second time in _scan_for_start_code()
when we found a result, but it's already been added to the data
pointer at the beginning of _masked_scan_uint32_peek(), so the
peeked value would be wrong if the initial offset was >0, and
we would potentially read memory out-of-bounds.
Add unit test for all of this.
https://bugzilla.gnome.org/show_bug.cgi?id=778365
These are not usable as they are, and can easily lead to crash
or leaks. This also silence warning from the scanner. If we manage to
make this usable, we can then remove that mark, it will require
to make this type boxed.
Adds API to get or peek a sub-reader of a certain size from
a given byte reader. This is useful when parsing nested chunks,
one can easily get a byte reader for a sub-chunk and make
sure one never reads beyond the sub-chunk boundary.
API: gst_byte_reader_peek_sub_reader()
API: gst_byte_reader_get_sub_reader()
Adds gst_byte_reader_masked_scan_uint32_peek just like
GstAdapter has a _peek and non _peek version
Upgraded tests to check that the returned value is correct in the
_peek version
API: gst_byte_reader_masked_scan_uint32_peek
https://bugzilla.gnome.org/show_bug.cgi?id=728356
Currently the scan uses Boyer-moore method and its performance is good.
but, it can be optimized from an implementation of view.
The original scan code is implemented by byte array and index-based access.
In _scan_for_start_code(), the index is increasing from start to end and the
base address of the byte array is referred to as return value.
In the case, index-based access can be replaced by pointer access, which
improve the performance by removing index-related operations.
Its performace is enhanced by approximately 8% on arm-based embedded devices.
Although it seems trivial, it can affect the overall performance because the
_scan_for_start_code() function is very often called when H.264/H.265 video is
played.
In addition, the technique can apply for all architectures and it is good in
view of readability and maintainability.
https://bugzilla.gnome.org/show_bug.cgi?id=731442
The normal functions are always useful to have for bindings, especially
runtime-created bindings like Seed or new GObject-Introspection based
Python bindings.
Clarify byte reader docs a bit: offset is relative to the current
position of the reader, not to the start of the data. Also, the
examples in both the adapter docs and the byte reader docs have
the mask and pattern arguments swapped (see #587561). Spotted
by Carl-Anton Ingmarsson.
Add a pattern scan function similar to the one recently added to
GstAdapter, and a unit test (based on the adapter one).
Fixes#585592.
API: add gst_byte_reader_masked_scan_uint32()
Original commit message from CVS:
* docs/libs/gstreamer-libs-sections.txt:
* libs/gst/base/gstbytereader.c: (gst_byte_reader_get_data),
(gst_byte_reader_peek_data):
* libs/gst/base/gstbytereader.h:
* win32/common/libgstbase.def:
API: Add gst_byte_reader_get_data and gst_byte_reader_peek_data
to get a pointer to the data at the current position and have
a guaranteed size.
Original commit message from CVS:
* libs/gst/base/gstbytereader.c: (gst_byte_reader_get_uint24_le),
(gst_byte_reader_get_uint24_be), (gst_byte_reader_get_int24_le),
(gst_byte_reader_get_int24_be), (gst_byte_reader_peek_uint24_le),
(gst_byte_reader_peek_uint24_be), (gst_byte_reader_peek_int24_le),
(gst_byte_reader_peek_int24_be):
Use new GST_READ_UINT24_(LE|BE) macros.
