[FFmpeg-cvslog] r19196 - trunk/ffmpeg.c

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Tue, Jun 16, 2009 at 02:05:56PM -0700, Baptiste Coudurier wrote:
>> Hi Michael,
>>
>> On 6/16/2009 1:15 PM, Michael Niedermayer wrote:
>>> On Mon, Jun 15, 2009 at 01:55:25AM +0200, bcoudurier wrote:
>>>> Author: bcoudurier
>>>> Date: Mon Jun 15 01:55:25 2009
>>>> New Revision: 19196
>>>>
>>>> Log:
>>>> do not use av_parser_change for h264 which uses bitstream filter, fix #1027
>>>>
>>>> Modified:
>>>>    trunk/ffmpeg.c
>>>>
>>>> Modified: trunk/ffmpeg.c
>>>> ==============================================================================
>>>> --- trunk/ffmpeg.c	Mon Jun 15 01:14:56 2009	(r19195)
>>>> +++ trunk/ffmpeg.c	Mon Jun 15 01:55:25 2009	(r19196)
>>>> @@ -1407,8 +1407,13 @@ static int output_packet(AVInputStream *
>>>>                          opkt.flags= pkt->flags;
>>>>  
>>>>                          //FIXME remove the following 2 lines they shall be replaced by the bitstream filters
>>>> +                        if(ost->st->codec->codec_id != CODEC_ID_H264) {
>>>>                          if(av_parser_change(ist->st->parser, ost->st->codec, &opkt.data, &opkt.size, data_buf, data_size, pkt->flags & PKT_FLAG_KEY))
>>>>                              opkt.destruct= av_destruct_packet;
>>>> +                        } else {
>>>> +                            opkt.data = data_buf;
>>>> +                            opkt.size = data_size;
>>>> +                        }
>>>>  
>>> did i approve this ?
>> Are you against ?
> 
> yes, the correct fix probably would be to improve the AVParser split API
> short of that a check for mov vs raw h264 in the h264 split would also do
> this one really is buggy, as its a workaround in one application,
> is ffmpeg.c the only app using av_parser_change(), i doubt it

I think it is the only application using it considering how obscure it
is. Feel free to revert it and reopen the bug in roundup. I've no
interest in fixing parser_split which is obsoleted by bitstream filters.

> that is, if i guessed correctly which bug this is supposed to fix ...

parser_change is called unconditionnaly that's wrong in any case.
The check is up to you, I see no problem with checking against codec id.

>> Relax a bit :)
> 
> iam very relaxed watching you sit in a pot with water that is standing
> on a big pile of wood ;)

Sorry I don't get this one.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org