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

Måns Rullgård mans
Fri Sep 26 01:35:24 CEST 2008

Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:

> 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.
> 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.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list