[FFmpeg-devel] regression - mpeg2 interlace/topfield flags not set anymore

Robert Swain robert.swain
Fri Sep 26 01:58:11 CEST 2008


On 26 Sep 2008, at 00:35, M?ns Rullg?rd wrote:
> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
>> Michael Niedermayer wrote:
>>> On Mon, Jan 28, 2008 at 12:07:53PM +0100, christophelorenz wrote:
>>>> Rich Felker wrote:
>>>>> On Mon, Jan 28, 2008 at 10:33:14AM +0100, christophelorenz wrote:
>>>>>> Rich Felker wrote:
>>>>>>> No, it breaks things on CORRECT platforms for the sake of  
>>>>>>> working
>>>>>>>
>>>>>>> around a bug on BROKEN platforms. This is unacceptable.

>>>>>> If tomorrow someone writes a piece of code that follows C99
>>>>>> standard and works ok on xxx but fails under linux, what will
>>>>>> happen ?
>>>>>> After that will come C102, C150, C200 and all will be different
>>>>>> again and broken again.
>>>>>>
>>>>>> We live in a world full of unacceptable things (more important
>>>>>> than a computer standards), however if you want to move on, you
>>>>>> have to make compromises.
>>>>>>
>>>>>> I can hardly believe it is the first time ff contains a
>>>>>> workaround for some faulty implementation.
>>>>>> Unless you're coding hello world, I can safely say that all libs
>>>>>> on all platforms are broken somewhere. Just that some are less
>>>>>> than others....

>>>>> Your rant is misplaced. I never in this thread said you can't work
>>>>> around broken platforms, just that you cannot cause regressions on
>>>>> valid platforms in the process. The traditional development  
>>>>> model of
>>>>> special-casing every known broken platform and failing to  
>>>>> support a
>>>>> not-already-known but fully-standards-conformant platform at all  
>>>>> needs
>>>>> to DIE.
>>>>>
>>>>> I still think this issue should be addressed with libbrokenos.  
>>>>> But I
>>>>> won't object to any workarounds that do not bloat or break working
>>>>> systems. (Including our own implementation of strtod in ffmpeg  
>>>>> would
>>>>> be bloat; using strtol whenever "0x" is seen would be breaking
>>>>> functionality, namely the ability to provide bit-exact floats.)

>>>> You're right. Sorry about this.
>>>> And I will definitely report this problem to the mingw project.
>>>>
>>>> But the background problem stays...
>>>> If we can't change the model because other than hex is
>>>> unacceptable, if we can't re-implement strtod, workaround the 0x
>>>> interger parsing etc...
>>>> I now wonder how we can get around this.

>>> you can get around this by having av_get_string() return a series of
>>> named flags like "trell+cbp+mv0", this also would be more readable
>>> to humans than 0x00040201
>>
>> Any reason for printing flags values as hex instead of decimal ?
>> Code is from r4581.
>> Attached patch fixes the issue it seems.
>>
>> Index: libavcodec/opt.c
>> ===================================================================
>> --- libavcodec/opt.c	(revision 15417)
>> +++ libavcodec/opt.c	(working copy)
>> @@ -239,7 +239,7 @@
>>     if(o_out) *o_out= o;
>>
>>     switch(o->type){
>> -    case FF_OPT_TYPE_FLAGS:     snprintf(buf, buf_len, "0x 
>> %08X",*(int    *)dst);break;
>> +    case FF_OPT_TYPE_FLAGS:     snprintf(buf, buf_len,  
>> "%d",*(int    *)dst);break;
>
> What?  Hex is much easier to read than decimal.

I agree, decimal isn't fun to read for flags, hex is much easier.  
Binary may be better still. :)

Rob



More information about the ffmpeg-devel mailing list