Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

2022-07-22 Thread Alex Converse 
On Fri, Jul 22, 2022 at 8:37 AM James Almer  wrote:
> On 7/22/2022 12:14 PM, Andreas Rheinhardt wrote:
> > James Almer:
> >> On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote:
> >>> James Almer:
>  On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote:
> > James Almer:
> >> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote:
> >>> James Almer:
>  On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
> > James Almer:
> >> Should fix ticket #3361
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> This also needs an update to some fate ref samples i'll upload
> >> before
> >> pushing
> >> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which
> >> are now
> >> decoded
> >> properly as he_aac mono, so the .s16 files need to be replaced).
> >>
> >

[snip]

> >>
> >>
> >> it seems at least for these samples the fixed decoder does not
> >> generate
> >> a decoded stream comparable to the float one, so I'll just upload a
> >> new
> >> raw pcm file.
> >
> > When I decode both of these streams with git master, the left
> > channel is
> > pretty much identical, yet the right channel of the fixed-point decoder
> > is silent and the right channel of the floating point decoder is not.
> > With this patch applied, the result are two mono streams that are
> > pretty
> > much identical: The test sample created by the floating-point decoder
> > works with the fixed-point decoder test (if one uncomments and modifies
> > the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to
> > upload new samples.
> 
>  Ok, can you suggest how to add a test that decodes with the fixed point
>  decoder then compares that with the output of the float decoder? Is
>  there a helper in fate.sh already for this?
> 
> >>>
> >>> There is currently no helper in fate-run.sh for this.
> >>
> >> Yeah, figures that's the case. Can you suggest how one would work for this?
> >>
> >
> > A new function in fate-run.sh seems to be necessary. Given that a
> > similar situation exists for AC-3 we should not hardcode aac; instead it
> > should have two parameters for the float and the fixed decoder. Then it
> > should decode the input file twice and do the same comparison that the
> > current tests use (they use the oneoff method, which results in
> > do_tiny_psnr with MAXDIFF being called).
> > I think the tests for the fixed-point decoder (with checksums) should be
> > separate, so that one can test this without the floating-point decoder
> > being present.
> >
> >>>
> >
> > - Andreas
> >
> > PS: libfdk-aac produces a file that looks pretty much like the floating
> > point decoder from git master. Are you sure your patch is correct?
> 
>  Yes, they duplicate the single channel in the stream and output it as
>  stereo, something that should be done by a filter if that's what the
>  user wants. Decoding a mono sample should generate a mono stream.
> >>>
> >>> Not really. The channels are different.
> >>
> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> >> channelmap=channel_layout=mono:map=0 -f md5 -
> >>
> >> has the same result as
> >>
> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af
> >> channelmap=channel_layout=mono:map=1 -f md5 -
> >>
> >> Same with the samples in the ticket.
> >>
> >
> > This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for
> > al_sbr_ps_06_new.mp4.
>
> So looks like nearly a hundred samples into al_sbr_ps_06_new.mp4 frames
> start containing PS info. With this patch the decoder properly decodes
> the first hundred as mono, but since the decoder is locked, it will keep
> decoding the stereo samples as mono.
>

Hey all,

I thought I should share a little bit of context about this problem,
but I don't mean to come back from nowhere and try to overrule you
all. Do what you decide is best.

An HE-AACv2 decoder treating unsignaled mono as stereo is an
intentional design trade-off that the MPEG audio committee made. It is
a tradeoff that the FFmpeg decoder has mimicked for a number of years.
If you want to revisit the trade-off (and there may very well be good
reasons to do that) that's fine, but I think treating the current
behavior as a "bug" is the wrong approach.

In fact, those fate tests are based on a Coding Technologies test
suite designed to validate a decoder conformed to the MPEG behavior.

Parametric Stereo is nested inside the SBR extension after the main
SBR payload which itself is nested inside the AAC raw data block after
the main channel elements. It takes a full bitstream parse of both the
AAC and SBR layers and finding an SBR intra-frame to even see if PS is
present.


As for why I think MPEG made this trade-off (my opinion of why they did this) :
- It enables cutting (or joining a stream of)

Re: [FFmpeg-devel] [PATCH 1/1] libavformat/rtmp: Implements RTMP reconnect feature

2021-10-21 Thread Alex Converse 
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)

It seems like this approach is operating from the assumption that the
time to setup a new connection and process all RPCs necessary to send
media is on the order of normal jitter. Or am I misunderstanding?

For many services I don't really think that's the case.

And even with a very fast publish response we are looking at like 1.5
RTTs for TCP, another 1.5 for TLS, another 1.5 for RTMP handshake,
another 1 RTT for RTMP connect, an RTT on createStream, and an RTT on
publish. That's like 7.5 RTTs (or 300 ms at 40ms RTT) where we are
leaving the media flow on pause while we are re-building the connection.

This also seems to conflate rebootstrapping a media decode session vs
re-bootstrapping an RMTP session. The cost of doing this seems to be
sending your biggest frame after a pause to resolve a bunch of
synchronous RPCs on a relatively fresh TCP connection.

> ---
>  libavformat/rtmppkt.c   |  19 +++
>  libavformat/rtmppkt.h   |  10 ++
>  libavformat/rtmpproto.c | 356 +---
>  3 files changed, 359 insertions(+), 26 deletions(-)
>
>[...]
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
>  RTMP_PT_SHARED_OBJ, ///< shared object
>  RTMP_PT_INVOKE, ///< invoke some stream action
>  RTMP_PT_METADATA = 22,  ///< FLV metadata
> +RTMP_PT_GO_AWAY  = 32,  ///< Indicates please reconnect ASAP, server 
> is about to go down
>  } RTMPPacketType;
>

I'm curious as to why this is a new top level message rather than just another
type 20 command message. Message types have a small address space while
commands have a large address space and a well chosen command name is unlikely
to conflict with (and therefore can be used in concert with) any other protocol
extensions.

> [snip]


On Sun, Sep 26, 2021 at 1:52 PM Jordi Cenzano  wrote:
>
> Nowadays when you are streaming to a live platform if the RTMP(s)
> server needs to restarted for any reason (ex: deploy new version)
> the RTMP connection is interrupted (probably after some draining time).
> Facebook will publish a proposal to avoid that by sending a
> GoAway message in the RTMP protocol.
> This code is the reference client implementation of that proposal.
> AFAIK other big live platforms showed their interest in implementing
> this mechanism.
> This can be already tested against Facebook live production using
> the querystring parameter ?ccr_sec=120 (that indicates the backend
> to send a disconnect signal after those seconds)
> ---
>  libavformat/rtmppkt.c   |  19 +++
>  libavformat/rtmppkt.h   |  10 ++
>  libavformat/rtmpproto.c | 356 +---
>  3 files changed, 359 insertions(+), 26 deletions(-)
>
> diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
> index 4b97c0833f..84ec72740d 100644
> --- a/libavformat/rtmppkt.c
> +++ b/libavformat/rtmppkt.c
> @@ -405,6 +405,25 @@ int ff_rtmp_packet_write(URLContext *h, RTMPPacket *pkt,
>  return written;
>  }
>
> +int ff_rtmp_packet_clone(RTMPPacket *pkt_dst, const RTMPPacket *pkt_src)
> +{
> +if (pkt_src->size) {
> +pkt_dst->data = av_realloc(NULL, pkt_src->size);
> +if (!pkt_dst->data)
> +return AVERROR(ENOMEM);
> +else
> +memcpy(pkt_dst->data, pkt_src->data, pkt_src->size);
> +}
> +pkt_dst->size   = pkt_src->size;
> +pkt_dst->channel_id = pkt_src->channel_id;
> +pkt_dst->type   = pkt_src->type;
> +pkt_dst->timestamp  = pkt_src->timestamp;
> +pkt_dst->extra  = pkt_src->extra;
> +pkt_dst->ts_field   = pkt_src->ts_field;
> +
> +return 0;
> +}
> +
>  int ff_rtmp_packet_create(RTMPPacket *pkt, int channel_id, RTMPPacketType 
> type,
>int timestamp, int size)
>  {
> diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
> index a15d2a5773..cdb901df89 100644
> --- a/libavformat/rtmppkt.h
> +++ b/libavformat/rtmppkt.h
> @@ -59,6 +59,7 @@ typedef enum RTMPPacketType {
>  RTMP_PT_SHARED_OBJ, ///< shared object
>  RTMP_PT_INVOKE, ///< invoke some stream action
>  RTMP_PT_METADATA = 22,  ///< FLV metadata
> +RTMP_PT_GO_AWAY  = 32,  ///< Indicates

Re: [FFmpeg-devel] [PATCH v3 3/3] avcodec/aacdec: Translate PCE to avutil channel layouts

2018-10-24 Thread Alex Converse 
On Wed, Oct 24, 2018 at 1:03 PM pkv.stream  wrote:
>
> Patch updated ; passes all FATE tests.
>
> Comments from Alex Converse review incorporated (much thanks to him).
>

Hey,

I'm a bit concerned with the outputs this generates for low channel
count streams.

al17_44.mp4 has two front SCEs.

"ISO/IEC 13818-7:2005(E), 8.5.3.2 Explicit channel mapping using a
program_config_element" says:

Included in the PCE are “list of front channels”, using the rule
center outwards, left before right. In this list, a center channel
SCE, if any, must come first, and any other SCE’s must appear in
pairs, constituting an LR pair. If only two SCE’s are specified, this
signifies one LR stereophonic pair.

Before the patch we were getting L+R. With the patch we are getting
(FC+TFC) (0x2004).

I know of at least one commercial encoder that supports unpaired dual mono.

Do you know which spec the contains the eratta for top channels? There
doesn't seem to be much of value in Amd.6. Do you have any real
examples of a multichannel stream with a top center speaker or any
supporting documentation you could point me at?

Thanks,
Alex
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/aacdec: Translate PCE to avutil channel layouts

2018-10-23 Thread Alex Converse 
> From a12637c97c3140a1676f20b19c91647313379b39 Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Sun, 9 Sep 2018 16:47:32 +0200
> Subject: [PATCH 3/3] avcodec/aacdec: Translate pce to avutil channel_layout
>
> This commit enables the native aac decoder to translate pce to
> ffmpeg channel layouts without any user input.
> For all pce generated by the native aac encoder a table is used.
> For more general pce (up to 20 channels) a custom layout is built.
> Fixes trac issue 7273 with patch 1 of the series.
>
> Signed-off-by: pkviet 
> ---
>  libavcodec/aacdec_template.c | 195 
> +--
>  libavcodec/aacdectab.h   |  43 ++
>  2 files changed, 233 insertions(+), 5 deletions(-)
>

Thanks for the patch. Overall I like this approach, but this patch has some
must-fix issues. In general make sure make fate-aac works with address
sanitizer.

> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index b60b31a92c..53b7ea6669 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -155,6 +155,26 @@ static av_cold int che_configure(AACContext *ac,
>  return 0;
>  }
>
> +static uint8_t* pce_reorder_map(uint64_t layout)
> +{
> +uint8_t map[8] = {0, 1, 2, 3, 4, 5, 6, 7};
> +uint8_t map8[8] = { 2, 0, 1, 6, 7, 4, 5, 3 };
> +uint8_t map7[7] = { 2, 0, 1, 4, 5, 6, 3 };
> +uint8_t map6[6] = { 2, 0, 1, 4, 5, 3 };
> +uint8_t map5[5] = { 2, 0, 1, 4, 3 };
> +if (layout == AV_CH_LAYOUT_7POINT1 || layout == 
> AV_CH_LAYOUT_7POINT1_WIDE ||
> +layout == AV_CH_LAYOUT_7POINT1_WIDE_BACK)
> +return map8;
> +if (layout == AV_CH_LAYOUT_6POINT1 || layout == 
> AV_CH_LAYOUT_6POINT1_BACK ||
> +layout == AV_CH_LAYOUT_6POINT1_FRONT)
> +return map7;
> +if (layout == AV_CH_LAYOUT_5POINT1 || layout == 
> AV_CH_LAYOUT_5POINT1_BACK)
> +return map6;
> +if (layout == AV_CH_LAYOUT_4POINT1)
> +   return map5;
> +return map;

You can't return local stack arrays like this. Return pointers to const arrays
that live outside the function. Consider building with -Wreturn-stack-address.

> +}
> +
>  static int frame_configure_elements(AVCodecContext *avctx)
>  {
>  AACContext *ac = avctx->priv_data;
> @@ -180,10 +200,15 @@ static int frame_configure_elements(AVCodecContext 
> *avctx)
>  if ((ret = ff_get_buffer(avctx, ac->frame, 0)) < 0)
>  return ret;
>
> +/* reorder channels in case pce table was used with LFE channel */
> +uint8_t reorder[8] = { 0 };
> +if (ac->oc[1].m4ac.chan_config == 0 && ac->oc[1].channel_layout && 
> avctx->channels < 9)

Can we ever hit this if with channel_layout == 0? If we can it seems
like all zero output is not what we want.
If we can't then what are we checking it for?

> +memcpy(reorder, pce_reorder_map(ac->oc[1].channel_layout), 
> avctx->channels * sizeof(uint8_t));
>  /* map output channel pointers to AVFrame data */
>  for (ch = 0; ch < avctx->channels; ch++) {
> +int ch_remapped = avctx->channels < 9 ? reorder[ch] : ch;
>  if (ac->output_element[ch])
> -ac->output_element[ch]->ret = (INTFLOAT 
> *)ac->frame->extended_data[ch];
> +ac->output_element[ch]->ret = (INTFLOAT 
> *)ac->frame->extended_data[ch_remapped];
>  }
>
>  return 0;
[...]
> +static uint64_t convert_layout_map_to_av_layout(uint8_t 
> layout_map[MAX_ELEM_ID * 4][3])
> +{
> +int i, config;
> +config = 0;
> +// look up pce table for channel layout correspondance used by native 
> encoder and decoder
nit: "correspondence"
> +for (i = 1; i < PCE_LAYOUT_NBR; i++) {
> +if (memcmp(layout_map, pce_channel_layout_map[i], sizeof(uint8_t) * 
> 3 * PCE_MAX_TAG) == 0) {
nit: use variables with sizeof. e.g. PCE_MAX_TAG * sizeof(layout_map[0])
> +config = i;
> +break;
> +}
> +}
> +
> +switch(config) {
nit: this should probably live as a table with: pce_channel_layout_map
> +case 1: return AV_CH_LAYOUT_HEXADECAGONAL;
> +case 2: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> +   AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> +   AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_CENTER |
> +   AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT;
> +case 3: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> +   AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> +   AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_LEFT |
> +   AV_CH_TOP_BACK_RIGHT;
> +case 4: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> +   AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> +   AV_CH_TOP_FRONT_CENTER | AV_CH_TOP_BACK_CENTER;
> +case 5: return AV_CH_LAYOUT_OCTAGONAL | AV_CH_TOP_CENTER |
> +   AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT |
> +   AV_CH_TOP_FRONT_CENTER;
> +case 6: return

Re: [FFmpeg-devel] [PATCH 2/2] flvenc: Fix sequence header update timestamps

2018-05-29 Thread Alex Converse 
On Sun, May 13, 2018 at 3:24 AM, Michael Niedermayer
 wrote:
> On Thu, May 10, 2018 at 06:40:08PM -0700, Alex Converse wrote:
>> From: Alex Converse 
>>
>> ---
>>  libavformat/flvenc.c | 9 -
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
>> index 9b7cdfe7db..7aa2dbf9a6 100644
>> --- a/libavformat/flvenc.c
>> +++ b/libavformat/flvenc.c
>> @@ -485,7 +485,7 @@ static int unsupported_codec(AVFormatContext *s,
>>  return AVERROR(ENOSYS);
>>  }
>>
>> -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par) {
>> +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
>> par, unsigned ts) {
>
> It seems jeeb prefers int64_t here instead of unsigned.
> Can you change that before pushing ?
>

Pushed with requested changes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Avoid truncating timestamp before avio_write_marker()

2018-05-29 Thread Alex Converse 
On Sun, May 13, 2018 at 3:41 AM, Michael Niedermayer
 wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/flvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index e8af48cb64..168ff9ffb8 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -873,7 +873,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
>  FLVContext *flv  = s->priv_data;
>  FLVStreamContext *sc = s->streams[pkt->stream_index]->priv_data;
> -unsigned ts;
> +int64_t ts;
>  int size = pkt->size;
>  uint8_t *data = NULL;
>  int flags = -1, flags_size, ret;
> --
> 2.17.0

The put_avc_eos_tag() function signature applies a similar truncation.
Best to be consistent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] flvenc: Fix sequence header update timestamps

2018-05-10 Thread Alex Converse 
From: Alex Converse <alexc...@twitch.tv>

---
 libavformat/flvenc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 9b7cdfe7db..7aa2dbf9a6 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -485,7 +485,7 @@ static int unsupported_codec(AVFormatContext *s,
 return AVERROR(ENOSYS);
 }
 
-static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) 
{
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par, 
unsigned ts) {
 int64_t data_size;
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
@@ -497,8 +497,7 @@ static void flv_write_codec_header(AVFormatContext* s, 
AVCodecParameters* par) {
 par->codec_type == AVMEDIA_TYPE_VIDEO ?
 FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
 avio_wb24(pb, 0); // size patched later
-avio_wb24(pb, 0); // ts
-avio_w8(pb, 0);   // ts ext
+put_timestamp(pb, ts);
 avio_wb24(pb, 0); // streamid
 pos = avio_tell(pb);
 if (par->codec_id == AV_CODEC_ID_AAC) {
@@ -761,7 +760,7 @@ static int flv_write_header(AVFormatContext *s)
 }
 
 for (i = 0; i < s->nb_streams; i++) {
-flv_write_codec_header(s, s->streams[i]->codecpar);
+flv_write_codec_header(s, s->streams[i]->codecpar, 0);
 }
 
 flv->datastart_offset = avio_tell(pb);
@@ -905,7 +904,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 memcpy(par->extradata, side, side_size);
 par->extradata_size = side_size;
-flv_write_codec_header(s, par);
+flv_write_codec_header(s, par, (unsigned)pkt->dts);
 }
 }
 
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] flvenc: Factorize timestamp writing

2018-05-10 Thread Alex Converse 
From: Alex Converse <alexc...@twitch.tv>

The code is trivial but the semantics in the spec are ambiguous. This
should help keep parts of the muxer interpreting them consistently.
---
 libavformat/flvenc.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index e8af48cb64..9b7cdfe7db 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -230,12 +230,17 @@ static void put_amf_string(AVIOContext *pb, const char 
*str)
 avio_write(pb, str, len);
 }
 
+// FLV timestamps are 32 bits signed, RTMP timestamps should be 32-bit unsigned
+static void put_timestamp(AVIOContext *pb, unsigned ts) {
+avio_wb24(pb, ts & 0xFF);
+avio_w8(pb, (ts >> 24) & 0x7F);
+}
+
 static void put_avc_eos_tag(AVIOContext *pb, unsigned ts)
 {
 avio_w8(pb, FLV_TAG_TYPE_VIDEO);
 avio_wb24(pb, 5);   /* Tag Data Size */
-avio_wb24(pb, ts);  /* lower 24 bits of timestamp in ms */
-avio_w8(pb, (ts >> 24) & 0x7F); /* MSB of ts in ms */
+put_timestamp(pb, ts);
 avio_wb24(pb, 0);   /* StreamId = 0 */
 avio_w8(pb, 23);/* ub[4] FrameType = 1, ub[4] CodecId = 7 
*/
 avio_w8(pb, 2); /* AVC end of sequence */
@@ -978,8 +983,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 
 avio_wb24(pb, size + flags_size);
-avio_wb24(pb, ts & 0xFF);
-avio_w8(pb, (ts >> 24) & 0x7F); // timestamps are 32 bits _signed_
+put_timestamp(pb, ts);
 avio_wb24(pb, flv->reserved);
 
 if (par->codec_type == AVMEDIA_TYPE_DATA ||
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

2018-05-10 Thread Alex Converse 
On Thu, May 10, 2018 at 4:08 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Fri, May 11, 2018 at 1:39 AM, Alex Converse <alex.conve...@gmail.com> 
> wrote:
>> On Thu, May 3, 2018 at 10:58 AM, Jan Ekström <jee...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
>>> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
>>> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
>>> UINT32_MAX)`?
>>>
>>
>> See the note about timestamps below.
>>
>>> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
>>> it doesn't really seem to define whether this value is PTS or DTS...
>>> Is this defined anywhere proper? Given FLV's age I wouldn't be
>>> surprised that the answer would be "effectively DTS", of course. But
>>> if you've seen what  Adobe's implementation writes with B-frames it'd
>>> be interesting to see.
>>>
>>
>> FLV AVC packets have a field called CompositionTime described to match
>> 14496-12. FLV requires this composition offset to be zero for sequence header
>> type packets. This strongly indicates to me that we want DTS here. In 
>> addition
>> the current muxer and demuxer already use dts pretty consistently for this
>> value (and use cts = pts - dts).
>>
>
> Alright, so dts it is... That only leaves out the fact that we're
> stuffing int64_t into an "unsigned int", which most likely will not
> warn on 64bit linux, but most likely will on various architectures
> and/or systems.
>
> So we:
> 1) take in the dts as int64_t.
> 2) apply wrap-over at either 32 or 31 bits depending on if the signed
> value is ever supposed to be negative. Depends on how wrap-around in
> FLV is supposed to be handled (aka "Is the negative area ever supposed
> to be used from the 32bit signed integer field?").
> 3) Write it there.
>
>>
>>> >  int64_t data_size;
>>> >  AVIOContext *pb = s->pb;
>>> >  FLVContext *flv = s->priv_data;
>>> > @@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* 
>>> > s, AVCodecParameters* par) {
>>> >  par->codec_type == AVMEDIA_TYPE_VIDEO ?
>>> >  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
>>> >  avio_wb24(pb, 0); // size patched later
>>> > -avio_wb24(pb, 0); // ts
>>> > -avio_w8(pb, 0);   // ts ext
>>> > +avio_wb24(pb, ts & 0xFF);
>>> > +avio_w8(pb, (ts >> 24) & 0x7F);
>>>
>>> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
>>> thus why is the second one not & 0xFF ?
>>>
>>
>> The mapping from dts to the flv timestamp we write to the stream is identical
>> for to what we do for non header packets. [1] I can pull this into a separate
>> function but it's only two lines so it didn't seem worth while.
>
> Yes, I think I commented on this that I hadn't noticed the signedness
> of the value there :) So this is 100% a-OK.
>
>>
>>> >  avio_wb24(pb, 0); // streamid
>>> >  pos = avio_tell(pb);
>>> >  if (par->codec_id == AV_CODEC_ID_AAC) {
>>> > @@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
>>> >  }
>>> >
>>> >  for (i = 0; i < s->nb_streams; i++) {
>>> > -flv_write_codec_header(s, s->streams[i]->codecpar);
>>> > +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
>>> >  }
>>> >
>>>
>>> Is it customary that even if you've got a live stream going, that the
>>> start point of a given ingest is always zero? In that case you might
>>> want to take mention of the initial dts, and then write offsets
>>> compared to that? Otherwise if you have an initial offset of, say, 5s,
>>> and then you a 5s GOP with an update, then while the difference to the
>>> initial timestamp would be 5s, using the original dts field you would
>>> get the second header having a value of 10s there. Or am I
>>> misunderstanding something here?
>>
>> The FLV file (on disk) format requires the initial DTS to be zero. For FLV
>> over RTMP this is not the case.
>>
>
> Oh, interesting... makes sense, of course, for continuing a stream
> relative to the last timestamp of the previous ingest.
>
>> At one point th

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

2018-05-10 Thread Alex Converse 
On Fri, May 4, 2018 at 7:11 AM, Josh de Kock <j...@itanimul.li> wrote:
>
>> On 4 May 2018, at 12:26, Michael Niedermayer <mich...@niedermayer.cc> wrote:
>>
>>> On Fri, May 04, 2018 at 11:03:20AM +0800, Steven Liu wrote:
>>>
>>>
>>>> On 4 May 2018, at 02:00, Jan Ekström <jee...@gmail.com> wrote:
>>>>
>>>> On Thu, May 3, 2018 at 8:58 PM, Jan Ekström <jee...@gmail.com> wrote:
>>>>> On Thu, May 3, 2018 at 7:50 PM, Alex Converse <alex.conve...@gmail.com> 
>>>>> wrote:
>> [...]
>>
>>> Will apply.
>>
>> I think Alex Converse has a git write account, so he can push himself if you
>> prefer
>>
>> thx
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> In a rich man's house there is no place to spit but his face.
>> -- Diogenes of Sinope
>
> Hold off on pushing this for a day or two, I think Jan had some extra 
> comments (he said he was unable to reply until later as he is busy right now).
>

Sorry about the lateness on my part. Were there any later comments. I
haven't seen any. (And yes I can push this myself when all the
concerns are resolved).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

2018-05-10 Thread Alex Converse 
On Thu, May 3, 2018 at 10:58 AM, Jan Ekström <jee...@gmail.com> wrote:
>
> On Thu, May 3, 2018 at 7:50 PM, Alex Converse <alex.conve...@gmail.com> wrote:
> > From: Alex Converse <alexc...@twitch.tv>
> >
> > ---
> >  libavformat/flvenc.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> > index e8af48cb64..827d798a61 100644
> > --- a/libavformat/flvenc.c
> > +++ b/libavformat/flvenc.c
> > @@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
> >  return AVERROR(ENOSYS);
> >  }
> >
> > -static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> > par) {
> > +static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* 
> > par, unsigned int ts) {
>
> Hi,
>
> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
> something a la ´uint32_t wrapped_timestamp = (uint32_t)(ts %
> UINT32_MAX)`?
>

See the note about timestamps below.

> Additionally, I did briefly go through E.4.1 (FLV Tag) in the spec and
> it doesn't really seem to define whether this value is PTS or DTS...
> Is this defined anywhere proper? Given FLV's age I wouldn't be
> surprised that the answer would be "effectively DTS", of course. But
> if you've seen what  Adobe's implementation writes with B-frames it'd
> be interesting to see.
>

FLV AVC packets have a field called CompositionTime described to match
14496-12. FLV requires this composition offset to be zero for sequence header
type packets. This strongly indicates to me that we want DTS here. In addition
the current muxer and demuxer already use dts pretty consistently for this
value (and use cts = pts - dts).


> >  int64_t data_size;
> >  AVIOContext *pb = s->pb;
> >  FLVContext *flv = s->priv_data;
> > @@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* s, 
> > AVCodecParameters* par) {
> >  par->codec_type == AVMEDIA_TYPE_VIDEO ?
> >  FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
> >  avio_wb24(pb, 0); // size patched later
> > -avio_wb24(pb, 0); // ts
> > -avio_w8(pb, 0);   // ts ext
> > +avio_wb24(pb, ts & 0xFF);
> > +avio_w8(pb, (ts >> 24) & 0x7F);
>
> Looking at the spec this is bottom 24 bits of the timestamp and top 8,
> thus why is the second one not & 0xFF ?
>

The mapping from dts to the flv timestamp we write to the stream is identical
for to what we do for non header packets. [1] I can pull this into a separate
function but it's only two lines so it didn't seem worth while.

> >  avio_wb24(pb, 0); // streamid
> >  pos = avio_tell(pb);
> >  if (par->codec_id == AV_CODEC_ID_AAC) {
> > @@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
> >  }
> >
> >  for (i = 0; i < s->nb_streams; i++) {
> > -flv_write_codec_header(s, s->streams[i]->codecpar);
> > +flv_write_codec_header(s, s->streams[i]->codecpar, 0);
> >  }
> >
>
> Is it customary that even if you've got a live stream going, that the
> start point of a given ingest is always zero? In that case you might
> want to take mention of the initial dts, and then write offsets
> compared to that? Otherwise if you have an initial offset of, say, 5s,
> and then you a 5s GOP with an update, then while the difference to the
> initial timestamp would be 5s, using the original dts field you would
> get the second header having a value of 10s there. Or am I
> misunderstanding something here?

The FLV file (on disk) format requires the initial DTS to be zero. For FLV
over RTMP this is not the case.

At one point the flv muxer handled that itself, but that changed to handle
copyts better.[2]

For non-zero starting DTS should header packets have non-zero
timestamp? Maybe but that's the case irrespective of weather or
not we offset late extradata. Meanwhile many popular demuxers
(avformat included) special case initial extradata.

[1] 
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/flvenc.c;h=e8af48cb6415a0e5795d7e36d82789ae1699f89f#l981
[2] 
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a0174f67298ba9494c146183dd360e637b03db64

>
> Otherwise, looks like a nice improvement in the implementation.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] flvenc: Fix sequence header update timestamps

2018-05-03 Thread Alex Converse 
From: Alex Converse <alexc...@twitch.tv>

---
 libavformat/flvenc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index e8af48cb64..827d798a61 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -480,7 +480,7 @@ static int unsupported_codec(AVFormatContext *s,
 return AVERROR(ENOSYS);
 }
 
-static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) 
{
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par, 
unsigned int ts) {
 int64_t data_size;
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
@@ -492,8 +492,8 @@ static void flv_write_codec_header(AVFormatContext* s, 
AVCodecParameters* par) {
 par->codec_type == AVMEDIA_TYPE_VIDEO ?
 FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
 avio_wb24(pb, 0); // size patched later
-avio_wb24(pb, 0); // ts
-avio_w8(pb, 0);   // ts ext
+avio_wb24(pb, ts & 0xFF);
+avio_w8(pb, (ts >> 24) & 0x7F);
 avio_wb24(pb, 0); // streamid
 pos = avio_tell(pb);
 if (par->codec_id == AV_CODEC_ID_AAC) {
@@ -756,7 +756,7 @@ static int flv_write_header(AVFormatContext *s)
 }
 
 for (i = 0; i < s->nb_streams; i++) {
-flv_write_codec_header(s, s->streams[i]->codecpar);
+flv_write_codec_header(s, s->streams[i]->codecpar, 0);
 }
 
 flv->datastart_offset = avio_tell(pb);
@@ -900,7 +900,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 memcpy(par->extradata, side, side_size);
 par->extradata_size = side_size;
-flv_write_codec_header(s, par);
+flv_write_codec_header(s, par, pkt->dts);
 }
 }
 
-- 
2.17.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

2018-02-20 Thread Alex Converse 
On Tue, Feb 20, 2018 at 4:56 PM, Dale Curtis <dalecur...@chromium.org> wrote:
> On Tue, Feb 20, 2018 at 4:18 PM, Alex Converse <alex.conve...@gmail.com>
> wrote:
>
>>
>> I would make this uint8_t
>>
>
> Done.
>
>
>> I would drop this stack struck and replace the leaf get_bits() with
>> skip bits. It makes the code that much harder to exploit and there is
>> no point in storing data we don't plan on decoding
>>
>
> Done.
>
>
>> This block seems funny. decode_gain_control() always returns zero.
>> Maybe make this warn once per stream when present like some of the
>> other AAC warn
>> cases.
>>
>
> Done. I've added an AACContext::warn_gain_control member to do this.
>
> This patch set also changes the attribution from Robert Swain to Maxim
> Gavrilov based on svn blame of the SoC repository after discussion at
> https://trac.ffmpeg.org/ticket/1693#comment:34
>

LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [aacdec] Parse and drop gain control data, so that SSR packets decode.

2018-02-20 Thread Alex Converse 
On Tue, Feb 20, 2018 at 3:37 PM, Dale Curtis  wrote:
> From 97380752ef12337d9b9a01801a9a84df3b4b9c0a Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Thu, 15 Feb 2018 16:22:55 -0800
> Subject: [PATCH] [aacdec] Parse and drop gain control data, so that SSR
>  packets decode.
>
> This will result in poor quality audio for SSR streams, but they
> will at least demux and decode without error; partially fixing
> ticket #1693.
>
> This just pulls in the decode_gain_control() function from the
> ffmpeg summer-of-code repo (original author Robert Swain) at
> svn://svn.mplayerhq.hu/soc/aac/aac.c and adds AOT_AAC_SSR to
> decode_audio_specific_config_gb().
>
> Signed-off-by: Dale Curtis 
> Co-authored-by: Robert Swain 
> ---
>  libavcodec/aacdec_template.c | 49 +---
>  1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index c2d9802023..c3ec3eefe8 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -997,6 +997,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
>  switch (m4ac->object_type) {
>  case AOT_AAC_MAIN:
>  case AOT_AAC_LC:
> +case AOT_AAC_SSR:
>  case AOT_AAC_LTP:
>  case AOT_ER_AAC_LC:
>  case AOT_ER_AAC_LD:
> @@ -1967,6 +1968,44 @@ static void apply_prediction(AACContext *ac, 
> SingleChannelElement *sce)
>  reset_all_predictors(sce->predictor_state);
>  }
>
> +static int decode_gain_control(SingleChannelElement * sce, GetBitContext * 
> gb)
> +{
> +// wd_num, wd_test, aloc_size
> +static const int gain_mode[4][3] = {

I would make this uint8_t

> +{1, 0, 5},  // ONLY_LONG_SEQUENCE = 0,
> +{2, 1, 2},  // LONG_START_SEQUENCE,
> +{8, 0, 2},  // EIGHT_SHORT_SEQUENCE,
> +{2, 1, 5},  // LONG_STOP_SEQUENCE
> +};
> +
> +// per-element gain control for SSR
> +struct {
> +  int max_band;
> +  int adjust_num[4][8];
> +  int alev[4][8][8];
> +  int aloc[4][8][8];
> +} ssr;

I would drop this stack struck and replace the leaf get_bits() with
skip bits. It makes the code that much harder to exploit and there is
no point in storing data we don't plan on decoding

> +
> +const int mode = sce->ics.window_sequence[0];
> +int bd, wd, ad;
> +
> +// FIXME: Store the gain control data on |sce| and do something with it.
> +ssr.max_band = get_bits(gb, 2);
> +for (bd = 0; bd < ssr.max_band; bd++) {
> +for (wd = 0; wd < gain_mode[mode][0]; wd++) {
> +ssr.adjust_num[bd][wd] = get_bits(gb, 3);
> +for (ad = 0; ad < ssr.adjust_num[bd][wd]; ad++) {
> +ssr.alev[bd][wd][ad] = get_bits(gb, 4);
> +if (wd == 0 && gain_mode[mode][1])
> +ssr.aloc[bd][wd][ad] = get_bits(gb, 4);
> +else
> +ssr.aloc[bd][wd][ad] = get_bits(gb, gain_mode[mode][2]);
> +}
> +}
> +}
> +return 0;
> +}
> +
>  /**
>   * Decode an individual_channel_stream payload; reference: table 4.44.
>   *
> @@ -2034,9 +2073,13 @@ static int decode_ics(AACContext *ac, 
> SingleChannelElement *sce,
>  goto fail;
>  }
>  if (!eld_syntax && get_bits1(gb)) {
> -avpriv_request_sample(ac->avctx, "SSR");
> -ret = AVERROR_PATCHWELCOME;
> -goto fail;
> +// FIXME: Do something with the gain control data...
> +ret = decode_gain_control(sce, gb);
> +if (ret < 0) {
> +ret = AVERROR_PATCHWELCOME;
> +avpriv_request_sample(ac->avctx, "SSR");
> +goto fail;
> +}

This block seems funny. decode_gain_control() always returns zero.
Maybe make this warn once per stream when present like some of the
other AAC warn
cases.

>  }
>  // I see no textual basis in the spec for this occurring after SSR 
> gain
>  // control, but this is what both reference and real implmentations 
> do
> --
> 2.16.1.291.g4437f3f132-goog
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/flvdec: Set need_context_update when setting the initial extradata

2017-09-03 Thread Alex Converse 
On Wed, Aug 30, 2017 at 5:09 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Tue, Aug 29, 2017 at 11:40:06AM -0700, Alex Converse wrote:
>> Fixes ticket 6398.
>>
>> Debugged with the help of James Almer and Hendrik Leppkes.
>> ---
>>  libavformat/flvdec.c | 1 +
>>  1 file changed, 1 insertion(+)
>
> should be ok
>
> thx
>

Pushed.

Any thoughts on patch 2/2?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avformat/flvdec: Set need_context_update when setting the initial extradata

2017-08-29 Thread Alex Converse 
Fixes ticket 6398.

Debugged with the help of James Almer and Hendrik Leppkes.
---
 libavformat/flvdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 94c9e28334..2e70352c53 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -754,6 +754,7 @@ static int flv_get_extradata(AVFormatContext *s, AVStream 
*st, int size)
 av_freep(>codecpar->extradata);
 if (ff_get_extradata(s, st->codecpar, s->pb, size) < 0)
 return AVERROR(ENOMEM);
+st->internal->need_context_update = 1;
 return 0;
 }
 
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat: Handle AV_CODEC_CAP_CHANNEL_CONF when first frame fails to decode

2017-08-29 Thread Alex Converse 
Fixes probing the stream from ticket 6398.

Noticed by James Almer.
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 23865c88c4..68ba8aa85b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2997,7 +2997,7 @@ static int try_decode_frame(AVFormatContext *s, AVStream 
*st, AVPacket *avpkt,
 while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
ret >= 0 &&
(!has_codec_parameters(st, NULL) || 
!has_decode_delay_been_guessed(st) ||
-(!st->codec_info_nb_frames &&
+(!st->nb_decoded_frames &&
  (avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF {
 got_picture = 0;
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] fate: add test vector aac-al04sf_48

2017-08-22 Thread Alex Converse 
On Tue, Aug 22, 2017 at 3:23 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Mon, Aug 21, 2017 at 04:22:15PM -0700, Alex Converse wrote:
>> ---
>>  tests/fate/aac.mak | 4 
>>  1 file changed, 4 insertions(+)
>
> where can i find the files to test & upload to fate samples ?
>

The files are part of the official conformance suite and can be found at:
ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al04sf_48.mp4
and
ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/referencesWav/al04sf_48.wav
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/aac: Add floating point 960/120 MDCT window

2017-08-21 Thread Alex Converse 
From: Paul B Mahol <one...@gmail.com>

Co-Authored-By: Alex Converse <alex.conve...@gmail.com>
---
 libavcodec/aac.h  |   3 +
 libavcodec/aacdec_template.c  | 124 +++---
 libavcodec/aactab.c   | 120 
 libavcodec/aactab.h   |   6 ++
 libavcodec/sinewin.h  |   4 +-
 libavcodec/sinewin_tablegen.h |   5 +-
 6 files changed, 253 insertions(+), 9 deletions(-)

diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 97a2df6b86..4910c661d6 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -327,7 +327,9 @@ struct AACContext {
 #if USE_FIXED
 AVFixedDSPContext *fdsp;
 #else
+MDCT15Context *mdct120;
 MDCT15Context *mdct480;
+MDCT15Context *mdct960;
 AVFloatDSPContext *fdsp;
 #endif /* USE_FIXED */
 int random_state;
@@ -353,6 +355,7 @@ struct AACContext {
 
 OutputConfiguration oc[2];
 int warned_num_aac_frames;
+int warned_960_sbr;
 
 /* aacdec functions pointers */
 void (*imdct_and_windowing)(AACContext *ac, SingleChannelElement *sce);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index a539f74e6f..e76e824fbb 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -811,11 +811,21 @@ static int decode_ga_specific_config(AACContext *ac, 
AVCodecContext *avctx,
 uint8_t layout_map[MAX_ELEM_ID*4][3];
 int tags = 0;
 
+#if USE_FIXED
 if (get_bits1(gb)) { // frameLengthFlag
-avpriv_request_sample(avctx, "960/120 MDCT window");
+avpriv_report_missing_feature(avctx, "Fixed point 960/120 MDCT 
window");
 return AVERROR_PATCHWELCOME;
 }
 m4ac->frame_length_short = 0;
+#else
+m4ac->frame_length_short = get_bits1(gb);
+if (m4ac->frame_length_short && m4ac->sbr == 1) {
+  avpriv_report_missing_feature(avctx, "SBR with 960 frame length");
+  if (ac) ac->warned_960_sbr = 1;
+  m4ac->sbr = 0;
+  m4ac->ps = 0;
+}
+#endif
 
 if (get_bits1(gb))   // dependsOnCoreCoder
 skip_bits(gb, 14);   // coreCoderDelay
@@ -1126,6 +1136,12 @@ static av_cold void aac_static_table_init(void)
 // window initialization
 AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_long_1024), 4.0, 
1024);
 AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_short_128), 6.0, 128);
+#if !USE_FIXED
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_long_960), 4.0, 960);
+AAC_RENAME(ff_kbd_window_init)(AAC_RENAME(ff_aac_kbd_short_120), 6.0, 120);
+AAC_RENAME(ff_sine_window_init)(AAC_RENAME(ff_sine_960), 960);
+AAC_RENAME(ff_sine_window_init)(AAC_RENAME(ff_sine_120), 120);
+#endif
 AAC_RENAME(ff_init_ff_sine_windows)(10);
 AAC_RENAME(ff_init_ff_sine_windows)( 9);
 AAC_RENAME(ff_init_ff_sine_windows)( 7);
@@ -1211,9 +1227,15 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
 AAC_RENAME_32(ff_mdct_init)(>mdct_small,  8, 1, 1.0 / RANGE15(128.0));
 AAC_RENAME_32(ff_mdct_init)(>mdct_ltp,   11, 0, RANGE15(-2.0));
 #if !USE_FIXED
+ret = ff_mdct15_init(>mdct120, 1, 3, 1.0f/(16*1024*120*2));
+if (ret < 0)
+return ret;
 ret = ff_mdct15_init(>mdct480, 1, 5, 1.0f/(16*1024*960));
 if (ret < 0)
 return ret;
+ret = ff_mdct15_init(>mdct960, 1, 6, 1.0f/(16*1024*960*2));
+if (ret < 0)
+return ret;
 #endif
 
 return 0;
@@ -1314,8 +1336,13 @@ static int decode_ics_info(AACContext *ac, 
IndividualChannelStream *ics,
 }
 }
 ics->num_windows   = 8;
-ics->swb_offset=ff_swb_offset_128[sampling_index];
-ics->num_swb   =   ff_aac_num_swb_128[sampling_index];
+if (m4ac->frame_length_short) {
+ics->swb_offset=  ff_swb_offset_120[sampling_index];
+ics->num_swb   = ff_aac_num_swb_120[sampling_index];
+} else {
+ics->swb_offset=  ff_swb_offset_128[sampling_index];
+ics->num_swb   = ff_aac_num_swb_128[sampling_index];
+}
 ics->tns_max_bands = ff_tns_max_bands_128[sampling_index];
 ics->predictor_present = 0;
 } else {
@@ -1334,8 +1361,13 @@ static int decode_ics_info(AACContext *ac, 
IndividualChannelStream *ics,
 if (!ics->num_swb || !ics->swb_offset)
 return AVERROR_BUG;
 } else {
-ics->swb_offset=ff_swb_offset_1024[sampling_index];
-ics->num_swb   =   ff_aac_num_swb_1024[sampling_index];
+if (m4ac->frame_length_short) {
+ics->num_swb= ff_aac_num_swb_960[sampling_index];
+ics->swb_offset = ff_swb_offset_960[sampling_index];
+} else {
+ics->num_swb= ff_aac_num_swb_1024[sampling_index];
+

[FFmpeg-devel] [PATCH 2/2] fate: add test vector aac-al04sf_48

2017-08-21 Thread Alex Converse 
---
 tests/fate/aac.mak | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 5ef8ddc2b9..e8cbcef54d 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -2,6 +2,10 @@ FATE_AAC += fate-aac-al04_44
 fate-aac-al04_44: CMD = pcm -i $(TARGET_SAMPLES)/aac/al04_44.mp4
 fate-aac-al04_44: REF = $(SAMPLES)/aac/al04_44.s16
 
+FATE_AAC += fate-aac-al04sf_48
+fate-aac-al04sf_48: CMD = pcm -i $(TARGET_SAMPLES)/aac/al04sf_48.mp4
+fate-aac-al04sf_48: REF = $(SAMPLES)/aac/al04sf_48.s16
+
 FATE_AAC += fate-aac-al05_44
 fate-aac-al05_44: CMD = pcm -i $(TARGET_SAMPLES)/aac/al05_44.mp4
 fate-aac-al05_44: REF = $(SAMPLES)/aac/al05_44.s16
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/aacdec_template: Fix running cleanup in decode_ics_info()

2017-08-21 Thread Alex Converse 
On Sun, Aug 20, 2017 at 5:15 PM, Michael Niedermayer
 wrote:
>
> Fixes: out of array read
> Fixes: 2873/clusterfuzz-testcase-minimized-5924145713905664
>
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacdec_template.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index a539f74e6f..e7fa27e8db 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -1332,7 +1332,7 @@ static int decode_ics_info(AACContext *ac, 
> IndividualChannelStream *ics,
>  ics->tns_max_bands =  ff_tns_max_bands_512[sampling_index];
>  }
>  if (!ics->num_swb || !ics->swb_offset)
> -return AVERROR_BUG;
> +goto fail;
>  } else {
>  ics->swb_offset=ff_swb_offset_1024[sampling_index];
>  ics->num_swb   =   ff_aac_num_swb_1024[sampling_index];

okay

> @@ -1356,7 +1356,7 @@ static int decode_ics_info(AACContext *ac, 
> IndividualChannelStream *ics,
>  if (aot == AOT_ER_AAC_LD) {
>  av_log(ac->avctx, AV_LOG_ERROR,
> "LTP in ER AAC LD not yet implemented.\n");
> -return AVERROR_PATCHWELCOME;
> +goto fail;
>  }
>  if ((ics->ltp.present = get_bits(gb, 1)))
>  decode_ltp(>ltp, gb, ics->max_sfb);

I'm not sure if it matters to anyone, but this is a missing decoder
feature and returning AVERROR_INVALIDDATA is semantically wrong.

> --
> 2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling

2017-08-15 Thread Alex Converse 
On Sat, Aug 12, 2017 at 9:47 AM, Dave Rice  wrote:
>
> Hello all,
> This issue originated in this thread 
> https://github.com/amiaopensource/vrecord/issues/170. On Field Order, in the 
> QuickTime specification at 
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
>  (and similarly in the Matroska specification which adopted similar language) 
> it states the following meanings for field order values:
>
> > 9 – B is displayed earliest, T is stored first in the file. 14 – T is 
> > displayed earliest, B is stored first in the file.
>
>  This definition is contradicted by other Apple documentation such as 
> https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXTENSION__FIELD_FRAME_INFORMATION.
>
> An Apple engineer confirmed that the QuickTime specification’s definitions 
> for those Field Order values is wrong and does not match Apple’s (of 
> FFmpeg’s) practice, see 
> https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668.
>
> However I think that some of the commenting in ffmpeg is based upon the 
> inaccurate definitions from Apple. For instance, in that thread David Singer 
> confirms:
>
> > Ah, not quite. 1 and 6 are indeed 'planar' (all of one field before all of 
> > the other). They don't concern us. Both 9 and 14 are stored in spatial 
> > order (i.e. you could do terrible de-interlacing by simply displaying the 
> > buffer as a frame), and the 9 or 14 value tells you which field is to be 
> > displayed first.
> >
> > 9 – T is earlier than B. 14 – B is earlier than T
>
> mov.c associates AV_FIELD_TB with 9 and AV_FIELD_BT with 14 (similar 
> associations in matroska.h), but avcodec.h states:
>
> > AV_FIELD_TB,  //< Top coded first, bottom displayed first
> > AV_FIELD_BT,  //< Bottom coded first, bottom displayed first
>
> IMHO in both cases of AV_FIELD_TB and AV_FIELD_BT the coding should be 
> referred as interleaved rather than ‘bottom coded first’ or ‘top coded 
> first’. In the case of AV_FIELD_TT and AV_FIELD_BB the fields are stored as 
> planar images where storage order is notable, but with TB and BT the fields 
> are interleaved.
>
> Also utils.c associates these field order values with the following labels:
>
> > AV_FIELD_TB  -> "top coded first (swapped)";
> > AV_FIELD_BT -> "bottom coded first (swapped)";
>
> From my reading, I infer that "top coded first (swapped)” means "top coded 
> first, bottom displayed first”; however in practice from files generated by 
> QuickTime and FFmpeg files with a value of TB have the top field displayed 
> first, so I think the labels are swapped. In the patch below I suggest using 
> “top first (interleaved)” for TB and “bottom first (interleaved)” for BT.
>
> Comments?
>

Icefloe019 agrees with your changes:
http://mirror.informatimago.com/next/developer.apple.com/quicktime/icefloe/dispatch019.html#fiel

They seems reasonable to me. when I made this change originally my
primary concern was getting the field info out of extradata.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch for CUDA Scale Filter

2017-04-18 Thread Alex Converse 
On Mon, Apr 17, 2017 at 2:51 PM, Timo Rothenpieler
 wrote:
>>> I'm generally in favor of adding CUDA based filtering, there's a lot of
>>> nice stuff that could be done that way.
>>>
>>> But there is one big issue with this approach:
>>>
>>> Having to run a .bat file prior to building isn't really nice, and not
>>> something I and some other people on IRC would like to see in ffmpeg.
>>>
>>> Instead, it would be nice if configure/make would learn how to handle
>>> .cu files, converting them straight to an object-file.
>>> My idea for this would be to teach the Makefiles about .cu files, and
>>> using a shell script as their compiler.
>>> That script can then call nvcc and include the ptx2c functionality, and
>>> additionally also calls the designated C compiler, so for the build
>>> system it converts .cu to .o.
>>>
>>> Also, due to these kind of filters having to include cuda.h, they need
>>> to be put behind --enable-nonfree in configure.
>>>
>>> That's what I have in mind so far. I didn't have time for a full review
>>> of the code yet, so can't say much about the filter itself.
>>
>>
>> I'm against. Building the "script" seems pretty terribly complicated,
>> and adding generated code is usually not what we do in this project.
>> This is probably done better with a d3d11 video scale filter, although
>> I'm not sure about the tradeoffs yet.
>
>
> That's exactly what I said though? Making configure/make generate the code
> at build time, so the generated code is not in the repo, only the actual .cu
> file.
>
> One problem with that is, that nvcc require cl.exe on Windows, it doesn't
> work with gcc. So that would limit it to MSVC builds on Windows, which is
> fine with me.
>

FWIW there are non-nvcc cuda compilers that run on Windows, like clang.
http://llvm.org/docs/CompileCudaWithLLVM.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aacsbr: Turnoff in the event of over read.

2017-03-20 Thread Alex Converse 
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.

Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
---
 libavcodec/aacsbr_template.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index cf8621eee0..750131c64c 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -1137,6 +1137,7 @@ int AAC_RENAME(ff_decode_sbr_extension)(AACContext *ac, 
SpectralBandReplication
 if (bytes_read > cnt) {
 av_log(ac->avctx, AV_LOG_ERROR,
"Expected to read %d SBR bytes actually read %d.\n", cnt, 
bytes_read);
+sbr_turnoff(sbr);
 }
 return cnt;
 }
-- 
2.11.0.390.gc69c2f50cf-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: When ignoring a PCE restore the previous config

2017-02-21 Thread Alex Converse 
On Thu, Feb 16, 2017 at 3:21 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2017-02-16 22:13 GMT+01:00 Alex Converse <alex.conve...@gmail.com>:
>> This is related to, but doesn't solve ticker 6152.
>> ---
>>  libavcodec/aacdec_template.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 4e0a9529e1..4367e74cf7 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -3036,6 +3036,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
>> void *data,
>>  if (pce_found) {
>>  av_log(avctx, AV_LOG_ERROR,
>> "Not evaluating a further program_config_element as 
>> this construct is dubious at best.\n");
>> +pop_output_configuration(ac);
>>  } else {
>>  err = output_configure(ac, layout_map, tags, OC_TRIAL_PCE, 
>> 1);
>>  if (!err)
>
> I thought ticket #6152 was related to the else tree...
>
> Anyway: Since this is your code, please wait a day or two
> and push.
>

Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init

2017-02-12 Thread Alex Converse 
On Thu, Feb 9, 2017 at 4:11 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>
> 2017-02-09 18:40 GMT+01:00 Alex Converse <alex.conve...@gmail.com>:
> > Quiets some log spam on pure upsampling mode.
>
> Please mention ticket #5163.
>

Done

> For the whole patchset, I suggest you push as soon as everybody
> agrees on the function prefixes.
>

Prefix changed. Patches 2 and 4 don't have any comments. Do they need
further review by anyone?

> Could you review my patch for ticket #1614?
> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164080.html
> It seems to fix the second sample attached on trac, aac_broken.mp4.
>

It appears that your patch is decoding two channels "on top of each
other" creating the artifacts noted in the original review. There
isn't an easy change to make to that patch to fix this. The best way
to handle it is in positional channel orders to try to decode
everything we see then sniff out the channel order after the fact,
using the indexed channel configuration as more of a suggestion. That
may open the door to some truly crazy stuff, so it's probably best to
do some fuzzing and large scale testing on that sort of change before
landing it.

> Did you see ticket #5722?
>

It looks like it's probably a demuxer issue. I haven't looked at mov.c
in a long time.

[...]

Regards,
Alex
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/4] aacsbr: Associate SBR data with AAC elements on init

2017-02-12 Thread Alex Converse 
Quiets some log spam on pure upsampling mode.

Fixes ticket 5163.
---
 libavcodec/aacdec_template.c | 2 +-
 libavcodec/aacsbr.h  | 2 +-
 libavcodec/aacsbr_template.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index e230c87733..d980ae0e22 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
 if (!ac->che[type][id]) {
 if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
 return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr, type);
 }
 if (type != TYPE_CCE) {
 if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type == 
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
 /** Initialize SBR. */
 void AAC_RENAME(ff_aac_sbr_init)(void);
 /** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr, int id_aac);
 /** Close one SBR context. */
 void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
 /** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
 memset(>spectrum_params, -1, sizeof(SpectrumParameters));
 }
 
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr, int id_aac)
 {
 if(sbr->mdct.mdct_bits)
 return;
 sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
 sbr_turnoff(sbr);
 sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
 sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
-- 
2.11.0.483.g087da7b7c-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 1/4] aac_latm: Allow unaligned AudioSpecificConfig

2017-02-12 Thread Alex Converse 
Fixes ticket 4730
---
 libavcodec/aacdec.c  | 26 --
 libavcodec/aacdec_template.c | 82 
 libavcodec/mpeg4audio.c  | 76 ++--
 libavcodec/mpeg4audio.h  | 12 ++-
 4 files changed, 120 insertions(+), 76 deletions(-)

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 AACContext *ac= >aac_ctx;
 AVCodecContext *avctx = ac->avctx;
 MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
 int config_start_bit  = get_bits_count(gb);
 int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
 
 if (asclen) {
 sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 } else
 asclen = get_bits_left(gb);
 
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
-  "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
 if (asclen <= 0)
 return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, ,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
 
-if (bits_consumed < 0)
+init_get_bits(, gb->buffer, config_start_bit + asclen);
+skip_bits_long(, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, ,
+, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
 return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
 
 if (!latmctx->initialized ||
 ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 }
 
 avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+  avctx->extradata[i] = get_bits(, 8);
+}
 memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 }
 skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..e230c87733 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
 }
 }
 
+static inline void relative_align_get_bits(GetBitContext *gb,
+   int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
 /**
  * Decode program configuration element; reference: table 4.2.
  *
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
  */
 static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
   uint8_t (*layout_map)[3],
-  GetBitContext *gb)
+  GetBitContext *gb, int byte_align_ref)
 {
 int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
 int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
 decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
 tags += num_cc;
 
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
 
 /* comment field, first byte is length */
 comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
  */
 static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
  GetBitContext *gb,
+ int get_bit_alignment,
  MPEG4AudioConfig *m4ac,
  int channel_config)
 {
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac, 
AVCodecContext *avctx,
 
 if (channel_config == 0) {
 skip_bits(gb, 4);  // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
 if (tags < 0)
 return tags;
 } else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac, 
AVCodecContext *avctx,
  * @param   ac  pointer to AACContext, may be null
  * @param   avctx   pointer to AVCCodecContext, used for logging
  * @param   m4acpointer to MPEG4AudioConfig, used for parsing
- * @param

[FFmpeg-devel] [PATCH 2/4] aac_latm: Copy whole AudioSpecificConfig when it is sized.

2017-02-09 Thread Alex Converse 
This preserves sync extensions.
---
 libavcodec/aacdec.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 709ac7cdf8..08d92fe145 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -289,17 +289,19 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 int sync_extension= 0;
 int bits_consumed, esize, i;
 
-if (asclen) {
+if (asclen > 0) {
 sync_extension = 1;
 asclen = FFMIN(asclen, get_bits_left(gb));
-} else
-asclen = get_bits_left(gb);
-
-if (asclen <= 0)
+init_get_bits(, gb->buffer, config_start_bit + asclen);
+skip_bits_long(, config_start_bit);
+} else if (asclen == 0) {
+gbc = *gb;
+} else {
 return AVERROR_INVALIDDATA;
+}
 
-init_get_bits(, gb->buffer, config_start_bit + asclen);
-skip_bits_long(, config_start_bit);
+if (get_bits_left(gb) <= 0)
+return AVERROR_INVALIDDATA;
 
 bits_consumed = decode_audio_specific_config_gb(NULL, avctx, ,
 , config_start_bit,
@@ -309,6 +311,9 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 return AVERROR_INVALIDDATA;
 bits_consumed -= config_start_bit;
 
+if (asclen == 0)
+  asclen = bits_consumed;
+
 if (!latmctx->initialized ||
 ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
 ac->oc[1].m4ac.chan_config != m4ac.chan_config) {
@@ -320,7 +325,7 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 }
 latmctx->initialized = 0;
 
-esize = (bits_consumed+7) / 8;
+esize = (asclen + 7) / 8;
 
 if (avctx->extradata_size < esize) {
 av_free(avctx->extradata);
@@ -336,9 +341,9 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 }
 memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 }
-skip_bits_long(gb, bits_consumed);
+skip_bits_long(gb, asclen);
 
-return bits_consumed;
+return 0;
 }
 
 static int read_stream_mux_config(struct LATMContext *latmctx,
@@ -379,8 +384,6 @@ static int read_stream_mux_config(struct LATMContext 
*latmctx,
 int ascLen = latm_get_value(gb);
 if ((ret = latm_decode_audio_specific_config(latmctx, gb, ascLen)) 
< 0)
 return ret;
-ascLen -= ret;
-skip_bits_long(gb, ascLen);
 }
 
 latmctx->frame_length_type = get_bits(gb, 3);
-- 
2.11.0.483.g087da7b7c-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] aac_latm: Align inband PCE to the start of the payload

2017-02-09 Thread Alex Converse 
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.

It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.

Fixes ticket 4544
---
 libavcodec/aacdec_template.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 6654416e69..1f14a1cbae 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2949,6 +2949,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 int err, elem_id;
 int samples = 0, multiplier, audio_found = 0, pce_found = 0;
 int is_dmono, sce_count = 0;
+int payload_alignment;
 
 ac->frame = data;
 
@@ -2971,6 +2972,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 // This may lead to an undefined profile being signaled
 ac->avctx->profile = ac->oc[1].m4ac.object_type - 1;
 
+payload_alignment = get_bits_count(gb);
 ac->tags_mapped = 0;
 // parse
 while ((elem_type = get_bits(gb, 3)) != TYPE_END) {
@@ -3025,7 +3027,8 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 uint8_t layout_map[MAX_ELEM_ID*4][3];
 int tags;
 push_output_configuration(ac);
-tags = decode_pce(avctx, >oc[1].m4ac, layout_map, gb, 0);
+tags = decode_pce(avctx, >oc[1].m4ac, layout_map, gb,
+  payload_alignment);
 if (tags < 0) {
 err = tags;
 break;
-- 
2.11.0.483.g087da7b7c-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] aac_latm: Allow unaligned AudioSpecificConfig

2017-02-09 Thread Alex Converse 
Fixes ticket 4730
---
 libavcodec/aacdec.c  | 26 --
 libavcodec/aacdec_template.c | 82 
 libavcodec/mpeg4audio.c  | 76 ++--
 libavcodec/mpeg4audio.h  | 12 ++-
 4 files changed, 120 insertions(+), 76 deletions(-)

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 AACContext *ac= >aac_ctx;
 AVCodecContext *avctx = ac->avctx;
 MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
 int config_start_bit  = get_bits_count(gb);
 int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
 
 if (asclen) {
 sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 } else
 asclen = get_bits_left(gb);
 
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
-  "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
 if (asclen <= 0)
 return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, ,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
 
-if (bits_consumed < 0)
+init_get_bits(, gb->buffer, config_start_bit + asclen);
+skip_bits_long(, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, ,
+, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
 return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
 
 if (!latmctx->initialized ||
 ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct 
LATMContext *latmctx,
 }
 
 avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+  avctx->extradata[i] = get_bits(, 8);
+}
 memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 }
 skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..2a06f82efe 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
 }
 }
 
+static inline void relative_align_get_bits(GetBitContext *gb,
+   int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
 /**
  * Decode program configuration element; reference: table 4.2.
  *
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
  */
 static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
   uint8_t (*layout_map)[3],
-  GetBitContext *gb)
+  GetBitContext *gb, int byte_align_ref)
 {
 int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
 int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
 decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
 tags += num_cc;
 
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
 
 /* comment field, first byte is length */
 comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx, 
MPEG4AudioConfig *m4ac,
  */
 static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
  GetBitContext *gb,
+ int get_bit_alignment,
  MPEG4AudioConfig *m4ac,
  int channel_config)
 {
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac, 
AVCodecContext *avctx,
 
 if (channel_config == 0) {
 skip_bits(gb, 4);  // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
 if (tags < 0)
 return tags;
 } else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac, 
AVCodecContext *avctx,
  * @param   ac  pointer to AACContext, may be null
  * @param   avctx   pointer to AVCCodecContext, used for logging
  * @param   m4acpointer to MPEG4AudioConfig, used for parsing
- * @param

[FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init

2017-02-09 Thread Alex Converse 
Quiets some log spam on pure upsampling mode.
---
 libavcodec/aacdec_template.c | 2 +-
 libavcodec/aacsbr.h  | 2 +-
 libavcodec/aacsbr_template.c | 3 ++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 2a06f82efe..6654416e69 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
 if (!ac->che[type][id]) {
 if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
 return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, >che[type][id]->sbr, type);
 }
 if (type != TYPE_CCE) {
 if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type == 
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
 /** Initialize SBR. */
 void AAC_RENAME(ff_aac_sbr_init)(void);
 /** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication 
*sbr, int id_aac);
 /** Close one SBR context. */
 void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
 /** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
 memset(>spectrum_params, -1, sizeof(SpectrumParameters));
 }
 
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, 
SpectralBandReplication *sbr, int id_aac)
 {
 if(sbr->mdct.mdct_bits)
 return;
 sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
 sbr_turnoff(sbr);
 sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
 sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE 
- (1280 - 128);
-- 
2.11.0.483.g087da7b7c-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes

2016-12-13 Thread Alex Converse 
On Mon, Dec 12, 2016 at 2:41 PM, James Zern <jz...@google.com> wrote:
> On Mon, Dec 12, 2016 at 12:12 PM, Alex Converse <alex.conve...@gmail.com> 
> wrote:
>> Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not
>> implement requested capability" log messages on VP8 encodes.
>> ---
>>  libavcodec/libvpxenc.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> lgtm

Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes

2016-12-12 Thread Alex Converse 
Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not
implement requested capability" log messages on VP8 encodes.
---
 libavcodec/libvpxenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 1325199..de0d0b6 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -293,7 +293,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
 VPxContext *ctx = avctx->priv_data;
 
 #if VPX_ENCODER_ABI_VERSION >= 12
-if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->level >= 0 &&
+!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
 int level_out = 0;
 if (!codecctl_intp(avctx, VP9E_GET_LEVEL, _out))
 av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 
0.1);
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

2016-12-08 Thread Alex Converse 
On Thu, Dec 8, 2016 at 12:36 PM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
>
> On 8 December 2016 at 19:42, Alex Converse <alex.conve...@gmail.com> wrote:
>>
>> On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
>> <atomnu...@gmail.com> wrote:
>> > On 7 December 2016 at 01:08, Alex Converse <alex.conve...@gmail.com>
>> > wrote:
>> >
>> >> Fixes
>> >> https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>> >>
>> >> Reported-by: rcombs on IRC
>> >> ---
>> >>  libavcodec/aacdec_template.c | 6 --
>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/libavcodec/aacdec_template.c
>> >> b/libavcodec/aacdec_template.c
>> >> index 8cfa34b..64d46e3 100644
>> >> --- a/libavcodec/aacdec_template.c
>> >> +++ b/libavcodec/aacdec_template.c
>> >> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext
>> >> *avctx, void *data,
>> >>  break;
>> >>  }
>> >>
>> >> -che_prev   = che;
>> >> -elem_type_prev = elem_type;
>> >> +if (elem_type < TYPE_DSE) {
>> >> +che_prev   = che;
>> >> +elem_type_prev = elem_type;
>> >> +}
>> >>
>> >>  if (err)
>> >>  goto fail;
>> >>
>> >
>> > I'm not quite following. So it prevents TYPE_DSE and above from getting
>> > into che_prev which goes into decode_extension_payload() which then
>> > decodes
>> > extensions. But DSE isn't the last in the enum, what about PCE, FIL and
>> > END
>> > elements?
>>
>> The actual use of elem_type_prev is to describe the element type of
>> che_prev, but che only updates for element types SCE, CPE, CCE, and
>> LFE (0, 1, 2, and 3). (che_prev is currently updated every element,
>> but if che isn't updated on an element then it's a noop.)
>>
>
> Thanks for the great explanation, now it all makes sense.
> Patch LGTM, feel free to push whenever you can.
>

Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.

2016-12-08 Thread Alex Converse 
On Thu, Dec 8, 2016 at 12:56 PM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
> On 8 December 2016 at 19:55, Alex Converse <alex.conve...@gmail.com> wrote:
>
>> It describes the type of the previous che element (SCE, CPE, CCE, or
>> LFE) and does not reflect non-che elements.
>> ---
>>  libavcodec/aacdec_template.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
[...]
>
> LGTM, thanks.

Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.

2016-12-08 Thread Alex Converse 
It describes the type of the previous che element (SCE, CPE, CCE, or
LFE) and does not reflect non-che elements.
---
 libavcodec/aacdec_template.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 64d46e3..83e9fb5 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2923,7 +2923,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 {
 AACContext *ac = avctx->priv_data;
 ChannelElement *che = NULL, *che_prev = NULL;
-enum RawDataBlockType elem_type, elem_type_prev = TYPE_END;
+enum RawDataBlockType elem_type, che_prev_type = TYPE_END;
 int err, elem_id;
 int samples = 0, multiplier, audio_found = 0, pce_found = 0;
 int is_dmono, sce_count = 0;
@@ -3029,7 +3029,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 goto fail;
 }
 while (elem_id > 0)
-elem_id -= decode_extension_payload(ac, gb, elem_id, che_prev, 
elem_type_prev);
+elem_id -= decode_extension_payload(ac, gb, elem_id, che_prev, 
che_prev_type);
 err = 0; /* FIXME */
 break;
 
@@ -3039,8 +3039,8 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 }
 
 if (elem_type < TYPE_DSE) {
-che_prev   = che;
-elem_type_prev = elem_type;
+che_prev  = che;
+che_prev_type = elem_type;
 }
 
 if (err)
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

2016-12-08 Thread Alex Converse 
On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
> On 7 December 2016 at 01:08, Alex Converse <alex.conve...@gmail.com> wrote:
>
>> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>>
>> Reported-by: rcombs on IRC
>> ---
>>  libavcodec/aacdec_template.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> index 8cfa34b..64d46e3 100644
>> --- a/libavcodec/aacdec_template.c
>> +++ b/libavcodec/aacdec_template.c
>> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext
>> *avctx, void *data,
>>  break;
>>  }
>>
>> -che_prev   = che;
>> -elem_type_prev = elem_type;
>> +if (elem_type < TYPE_DSE) {
>> +che_prev   = che;
>> +elem_type_prev = elem_type;
>> +}
>>
>>  if (err)
>>  goto fail;
>>
>
> I'm not quite following. So it prevents TYPE_DSE and above from getting
> into che_prev which goes into decode_extension_payload() which then decodes
> extensions. But DSE isn't the last in the enum, what about PCE, FIL and END
> elements?

The actual use of elem_type_prev is to describe the element type of
che_prev, but che only updates for element types SCE, CPE, CCE, and
LFE (0, 1, 2, and 3). (che_prev is currently updated every element,
but if che isn't updated on an element then it's a noop.)

>if (elem_type < TYPE_DSE) {
>if (!(che=get_che(ac, elem_type, elem_id))) {
>av_log(ac->avctx, AV_LOG_ERROR, "channel element %d.%d is not 
> allocated\n",
>   elem_type, elem_id);
>err = AVERROR_INVALIDDATA;
>goto fail;
>}
>samples = 1024;
>che->present = 1;
>}


Allowing elem_type_prev to desynchronize from che_prev means that the
SBR decoder is provided a che but incorrectly informed of the type of
element the che represents.

For example, the frames of the stream look like this:
[aac @ 0x25659c0] Elem type:0 id:0  // SCE
[aac @ 0x25659c0] Elem type:6 id:3  // FIL
[aac @ 0x25659c0] extension type: 11 len:3  // FIL payload DRC
[aac @ 0x25659c0] Elem type:6 id:9  // FIL
[aac @ 0x25659c0] extension type: 13 len:9  // FIL payload SBR
[aac @ 0x25659c0] Invalid bitstream - cannot apply SBR to element type 6
[aac @ 0x25659c0] Elem type:1 id:0  // CPE
[aac @ 0x25659c0] Elem type:6 id:f  // FIL
[aac @ 0x25659c0] extension type: 13 len:18  // FIL payload SBR
[aac @ 0x25659c0] Elem type:1 id:1  // CPE
[aac @ 0x25659c0] Elem type:6 id:f  // FIL
[aac @ 0x25659c0] extension type: 13 len:18 // FIL payload SBR
[aac @ 0x25659c0] Elem type:1 id:2  // CPE
[aac @ 0x25659c0] Elem type:6 id:f  // FIL
[aac @ 0x25659c0] extension type: 13 len:18  // FIL payload SBR
[aac @ 0x25659c0] Elem type:3 id:0  // LFE
[aac @ 0x25659c0] Elem type:4 id:0  // DSE
[aac @ 0x25659c0] Elem type:7  // END
[aac @ 0x25659c0] element type mismatch 3 != 0
[aac @ 0x25659c0] element type mismatch 0 != 6

In this case we clearly want to apply the first SBR element to the
first SCE element. But the DRC element between them means that we are
going to attempt to apply it the the first SCE element, but we are
going to tell the SBR decoder that the SCE element is a FIL element
which is nonsense.

Assuming we want to support streams like this (generated by
"Fraunhofer IIS MPEG-4 Audio Encoder 03.02.15_MPEGScbr_hdaac") the
che_prev should stay live across FIL elements.

The 2009 spec says:
> 4.5.2.8.2.2 SBR extension payload for the audio object
> types AAC main, AAC SSR, AAC LC and AAC LTP
>
> One SBR fill element is used per AAC syntactic element
> that is to be enhanced by SBR. SBR elements are
> inserted into the raw_data_block() after the
> corresponding AAC elements. Each AAC SCE, CPE or
> independently switched CCE must be succeeded by a
> corresponding SBR element. LFE elements are decoded
> according to standard AAC procedures but must be delay
> adjusted and re-sampled to match the output sample
> rate. Given below is an example of the structure of
> syntactic elements within a raw data block of a 5.1
> (multichannel) configuration, where SBR is used
> without a CRC check.
>
>  > // center
>  > // front L/R
>  > // back L/R
>  // sub
>  // (end of raw data block)

If someone really wanted to be pedantic about it, they could argue
that the SBR data has to follow the SCE, CPE, or CCE, but it doesn't
have to immediately follow the element. I think this is an awkward
interpretation of the text, but the text doesn't seem to otherwise
address having a diff

[FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

2016-12-06 Thread Alex Converse 
Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4

Reported-by: rcombs on IRC
---
 libavcodec/aacdec_template.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 8cfa34b..64d46e3 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
void *data,
 break;
 }
 
-che_prev   = che;
-elem_type_prev = elem_type;
+if (elem_type < TYPE_DSE) {
+che_prev   = che;
+elem_type_prev = elem_type;
+}
 
 if (err)
 goto fail;
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

2016-12-06 Thread Alex Converse 
On Tue, Dec 6, 2016 at 5:08 PM, Alex Converse <alex.conve...@gmail.com> wrote:
> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>
> Reported-by: rcombs on IRC
> ---
>  libavcodec/aacdec_template.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 8cfa34b..64d46e3 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -3038,8 +3038,10 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
> void *data,
>  break;
>  }
>
> -che_prev   = che;
> -elem_type_prev = elem_type;
> +if (elem_type < TYPE_DSE) {
> +che_prev   = che;
> +elem_type_prev = elem_type;
> +}
>

Arguably the che having knowledge of its element type would be better
design but more invasive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level

2016-11-28 Thread Alex Converse 
On Mon, Nov 28, 2016 at 11:57 AM, James Zern <jz...@google.com> wrote:
> On Mon, Nov 28, 2016 at 10:34 AM, Alex Converse <alex.conve...@gmail.com> 
> wrote:
>> Report the actual level of the encoded output if a level is
>> targeted or the level is passively tracked with a target of 0.
>> ---
>>  libavcodec/libvpxenc.c | 32 
>>  1 file changed, 32 insertions(+)
>>
>
> lgtm

pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level

2016-11-28 Thread Alex Converse 
On Tue, Nov 22, 2016 at 3:10 PM, James Zern <jz...@google.com> wrote:
> On Tue, Nov 22, 2016 at 12:08 PM, James Zern <jz...@google.com> wrote:
>> On Tue, Nov 22, 2016 at 12:04 PM, James Zern <jz...@google.com> wrote:
>>> On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse <alex.conve...@gmail.com> 
>>> wrote:
>>>> Report the actual level of the encoded output if a level is
>>>> targeted or the level is passively tracked with a target of 0.
>>>> ---
>>>>  libavcodec/libvpxenc.c | 31 +++
>>>>  1 file changed, 31 insertions(+)
>>>>
>>>
>>> lgtm.
>>> I don't know if there's a better way to report this at the stream
>>> level (AV_PKT_DATA_STRINGS_METADATA?), there doesn't seem to be
>>> anything specific right now. This info can be translated quickly if
>>> someone wants to make this more structured or has any opinion now.
>>>
>>
>> I forgot that there was some discussion around adding this to the
>> codec extradata in webm. That could be a followup if there's
>> documentation on the format for that.
>
> http://wiki.webmproject.org/vp9-codecprivate

Are there any tools that read or write this data. libavformat and
libvpx/webmenc.cc don't seem to implement it. I'd rather not be the
guinea pig for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libvpxenc: Report encoded VP9 level

2016-11-28 Thread Alex Converse 
Report the actual level of the encoded output if a level is
targeted or the level is passively tracked with a target of 0.
---
 libavcodec/libvpxenc.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 51f423a..1325199 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -137,6 +137,7 @@ static const char *const ctlidstr[] = {
 #endif
 #if VPX_ENCODER_ABI_VERSION >= 12
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+[VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
 #endif
 };
@@ -264,10 +265,41 @@ static av_cold int codecctl_int(AVCodecContext *avctx,
 return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
 }
 
+#if VPX_ENCODER_ABI_VERSION >= 12
+static av_cold int codecctl_intp(AVCodecContext *avctx,
+ enum vp8e_enc_control_id id, int *val)
+{
+VPxContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, "  %*s%d\n", width, buf, *val);
+
+res = vpx_codec_control(>encoder, id, val);
+if (res != VPX_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+}
+
+return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
+}
+#endif
+
 static av_cold int vpx_free(AVCodecContext *avctx)
 {
 VPxContext *ctx = avctx->priv_data;
 
+#if VPX_ENCODER_ABI_VERSION >= 12
+if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+int level_out = 0;
+if (!codecctl_intp(avctx, VP9E_GET_LEVEL, _out))
+av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 
0.1);
+}
+#endif
+
 vpx_codec_destroy(>encoder);
 if (ctx->is_alpha)
 vpx_codec_destroy(>encoder_alpha);
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libvpxenc: Support targeting a VP9 level

2016-11-22 Thread Alex Converse 
On Fri, Nov 18, 2016 at 3:44 PM, James Zern
<jzern-at-google@ffmpeg.org> wrote:
>
> On Fri, Nov 18, 2016 at 2:01 PM, Alex Converse <alex.conve...@gmail.com> 
> wrote:
> > Levels are specified at https://www.webmproject.org/vp9/levels/
> > ---
> >  libavcodec/libvpxenc.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
>
> lgtm

Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] libvpxenc: Report encoded VP9 level

2016-11-18 Thread Alex Converse 
Report the actual level of the encoded output if a level is
targeted or the level is passively tracked with a target of 0.
---
 libavcodec/libvpxenc.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 51f423a..a2fb82e 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -137,6 +137,7 @@ static const char *const ctlidstr[] = {
 #endif
 #if VPX_ENCODER_ABI_VERSION >= 12
 [VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+[VP9E_GET_LEVEL]   = "VP9E_GET_LEVEL",
 #endif
 #endif
 };
@@ -264,9 +265,39 @@ static av_cold int codecctl_int(AVCodecContext *avctx,
 return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
 }
 
+#if VPX_ENCODER_ABI_VERSION >= 12
+static av_cold int codecctl_intp(AVCodecContext *avctx,
+ enum vp8e_enc_control_id id, int *val)
+{
+VPxContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, "  %*s%d\n", width, buf, *val);
+
+res = vpx_codec_control(>encoder, id, val);
+if (res != VPX_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_encoder_error(avctx, buf);
+}
+
+return res == VPX_CODEC_OK ? 0 : AVERROR(EINVAL);
+}
+#endif
+
 static av_cold int vpx_free(AVCodecContext *avctx)
 {
 VPxContext *ctx = avctx->priv_data;
+int level_out = 0;
+
+#if VPX_ENCODER_ABI_VERSION >= 12
+if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1) &&
+!codecctl_intp(avctx, VP9E_GET_LEVEL, _out))
+  av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 0.1);
+#endif
 
 vpx_codec_destroy(>encoder);
 if (ctx->is_alpha)
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] libvpxenc: Support targeting a VP9 level

2016-11-18 Thread Alex Converse 
Levels are specified at https://www.webmproject.org/vp9/levels/
---
 libavcodec/libvpxenc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 68f25a4..51f423a 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -107,6 +107,7 @@ typedef struct VPxEncoderContext {
 int drop_threshold;
 int noise_sensitivity;
 int vpx_cs;
+float level;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -134,6 +135,9 @@ static const char *const ctlidstr[] = {
 #if VPX_ENCODER_ABI_VERSION >= 11
 [VP9E_SET_COLOR_RANGE] = "VP9E_SET_COLOR_RANGE",
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 12
+[VP9E_SET_TARGET_LEVEL]= "VP9E_SET_TARGET_LEVEL",
+#endif
 #endif
 };
 
@@ -680,6 +684,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if VPX_ENCODER_ABI_VERSION >= 11
 set_color_range(avctx);
 #endif
+#if VPX_ENCODER_ABI_VERSION >= 12
+codecctl_int(avctx, VP9E_SET_TARGET_LEVEL, ctx->level < 0 ? 255 : 
lrint(ctx->level * 10));
+#endif
 }
 #endif
 
@@ -1089,6 +1096,9 @@ static const AVOption vp9_options[] = {
 { "variance","Variance based Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
1}, 0, 0, VE, "aq_mode" },
 { "complexity",  "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 = 
2}, 0, 0, VE, "aq_mode" },
 { "cyclic",  "Cyclic Refresh Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
3}, 0, 0, VE, "aq_mode" },
+#if VPX_ENCODER_ABI_VERSION >= 12
+{"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
+#endif
 LEGACY_OPTIONS
 { NULL }
 };
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ivfenc: Add VPX codec tags.

2016-09-09 Thread Alex Converse 
This fixes remuxing VPX from MP4 without manually overwriting the tag.
---
 libavformat/ivfenc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 5dbcd97..f3ae4dc 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -97,6 +97,12 @@ static int ivf_check_bitstream(struct AVFormatContext *s, 
const AVPacket *pkt)
 return ret;
 }
 
+static const AVCodecTag codec_ivf_tags[] = {
+{ AV_CODEC_ID_VP8,  MKTAG('V', 'P', '8', '0') },
+{ AV_CODEC_ID_VP9,  MKTAG('V', 'P', '9', '0') },
+{ AV_CODEC_ID_NONE, 0 }
+};
+
 AVOutputFormat ff_ivf_muxer = {
 .priv_data_size = sizeof(IVFEncContext),
 .name = "ivf",
@@ -108,4 +114,5 @@ AVOutputFormat ff_ivf_muxer = {
 .write_packet = ivf_write_packet,
 .write_trailer = ivf_write_trailer,
 .check_bitstream = ivf_check_bitstream,
+.codec_tag= (const AVCodecTag* const []){ codec_ivf_tags, 0 },
 };
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] Parse VP9 when coming out of MP4.

2016-09-08 Thread Alex Converse 
Fixes Netflix VP9 DASH samples.
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a7595c5..6e80b93 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, 
AVIOContext *pb,
 case AV_CODEC_ID_EAC3:
 case AV_CODEC_ID_MPEG1VIDEO:
 case AV_CODEC_ID_VC1:
+case AV_CODEC_ID_VP9:
 st->need_parsing = AVSTREAM_PARSE_FULL;
 break;
 default:
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] Normalize VP8 and VP9 tags when writing IVF.

2016-09-08 Thread Alex Converse 
VP9-in-ISOM uses vp08 and vp09 tags, while ivf uses VP80 and VP90.
---
 libavformat/ivfenc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 5dbcd97..1735606 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -26,6 +26,17 @@ typedef struct IVFEncContext {
 uint64_t last_pts, sum_delta_pts;
 } IVFEncContext;
 
+static const int canonical_tag_vp8 = MKTAG('V', 'P', '8', '0');
+static const int canonical_tag_vp9 = MKTAG('V', 'P', '9', '0');
+
+static uint32_t canonicalize_tag(AVCodecParameters *par) {
+  switch (par->codec_id) {
+  case AV_CODEC_ID_VP8: return  MKTAG('V', 'P', '8', '0');
+  case AV_CODEC_ID_VP9: return  MKTAG('V', 'P', '9', '0');
+  default: return par->codec_tag;
+  }
+}
+
 static int ivf_write_header(AVFormatContext *s)
 {
 AVCodecParameters *par;
@@ -44,7 +55,7 @@ static int ivf_write_header(AVFormatContext *s)
 avio_write(pb, "DKIF", 4);
 avio_wl16(pb, 0); // version
 avio_wl16(pb, 32); // header length
-avio_wl32(pb, par->codec_tag ? par->codec_tag : par->codec_id == 
AV_CODEC_ID_VP9 ? AV_RL32("VP90") : AV_RL32("VP80"));
+avio_wl32(pb, canonicalize_tag(par));
 avio_wl16(pb, par->width);
 avio_wl16(pb, par->height);
 avio_wl32(pb, s->streams[0]->time_base.den);
-- 
2.8.0.rc3.226.g39d4020

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel