Hi!
David Timms wrote:
>>Not actually necessary.
>
> Agreed, they are only warnings. When compiling, it seems to me to be
> cleaner to not have warnings being output - and people wondering whether
> it is something going wrong. IMHO, in terms of portability it forces the
> compiler to do the evaluation correctly even if a particular compiler's
> operator precedence differed from the compiler that is currently used.
>
> eg: a compiler that interprets:
> buf[5] = (mm<<4) & 0xf0 | (ss>>3) & 0x07 | 0x08;
> as:
> buf[5] = (mm<<4) & (0xf0 | (ss>>3)) & (0x07 | 0x08);
> I have no idea if such a thing exists ;)
A C/C++ compiler that does that is broken.
>>>Index: src/lavfmuxer.cpp
>>>===================================================================
>>>--- src/lavfmuxer.cpp (revision 116)
>>>+++ src/lavfmuxer.cpp (working copy)
>>>@@ -89,7 +89,7 @@
>>> int16_t samples[6*1536]; // must be enough for 6 AC-3 channels --mr
>>> int frame_size=sizeof(samples);
>>> //fprintf(stderr, "** decode audio size=%d\n", sd->inbytes());
>>>- avcodec_decode_audio(s->codec,samples,&frame_size,
>>>+ avcodec_decode_audio2(s->codec,samples,&frame_size,
>>> (uint8_t*) sd->getdata(),sd->inbytes());
>>> avcodec_close(s->codec);
>>> }
>>
>>avcodec_decode_audio2 doesn't exist in the local version of ffmpeg.
>>
>>What's the difference, by the way?
>
> In current ffmpeg {ffmpeg-0.4.9-0.44.20080113.lvn9}, various functions
> have been deprecated {both avcodec_decode_audio and img_copy}.
Fine. Yet another argument for getting rid of this dependency.
> I notice that it was 2005 {according to the source} when ffmpeg was
> taken internally. How much work would it be to rebase the internal one
> to current ffmpeg svn ?
Too much. Convince them to make an official release and/or stick to a
stable API, and I might think about it. But not a nanosecond sooner.
> I might be putting my hand up to do it - based on the customizations the
> internal ffmpeg has to reduce it's size.
How often do you want to perform that task - once every two months?
> Or would you prefer to wait until ffmpeg actually removes that function
> {they don't seem to give a timeframe} ?
I would prefer to not use ffmpeg at all. It's a constant source of
annoyance.
[...]
> So there appears to be some extra checking to make sure that things
> don't go wrong. Since the _2 version isn't in the included ffmpeg, then
> we couldn't directly apply without moving to a newer ffmpeg.
Why didn't they simply add the checks to the existing function instead
of deprecating it and adding a new one with exactly the same prototype?
That's plain stupid.
--
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DVBCUT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user
