[FFmpeg-devel] [PATCH 1/2] avcodec/parser: simplify ff_mpeg4video_split()

[zhaoxiu.zeng]

在 2015/2/13 17:22, wm4 写道:
> On Fri, 13 Feb 2015 13:50:23 +0800
> Zhaoxiu Zeng <zhaoxiu.zeng at gmail.com> wrote:
> 
>> From 3cac16572aee4425377e4bc9e496ab5844200a51 Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu <zhaoxiu.zeng at gmail.com>
>> Date: Fri, 13 Feb 2015 13:27:26 +0800
>> Subject: [PATCH 1/2] avcodec/parser: simplify ff_mpeg4video_split()
>>
>> Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng at gmail.com>
>> ---
>>  libavcodec/parser.c | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
>> index aa25481..83019e7 100644
>> --- a/libavcodec/parser.c
>> +++ b/libavcodec/parser.c
>> @@ -28,6 +28,7 @@
>>  #include "libavutil/mem.h"
>>
>>  #include "parser.h"
>> +#include "internal.h"
>>
>>  static AVCodecParser *av_first_parser = NULL;
>>
>> @@ -308,13 +309,14 @@ void ff_parse_close(AVCodecParserContext *s)
>>
>>  int ff_mpeg4video_split(AVCodecContext *avctx, const uint8_t *buf,
>> int buf_size)
>>  {
>> -    int i;
>>      uint32_t state = -1;
>> +    const uint8_t *ptr = buf, *end = buf + buf_size;
>>
>> -    for (i = 0; i < buf_size; i++) {
>> -        state = state << 8 | buf[i];
>> +    while (ptr < end) {
>> +        ptr = avpriv_find_start_code(ptr, end, &state);
>>          if (state == 0x1B3 || state == 0x1B6)
>> -            return i - 3;
>> +            return ptr - 4 - buf;
>>      }
>> +
>>      return 0;
>>  }
> 
> I don't know, it looks more complicated to me now. Following track of
> an integer index is much easier than playing with pointer arithmetics.
> Also, why this (apparently) can return a negative integer index just
> fine, your pointer calculations can go out of the range [buf,
> buf+buf_size], possibly leading to undefined behavior. The code

No problem. In this case, if state is 0x000001xx ptr must behind "buf + 4",
else ptr equal to end.

> introduces a function call, without actually reducing the number of
> lines.

avpriv_find_start_code is faster than the byte-by-byte version!
Also, we would optimize avpriv_find_start_code in the future.

> 
> Well, I know nothing about this code, so you don't need to listen to
> me. These are just my impressions.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>