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

[Baptiste Coudurier]

Hi,

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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opt_hex.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080925/aba670b3/attachment.txt>