Re: [libav-devel] [PATCH 5/6] stereo3d: Add API to retrieve the name of the stereo type

[Tim W.]

On Thu, Apr 7, 2016 at 8:44 PM, Vittorio Giovara <vittorio.giov...@gmail.com
> wrote:

> On Thu, Apr 7, 2016 at 1:09 PM, Tim W. <tdskywal...@gmail.com> wrote:
> > On Wed, Apr 6, 2016 at 4:40 PM, Vittorio Giovara <
> vittorio.giov...@gmail.com
> >> wrote:
> >
> >> On Tue, Apr 5, 2016 at 11:04 PM, Tim W. <tdskywal...@gmail.com> wrote:
> >> > On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
> >> > vittorio.giov...@gmail.com> wrote:
> >> >
> >> >> Use it in av_dump_format() instead of a huge switch case. Needed in
> >> >> the next commit as well.
> >> >> ---
> >> >>  libavformat/dump.c   | 33 +
> >> >>  libavutil/stereo3d.c | 11 +++
> >> >>  libavutil/stereo3d.h | 14 ++
> >> >>  libavutil/version.h  |  2 +-
> >> >>  4 files changed, 31 insertions(+), 29 deletions(-)
> >> >>
> >> >> diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
> >> >> index 2dcfddf..c8346aa 100644
> >> >> --- a/libavutil/stereo3d.c
> >> >> +++ b/libavutil/stereo3d.c
> >> >> @@ -41,3 +41,14 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame
> >> *frame)
> >> >>
> >> >>  return (AVStereo3D *)side_data->data;
> >> >>  }
> >> >> +
> >> >> +static const char *stereo3d_type_names[AV_STEREO3D_NB] = {
> >> >> +"2D", "side by side", "top and bottom", "frame alternate",
> >> >> +"checkerboard", "interleaved lines", "interleaved columns",
> >> >> +"side by side (quincunx subsampling)",
> >> >> +};
> >> >
> >> >
> >> > Yuck… yuck yuck yuck.
> >> >
> >> > May I suggest libavutil/channel_layout.c as a much prettier (and IMO
> >> > better) example?
> >>
> >> You may if you explain why it's better.
> >>
> >
> > In retrospect, I must have been in a bad mood because of tiredness.
> >
> > Here goes: IMO, one line per name is much more readable. The names
> > themselves are fine, AFAICT.
> >
> >
> >> Also note that this is the same style of lavu/pix_desc names too.
> >>
> >
> > Actually, av_pix_fmt_descriptors seems to have more than one line per
> > pix_fmt ;)
>
> I wrote pix_desc not pix_fmt, check out the current style:
> https://github.com/libav/libav/blob/master/libavutil/pixdesc.c#L1598-L1624


To be fair it's the same file, and the pix_fmt descriptors take up 1460
lines, as opposed to those 6 you mentioned and which I missed. Also, it
wasn't immediately obvious that you meant color characteristics by
"pix_desc", I just looked at the file with that name.

I prefer one line per name (more readable, and since we're talking about
enums, you can associate a value with a name by just counting lines, as
opposed to counting items on lines with a variable name count).

Still, I'm not quite as disgusted as I seemed to be the other day so I
guess that part's up to you :)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/6] stereo3d: Add API to retrieve the name of the stereo type

[Tim W.]

On Wed, Apr 6, 2016 at 4:40 PM, Vittorio Giovara <vittorio.giov...@gmail.com
> wrote:

> On Tue, Apr 5, 2016 at 11:04 PM, Tim W. <tdskywal...@gmail.com> wrote:
> > On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
> > vittorio.giov...@gmail.com> wrote:
> >
> >> Use it in av_dump_format() instead of a huge switch case. Needed in
> >> the next commit as well.
> >> ---
> >>  libavformat/dump.c   | 33 +
> >>  libavutil/stereo3d.c | 11 +++
> >>  libavutil/stereo3d.h | 14 ++
> >>  libavutil/version.h  |  2 +-
> >>  4 files changed, 31 insertions(+), 29 deletions(-)
> >>
> >> diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
> >> index 2dcfddf..c8346aa 100644
> >> --- a/libavutil/stereo3d.c
> >> +++ b/libavutil/stereo3d.c
> >> @@ -41,3 +41,14 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame
> *frame)
> >>
> >>  return (AVStereo3D *)side_data->data;
> >>  }
> >> +
> >> +static const char *stereo3d_type_names[AV_STEREO3D_NB] = {
> >> +"2D", "side by side", "top and bottom", "frame alternate",
> >> +"checkerboard", "interleaved lines", "interleaved columns",
> >> +"side by side (quincunx subsampling)",
> >> +};
> >
> >
> > Yuck… yuck yuck yuck.
> >
> > May I suggest libavutil/channel_layout.c as a much prettier (and IMO
> > better) example?
>
> You may if you explain why it's better.
>

In retrospect, I must have been in a bad mood because of tiredness.

Here goes: IMO, one line per name is much more readable. The names
themselves are fine, AFAICT.


> Also note that this is the same style of lavu/pix_desc names too.
>

Actually, av_pix_fmt_descriptors seems to have more than one line per
pix_fmt ;)

I agree with Anton that FF_ARRAY_ELEMS should work. Introducing AV_STEREO3D_NB
seems outside the scope of such a patch.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] build: miscellaneous cosmetics

[Tim W.]

On Thu, Apr 7, 2016 at 3:16 PM, Diego Biurrun  wrote:

> On Tue, Apr 05, 2016 at 02:28:42PM +0200, Vittorio Giovara wrote:
> >
> > IMHO this looks much worse than before
>
> This is the only long list in the build system that is not broken across
> multiple lines.  It's more readable this way, especially the diffs if
> you make changes.


Agreed.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libxvid: Create extradata in init using a dummy frame

[Tim W.]

On Tue, Apr 5, 2016 at 5:21 PM, Derek Buitenhuis  wrote:

> Modifying global header extradata in encode_frame is an API violation
> and only happens to work currently because mov writes its header
> at the end of the file.
>
> Heavily based off of a patch from 2012 by Nicolas George.
>
> Signed-off-by: Derek Buitenhuis 
> ---
> Fixes encoding xvid to mov.
> ---
>  libavcodec/libxvid.c | 41 +
>  1 file changed, 41 insertions(+)


LGTM except cosmetics already mentioned by Luca.

It is ugly, but AFAICT that's libxvid's fault; other solution I can imagine
would be to create fake extradata like Anton did for QSV/HEVC/VPS, which is
a lot more work for little benefit.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 6/6] avprobe: Print stereo3d information

[Tim W.]

On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> ---
>  avprobe.c | 11 +++
>  1 file changed, 11 insertions(+)


LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/6] stereo3d: Add API to retrieve the name of the stereo type

[Tim W.]

On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> Use it in av_dump_format() instead of a huge switch case. Needed in
> the next commit as well.
> ---
>  libavformat/dump.c   | 33 +
>  libavutil/stereo3d.c | 11 +++
>  libavutil/stereo3d.h | 14 ++
>  libavutil/version.h  |  2 +-
>  4 files changed, 31 insertions(+), 29 deletions(-)
>
> diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
> index 2dcfddf..c8346aa 100644
> --- a/libavutil/stereo3d.c
> +++ b/libavutil/stereo3d.c
> @@ -41,3 +41,14 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame)
>
>  return (AVStereo3D *)side_data->data;
>  }
> +
> +static const char *stereo3d_type_names[AV_STEREO3D_NB] = {
> +"2D", "side by side", "top and bottom", "frame alternate",
> +"checkerboard", "interleaved lines", "interleaved columns",
> +"side by side (quincunx subsampling)",
> +};


Yuck… yuck yuck yuck.

May I suggest libavutil/channel_layout.c as a much prettier (and IMO
better) example?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/6] mov: Parse uuid box and detect spherical videos

[Tim W.]

On Wed, Apr 6, 2016 at 12:00 AM, Luca Barbato  wrote:

> those magic numbers might enjoy being constants.
>

Yes please.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/6] stereo3d: Add flag to identify equirectangural spherical videos

[Tim W.]

On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> ---
> The alternative would be to store everything in metadata (like matroska
> does
> already).
> Vittorio
>
>  libavformat/dump.c   | 3 +++
>  libavutil/stereo3d.h | 5 +
>  libavutil/version.h  | 2 +-
>  3 files changed, 9 insertions(+), 1 deletion(-)


No idea, sorry.

Could you maybe elaborate of what  "spherical equi-rectangular" 3D means?

Also, is it a good idea to implement support for it while the spec. seems
like it wasn't finalized yet?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/6] x264: Forbid inverted Stereo3D mode

[Tim W.]

On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> ---
>  libavcodec/libx264.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 84678cb..6fe2aca 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -219,6 +219,10 @@ static void reconfig_encoder(AVCodecContext *ctx,
> const AVFrame *frame)
>  break;
>  }
>
> +/* Inverted mode is not supported by x264 */
> +if (stereo->flags & AV_STEREO3D_FLAG_INVERT)
> +fpa_type = -1;
>

Nit: if  (stereo->flags & AV_STEREO3D_FLAG_INVERT) { foo } else switch
(stereo->type)?

Intent LGTM though.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/6] x264: Allow Stereo3D monoscopic value

[Tim W.]

On Tue, Apr 5, 2016 at 10:19 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> ---
>  libavcodec/libx264.c | 5 +
>  1 file changed, 5 insertions(+)


OK, I guess. This the only check against X264_BUILD in all of libav, except
in configure, though.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] build: Group declarations for hw-accelerated de-/encoding separately

[Tim W.]

On Tue, Apr 5, 2016 at 11:43 AM, Diego Biurrun  wrote:

> ---
>
> This would be simpler and more logical if these codecs had different
> AVCodec declarations from the purely software ones...
>
>  configure   | 86
> +++--
>  libavcodec/Makefile | 33 ++--
>  2 files changed, 69 insertions(+), 50 deletions(-)


LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 12/12] h264_parser: remove the remaining dependencies on the h264 decoder

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> ---
>  configure|  2 +-
>  libavcodec/Makefile  |  3 +-
>  libavcodec/h264.c| 27 -
>  libavcodec/h264.h|  5 ---
>  libavcodec/h264_parse.c  | 27 +
>  libavcodec/h264_parse.h  |  5 +++
>  libavcodec/h264_parser.c | 98
> ++--
>  7 files changed, 71 insertions(+), 96 deletions(-)
>
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index 55170f8..6d21632 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -485,21 +477,12 @@ static int h264_parse(AVCodecParserContext *s,
>const uint8_t *buf, int buf_size)
>  {
>  H264ParseContext *p = s->priv_data;
> -H264Context  *h = >h;
>  ParseContext *pc = >pc;
>  int next;
>
>  if (!p->got_first) {
>  p->got_first = 1;
>  if (avctx->extradata_size) {
> -h->avctx = avctx;
> -// must be done like in the decoder.
> -// otherwise opening the parser, creating extradata,
> -// and then closing and opening again
> -// will cause has_b_frames to be always set.
> -// NB: estimate_timings_from_pts behaves exactly like this.
> -if (!avctx->has_b_frames)
> -h->low_delay = 1;


I gather this is no longer required, but an explanation as to why would be
welcome.

Rest LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 11/12] h264_parser: do not call ff_h264_decode_extradata()

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> Just call parse_nal_units() instead. The only major differences are that
> ff_h264_decode_extradata() handles the mp4-style extradata (which the
> parser does not support anyway) and calls the full decoder parsing code
> (which should not be necessary in the parser).
> ---
>  libavcodec/h264.c| 4 ++--
>  libavcodec/h264.h| 1 -
>  libavcodec/h264_parser.c | 2 +-
>  3 files changed, 3 insertions(+), 4 deletions(-)


OK, I guess (not familiar enough with the code to give a more definitive
opinion).

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 10/12] h264: decouple h264_sei from the h264 decoder

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> Make the SEI parsing independent of the H264Context, to allow
> decoupling the parser from the decoder.
> ---
>  libavcodec/h264.c|  74 ++---
>  libavcodec/h264.h| 103 +-
>  libavcodec/h264_direct.c |   4 +-
>  libavcodec/h264_parser.c |  22 ++--
>  libavcodec/h264_sei.c| 266
> ---
>  libavcodec/h264_sei.h| 137 
>  libavcodec/h264_slice.c  |   2 +-
>  7 files changed, 333 insertions(+), 275 deletions(-)
>  create mode 100644 libavcodec/h264_sei.h
>

OK with minor nits:


>
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index e415103..060feb9 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
> @@ -602,16 +602,17 @@ static void decode_postinit(H264Context *h, int
> setup_finished)
>  }
>  }
>
> -if (h->sei_frame_packing_present &&
> -h->frame_packing_arrangement_type >= 0 &&
> -h->frame_packing_arrangement_type <= 6 &&
> -h->content_interpretation_type > 0 &&
> -h->content_interpretation_type < 3) {
> +if (h->sei.frame_packing.present &&
> +h->sei.frame_packing.arrangement_type >= 0 &&
> +h->sei.frame_packing.arrangement_type <= 6 &&
> +h->sei.frame_packing.content_interpretation_type > 0 &&
> +h->sei.frame_packing.content_interpretation_type < 3) {
> +H264SEIFramePacking *fp = >sei.frame_packing;
>

Minor nit: given the number of times h is dereferenced here, you might as
well declare fp before the if checks.


> @@ -638,13 +639,16 @@ static void decode_postinit(H264Context *h, int
> setup_finished)
>  break;
>  }
>
> -if (h->content_interpretation_type == 2)
> +if (fp->content_interpretation_type == 2)
>  stereo->flags = AV_STEREO3D_FLAG_INVERT;
>  }
>
> -if (h->sei_display_orientation_present &&
> -(h->sei_anticlockwise_rotation || h->sei_hflip || h->sei_vflip)) {
> -double angle = h->sei_anticlockwise_rotation * 360 / (double) (1
> << 16);
> +if (h->sei.display_orientation.present &&
> +(h->sei.display_orientation.anticlockwise_rotation ||
> + h->sei.display_orientation.hflip ||
> + h->sei.display_orientation.vflip)) {
> +H264SEIDisplayOrientation *o = >sei.display_orientation;
>

Ditto.


> @@ -831,7 +836,7 @@ void ff_h264_flush_change(H264Context *h)
>  if (h->cur_pic_ptr)
>  h->cur_pic_ptr->reference = 0;
>  h->first_field = 0;
> -ff_h264_reset_sei(h);
> +ff_h264_sei_uninit(>sei);
>

This is more of a question, is there any rule somewhere as to why one would
pick foo_reset vs. foo_uninit?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 09/12] h264: factor out calculating the POC count into a separate file

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> This will allow decoupling the parser from the decoder.
> ---
>  libavcodec/dxva2_h264.c   |  2 +-
>  libavcodec/h264.c | 93
> ---
>  libavcodec/h264.h | 13 +--
>  libavcodec/h264_parse.c   | 80 
>  libavcodec/h264_parse.h   | 17 +
>  libavcodec/h264_parser.c  | 34 +
>  libavcodec/h264_picture.c |  8 ++--
>  libavcodec/h264_refs.c|  2 +-
>  libavcodec/h264_slice.c   | 61 ---
>  libavcodec/vaapi_h264.c   |  2 +-
>  libavcodec/vdpau_h264.c   |  2 +-
>  11 files changed, 162 insertions(+), 152 deletions(-)


LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 08/12] h264_parser: move the H264DSPContext to the parser context

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> ---
>  libavcodec/h264_parser.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)


LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 07/12] h264: decouple h264_ps from the h264 decoder

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> Make the SPS/PPS parsing independent of the H264Context, to allow
> decoupling the parser from the decoder. The change is modelled after the
> one done earlier for HEVC.
>
> Move the dequant buffers to the PPS to avoid complex checks whether they
> changed and an expensive copy for frame threads.
> ---
>  libavcodec/dxva2_h264.c   |  80 +++
>  libavcodec/h264.c |  69 +++
>  libavcodec/h264.h |  48 +++--
>  libavcodec/h264_cabac.c   |  25 +--
>  libavcodec/h264_cavlc.c   |  22 +-
>  libavcodec/h264_direct.c  |   6 +-
>  libavcodec/h264_loopfilter.c  |   8 +-
>  libavcodec/h264_mb.c  |   8 +-
>  libavcodec/h264_mb_template.c |  20 +-
>  libavcodec/h264_mvpred.h  |   2 +-
>  libavcodec/h264_parser.c  |  73 ---
>  libavcodec/h264_ps.c  | 470
> ++
>  libavcodec/h264_refs.c|   8 +-
>  libavcodec/h264_sei.c |  23 ++-
>  libavcodec/h264_slice.c   | 325 +++--
>  libavcodec/vaapi_h264.c   |  66 +++---
>  libavcodec/vdpau_h264.c   |  54 ++---
>  17 files changed, 677 insertions(+), 630 deletions(-)


LGTM. Big patch though.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 06/12] h264_parser: eliminate H264SliceContext usage

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> It is no longer needed for anything.
> ---
>  libavcodec/h264_parser.c | 66
> +++-
>  1 file changed, 32 insertions(+), 34 deletions(-)


Fine by me. Unlike Luca, I can't "hear" code though :)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 04/12] h264: factor out parsing the reference count into a separate file

[Tim W.]

On Tue, Apr 5, 2016 at 10:07 AM, Diego Biurrun  wrote:

> On Mon, Apr 04, 2016 at 08:35:46PM +0200, Anton Khirnov wrote:
> > This will allow decoupling the parser from the decoder.
> > ---
> >  libavcodec/h264.c| 47
> ---
> >  libavcodec/h264.h|  1 -
> >  libavcodec/h264_parse.c  | 46
> ++
> >  libavcodec/h264_parse.h  |  5 +
> >  libavcodec/h264_parser.c | 10 ++
> >  libavcodec/h264_slice.c  |  4 +++-
> >  6 files changed, 60 insertions(+), 53 deletions(-)
>
> I still don't understand why we had to introduce h264_parse.[ch] next to
> h264_parser.[ch] unless the goal was to maximize confusion.


I have to agree with this.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/12] h264: stop testing whether the reference count change in ff_set_ref_count()

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> It is no longer necessary after 741b494fa8cd28a7d096349bac183893c236e3f9
> ---
>  libavcodec/h264.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)


LGTM, but please do fix the typo before pushing :)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 02/12] h264: move reading direct_spatial_mv_pred out of ff_set_ref_count()

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> It has nothing to do with the reference count and so does not belong in
> this function.
> ---
>  libavcodec/h264.c| 2 --
>  libavcodec/h264_parser.c | 3 +++
>  libavcodec/h264_slice.c  | 3 +++
>  3 files changed, 6 insertions(+), 2 deletions(-)


LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/12] h264_parser: switch to h2645_parse for NAL unescaping

[Tim W.]

On Mon, Apr 4, 2016 at 8:35 PM, Anton Khirnov  wrote:

> Remove now unused ff_h264_decode_nal().
> ---
>  libavcodec/Makefile  |   2 +-
>  libavcodec/h264.c| 106
> ---
>  libavcodec/h264.h|  11 -
>  libavcodec/h264_parser.c |  37 -
>  4 files changed, 28 insertions(+), 128 deletions(-)


LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] ac3dec: change logging of skipped E-AC-3 substreams.

[Tim W.]

On Sun, Apr 3, 2016 at 5:17 PM, Luca Barbato <lu_z...@gentoo.org> wrote:

> On 03/04/16 11:26, Tim W. wrote:
> > Well, it's definitely redundant before my patchset. Afterwards, the
> > avpriv_request_sample is only printed once, so it's (slightly) less
> > redundant).
> >
> > Is there any sort of agreement about what I should do, before I amend the
> > patch?
> >
>
> The patch is in, and the idea of the set is having less noise so worst
> case can we get a patch by somebody that has a stronger opinion on the
> level.


Fair enough, thanks.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] ac3dec: change logging of skipped E-AC-3 substreams.

[Tim W.]

On Sat, Apr 2, 2016 at 5:09 PM, Luca Barbato  wrote:

> On 02/04/16 14:04, Luca Barbato wrote:
> > On 01/04/16 17:33, James Almer wrote:
> >> On 3/31/2016 10:22 PM, Tim Walker wrote:
> >>> Change log level from warning to debug: the E-AC-3 "core"
> >>> substream can be successfully decoded without the additional
> >>> and dependent substreams, and their presence is already
> >>> indicated via avpriv_request_sample in ff_eac3_parse_header.
> >>> ---
> >>>  libavcodec/ac3dec.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> >>> index 97ce287..1161992 100644
> >>> --- a/libavcodec/ac3dec.c
> >>> +++ b/libavcodec/ac3dec.c
> >>> @@ -1347,7 +1347,7 @@ static int ac3_decode_frame(AVCodecContext *
> avctx, void *data,
> >>>  /* skip frame if CRC is ok. otherwise use error
> concealment. */
> >>>  /* TODO: add support for substreams and dependent frames
> */
> >>>  if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT ||
> s->substreamid) {
> >>> -av_log(avctx, AV_LOG_WARNING, "unsupported frame type
> : "
> >>> +av_log(avctx, AV_LOG_DEBUG, "unsupported frame type :
> "
> >>> "skipping frame\n");
> >>
> >> Maybe AV_LOG_VERBOSE? Also, it could actually mention what kind of frame
> >> type is being skipped.
> >>
> >
> > I prefer keeping it as debug, reporting the frame type is a good idea
> > though.
> >
>
> Looks like it would be a redundant message if I understood the error
> path correctly.
>
> lu


Well, it's definitely redundant before my patchset. Afterwards, the
avpriv_request_sample is only printed once, so it's (slightly) less
redundant).

Is there any sort of agreement about what I should do, before I amend the
patch?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] vaapi_h264: Fix bit offset of slice data.

[Tim W.]

On Sat, Apr 2, 2016 at 5:48 PM, Mark Thompson  wrote:

> Commit ca2f19b9cc37be509d85f05c8f902860475905f8 modified the meaning of
> H264SliceContext.gb: it is now initialised at the start of the NAL unit
> header, rather than at the start of the slice header.  The VAAPI slice
> decoder uses the offset after parsing to determine the offset of the
> slice data in the bitstream, so with the changed meaning we no longer
> need to add the extra byte to account for the NAL unit header because
> it is now included directly.
> ---
>  libavcodec/vaapi_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> index 431a428..2e2626e 100644
> --- a/libavcodec/vaapi_h264.c
> +++ b/libavcodec/vaapi_h264.c
> @@ -328,7 +328,7 @@ static int vaapi_h264_decode_slice(AVCodecContext
> *avctx,
>  slice_param = (VASliceParameterBufferH264
> *)ff_vaapi_alloc_slice(avctx->hwaccel_context, buffer, size);
>  if (!slice_param)
>  return -1;
> -slice_param->slice_data_bit_offset  = get_bits_count(>gb)
> + 8; /* bit buffer started beyond nal_unit_type */
> +slice_param->slice_data_bit_offset  = get_bits_count(>gb);
>  slice_param->first_mb_in_slice  = (sl->mb_y >>
> FIELD_OR_MBAFF_PICTURE(h)) * h->mb_width + sl->mb_x;
>  slice_param->slice_type =
> ff_h264_get_slice_type(sl);
>  slice_param->direct_spatial_mv_pred_flag= sl->slice_type ==
> AV_PICTURE_TYPE_B ? sl->direct_spatial_mv_pred : 0;
> --
> 2.8.0.rc3


LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] matroska: Write the field order information

[Tim W.]

On Sat, Apr 2, 2016 at 10:36 PM, Luca Barbato  wrote:

> And bump the document version to 4.
> ---
>  libavformat/matroskaenc.c | 45
> +++--
>  1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index c2b1de0..667646d 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -632,6 +632,45 @@ static int mkv_write_codecprivate(AVFormatContext *s,
> AVIOContext *pb,
>  return ret;
>  }
>
> +static void mkv_write_field_order(AVIOContext *pb,
> +  enum AVFieldOrder field_order)
> +{
> +switch (field_order) {
> +case AV_FIELD_UNKNOWN:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFLAGINTERLACED,
> +  MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED);
> +break;
> +case AV_FIELD_PROGRESSIVE:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFLAGINTERLACED,
> +  MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE);
> +break;
> +case AV_FIELD_TT:
> +case AV_FIELD_BB:
> +case AV_FIELD_TB:
> +case AV_FIELD_BT:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFLAGINTERLACED,
> +  MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED);
> +switch (field_order) {
> +case AV_FIELD_TT:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFIELDORDER,
> +  MATROSKA_VIDEO_FIELDORDER_TT);
> +break;
> +case AV_FIELD_BB:
> + put_ebml_uint(pb, MATROSKA_ID_VIDEOFIELDORDER,
> +  MATROSKA_VIDEO_FIELDORDER_BB);
> +break;
> +case AV_FIELD_TB:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFIELDORDER,
> +  MATROSKA_VIDEO_FIELDORDER_TB);
> +break;
> +case AV_FIELD_BT:
> +put_ebml_uint(pb, MATROSKA_ID_VIDEOFIELDORDER,
> +  MATROSKA_VIDEO_FIELDORDER_BT);
> +break;
> +}
> +}
> +}
> +
>  static int mkv_write_stereo_mode(AVFormatContext *s, AVIOContext *pb,
>   AVStream *st, int mode)
>  {
> @@ -831,10 +870,12 @@ static int mkv_write_track(AVFormatContext *s,
> MatroskaMuxContext *mkv,
>  }
>
>  subinfo = start_ebml_master(pb, MATROSKA_ID_TRACKVIDEO, 0);
> -// XXX: interlace flag?
> +
>  put_ebml_uint (pb, MATROSKA_ID_VIDEOPIXELWIDTH , par->width);
>  put_ebml_uint (pb, MATROSKA_ID_VIDEOPIXELHEIGHT, par->height);
>
> +mkv_write_field_order(pb, par->field_order);
> +
>  // check both side data and metadata for stereo information,
>  // write the result to the bitstream if any is found
>  ret = mkv_write_stereo_mode(s, pb, st, mkv->mode);
> @@ -1151,7 +1192,7 @@ static int mkv_write_header(AVFormatContext *s)
>  put_ebml_uint   (pb, EBML_ID_EBMLMAXIDLENGTH,   4);
>  put_ebml_uint   (pb, EBML_ID_EBMLMAXSIZELENGTH  ,   8);
>  put_ebml_string (pb, EBML_ID_DOCTYPE, s->oformat->name);
> -put_ebml_uint   (pb, EBML_ID_DOCTYPEVERSION ,   2);
> +put_ebml_uint   (pb, EBML_ID_DOCTYPEVERSION ,   4);
>  put_ebml_uint   (pb, EBML_ID_DOCTYPEREADVERSION ,   2);
>  end_ebml_master(pb, ebml_header);
>
> --
> 2.6.1
>

Looks OK.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] avconv: Drop an unused variable

[Tim W.]

On Fri, Apr 1, 2016 at 5:31 AM, Luca Barbato  wrote:

> ---
>  avconv.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/avconv.c b/avconv.c
> index 2e199e3..1351cfc 100644
> --- a/avconv.c
> +++ b/avconv.c
> @@ -1002,7 +1002,6 @@ static void flush_encoders(void)
>
>  if (1) {
>  AVPacket pkt;
> -int got_packet;
>  av_init_packet();
>  pkt.data = NULL;
>  pkt.size = 0;
> --
> 2.6.1


LGTM.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] oggparsespeex: Fix unchecked malloc

[Tim W.]

On Sun, Nov 22, 2015 at 7:12 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/oggparsespeex.c | 2 ++
>  1 file changed, 2 insertions(+)


LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [RFC] dcadec: don't check for overreads in auxiliary data.

[Tim W.]

On Sun, Nov 22, 2015 at 12:02 AM, Tim Walker  wrote:

> The auxiliary data length field is not reliable,
> and incorrect overread errors could be returned
> for valid, real-world bitstreams.
> ---
>  libavcodec/dcadec.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)


Been so long I had to use git send-email, I wanted to include more in the
initial email, sorry.

A sample is currently available at:
https://drive.google.com/file/d/0B814FrOKy8oHT0hVZ3RGNGdON2s/view?usp=sharing

This error seems to happen on several/many Blu-ray discs, too (try Googling
"Overread auxiliary data by 32 bits").

libdcadec simply ignores the field entirely:

libdcadec/core_decoder.c :
// Auxiliary data byte count (can't be trusted)
bits_skip(>bits, 6);

I'm unsure what the best approach is (mine or dcadec's), to be honest.
Thoughts?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] [RFC] dcadec: don't check for overreads in auxiliary data.

[Tim W.]

On Sun, Nov 22, 2015 at 12:30 AM, Luca Barbato  wrote:

>
>
> Well assuming the user just gets the warning once it sounds fine, the
> audio with your patch is ok?


AFAICT there is no discernible difference, the error only happens on one
frame and I really can't tell them apart.

I don't have any full-length Blu-ray discs on my hard drive right now,
there may or may not be discernible differences on some discs (though there
wasn't in the sample I tested before, but I unfortunately can't recall
which disc it was).

Given how widespread the issue is (see Google, quite a few hits), I'm
fairly confident libdcadec is right and aux_data_count can't be trusted.

I might still be OK to print a warning, but I think returning
AVERROR_INVALIDDATA is wrong, because this happens with many valid DTS
streams.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC PATCH 3/4] lavc: add Intel libmfx-based MPEG2 encoder

[Tim W.]

On Sat, Jul 4, 2015 at 10:07 AM, Luca Barbato lu_z...@gentoo.org wrote:

 On 04/07/15 03:17, Tim W. wrote:
  On Tue, Jun 30, 2015 at 8:24 PM, Anton Khirnov an...@khirnov.net
 wrote:
 
  ---
   configure |   1 +
   libavcodec/Makefile   |   1 +
   libavcodec/allcodecs.c|   1 +
   libavcodec/qsv.c  |   2 +
   libavcodec/qsvenc.c   |  10 ++--
   libavcodec/qsvenc_mpeg2.c | 117
  ++
   6 files changed, 128 insertions(+), 4 deletions(-)
   create mode 100644 libavcodec/qsvenc_mpeg2.c
 
  diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
  index bd9e18d..f563100 100644
  --- a/libavcodec/qsv.c
  +++ b/libavcodec/qsv.c
  @@ -19,6 +19,8 @@
*/
 
   #include mfx/mfxvideo.h
  +#include mfx/mfxplugin.h
  +#include stdio.h
 
 
  Does this fix checkheaders or something? Doesn't look related to this
  particular patch.

 That part is needed for HEVC I guess.

 lu


That was my guess too, but it still doesn't belong in this patch ;)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC PATCH 4/4] lavc: add Intel libmfx-based HEVC encoder

[Tim W.]

On Sat, Jul 4, 2015 at 10:09 AM, Luca Barbato lu_z...@gentoo.org wrote:

 On 04/07/15 02:33, Tim W. wrote:
  Have you seen a case where the plugin didn't load but encoding worked?
 Else
  we may as well fail here.

 Hypothetical full hw implementation that does not have the plugin.

 lu


Fair enough (though all known hardware implementations will require loading
a plugin, as far as I can tell - e.g. MFX_PLUGINID_HEVCE_HW for
hardware-accelerated HEVC encoding using Intel Skylake's onboard graphics).

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC PATCH 3/4] lavc: add Intel libmfx-based MPEG2 encoder

[Tim W.]

On Tue, Jun 30, 2015 at 8:24 PM, Anton Khirnov an...@khirnov.net wrote:

 ---
  configure |   1 +
  libavcodec/Makefile   |   1 +
  libavcodec/allcodecs.c|   1 +
  libavcodec/qsv.c  |   2 +
  libavcodec/qsvenc.c   |  10 ++--
  libavcodec/qsvenc_mpeg2.c | 117
 ++
  6 files changed, 128 insertions(+), 4 deletions(-)
  create mode 100644 libavcodec/qsvenc_mpeg2.c

 diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
 index bd9e18d..f563100 100644
 --- a/libavcodec/qsv.c
 +++ b/libavcodec/qsv.c
 @@ -19,6 +19,8 @@
   */

  #include mfx/mfxvideo.h
 +#include mfx/mfxplugin.h
 +#include stdio.h


Does this fix checkheaders or something? Doesn't look related to this
particular patch.

diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
 new file mode 100644
 index 000..81897c2
 --- /dev/null
 +++ b/libavcodec/qsvenc_mpeg2.c
 @@ -0,0 +1,117 @@
 +/*
 + * Intel MediaSDK QSV based H.264 enccoder


H.264 - MPEG-2, enccoder - encoder.

The rest LGTM (including the name mpeg2_qsv).

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC PATCH 4/4] lavc: add Intel libmfx-based HEVC encoder

[Tim W.]

On Tue, Jun 30, 2015 at 8:24 PM, Anton Khirnov an...@khirnov.net wrote:

 ---
  configure |   1 +
  libavcodec/Makefile   |   1 +
  libavcodec/allcodecs.c|   1 +
  libavcodec/hevc.h |   3 +
  libavcodec/qsv.c  |  14 +++
  libavcodec/qsv_internal.h |   4 +
  libavcodec/qsvenc.c   |  22 +++--
  libavcodec/qsvenc_hevc.c  | 236
 ++
  8 files changed, 273 insertions(+), 9 deletions(-)
  create mode 100644 libavcodec/qsvenc_hevc.c

 diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
 index 8b06e1f..60377c2 100644
 --- a/libavcodec/hevc.h
 +++ b/libavcodec/hevc.h
 @@ -113,5 +117,15 @@ int ff_qsv_init_internal_session(AVCodecContext
 *avctx, mfxSession *session)
 Initialized an internal MFX session using %s
 implementation\n,
 desc);

 +#if QSV_VERSION_ATLEAST(1, 8)


This will ensure MFXVideoUSER_Load is available, but MFX_PLUGINID_HEVCE_SW
was introduced in the dispatcher with MFX_VERSION_MINOR == 10; if you
really want to support building with older dispatchers/headers, you can
always hardcode it:

{{0x2f, 0xca, 0x99, 0x74, 0x9f, 0xdb, 0x49, 0xae, 0xb1, 0x21, 0xa5, 0xb6,
0x3e, 0xf5, 0x68, 0xf7}}


 +if (avctx-codec_id == AV_CODEC_ID_HEVC) {

+ret = MFXVideoUSER_Load(*session, MFX_PLUGINID_HEVCE_SW, 1);


MFX_PLUGINID_HEVCE_SW is the plugin UID for the software-based HEVC
encoder. Loading it in a hardware-accelerated session appears to work (all
the way to MFXVideoENCODE_Init), so at least we're good there.

That being said, if the session is hardware-accelerated, we could/should
try loading MFX_PLUGINID_HEVCE_HW first? You'll need the latest dispatcher
to build it (MFX_VERSION_MINOR == 15), but you can also hardcode it:

{{0x6f, 0xad, 0xc7, 0x91, 0xa0, 0xc2, 0xeb, 0x47, 0x9a, 0xb6, 0xdc, 0xd5,
0xea, 0x9d, 0xa3, 0x47}}

There is no way to test it directly, but if you ask nicely Maxym
(Dmytrychenko) may be able to do it for you.


 +if (ret  0) {
 +av_log(avctx, AV_LOG_WARNING,
 +   Could not load the HEVC encoding plugin, encoding
 will likely fail\n);


Have you seen a case where the plugin didn't load but encoding worked? Else
we may as well fail here.


 diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
 index d13848a..4b6d9c4 100644
 --- a/libavcodec/qsv_internal.h
 +++ b/libavcodec/qsv_internal.h
 @@ -30,6 +30,10 @@

  #define ASYNC_DEPTH_DEFAULT 4   // internal parallelism

 +#define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
 +(MFX_VERSION_MAJOR  (MAJOR) || \
 + MFX_VERSION_MAJOR == (MAJOR)  MFX_VERSION_MINOR = (MINOR))
 +


This would be more useful if MFX_VERSION_* wasn't hardcoded, that way we
could check the API version exposed by the runtime (via MFXQueryVersion) if
the need were to arise in the future.


 diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
 index 690d5aa..a724611 100644
 --- a/libavcodec/qsvenc.c
 +++ b/libavcodec/qsvenc.c
 @@ -124,15 +124,19 @@ static int init_video_param(AVCodecContext *avctx,
 QSVEncContext *q)
  break;
  }


FrameInfo.Width should be 32-aligned for (QSV-based) HEVC encoding,
according to Maxym. Makes sense, too.



 -q-extco.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION;
 -q-extco.Header.BufferSz  = sizeof(q-extco);
 -q-extco.CAVLC= avctx-coder_type ==
 FF_CODER_TYPE_VLC ?
 -MFX_CODINGOPTION_ON :
 MFX_CODINGOPTION_UNKNOWN;
 -
 -q-extparam[0] = (mfxExtBuffer *)q-extco;
 -
 -q-param.ExtParam= q-extparam;
 -q-param.NumExtParam = FF_ARRAY_ELEMS(q-extparam);
 +// the HEVC encoder plugin currently fails if coding options
 +// are provided
 +if (avctx-codec_id != AV_CODEC_ID_HEVC) {
 +q-extco.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION;
 +q-extco.Header.BufferSz  = sizeof(q-extco);
 +q-extco.CAVLC= avctx-coder_type ==
 FF_CODER_TYPE_VLC ?
 +MFX_CODINGOPTION_ON :
 MFX_CODINGOPTION_UNKNOWN;
 +
 +q-extparam[0] = (mfxExtBuffer *)q-extco;
 +
 +q-param.ExtParam= q-extparam;
 +q-param.NumExtParam = FF_ARRAY_ELEMS(q-extparam);
 +}


I guess this is OK for now, but using MFXVideoENCODE_Query would be better.
Probably outside the scope of this patch though.


 diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
 new file mode 100644
 index 000..9934472
 --- /dev/null
 +++ b/libavcodec/qsvenc_hevc.c
 @@ -0,0 +1,236 @@
 +/*
 + * Intel MediaSDK QSV based H.264 enccoder
 + *
 + * This file is part of Libav.
 + *
 + * Libav is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU Lesser General Public
 + * License as published by the Free Software Foundation; either
 + * version 2.1 of the License, or (at your option) any later version.
 + *
 + * Libav is distributed in the hope that it will be useful,
 + * but 

Re: [libav-devel] [RFC PATCH 4/4] lavc: add Intel libmfx-based HEVC encoder

[Tim W.]

On Tue, Jun 30, 2015 at 8:24 PM, Anton Khirnov an...@khirnov.net wrote:

 ---
  configure |   1 +
  libavcodec/Makefile   |   1 +
  libavcodec/allcodecs.c|   1 +
  libavcodec/hevc.h |   3 +
  libavcodec/qsv.c  |  14 +++
  libavcodec/qsv_internal.h |   4 +
  libavcodec/qsvenc.c   |  22 +++--
  libavcodec/qsvenc_hevc.c  | 236
 ++
  8 files changed, 273 insertions(+), 9 deletions(-)
  create mode 100644 libavcodec/qsvenc_hevc.c


I have several comments on this patch, but I'd rather wait a couple days
until I'm back home so I can check stuff more easily (and also do some
testing).

Regards,

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavf/hevc: pad the RBSP buffer as required by the bistream reader

[Tim W.]

On Wed, Jul 1, 2015 at 1:13 PM, Luca Barbato lu_z...@gentoo.org wrote:

 On 01/07/15 08:14, Anton Khirnov wrote:
  Because plaid.host/tags/lavf/hevc is annoying to support (I'll add a
  deploy of the software soon).
 
  Sorry, but I really don't think that quirks of some software that is not
  even used by most people should dictate rules to everybody.

 As you wish, I prefer having lavf: hevc:.

 lu


I feel sorry for you (since I don't expect I would find it in me to fix
plaid), but I have to agree, / came first, it has seniority :P

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] s302m: fix arithmetic exception

[Tim W.]

On Fri, Jun 26, 2015 at 12:05 AM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 If 'buf_size * 8' is smaller than 'avctx-channels *
 (avctx-bits_per_raw_sample + 4)' it resulted in a division by zero.

 Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
 ---
  libavcodec/s302m.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Is the indentation correct for libav's coding conventions? If not, might be
worth trying to fix it, hopefully it makes it more readable.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/1] libvpx: fix test for VPX_IMAGE_ABI_VERSION

[Tim W.]

On Wed, Jun 24, 2015 at 8:47 AM, Luca Barbato lu_z...@gentoo.org wrote:

 On 24/06/15 09:40, Janne Grunau wrote:
  ---
   libavcodec/libvpx.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)


I missed this too when reviewing :oops:

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libvpx: Support the vp9 extended profiles

[Tim W.]

On Wed, Jun 17, 2015 at 10:25 PM, Luca Barbato lu_z...@gentoo.org wrote:

 Bump the minimum libvpx version to 1.3.0 and rework the configure logic
 to fail only if no decoders and encoders are found.

 Based on the original patch from Vittorio.

 Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
 Signed-off-by: Luca Barbato lu_z...@gentoo.org
 ---

 Changed the configure logic and the guards for the new pixel formats.

  configure  | 28 +--
  libavcodec/avcodec.h   |  4 
  libavcodec/libvpx.c| 60
 +++---
  libavcodec/libvpx.h|  3 ++-
  libavcodec/libvpxdec.c |  7 ++
  libavcodec/libvpxenc.c | 36 ++
  6 files changed, 108 insertions(+), 30 deletions(-)


Looks good, but in the discussion for the previous version of this patch,
Vittorio commented that you might want to add a Changelog entry and maybe
even a version bump?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] udp: Fix local_port management

[Tim W.]

On Sun, Jun 21, 2015 at 8:54 PM, Luca Barbato lu_z...@gentoo.org wrote:

 The default value for unset is -1, not 0.

 Problem introduced in 66028b7ba6b411ba12ef553e9c8f1f4a4fe27710

 ---

 Meh.

  libavformat/udp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] mov: Preserve the metadata even when bit-exactness is requested

[Tim W.]

On Tue, Jun 16, 2015 at 2:26 AM, Luca Barbato lu_z...@gentoo.org wrote:

 On 15/06/15 20:40, Luca Barbato wrote:
  Make sure to not write the custom `encoder` string in that case.
 
  Bug-Id: 845
  CC: libav-sta...@libav.org
  ---
   libavformat/movenc.c   | 14 +++---
   tests/ref/vsynth/vsynth1-mpeg4 |  4 ++--
   tests/ref/vsynth/vsynth2-mpeg4 |  4 ++--
   3 files changed, 11 insertions(+), 11 deletions(-)
 

 Reported to work fine by Nikoli on bugzilla. I'd candidate it for stable
 as well.

 lu


Patch looks correct at first glance.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavc: Clarify the behaviour of dimension and format context fields

[Tim W.]

On Sun, Jun 14, 2015 at 12:39 PM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 That would have worked, had it been there from the beginning,
 but adding it now, after being documented differently for years,
 doesn't help that much.

 Best regards,
 Andreas


AVFrame is less than 3 years old, this is (to some extent) an API change
that was never documented, rather than a many-years documentation problem.

Maybe it would make sense to deprecate these context fields? Won't fix
anything now, but will prevent incorrect API usage in the long run.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavc: Clarify the behaviour of dimension and format context fields

[Tim W.]

On Sun, Jun 14, 2015 at 11:50 AM, Luca Barbato lu_z...@gentoo.org wrote:

 The AVCodecContext width, height, coded_width, coded_height and format
 are used mainly as decoding hints and they get internally overwritten
 during the data parsing stage.

 Do not assume they match the last AVFrame provided by
 avcodec_decode_video2 and assimilated functions since multi-threading
 and other frame reordering might make those values to refer to frames
 that will be outputted in the future.

 CC: libav-sta...@libav.org
 ---
  libavcodec/avcodec.h | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

 diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
 index 3440126..59179dd 100644
 --- a/libavcodec/avcodec.h
 +++ b/libavcodec/avcodec.h
 @@ -1217,21 +1217,31 @@ typedef struct AVCodecContext {
  /* video only */
  /**
   * picture width / height.
 + *
 + * @note Those fields may not match the values of the last
 + * AVFrame outputted by avcodec_decode_video2 due frame
 + * reorderning.


Typo ;)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libx264: Factor out the reconfiguration code

[Tim W.]

On Fri, Jun 12, 2015 at 12:10 AM, Luca Barbato lu_z...@gentoo.org wrote:

 ---

  libavcodec/libx264.c | 164
 +++
  1 file changed, 86 insertions(+), 78 deletions(-)


Looks good. Would it hurt to use a variable to keep track of
reconfiguration and calling x264_encoder_reconfig only once at the end?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libx265: Use x265_param_parse to set the SAR

[Tim W.]

Sent from my iPhone

 On Apr 8, 2014, at 7:46 PM, Derek Buitenhuis derek.buitenh...@gmail.com 
 wrote:
 
 Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
 ---
 This doesn't require an API requirement bump, and should be future proof.
 ---
 libavcodec/libx265.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)
 
 diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
 index 77d0b03..bcd5a11 100644
 --- a/libavcodec/libx265.c
 +++ b/libavcodec/libx265.c
 @@ -77,6 +77,7 @@ static av_cold int libx265_encode_init(AVCodecContext 
 *avctx)
 {
 libx265Context *ctx = avctx-priv_data;
 x265_nal *nal;
 +char sar[10];

IIRC H.265 has 16-bit fields for SAR width/height: strlen(65535) * 2 + ':' + 
'\n' should be 12, IMO.

 int sar_num, sar_den;
 int nnal;
 
 @@ -115,11 +116,11 @@ static av_cold int libx265_encode_init(AVCodecContext 
 *avctx)
 av_reduce(sar_num, sar_den,
   avctx-sample_aspect_ratio.num,
   avctx-sample_aspect_ratio.den, 4096);
 -ctx-params-vui.bEnableVuiParametersPresentFlag = 1;
 -ctx-params-vui.bEnableAspectRatioIdc   = 1;
 -ctx-params-vui.aspectRatioIdc  = 255;
 -ctx-params-vui.sarWidth= sar_num;
 -ctx-params-vui.sarHeight   = sar_den;
 +snprintf(sar, 10, %d:%d, sar_num, sar_den);
 +if (x265_param_parse(ctx-params, sar, sar) == X265_PARAM_BAD_VALUE) {
 +av_log(avctx, AV_LOG_ERROR, Invalid SAR: %d:%d.\n, sar_num, 
 sar_den);
 +return AVERROR_INVALIDDATA;
 +}

I would *maybe* check for X265_PARAM_BAD_NAME too, just in case they change the 
option name (however unlikely).

Rest LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [FOSDEM] cab-sharing and such

[Tim W.]

Sent from my iPhone

 On Jan 30, 2014, at 3:15 PM, Tim Walker tdskywal...@gmail.com wrote:
 
 On 30 Jan 2014, at 15:10, Luca Barbato lu_z...@gentoo.org wrote:
 
 Hi,
 
 When people arrives at the airport and which airport?
 
 I'll be at the main one at around 5.30pm
 
 lu

Anyone here already in Brussels?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] vc1: enable the interlaced B-frame codepath.

[Tim W.]

 
 On Jan 12, 2014, at 4:39 PM, Diego Biurrun di...@biurrun.de wrote:
 
 On Sat, Jan 11, 2014 at 11:58:16PM +0100, Tim Walker wrote:
 This should have been done in 1fb013a57c6d98d3f425506eb25f32b2cf7ddc6f, but 
 was missed because FFmpeg had moved that code elsewhere.
 
 Please keep line lengths in log messages reasonable.
 
 Diego
 ___
 libav-devel mailing list
 libav-devel@libav.org
 https://lists.libav.org/mailman/listinfo/libav-devel

Please consider this patch superseded by the version in Luca's patch set.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] vc1dsp: KR formatting cosmetics

[Tim W.]

On 12/01/14 00:59, Vittorio Giovara wrote:
 From: Luca Barbato lu_zero at gentoo.org
 
 Signed-off-by: Vittorio Giovara vittorio.giovara at gmail.com

LGTM too.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/4] vc1: Factorize out chroma MC

[Tim W.]

On Sun, Jan 12, 2014 at 12:16 AM, Luca Barbato lu_zero at gentoo.org wrote:
 ---
  libavcodec/vc1dsp.c | 71 
 +
  1 file changed, 23 insertions(+), 48 deletions(-)
 
 diff --git a/libavcodec/vc1dsp.c b/libavcodec/vc1dsp.c
 index fe6e26d..5afb34c 100644
 --- a/libavcodec/vc1dsp.c
 +++ b/libavcodec/vc1dsp.c
 @@ -676,6 +676,9 @@ PUT_VC1_MSPEL(1, 3)
  PUT_VC1_MSPEL(2, 3)
  PUT_VC1_MSPEL(3, 3)
  
 +#define chroma_mc(a) \
 +((A * src[a] + B * src[a + 1] + \
 +  C * src[stride + a] + D * src[stride + a +1] + 32 - 4)  6)

+ a +1 - + a + 1

Otherwise LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/4] vc1: Add avg_no_rnd_vc1_chroma_mc4_c()

[Tim W.]

On Sun, Jan 12, 2014 at 12:16:05AM +0100, Luca Barbato wrote:
 From: Michael Niedermayer michaelni at gmx.at
 
 Needed for proper interlaced support.
 
 Signed-off-by: Luca Barbato lu_zero at gentoo.org
 ---
  libavcodec/vc1dsp.c | 23 +++
  1 file changed, 23 insertions(+)

LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] vc1: Enable the interlaced B-frame codepath.

[Tim W.]

On Sun, Jan 12, 2014 at 12:16 AM, Luca Barbato lu_zero at gentoo.org wrote:
 From: Tim Walker tdskywalker at gmail.com
 
 Signed-off-by: Luca Barbato lu_zero at gentoo.org
 ---
  libavcodec/vc1.c | 1 -
  1 file changed, 1 deletion(-)

Probably OK.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] FOSDEM 2014

[Tim W.]

Looks like I may be attending too.

Definitely interested in sharing a room with someone.

Just a quick note: don't always assume train will be cheaper than air, you may 
be wrong…

Cheers,

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/9] lavu: Add values for various Dolby flags to the AVMatrixEncoding enum.

[Tim W.]

Patchset OKed by Justin and Benjamin on IRC.

Since it's been 3 weeks already, I'll push soonish, unless there are objections?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] h264: namespace the decode function

[Tim W.]

Sent from my iPhone

 On Dec 28, 2013, at 2:58 PM, Luca Barbato lu_z...@gentoo.org wrote:
 
 Make much easier debugging.
 ---
 libavcodec/h264.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/libavcodec/h264.c b/libavcodec/h264.c
 index 07a93cf..f610d71 100644
 --- a/libavcodec/h264.c
 +++ b/libavcodec/h264.c
 @@ -4853,8 +4853,8 @@ static int output_frame(H264Context *h, AVFrame *dst, 
 AVFrame *src)
 return 0;
 }
 
 -static int decode_frame(AVCodecContext *avctx, void *data,
 -int *got_frame, AVPacket *avpkt)
 +static int h264_decode_frame(AVCodecContext *avctx, void *data,
 + int *got_frame, AVPacket *avpkt)
 {
 const uint8_t *buf = avpkt-data;
 int buf_size   = avpkt-size;
 @@ -4989,7 +4989,7 @@ AVCodec ff_h264_decoder = {
 .priv_data_size= sizeof(H264Context),
 .init  = ff_h264_decode_init,
 .close = h264_decode_end,
 -.decode= decode_frame,
 +.decode= h264_decode_frame,
 .capabilities  = /*CODEC_CAP_DRAW_HORIZ_BAND |*/ CODEC_CAP_DR1 |
  CODEC_CAP_DELAY | CODEC_CAP_SLICE_THREADS

LGTM.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] hevc: add HEVC profiles names

[Tim W.]

Sent from my iPhone

 On Dec 19, 2013, at 6:32 PM, Diego Biurrun di...@biurrun.de wrote:
 
 profile_
 
 On Thu, Dec 19, 2013 at 12:30:24AM +0100, Guillaume Martres wrote:
 --- a/libavcodec/avcodec.h
 +++ b/libavcodec/avcodec.h
 @@ -2662,6 +2662,11 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_JPEG2000_DCINEMA_2K  3
 #define FF_PROFILE_JPEG2000_DCINEMA_4K  4
 
 +
 +#define FF_PROFILE_HEVC_MAIN1
 +#define FF_PROFILE_HEVC_MAIN_10 2
 +#define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
 
 I think these should be AV_-prefixed if they are considered public API.
 
 Of course, that is slightly unrelated to this patch, but if we agree
 to AV-prefix these instead, I can perform the necessary deprecation
 dance.
 
 Diego

It's certainly something we (HandBrake) check in some cases, so we do treat it 
as if it were a public API.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/17] lavc: add ff_side_data_update_matrix_encoding utility function.

[Tim W.]

On 07 Dec 2013, at 08:35, Anton Khirnov an...@khirnov.net wrote:

 
 On Fri,  6 Dec 2013 23:23:58 +0100, Tim Walker tdskywal...@gmail.com wrote:
 ---
 libavcodec/internal.h |  5 +
 libavcodec/utils.c| 16 
 2 files changed, 21 insertions(+)
 
 diff --git a/libavcodec/internal.h b/libavcodec/internal.h
 index c1108ff..b9d626d 100644
 --- a/libavcodec/internal.h
 +++ b/libavcodec/internal.h
 @@ -179,4 +179,9 @@ const uint8_t *avpriv_find_start_code(const uint8_t 
 *restrict p,
  */
 int ff_set_dimensions(AVCodecContext *s, int width, int height);
 
 +/**
 + * Add or update AV_FRAME_DATA_MATRIXENCODING side data.
 + */
 +void ff_side_data_update_matrix_encoding(AVFrame *frame, int 
 matrix_encoding);
 
 Any reason for it to take an int instead of enum AVMatrixEncoding?

Nope, fixed locally.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] dcadec: decode LFE so we dont just add random data when downmixing with LFE

[Tim W.]

On 05 Dec 2013, at 15:59, Diego Biurrun di...@biurrun.de wrote:

 On 05.12.2013 09:18, Tim Walker wrote:
 ---
 
 Now with proper commit message, hopefully.
 
 You're still propagating the standard dont typo.  Try
 
 dcadec: Decode LFE to avoid adding random data when downmixing with LFE
 
 Diego

Oops…

:-) 

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] dcadec: Decode LFE to avoid adding random data when downmixing with LFE

[Tim W.]

On 05 Dec 2013, at 21:18, Luca Barbato lu_z...@gentoo.org wrote:

 On 05/12/13 21:06, Tim Walker wrote:
 From: Michael Niedermayer michae...@gmx.at
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 Signed-off-by: Tim Walker tdskywal...@gmail.com
 ---
 
 Once more, with feeling.
 
 
 Probably ok, that fixme message is still valid?
 
 lu

No clue. But it's not related to the patch, which only changes the condition to 
trigger decoding of the LFE.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] Release preparation

[Tim W.]

How about libav 10, aka Domestic Cat? Don't think Apple used that one yet.

On a somewhat more serious note, Eks makes me think of elks (the animal)…

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] Release preparation

[Tim W.]

On 01 Dec 2013, at 17:00, Reinhard Tartler siret...@gmail.com wrote:

 On Mon, Nov 25, 2013 at 8:25 AM, Luca Barbato lu_z...@gentoo.org wrote:
 Hi, we already have enough fixes piled up for another release, I'd aim
 to get 0.8 and 9 out early in December.
 
 Given the requests from some of our community members we could even
 think about getting ready for a libav10 pre-release before the end of
 the year, most of the features we discussed at the vdd and return to
 have a seasonal major release with just some major feature increase.
 
 Any ideas on a codename for Libav 10?

Vista

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] dcadec: add some logging before returning on error.

[Tim W.]

On 29 Nov 2013, at 13:50, Diego Biurrun di...@biurrun.de wrote:

 On Fri, Nov 29, 2013 at 01:47:48PM +0100, Tim Walker wrote:
 --- a/libavcodec/dcadec.c
 +++ b/libavcodec/dcadec.c
 @@ -1301,8 +1301,10 @@ static int dca_subframe_footer(DCAContext *s, int 
 base_channel)
 
 -if (get_bits_long(s-gb, 32) != 0x9A1105A0) // nSYNCAUX
 +if (get_bits_long(s-gb, 32) != 0x9A1105A0) { // nSYNCAUX
 +av_log(s-avctx,AV_LOG_ERROR, nSYNCAUX mismatch\n);
 return AVERROR_INVALIDDATA;
 +}
 
 I guess a #define for this magic number would not hurt.
 
 Diego

#define DCA_NSYNCAUX 0x9A1105A0 all right?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] avcodec/dcadec: decode LFE so we dont just add random data when downmixing with LFE

[Tim W.]

On 29 Nov 2013, at 19:15, Diego Biurrun di...@biurrun.de wrote:

 On 29.11.2013 11:43, Tim Walker wrote:
 From: Michael Niedermayer michae...@gmx.at
 
 
 Just dcadec: is fine.  Please don't propagate obvious typos.
 
 Diego

Sorry, missed it. Would you like me to resend just for that?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/9] dcadec: implement request_channel_layout.

[Tim W.]

On 28 Nov 2013, at 22:07, Anton Khirnov an...@khirnov.net wrote:

 
 On Sun, 24 Nov 2013 00:20:05 +0100, Tim Walker tdskywal...@gmail.com wrote:
 ---
 libavcodec/dcadec.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)
 
 
 Approved by Benjamin on IRC and pushed.

Cool. I think now would be a good time to re-submit FATE: add a test for DTS 
downmixing. :-)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] mpeg12dec: Extract CC user data into frame side data

[Tim W.]

On 24 Nov 2013, at 18:08, John Stebbins stebb...@jetheaddev.com wrote:

 diff --git a/libavutil/frame.h b/libavutil/frame.h
 index 449a6b7..2361233 100644
 --- a/libavutil/frame.h
 +++ b/libavutil/frame.h
 @@ -35,6 +35,7 @@ enum AVFrameSideDataType {
  * The data is the AVPanScan struct defined in libavcodec.
  */
 AV_FRAME_DATA_PANSCAN,
 +AV_FRAME_DATA_CC,
 };
 
 typedef struct AVFrameSideData {

A doxy description of the associated data structure would be nice, so that 
calling applications know what to do with the side data ;-)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] ac3dec: fix out-of-array read.

[Tim W.]

On 23 Nov 2013, at 21:04, Diego Biurrun di...@biurrun.de wrote:

 On Sat, Nov 23, 2013 at 08:48:38PM +0100, Luca Barbato wrote:
 On 23/11/13 18:29, Tim Walker wrote:
 ---
 libavcodec/ac3dec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
 
 Should it land stable as well?
 
 AFAIU that is a fix for the channel layout changes recently applied
 to ac3dec, so it's specific to master.

That is correct.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/7] dcadec: implement request_channel_layout.

[Tim W.]

On 21 Nov 2013, at 14:30, Anton Khirnov an...@khirnov.net wrote:

 
 On Mon, 18 Nov 2013 12:41:44 +0100, Tim Walker tdskywal...@gmail.com wrote:
 ---
 libavcodec/dcadec.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)
 
 diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
 index 7af5e5c..8835133 100644
 --- a/libavcodec/dcadec.c
 +++ b/libavcodec/dcadec.c
 @@ -1288,7 +1288,8 @@ static int dca_filter_channels(DCAContext *s, int 
 block_index)
 }
 
 /* Down mixing */
 -if (s-avctx-request_channels == 2  s-prim_channels  2) {
 +if (s-prim_channels  2 
 +s-avctx-request_channel_layout == AV_CH_LAYOUT_STEREO) {
 dca_downmix(s-samples_chanptr, s-amode, s-downmix_coef, 
 s-channel_order_tab);
 }
 
 @@ -1803,8 +1804,11 @@ static int dca_decode_frame(AVCodecContext *avctx, 
 void *data,
 if (s-amode  16) {
 avctx-channel_layout = dca_core_channel_layout[s-amode];
 
 -if (s-xch_present  (!avctx-request_channels ||
 -   avctx-request_channels  num_core_channels 
 + !!s-lfe)) {
 +if (s-xch_present 
 +(!avctx-request_channels ||
 + avctx-request_channels  num_core_channels + !!s-lfe) 
 +(!avctx-request_channel_layout ||
 + avctx-request_channel_layout  AV_CH_BACK_CENTER)) {
 
 I'm a bit confused by this part.
 If we're only handling request_channel_layout == stereo
 (and temporarily request_channels == 2, which is converted to
 request_channel_layout in init), why are you checking request_channels here?

No, the DCA decoder also handles disabling XCh via request_channels, by 
checking whether (request_channels  num_core_channels + lfe + xch).

Not sure how to properly handle that, short of hardcoding the layout for 
request_channels == 5 (- 5.0) or == 6 (- 5.1) or checking request_channels as 
I do above.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/7] ac3dec: simplify an expression.

[Tim W.]

On 19 Nov 2013, at 01:15, Diego Biurrun di...@biurrun.de wrote:

 On Mon, Nov 18, 2013 at 12:41:47PM +0100, Tim Walker wrote:
 --- a/libavcodec/ac3dec.c
 +++ b/libavcodec/ac3dec.c
 @@ -178,9 +178,8 @@ static av_cold int ac3_decode_init(AVCodecContext *avctx)
 
 /* allow downmixing to stereo or mono */
 -if (avctx-channels  0  avctx-request_channels  0 
 -avctx-request_channels  avctx-channels 
 -avctx-request_channels = 2) {
 +if (avctx-request_channels  0  avctx-request_channels = 2 
 +avctx-request_channels  avctx-channels) {
 avctx-channels = avctx-request_channels;
 
 what ensures that avctx-channels is non-negative?  (Yes, I wonder why
 that struct member is signed in the first place.)
 
 Diego

(avctx-request_channels  0  avctx-request_channels  avctx-channels) 
implies (avctx-channels  0) or false (so the result is unchanged).

Would:

 if (avctx-request_channels  0  avctx-request_channels = 2 
 avctx-channels  avctx-request_channels) {


Be clearer?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/7] dcadec: implement request_channel_layout.

[Tim W.]

On 17 Nov 2013, at 12:58, Hendrik Leppkes h.lepp...@gmail.com wrote:

 Hm, how about removing request_channels from all the decoding code,
 and just setting request_channel_layout in init if request_channels is
 set?
 Should make for a bit prettier code and less cruft to be removed later.
 
 - Hendrik

Doh!

Thanks for the suggestion.

Tim

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] FATE: add a test for DTS downmixing.

[Tim W.]

On 05 Nov 2013, at 10:36, Anton Khirnov an...@khirnov.net wrote:

 ---
 tests/fate/audio.mak |6 ++
 1 file changed, 6 insertions(+)

Hmm, IIRC the default downmix coefficients are still broken (pretty much every 
input channel goes into both downmixed channels). Do we want to fix them before 
adding FATE tests for it?

Also, AFAICT that downmix code is very crude and has no advantage over 
avresample except one less dependency (obviously). Thoughts on removing it 
altogether?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] vf_fieldorder: log when processing is skipped

[Tim W.]

On Oct 21, 2013, at 4:47 PM, Anton Khirnov an...@khirnov.net wrote:

 
 On Tue, 15 Oct 2013 11:14:22 +0200, Vittorio Giovara 
 vittorio.giov...@gmail.com wrote:
 ---
 Now typo-free and with more precise message.
 Vittorio
 
 libavfilter/vf_fieldorder.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/libavfilter/vf_fieldorder.c b/libavfilter/vf_fieldorder.c
 index 19b07b1..09b78d6 100644
 --- a/libavfilter/vf_fieldorder.c
 +++ b/libavfilter/vf_fieldorder.c
 @@ -101,8 +101,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
 *frame)
 uint8_t *data;
 
 if (!frame-interlaced_frame ||
 -frame-top_field_first == s-dst_tff)
 +frame-top_field_first == s-dst_tff) {
 +av_log(ctx, AV_LOG_WARNING,
 +   Skipping %s.\n,
 +   frame-interlaced_frame ?
 +   frame with same field order : progressive frame);
 return ff_filter_frame(outlink, frame);
 +}
 
 
 I don't think this should be a warning. It's perfectly normal for a user to
 insert this to ensure some specific field order on output, regardless of what 
 is
 on input. So verbose/debug would be more appropriate imo.

+1

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] h264: use the neutral name first

[Tim W.]

On Oct 4, 2013, at 12:25 PM, Kieran Kunhya kier...@obe.tv wrote:

 On 4 October 2013 11:13, Luca Barbato lu_z...@gentoo.org wrote:
 On 04/10/13 12:01, Vittorio Giovara wrote:
 ---
 libavcodec/h264.c|6 +++---
 libavcodec/libx264.c |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)
 
 
 I demand a latin explanation as to why it is AVC and not H.264
 especially now they have diverged.

I've been living under a rock. Could you elaborate on that?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2][RFC] Add libx265 encoder

[Tim W.]

On Oct 3, 2013, at 11:33 PM, Vittorio Giovara vittorio.giov...@gmail.com 
wrote:

 On Wed, Oct 2, 2013 at 10:35 PM, Diego Biurrun di...@biurrun.de wrote:
 +AVCodec ff_libx265_encoder = {
 +.name   = libx265,
 +.type   = AVMEDIA_TYPE_VIDEO,
 +.id = AV_CODEC_ID_HEVC,
 +.init   = libx265_encode_init,
 +.encode2= libx265_encode_frame,
 +.close  = libx265_encode_close,
 +.pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
 AV_PIX_FMT_NONE },
 +.priv_data_size = sizeof(libx265Context),
 +.long_name  = NULL_IF_CONFIG_SMALL(libx265 H.265 / HEVC),
 
 Move .long_name after .name.
 
 Also please use HEVC name first if you don't mind.
 Vittorio

Just FWIW, the libx264 wrapper uses:

NULL_IF_CONFIG_SMALL(libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)

and the H.264 decoder uses:

NULL_IF_CONFIG_SMALL(H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 13/13] qsv: Add MPEG-2 video decoding support

[Tim W.]

On Sep 10, 2013, at 2:15 PM, Yukinori Yamazoe droco...@gmail.com wrote:

 2013/9/9 Diego Biurrun di...@biurrun.de:
 On Sun, Sep 08, 2013 at 03:22:35AM +0900, Yukinori Yamazoe wrote:
 --- /dev/null
 +++ b/libavcodec/qsv_mpeg2.c
 @@ -0,0 +1,124 @@
 +
 +#define OFFSET(x) offsetof(QSVMpegContext, x)
 +#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 +static const AVOption options[] = {
 +{ async_depth, Number of parallel processing, 
 OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 = ASYNC_DEPTH_DEFAULT }, 
 0, INT_MAX, VD },
 
 number of parallel processes?
 
 
 Depth of asynchronous is OK?

Doubt it, doesn't sound grammatically correct to me :P

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 13/13] qsv: Add MPEG-2 video decoding support

[Tim W.]

On Sep 10, 2013, at 2:57 PM, Diego Biurrun di...@biurrun.de wrote:

 On Tue, Sep 10, 2013 at 09:15:47PM +0900, Yukinori Yamazoe wrote:
 2013/9/9 Diego Biurrun di...@biurrun.de:
 On Sun, Sep 08, 2013 at 03:22:35AM +0900, Yukinori Yamazoe wrote:
 --- /dev/null
 +++ b/libavcodec/qsv_mpeg2.c
 @@ -0,0 +1,124 @@
 +
 +#define OFFSET(x) offsetof(QSVMpegContext, x)
 +#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 +static const AVOption options[] = {
 +{ async_depth, Number of parallel processing, 
 OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 = ASYNC_DEPTH_DEFAULT }, 
 0, INT_MAX, VD },
 
 number of parallel processes?
 
 Depth of asynchronous is OK?
 
 To be completely honest, I'm starting to doubt what you are trying to
 express in the first place.  Could you explain in a few sentences what
 this option is supposed to accomplish?
 
 Diego

As discussed on IRC: 
https://trac.handbrake.fr/browser/trunk/test/test.c?rev=5737#L3456

(see --qsv-async-depth)

Maybe something along those lines?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] qsv: Various improvements

[Tim W.]

On Sep 2, 2013, at 6:09 PM, Luca Barbato lu_z...@gentoo.org wrote:

 On 02/09/13 16:45, Luca Barbato wrote:
 From: Yukinori Yamazoe droco...@gmail.com
 
 ---
 
 +int ff_qsv_postinit(AVCodecContext *avctx, QSVContext *q)
 {
 -int i;
 -for (i = 0; i  q-nb_surfaces; i++) {
 -if (q-pts[i] == AV_NOPTS_VALUE)
 -break;
 -}
 +avctx-width = q-param.mfx.FrameInfo.CropW;
 +avctx-height= q-param.mfx.FrameInfo.CropH;
 
 why using the Crop dimensions?

Take 1080p:

mfx.FrameInfo.Width:  1920
mfx.FrameInfo.Height: 1088 // coded_height
mfx.FrameInfo.CropW:  1920
mfx.FrameInfo.CropH:  1080

Tim


___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] matroskaenc: Fix writing TRACKDEFAULTFLAG

[Tim W.]

On Aug 22, 2013, at 6:01 PM, Luca Barbato lu_z...@gentoo.org wrote:

 On 22/08/13 17:54, John Stebbins wrote:
 The element was only being written when the value == 1.  But the default
 value of this element is 1, so this has no useful effect.  This element
 needs to be written when the value == 0.
 ---
 libavformat/matroskaenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 
 
 I trust you on that.
 
 lu

It's easily checkable, too:

http://www.matroska.org/technical/specs/index.html

FlagDefault

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] mov: use tkhd enabled flag to set the default track

[Tim W.]

On Aug 21, 2013, at 5:33 PM, John Stebbins stebb...@jetheaddev.com wrote:

 ---
 libavformat/isom.h |  5 +
 libavformat/mov.c  | 14 --
 2 files changed, 13 insertions(+), 6 deletions(-)
 
 diff --git a/libavformat/isom.h b/libavformat/isom.h
 index 932b1d0..94f1296 100644
 --- a/libavformat/isom.h
 +++ b/libavformat/isom.h
 @@ -190,6 +190,11 @@ void ff_mp4_parse_es_descr(AVIOContext *pb, int *es_id);
 #define MOV_FRAG_SAMPLE_FLAG_DEPENDS_NO0x0200
 #define MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES   0x0100
 
 +#define MOV_TKHD_FLAG_ENABLED   0x0001
 +#define MOV_TKHD_FLAG_IN_MOVIE  0x0002
 +#define MOV_TKHD_FLAG_IN_PREVIEW0x0004
 +#define MOV_TKHD_FLAG_IN_POSTER 0x0008
 +
 int ff_mov_read_esds(AVFormatContext *fc, AVIOContext *pb, MOVAtom atom);
 enum AVCodecID ff_mov_get_lpcm_codec_id(int bps, int flags);
 
 diff --git a/libavformat/mov.c b/libavformat/mov.c
 index 0c938cd..c644699 100644
 --- a/libavformat/mov.c
 +++ b/libavformat/mov.c
 @@ -2125,6 +2125,7 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext 
 *pb, MOVAtom atom)
 AVStream *st;
 MOVStreamContext *sc;
 int version;
 +int flags;
 
 if (c-fc-nb_streams  1)
 return 0;
 @@ -2132,13 +2133,14 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext 
 *pb, MOVAtom atom)
 sc = st-priv_data;
 
 version = avio_r8(pb);
 -avio_rb24(pb); /* flags */
 -/*
 -MOV_TRACK_ENABLED 0x0001
 -MOV_TRACK_IN_MOVIE 0x0002
 -MOV_TRACK_IN_PREVIEW 0x0004
 -MOV_TRACK_IN_POSTER 0x0008
 +flags = avio_rb24(pb);
 +/* flags
 +MOV_TKHD_FLAG_ENABLED0x0001
 +MOV_TKHD_FLAG_IN_MOVIE   0x0002
 +MOV_TKHD_FLAG_IN_PREVIEW 0x0004
 +MOV_TKHD_FLAG_IN_POSTER  0x0008
 */

This comment seems overkill now, IMO.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Add a libfdk-aac decoder

[Tim W.]

On Aug 15, 2013, at 11:45 PM, Diego Biurrun di...@biurrun.de wrote:

 On Thu, Aug 15, 2013 at 04:07:28PM -0400, Justin Ruggles wrote:
 
 
 This can be useful for decoding AAC object types that are not supported
 by the native AAC decoder, e.g. AAC-LD and AAC-ELD.
 
 Why?  What's the point of this alternative decoder?

Did I miss something?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [libav-commits] cabac: x86 version of get_cabac_bypass

[Tim W.]

On Jul 5, 2013, at 8:14 PM, Martin Storsjö mar...@martin.st wrote:

 Don't remember exactly in which version the llvm-gcc became the default 
 instead of plain gcc.

Xcode 4.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] build: do not leave asserts enabled

[Tim W.]

On May 17, 2013, at 3:26 PM, Luca Barbato lu_z...@gentoo.org wrote:

 A library should not crash on purpose.
 ---
 
 I find dangerous leaving them around, the performance loss is negligible
 probably, but leaving them around on release build feels wrong nonetheless.

+1

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] FATE: use a less ambiguous end time for filter-trim-time test

[Tim W.]

On May 5, 2013, at 8:01 AM, Anton Khirnov an...@khirnov.net wrote:

 0.1 seconds at 25 fps is exactly 2.5 frames, which may be rounded either
 to 2 or 3 on different platforms.

.09 is still exactly 4.5 frames at 50 fps, which is not as common as 25 but not 
completely uncommon either…

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] FATE: use a less ambiguous end time for filter-trim-time test

[Tim W.]

On May 5, 2013, at 5:22 PM, Anton Khirnov an...@khirnov.net wrote:

 
 On Sun, 5 May 2013 16:49:00 +0200, Tim W. tdskywal...@gmail.com wrote:
 On May 5, 2013, at 8:01 AM, Anton Khirnov an...@khirnov.net wrote:
 
 0.1 seconds at 25 fps is exactly 2.5 frames, which may be rounded either
 to 2 or 3 on different platforms.
 
 .09 is still exactly 4.5 frames at 50 fps, which is not as common as 25 but 
 not completely uncommon either…
 
 
 The point is that in this specific test the input is (or defaults to) 25 fps.

Oh, OK.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] ape: provide two additional bytes in buffer for old MAC versions

[Tim W.]

On Mar 13, 2013, at 6:25 AM, Kostya Shishkov kostya.shish...@gmail.com wrote:

 On Tue, Mar 12, 2013 at 11:11:24PM +0100, Tim W. wrote:
 What does MAC stand for? If it's Apple, then MAC - Mac ;-)
 
 In this context it's Monkey's Audio Codec.

OK, thanks for the clarification.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] ape: provide two additional bytes in buffer for old MAC versions

[Tim W.]

What does MAC stand for? If it's Apple, then MAC - Mac ;-)

Tim

On Mar 12, 2013, at 8:08 PM, Kostya Shishkov kostya.shish...@gmail.com wrote:

 Range coder in 3.90-3.95 overread two bytes in the final normalize.
 ---
 libavcodec/apedec.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
 index 13d92e9..a46b040 100644
 --- a/libavcodec/apedec.c
 +++ b/libavcodec/apedec.c
 @@ -912,11 +912,13 @@ static int ape_decode_frame(AVCodecContext *avctx, void 
 *data,
 av_log(avctx, AV_LOG_WARNING, packet size is not a multiple of 
 4. 
extra bytes at the end will be skipped.\n);
 }
 -
 +if (s-fileversion  3950) // previous versions overread two bytes
 +buf_size += 2;
 av_fast_malloc(s-data, s-data_size, buf_size);
 if (!s-data)
 return AVERROR(ENOMEM);
 s-dsp.bswap_buf((uint32_t*)s-data, (const uint32_t*)buf, buf_size 
  2);
 +memset(s-data + (buf_size  ~3), 0, buf_size  3);
 s-ptr = s-data;
 s-data_end = s-data + buf_size;
 
 -- 
 1.7.9.5
 
 ___
 libav-devel mailing list
 libav-devel@libav.org
 https://lists.libav.org/mailman/listinfo/libav-devel

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 41/42] lavc: postpone the removal of request_channels API.

[Tim W.]

It's partly my fault :-( :P

Still, I'd like to see how Justin intends to deal with it for AC3 before I 
re-visit my patch for the DTS decoder.

As a side note, do any decoders other than AC3, DCA and MLP actually implement 
request_channels?

Also, some people seem to rely on request_channels for DCA, but the downmix is 
broken (as in wrong, it's more than just potential clipping). Is it maybe worth 
fixing?

Tim

On Mar 4, 2013, at 11:35 AM, Anton Khirnov an...@khirnov.net wrote:

 Its replacement is still not ready.
 ---
 libavcodec/version.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavcodec/version.h b/libavcodec/version.h
 index 20da9cb..8a6a39c 100644
 --- a/libavcodec/version.h
 +++ b/libavcodec/version.h
 @@ -47,7 +47,7 @@
  */
 
 #ifndef FF_API_REQUEST_CHANNELS
 -#define FF_API_REQUEST_CHANNELS (LIBAVCODEC_VERSION_MAJOR  55)
 +#define FF_API_REQUEST_CHANNELS (LIBAVCODEC_VERSION_MAJOR  56)
 #endif
 #ifndef FF_API_OLD_DECODE_AUDIO
 #define FF_API_OLD_DECODE_AUDIO (LIBAVCODEC_VERSION_MAJOR  55)
 -- 
 1.7.10.4
 
 ___
 libav-devel mailing list
 libav-devel@libav.org
 https://lists.libav.org/mailman/listinfo/libav-devel

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Announce Release 9.3

[Tim W.]

Not complaining, but why so soon after 9.2?

Tim

Sent from my iPhone

On Mar 2, 2013, at 12:13 PM, Reinhard Tartler siret...@tauware.de wrote:

 ---
 src/download |   22 +++---
 src/news |   21 +
 2 files changed, 32 insertions(+), 11 deletions(-)
 
 diff --git a/src/download b/src/download
 index 15fdb2b..4388e91 100644
 --- a/src/download
 +++ b/src/download
 @@ -208,23 +208,23 @@ and much faster bug fixes such as additional features 
 and security patches.
 a name=release_9/ah2Libav 9 plain 9/h2
 
 p
 -9.2 was released on 2013-02-24. It is the latest point release from
 +9.3 was released on 2013-03-02. It is the latest point release from
 the version 9 release branch, which was released on 2013-01-05. Please
 give us feedback and use our Bugzilla for filing
 bugs: a href=https://bugzilla.libav.org;https://bugzilla.libav.org//a
 /p
 
 p
 -a href=releases/libav-9.2.tar.xzDownload XZ tarball/anbsp;nbsp;
 -a href=releases/libav-9.2.tar.xz.md5MD5/a
 -a href=releases/libav-9.2.tar.xz.sha1SHA1/a
 -a href=releases/libav-9.2.tar.xz.ascPGP signature/abr /
 -a href=releases/libav-9.2.tar.gzDownload gzip tarball/anbsp;nbsp;
 -a href=releases/libav-9.2.tar.gz.md5MD5/a
 -a href=releases/libav-9.2.tar.gz.sha1SHA1/a
 -a href=releases/libav-9.2.tar.gz.ascPGP signature/abr /
 -a href=releases/libav-9.2.changelogChangelog/abr /
 -a href=releases/libav-9.2.releaseRelease Notes/a
 +a href=releases/libav-9.3.tar.xzDownload XZ tarball/anbsp;nbsp;
 +a href=releases/libav-9.3.tar.xz.md5MD5/a
 +a href=releases/libav-9.3.tar.xz.sha1SHA1/a
 +a href=releases/libav-9.3.tar.xz.ascPGP signature/abr /
 +a href=releases/libav-9.3.tar.gzDownload gzip tarball/anbsp;nbsp;
 +a href=releases/libav-9.3.tar.gz.md5MD5/a
 +a href=releases/libav-9.3.tar.gz.sha1SHA1/a
 +a href=releases/libav-9.3.tar.gz.ascPGP signature/abr /
 +a href=releases/libav-9.3.changelogChangelog/abr /
 +a href=releases/libav-9.3.releaseRelease Notes/a
 /p
 
 a name=release_0.8/ah2Libav 0.8.5 Forbidden Fruit/h2
 diff --git a/src/news b/src/news
 index 674e726..86c2c26 100644
 --- a/src/news
 +++ b/src/news
 @@ -1,5 +1,26 @@
 h1News/h1
 
 +a name=9.2/ah3March 2, 2013/h3
 +p
 +We have been made aware about a security issue in our vorbis
 +decoder. Therefore, we push out a small and quick
 +update, a href=download.html#release_9Libav 9.3/a, that fixes
 +CVE-2013-0894. Besides this, we also include a small number of critical
 +correction to our H.264, Flash Video and AC3 decoders. For details,
 +please refer to the verbose
 +a 
 href=http://git.libav.org/?p=libav.git;a=blob;f=Changelog;hb=refs/tags/v9.3;
 +Changelog file/a.
 +/p
 +
 +p
 +Distributors and system integrators are encouraged to update and share
 +their patches against our release branches.
 +/p
 +
 +p
 +You can download the new release, as usual,
 +from a href=download.html#release_9our download page/a.
 +/p
 
 a name=9.2/ah3February 24, 2013/h3
 p
 -- 
 1.7.9.5
 
 ___
 libav-devel mailing list
 libav-devel@libav.org
 https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] flac: don't check the number of channels before setting the channel layout.

[Tim W.]

Ping.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] flac: add channel layout masks for streams with 7 or 8 channels.

[Tim W.]

Ping.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] libvpx: make vp8 and vp9 selectable

[Tim W.]

On Jan 3, 2013, at 4:37 PM, Luca Barbato lu_z...@gentoo.org wrote:

 +#if CONFIG_LIBVPX_VP9_ENCODER
 static av_cold int vp9_init(AVCodecContext *avctx)
 {
 return vpx_init(avctx, vpx_codec_vp9_cx_algo);
 @@ -613,7 +615,6 @@ static const AVClass class_vp9 = {
 .version= LIBAVUTIL_VERSION_INT,
 };
 
 -
 AVCodec ff_libvpx_vp9_encoder = {
 .name   = libvpx-vp9,
 .type   = AVMEDIA_TYPE_VIDEO,
 @@ -628,3 +629,5 @@ AVCodec ff_libvpx_vp9_encoder = {
 .priv_class = class_vp9,
 .defaults   = defaults,
 };
 +#endif // CONFIG_LIBVPX_VP8_ENCODER


CONFIG_LIBVPX_VP9_ENCODER?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/6] mlp: implement support for AVCodecContext.request_channel_layout.

[Tim W.]

On Dec 31, 2012, at 3:33 PM, Tim Walker tdskywal...@gmail.com wrote:

 Also wrap usage of AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS 
 directives.
 ---
 libavcodec/mlp_parser.c |   29 +++--
 libavcodec/mlpdec.c |   18 ++
 2 files changed, 37 insertions(+), 10 deletions(-)

With this patch, request_channels always applies before request_channel_layout 
(in the rare case where both are set). I could easily reverse it 
(request_channel_layout, then request_channels) if someone thinks it's better 
though.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/8] mlpdec: store the channel layout for each substream.

[Tim W.]

On Dec 29, 2012, at 3:49 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 12/28/2012 08:05 PM, Tim Walker wrote:
 ---
 libavcodec/mlpdec.c |   17 +
 1 file changed, 17 insertions(+)
 
 diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
 index 3852f6e..6af3a71 100644
 --- a/libavcodec/mlpdec.c
 +++ b/libavcodec/mlpdec.c
 @@ -28,6 +28,7 @@
 
 #include avcodec.h
 #include libavutil/intreadwrite.h
 +#include libavutil/channel_layout.h
 #include get_bits.h
 #include internal.h
 #include libavutil/crc.h
 @@ -56,6 +57,8 @@ typedef struct SubStream {
 uint8_t max_matrix_channel;
 /// For each channel output by the matrix, the output channel to map it 
 to
 uint8_t ch_assign[MAX_CHANNELS];
 +/// The channel layout for this substream
 +uint64_tch_layout;
 
 /// Channel coding parameters for channels in the substream
 ChannelParams channel_params[MAX_CHANNELS];
 @@ -325,6 +328,20 @@ static int read_major_sync(MLPDecodeContext *m, 
 GetBitContext *gb)
 for (substr = 0; substr  MAX_SUBSTREAMS; substr++)
 m-substream[substr].restart_seen = 0;
 
 +if (m-avctx-codec_id == AV_CODEC_ID_MLP) {
 +if ((substr = (mh.num_substreams  1)))
 +m-substream[0].ch_layout = AV_CH_LAYOUT_STEREO;
 +m-substream[substr].ch_layout = mh.channel_layout_mlp;
 +} else {
 +if ((substr = (mh.num_substreams  1)))
 +m-substream[0].ch_layout = AV_CH_LAYOUT_STEREO;
 +if (mh.channel_layout_thd_stream2  mh.num_substreams  2)
 +m-substream[2].ch_layout = mh.channel_layout_thd_stream2;
 +else if (mh.num_substreams  2)
 +m-substream[2].ch_layout = mh.channel_layout_thd_stream1;
 +m-substream[substr].ch_layout = mh.channel_layout_thd_stream1;
 +}
 +
 return 0;
 }
 
 
 The logic there is not exactly obvious. Maybe you could add some
 comments explaining it a bit more.
 
 -Justin

Agreed. Will do.

Tim

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 7/8] mlp: wrap usage of deprecated AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives.

[Tim W.]

On Dec 29, 2012, at 3:57 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 12/28/2012 08:05 PM, Tim Walker wrote:
 ---
 libavcodec/mlp_parser.c |9 +
 libavcodec/mlpdec.c |2 ++
 2 files changed, 11 insertions(+)
 
 The point of deprecating request_channels is not to remove the
 functionality completely, but to replace it with request_channel_layout.
 So any patch removing request_channels functionality should implement
 request_channel_layout. It should be pretty straightforward after your
 other patches right?
 
 -Justin

If I'm only required to handle (m-avctx-request_channel_layout == 
s-ch_layout), yes. Which I guess would work for now.

There might be some cases where we'd want to check for something close enough 
(e.g. 2.0/5.1/7.1 source, 3.0 requested, we'd probably want to decode the 5.1 
substream). Not sure how to best handle that.

Maybe:

if (m-avctx-request_channel_layout 
(s-ch_layout  m-avctx-request_channel_layout) ==
m-avctx-request_channel_layout)
// discard further substreams

???

Or maybe we want something more elaborate to compare channel layouts, possibly 
in libavutil?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 6/8] mlp_parser: account for AVCodecContext.request_channels when setting the channel layout.

[Tim W.]

On Dec 29, 2012, at 4:07 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 12/28/2012 08:05 PM, Tim Walker wrote:
 Allows users (e.g. avconv) to configure the output based on what will 
 actually be decoded.
 
 Fixes the rest of bug 401.
 ---
 libavcodec/mlp_parser.c |   18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)
 
 diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
 index 31c79c9..8c57840 100644
 --- a/libavcodec/mlp_parser.c
 +++ b/libavcodec/mlp_parser.c
 @@ -322,11 +322,23 @@ static int mlp_parse(AVCodecParserContext *s,
 
 if (mh.stream_type == 0xbb) {
 /* MLP stream */
 -avctx-channels   = mh.channels_mlp;
 -avctx-channel_layout = mh.channel_layout_mlp;
 +if (avctx-request_channels  0  avctx-request_channels = 2 
 
 +mh.num_substreams  1) {
 +avctx-channels   = 2;
 +avctx-channel_layout = AV_CH_LAYOUT_STEREO;
 +} else {
 +avctx-channels   = mh.channels_mlp;
 +avctx-channel_layout = mh.channel_layout_mlp;
 +}
 } else { /* mh.stream_type == 0xba */
 /* TrueHD stream */
 -if (mh.channels_thd_stream2) {
 +if (avctx-request_channels  0  avctx-request_channels = 2 
 
 +mh.num_substreams  1) {
 +avctx-channels   = 2;
 +avctx-channel_layout = AV_CH_LAYOUT_STEREO;
 +} else if (mh.channels_thd_stream2 
 +   (avctx-request_channels = 0 ||
 +avctx-request_channels  mh.channels_thd_stream1)) 
 {
 avctx-channels   = mh.channels_thd_stream2;
 avctx-channel_layout = mh.channel_layout_thd_stream2;
 } else {
 
 Looks ok for now.
 
 Although ideally I would like to not handle
 request_channels/channel_layout in the parsers at all. To do that we
 would need to allow the decoders to set AVFrame.channel_layout to the
 requested layout prior to calling get_buffer() and have that used by
 get_buffer() instead of AVCodecContext.channel_layout (which would be
 the native layout of the stream) when applicable.
 
 -Justin

The use case for this patch is the following:

1) foo.thd, TrueHD source with 2.0, 5.1 and 7.1 substreams

2) avconv -request_channels 2 -i foo.thd

…the reported layout is 7.1. So when doing:

avconv -request_channels 2 -i foo.thd out.wav

…the output is 7.1, with 6 empty channels.

This doesn't happen with the AC3 or DCA decoders (layout is reported as Stereo 
and output is configured for Stereo unless requested otherwise).

While someone using -request_channels 2 (or its successor) will probably want 
to forcibly configure output to Stereo anyway, it still annoys me for some 
reason.

There might be a better fix for this which won't affect the parser, but I'm not 
familiar enough with the code and/or haven't been able to figure it out yet.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 7/8] mlp: wrap usage of deprecated AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives.

[Tim W.]

As a side note, I don't think there is any facility to let the user know which 
layout(s) the decoder can output without external (avresample) help?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 7/8] mlp: wrap usage of deprecated AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives.

[Tim W.]

On Dec 29, 2012, at 5:35 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 12/29/2012 11:07 AM, Tim W. wrote:
 As a side note, I don't think there is any facility to let the user know 
 which layout(s) the decoder can output without external (avresample) help?
 
 AVCodec.channel_layouts could be used for that.
 
 Typically such a list would be very long though and not really that
 useful since the actual set of possible layouts will always depend on
 the input.

No, I meant a facility to let the user know what the decoder can do with the 
current stream being parsed/decoded.

Tim

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 7/8] mlp: wrap usage of deprecated AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives.

[Tim W.]

On Dec 29, 2012, at 5:40 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 12/29/2012 11:00 AM, Tim W. wrote:
 On Dec 29, 2012, at 3:57 PM, Justin Ruggles justin.rugg...@gmail.com wrote:
 
 On 12/28/2012 08:05 PM, Tim Walker wrote:
 ---
 libavcodec/mlp_parser.c |9 +
 libavcodec/mlpdec.c |2 ++
 2 files changed, 11 insertions(+)
 
 The point of deprecating request_channels is not to remove the
 functionality completely, but to replace it with request_channel_layout.
 So any patch removing request_channels functionality should implement
 request_channel_layout. It should be pretty straightforward after your
 other patches right?
 
 -Justin
 
 If I'm only required to handle (m-avctx-request_channel_layout == 
 s-ch_layout), yes. Which I guess would work for now.
 
 There might be some cases where we'd want to check for something close 
 enough (e.g. 2.0/5.1/7.1 source, 3.0 requested, we'd probably want to 
 decode the 5.1 substream). Not sure how to best handle that.
 
 The only close enough we need to match is when the layouts differ only
 in rear vs. side surrounds. If the requested layout doesn't match any of
 the substreams I don't think we need to try to guess the closest. The
 user can remix on their own in that case.
 
 -Justin

I'll do just == for now. The 'close enough' part can be done later, at which 
point we could decide whether to have a libavutil channel layout helper rather 
than implementing it in every decoder.

Or do you think I should really go the extra mile in this patch already?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] flac: only set channel layout if not previously set or on channel count change

[Tim W.]

On Dec 16, 2012, at 5:13 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 @@ -457,9 +457,13 @@ static int get_best_header(FLACParseContext* fpc, const 
 uint8_t **poutbuf,
 check_header_mismatch(fpc, header, child, 0);
 }
 
 +if (header-fi.channels != fpc-avctx-channels ||
 +(!fpc-avctx-channel_layout  header-fi.channels = 6)) {
 +fpc-avctx-channels = header-fi.channels;
 +ff_flac_set_channel_layout(fpc-avctx);
 +}
 fpc-avctx-sample_rate = header-fi.samplerate;
 fpc-avctx-channels= header-fi.channels;



fpc-avctx-channels = header-fi.channels;

…is being called twice. The second line could be removed?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] matroskadec: fix variable name in a sanity check.

[Tim W.]

On Sep 20, 2012, at 8:13 PM, Anton Khirnov an...@khirnov.net wrote:

 Based on a patch by Michael Niedermayer michae...@gmx.at.
 ---
 libavformat/matroskadec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
 index 442db23..c73eb2c 100644
 --- a/libavformat/matroskadec.c
 +++ b/libavformat/matroskadec.c
 @@ -1804,7 +1804,7 @@ static int matroska_parse_laces(MatroskaDemuxContext 
 *matroska, uint8_t **buf,
 }
 
 case 0x2: /* fixed-size lacing */
 -if (size != (size / *laces) * size) {
 +if (size != (size / *laces) * (*laces)) {

Didn't Mans suggest (size % *laces) as an equivalent?

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/3] lavu/audioconvert: add a second low frequency channel.

[Tim W.]

On Sep 12, 2012, at 6:59 PM, Justin Ruggles justin.rugg...@gmail.com wrote:

 On 09/12/2012 11:09 AM, Tim Walker wrote:
 Can be used by DTS-HD, TrueHD and E-AC-3, among others.
 ---
 doc/APIchanges   |3 +++
 libavutil/audioconvert.c |1 +
 libavutil/audioconvert.h |1 +
 libavutil/version.h  |2 +-
 4 files changed, 6 insertions(+), 1 deletion(-)
 
 patch set looks good. I'll apply all 3 shortly.
 
 btw, are there any cases where we might want to mix both LFE and LFE2
 into a downmix?

No idea. I don't have, and can't produce, a sample with 2 LFE channels.

Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 2/2] mlpdec_parser: fix a few channel layouts.

[Tim W]

truehd_layout(): layout variable should be uint64_t to work with 
AV_CH_WIDE_LEFT etc.

This patch fixes the following samples:

Sample 1 (TrueHD, L R C LFE Ls Rs Lc Rc)


http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7front1.png
http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7front1.mka

Before patch:

avconv -i SpeakerID-7front1.mka 
avconv version v0.8-634-g535a80c, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:47:55 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7f936981ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7front1.mka':
  Duration: 00:00:31.66, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 8 channels (FL|FR|FC|LFE|SL|SR), 
s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR (, SL, SR) - incorrect (see PNG)

After patch:

avconv -i SpeakerID-7front1.mka 
avconv version v0.8-635-gda78073, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:55:32 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7ff6e281ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7front1.mka':
  Duration: 00:00:31.66, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 7.1(wide), s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR, FLC, FRC - correct (see PNG)

Sample 2 (TrueHD, L R C LFE Ls Rs Lw Rw)


http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7wide1.png
http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7wide1.mka

Before patch:

avconv -i SpeakerID-7wide1.mka 
avconv version v0.8-634-g535a80c, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:47:55 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7fbaa181ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7wide1.mka':
  Duration: 00:00:34.86, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 7.1(wide), s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR, FLC, FRC - incorrect (see PNG)

After patch:

avconv -i SpeakerID-7wide1.mka 
avconv version v0.8-635-gda78073, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:55:32 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7fdfc201ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7wide1.mka':
  Duration: 00:00:34.86, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 8 channels 
(FL|FR|FC|LFE|SL|SR|WL|WR), s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR, WL, WR - correct (see PNG)

Sample 3 (TrueHD, L R C LFE Ls Rs Cvh Ts)
-

http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7top1back.png
http://dl.dropbox.com/u/37259775/audio/truehd/SpeakerID-7top1back.mka

Before patch:

avconv -i SpeakerID-7top1back.mka 
avconv version v0.8-634-g535a80c, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:47:55 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7f93db81ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7top1back.mka':
  Duration: 00:00:34.81, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 8 channels 
(FL|FR|FC|LFE|SL|SR|TBC), s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR, TBC (, TBC) - incorrect (see PNG)

After patch:

avconv -i SpeakerID-7top1back.mka 
avconv version v0.8-635-gda78073, Copyright (c) 2000-2012 the Libav developers
  built on Feb 22 2012 15:55:32 with llvm_gcc 4.2.1 (Based on Apple Inc. build 
5658) (LLVM build 2336.1.00)
[matroska,webm @ 0x7fca6281ae00] Estimating duration from bitrate, this may be 
inaccurate
Input #0, matroska,webm, from 'SpeakerID-7top1back.mka':
  Duration: 00:00:34.81, start: 0.00, bitrate: N/A
Stream #0.0(eng): Audio: truehd, 48000 Hz, 8 channels 
(FL|FR|FC|LFE|SL|SR|TFC|TBC), s32 (default)
At least one output file must be specified

FL, FR, FC, LFE, SL, SR, TFC, TBC - (seems) correct (see PNG)

I also believe:

AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT,   // LRsd

should be:

AV_CH_SURROUND_DIRECT_LEFT|AV_CH_SURROUND_DIRECT_RIGHT, // LRsd

but I have no samples to test with so I left it out of the patch.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel