Re: [PATCH] Add Win32 check for FFMPEG_FORCE_NOCOLOR

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: libx264.c:encode_nals can overwrite buffers

On 31/12/10 23:40, Paul Flinders wrote:
> Oh **** - too tired! ignore 2nd patch for now
>

I really shouldn't try to write code on New Year's Eve!! - Happy new 
year BTW 

Revised patch attached - calculates the required space and, if 
insufficient, returns without copying data. This allows the caller of 
avcodec_encode_video to dynamically adjust the buffer size (at the cost 
of re-encoding the frame) if the initial allocation was too small.

Thoughts?

--- libavcodec/libx264.c~	2010-12-26 16:32:46.000000000 +0000
+++ libavcodec/libx264.c	2010-12-31 23:14:43.000000000 +0000
 <at>  <at>  -56,7 +56,22  <at>  <at> 
 {
     X264Context *x4 = ctx->priv_data;
     uint8_t *p = buf;
-    int i;
+    int i, reqd = 0;
+
+    /* Calc & check required buffer size */
+    if (x4->sei_size > 0 && nnal > 0) {
+        reqd = x4->sei_size;
+    }
+    for (i = 0; i < nnal; i++){

Re: [PATCH] fix for roundup issue 2127

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] movie video source

On Fri, Dec 31, 2010 at 04:35:30PM +0100, Stefano Sabatini wrote:
> On date Thursday 2010-12-30 01:03:38 +0100, Michael Niedermayer encoded:
> > On Tue, Dec 28, 2010 at 02:42:33PM +0100, Stefano Sabatini wrote:
[...]
> > > +        // Is this a packet from the video stream?
> > > +        if (packet.stream_index == movie->stream_idx) {
> > > +            // Decode video frame
> > > +            avcodec_decode_video2(movie->codec_ctx, movie->frame, &frame_finished, &packet);
> > > +
> > > +            // Did we get a video frame?
> > > +            if (frame_finished) {
> > > +                movie->picref =
> > > +                    avfilter_get_video_buffer_ref_from_arrays(movie->frame->data, movie->frame->linesize,
> > > +                                                              AV_PERM_READ,
> > > +                                                              outlink->format, outlink->w, outlink->h);
>  
> > > +                movie->picref->pts = packet.pts;
> > 
> > this is wrong
> > 
> > 
> > > +                movie->picref->pos = packet.pos;
> > 
> > so is this
> 
> wtf why?

see your favorit video player or reordered_opaque

[...]

Re: [PATCH] write AC-3 metadata

On Fri, Dec 31, 2010 at 11:57:59AM -0500, Justin Ruggles wrote:
> On 12/30/2010 09:46 PM, Michael Niedermayer wrote:
> 
> > On Wed, Dec 29, 2010 at 05:20:36PM -0500, Justin Ruggles wrote:
> >> Hi,
> >>
> >> On 12/25/2010 03:05 PM, Michael Niedermayer wrote:
> >>
> >>> On Wed, Dec 22, 2010 at 01:26:13PM -0500, Justin Ruggles wrote:
> 
> 
> >>>> +    {"0", "+3.0 dB (1.414)",           0, FF_OPT_TYPE_CONST, 0, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"1", "+1.5 dB (1.189)",           0, FF_OPT_TYPE_CONST, 1, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"2", "+0.0 dB (1.000)",           0, FF_OPT_TYPE_CONST, 2, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"3", "-1.5 dB (0.841)",           0, FF_OPT_TYPE_CONST, 3, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"4", "-3.0 dB (0.707)",           0, FF_OPT_TYPE_CONST, 4, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"5", "-4.5 dB (0.595) (default)", 0, FF_OPT_TYPE_CONST, 5, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"6", "-6.0 dB (0.500)",           0, FF_OPT_TYPE_CONST, 6, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +    {"7", "-inf dB (0.000)",           0, FF_OPT_TYPE_CONST, 7, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtcmixlev"},
> >>>> +{"ltrtsurmixlev", "Lt/Rt Surround Mix Level", offsetof(AC3EncodeContext,
options.lt_rt_surround_mix_level), FF_OPT_TYPE_INT, -1, -1, 7, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +    {"3", "-1.5 dB (0.841)",           0, FF_OPT_TYPE_CONST, 3, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +    {"4", "-3.0 dB (0.707)",           0, FF_OPT_TYPE_CONST, 4, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +    {"5", "-4.5 dB (0.595)",           0, FF_OPT_TYPE_CONST, 5, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +    {"6", "-6.0 dB (0.500) (default)", 0, FF_OPT_TYPE_CONST, 6, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +    {"7", "-inf dB (0.000)",           0, FF_OPT_TYPE_CONST, 7, INT_MIN, INT_MAX, AC3ENC_PARAM, "ltrtsurmixlev"},
> >>>> +{"lorocmixlev", "Lo/Ro Center Mix Level", offsetof(AC3EncodeContext,
options.lo_ro_center_mix_level), FF_OPT_TYPE_INT, -1, -1, 7, AC3ENC_PARAM, "lorocmixlev"},
> >>>> +    {"0", "+3.0 dB (1.414)",           0, FF_OPT_TYPE_CONST, 0, INT_MIN, INT_MAX, AC3ENC_PARAM, "lorocmixlev"},
> >>>> +    {"1", "+1.5 dB (1.189)",           0, FF_OPT_TYPE_CONST, 1, INT_MIN, INT_MAX, AC3ENC_PARAM, "lorocmixlev"},

Re: [PATCH] write AC-3 metadata

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

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
> 

Re: [PATCH] dca: export profile information on decode

On Fri, Dec 31, 2010 at 07:26:33AM +0200, Anssi Hannula wrote:
> On 31.12.2010 06:21, Michael Niedermayer wrote:
> > On Wed, Dec 29, 2010 at 07:24:09AM +0200, Anssi Hannula wrote:
> >> ---
> >>
> >> While waiting for that another opinion, here's another take on the
> >> patch, this time with a more noticiable separation of the HD parser.
> [...]
> >> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> index c803ec6..8833849 100644
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >>  <at>  <at>  -32,7 +32,7  <at>  <at> 
> >>  #include "libavutil/cpu.h"
> >>  
> >>  #define LIBAVCODEC_VERSION_MAJOR 52
> >> -#define LIBAVCODEC_VERSION_MINOR 101
> >> +#define LIBAVCODEC_VERSION_MINOR 102
> >>  #define LIBAVCODEC_VERSION_MICRO  0
> >>  
> >>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> >>  <at>  <at>  -2238,6 +2238,12  <at>  <at>  typedef struct AVCodecContext {
> >>  #define FF_PROFILE_AAC_SSR  2
> >>  #define FF_PROFILE_AAC_LTP  3
> >>  
> >> +#define FF_PROFILE_DTS         20
> >> +#define FF_PROFILE_DTS_ES      30
> >> +#define FF_PROFILE_DTS_96_24   40
> >> +#define FF_PROFILE_DTS_HD_HRA  50
> >> +#define FF_PROFILE_DTS_HD_MA   60

Re: [PATCH 1/2] lavf: add AVOption support for muxers

On 29.12.2010 14:19, Stefano Sabatini wrote:
> On date Wednesday 2010-12-29 13:58:00 +0200, Anssi Hannula encoded:
>> On 29.12.2010 13:40, Stefano Sabatini wrote:
>>> On date Wednesday 2010-12-29 06:54:14 +0200, Anssi Hannula encoded:
>>>> ---
>>>>  libavformat/avformat.h |    2 ++
>>>>  libavformat/utils.c    |    4 ++++
>>>>  2 files changed, 6 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>> index c6f2827..9eab2da 100644
>>>> --- a/libavformat/avformat.h
>>>> +++ b/libavformat/avformat.h
>>>>  <at>  <at>  -368,6 +368,8  <at>  <at>  typedef struct AVOutputFormat {
>>>>      const AVMetadataConv *metadata_conv;
>>>>  #endif
>>>>  
>>>> +    const AVClass *priv_class; ///< AVClass for the private context
>>>> +
>>>>      /* private fields */
>>>>      struct AVOutputFormat *next;
>>>>  } AVOutputFormat;
>>>
>>> Put this after the "next" field or it will break ABI (note for the
>>> committer: bump minor).
>>
>> Well, I thought the /* private fields */ meant that the lavf internal
>> variables are last so that they can be added/removed/modified at will
>> without breaking ABI, which only works if they indeed are the last ones.
>>

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

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