Re: [PATCH] Add Win32 check for FFMPEG_FORCE_NOCOLOR

Daniel Verkamp <daniel <at> drv.nu>
2011-01-01 00:26:51 GMT

On Fri, Dec 31, 2010 at 4:39 PM, Ramiro Polla <ramiro.polla <at> gmail.com> wrote:
> Hi Daniel,
>
> On Fri, Dec 31, 2010 at 8:35 PM, Daniel Verkamp <daniel <at> drv.nu> wrote:
>> Currently the Win32 path of libavutil/log.c only checks the NO_COLOR
>> environment variable; a check for the recently-added
>> FFMPEG_FORCE_NOCOLOR is missing.
>>
>> This fixes issue 2461.
>
> Thanks for looking at this.
>
> I think we can use the same logic as for tty, something like this:
> use_color = !getenv("NO_COLOR") && !getenv("FFMPEG_FORCE_NOCOLOR") &&
> (con != INVALID_HANDLE_VALUE || getenv("FFMPEG_FORCE_COLOR"));
>
> (it might even be possible to merge all three use_color ifdefs using this line)
I don't think it makes sense to allow forcing color for Win32, since
the console handle used for SetConsoleTextAttribute() will be invalid
in that case and nothing good can come of that.

Re: [PATCH] fix for roundup issue 2127

Daniel Kang <daniel.d.kang <at> gmail.com>
2011-01-01 00:47:23 GMT

I have added the changes and ran some more tests. It passes "make fate"
on 32/64-bit, with/without --disable-optimizations. The speed is the
exact same as the original. Are there any comments on the updated patch?
On Fri, Dec 31, 2010 at 11:54 AM, Ronald S. Bultje <rsbultje <at> gmail.com>wrote:
> Hi,
>
> On Fri, Dec 31, 2010 at 11:30 AM, Reimar Döffinger
> <Reimar.Doeffinger <at> gmx.de> wrote:
> > On Fri, Dec 31, 2010 at 10:59:01AM -0500, Ronald S. Bultje wrote:
> >> On Fri, Dec 31, 2010 at 10:55 AM, Reimar Döffinger
> >> <Reimar.Doeffinger <at> gmx.de> wrote:
> >> > which I think makes this unacceptable, at least if we still have to
> >> > policy that fast code in as many cases as possible is more important
> >> > that compilation with options that are only useful for debugging.
> >>
> >> The code is faster after his patch; the original code does 6 leas, the
> >> new code uses direct addressing.
> >
> > Well, it still needs gcc to generate the *3 value. By moving that into
> > the asm code (and making the strides inout values) I think it should be
> > possible to make it work with only 4 registers, though it might be
> > slower (instruction scheduling may be a bit problematic there).
>
> Worth testing. .
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list

Re: [PATCH] write AC-3 metadata

Michael Niedermayer <michaelni <at> gmx.at>
2011-01-01 01:52:51 GMT

On Fri, Dec 31, 2010 at 11:53:42AM -0500, Justin Ruggles wrote:
> On 12/31/2010 10:08 AM, Anssi Hannula wrote:
>
> > On 31.12.2010 15:31, Kieran Kunhya wrote:
> >>> clean effects ­ This field indicates that the referenced
> >>> program element has no language.
> >>> hearing impaired ­ This field indicates that the
> >>> referenced program element is prepared for the hearing
> >>> impaired.
> >>> visual_impaired_commentary ­ This field indicates that the
> >>> referenced program element is prepared for the visually
> >>> impaired viewer.
> >>> [...]
> >>
> >> For what it's worth, I've never seen anyone use anything other
> >> than "undefined" for that field in MPEG-2 systems. Visual Impaired
> >> commentary uses the country code "NAR" over here in the UK.
> >
> > Here in Finland visual impaired commentary is marked correctly using
> > that field (additionally it has the country code "hun").
>
> Well, since this is both codec-level and container-level information,
> there are limited options to support it.
>
> 1) a new field in AVCodecContext called audio_service_type
> - define FF_AUDIO_SERVICE_TYPE_AC3_COMPLETE_MAIN, etc...
> - define FF_AUDIO_SERVICE_TYPE_MPEG2LANG_CLEAN_EFFECTS, etc...
values have to bethe same between ac3 and mpeg2 for this to work

Re: [PATCH] write AC-3 metadata

Anssi Hannula <anssi.hannula <at> iki.fi>
2011-01-01 02:54:40 GMT

On 31.12.2010 18:53, Justin Ruggles wrote:
> On 12/31/2010 10:08 AM, Anssi Hannula wrote:
>
>> On 31.12.2010 15:31, Kieran Kunhya wrote:
>>>> clean effects ­ This field indicates that the referenced
>>>> program element has no language.
>>>> hearing impaired ­ This field indicates that the
>>>> referenced program element is prepared for the hearing
>>>> impaired.
>>>> visual_impaired_commentary ­ This field indicates that the
>>>> referenced program element is prepared for the visually
>>>> impaired viewer.
>>>> [...]
>>>
>>> For what it's worth, I've never seen anyone use anything other
>>> than "undefined" for that field in MPEG-2 systems. Visual Impaired
>>> commentary uses the country code "NAR" over here in the UK.
>>
>> Here in Finland visual impaired commentary is marked correctly using
>> that field (additionally it has the country code "hun").
>
> Well, since this is both codec-level and container-level information,
> there are limited options to support it.
>
> 1) a new field in AVCodecContext called audio_service_type
> - define FF_AUDIO_SERVICE_TYPE_AC3_COMPLETE_MAIN, etc...
> - define FF_AUDIO_SERVICE_TYPE_MPEG2LANG_CLEAN_EFFECTS, etc...
> - set the values in demuxers/decoders/muxers/encoders
> - I don't know if this would copy over when transcoding though
>

[PATCH 06/10 rev2] spdifenc: fix byte order on big-endian systems

Anssi Hannula <anssi.hannula <at> iki.fi>
2011-01-01 05:38:57 GMT

The preamble and final odd byte were outputted in the wrong byte order
on big-endian systems.
---
I'm wondering if this patch would be a better choice. All our audio
decoders output native-endian samples. As this muxer is usually used in
place of an encoder, it would be logical for it to have its output in
native-endian as well.
However, this would cause (AFAIK) the muxer to be the only one that has
different output depending on system endianness.. Don't know if that is
very big an issue, though.
Also, it looks like big-endian systems may have audio devices that take
little-endian format, thus requiring the byteswap anyway; though that'd
need to be done for regular audio decoding as well and we don't provide
any switches there either.
Please comment.
(BTW, technically this is a big-endian format by nature, and it is only
byteswapped in order to output it to audio devices/applications that
expect S16LE input; but I think it is too late to change our muxer to be
fixed big-endian (avoiding byte-swaps) at this point, and it would
indeed complicate its use on little-endian systems)
libavformat/spdifenc.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c