The expected number of iterations may increase by one for an input of alternating 0 and 1 bytes. Instead of incrementing by 2 everytime, it now alternates between incrementing by 1 and by 3.
For the check p[-2] != 0: This slightly reduces the number of iterations by starting with three new bytes on the next iteration, instead of keeping byte p[-3] which is invalid, since it is now known to be 01 when it must be 00. The comparisons (p[-1] > 1) and (p[-1] == 0) should be one comparison against 1 since p is unsigned, which makes (p[-1] == 0) equivalent to (p[-1] < 1) No other observable change. --- libavcodec/utils.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index 42a1885d61..5b49657b44 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -953,12 +953,27 @@ const uint8_t *avpriv_find_start_code(const uint8_t *av_restrict p, return p; } + /* with memory address increasing left to right, we are looking for (in hexadecimal): + * 00 00 01 XX + * p points at the address which should have the value of XX + */ while (p < end) { - if (p[-1] > 1 ) p += 3; - else if (p[-2] ) p += 2; - else if (p[-3]|(p[-1]-1)) p++; - else { + // UU UU UU + if (p[-1] > 1) { + p += 3; + // start check over with 3 new bytes + } + else if (p[-1] == 0) { + p++; + // could be in a start code, so check next byte + } + else if (/* UU UU 01 */ p[-2] != 0 || + /* UU 00 01 */ p[-3] != 0) { + p += 3; + } + else { /* 00 00 01 */ p++; + // p now points at the address following the start code value XX break; } } -- 2.32.0 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".