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

[Baptiste Coudurier]

Robert Swain wrote:
> 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. :)
> 

And like Michael said, strings are even easier ...
Stop joking guys, we are talking about fixing issue here, please.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA