GNOME Bugzilla – Bug 778365
bytereader: offset accounted twice in _masked_scan_uint32_peek for H264 special case
Last modified: 2017-02-23 10:07:18 UTC
In function gstreamer/libs/gst/base/gstbytereader.c:_masked_scan_uint32_peek "offset" value accounted twice. First time when we evaluate "data" variable. The second time when we pass "offset" value to _scan_for_start_code function. The case is applicable only when special condition are met: (pattern == 0x00000100) && (mask == 0xffffff00) - H264 nal unit border pattern.
Could you make a small test case (piece of code) in C that shows the problem? (Or add it to gstreamer/tests/check/libs/bytereader.c)
Okay, I have a test case that demonstrates the issue now.
Created attachment 346397 [details] [review] bytereader: fix scanning for 00 00 01 markers with non-0 offset
Created attachment 346399 [details] [review] bytereader: fix peek value when scanning for 00 00 01 with non-0 offset Updated commit message. The offset returned was correct before, just the peeked value was not.
Review of attachment 346399 [details] [review]: Looks good to me.
commit 834fd18dfaa79c99cac460f9597b3bb5f7e240d9 Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Feb 21 20:23:51 2017 +0000 bytereader: fix peek value when scanning for 00 00 01 with non-0 offset 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