Re: [FFmpeg-devel] [PATCH v2] avformat/hls: release mem resource to fix memleak

[Derek Buitenhuis]

On 12/31/2017 6:19 AM, Derek Buitenhuis wrote:
> Looking closer into the implementation of av_opt_get just kind of made me sad,
> though. It has a bunch of unchecked allocations, such that it can return 0 but
> have the string be NULL. I'll send a patch tomorrow to address that properly.

Looks like this was already fixed, and I had an old copy of the code open in a 
tab.

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

Re: [FFmpeg-devel] [PATCH] Added missing break statements

[James Almer]

On 12/31/2017 6:34 PM, Aleksa Savic wrote:
> Signed-off-by: Aleksa Savic 
> ---
>  libavcodec/avs.c   | 2 ++
>  libavcodec/mpegvideo_enc.c | 1 +
>  libavformat/aiffdec.c  | 1 +
>  libavformat/lmlm4.c| 1 +
>  4 files changed, 5 insertions(+)
> 
> diff --git a/libavcodec/avs.c b/libavcodec/avs.c
> index 66724d47b7..fc158c761e 100644
> --- a/libavcodec/avs.c
> +++ b/libavcodec/avs.c
> @@ -99,6 +99,8 @@ avs_decode_frame(AVCodecContext * avctx,
>  case AVS_I_FRAME:
>  p->pict_type = AV_PICTURE_TYPE_I;
>  p->key_frame = 1;
> +break;
> +
>  case AVS_P_FRAME_3X3:
>  vect_w = 3;
>  vect_h = 3;
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index f1f4989231..66aa8a6b47 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -3046,6 +3046,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
>  break;
>  case AV_CODEC_ID_MPEG2VIDEO:
>  if(s->mb_x==0 && s->mb_y!=0) is_gob_start=1;
> +break;
>  case AV_CODEC_ID_MPEG1VIDEO:
>  if(s->mb_skip_run) is_gob_start=0;
>  break;
> diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
> index 99e05c78ec..58350e8cfe 100644
> --- a/libavformat/aiffdec.c
> +++ b/libavformat/aiffdec.c
> @@ -155,6 +155,7 @@ static int get_aiff_header(AVFormatContext *s, int size,
>  break;
>  case AV_CODEC_ID_ADPCM_G726LE:
>  par->bits_per_coded_sample = 5;
> +break;
>  case AV_CODEC_ID_ADPCM_IMA_WS:
>  case AV_CODEC_ID_ADPCM_G722:
>  case AV_CODEC_ID_MACE6:
> diff --git a/libavformat/lmlm4.c b/libavformat/lmlm4.c
> index d0cf8feb03..67d44e9962 100644
> --- a/libavformat/lmlm4.c
> +++ b/libavformat/lmlm4.c
> @@ -109,6 +109,7 @@ static int lmlm4_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  switch (frame_type) {
>  case LMLM4_I_FRAME:
>  pkt->flags = AV_PKT_FLAG_KEY;
> +break;
>  case LMLM4_P_FRAME:
>  case LMLM4_B_FRAME:
>  pkt->stream_index = 0;

Have you actually encountered an issue with any of these while decoding,
encoding or demuxing? Because I'm fairly sure most if not all are like
this on purpose.

If what you noticed were warnings from your compiler, then first analyze
each of the above cases and see if falling through is indeed the
intended behavior, and then add such a hint instead to silence the
compiler warnings.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Added missing break statements

[Aleksa Savic]

Signed-off-by: Aleksa Savic 
---
 libavcodec/avs.c   | 2 ++
 libavcodec/mpegvideo_enc.c | 1 +
 libavformat/aiffdec.c  | 1 +
 libavformat/lmlm4.c| 1 +
 4 files changed, 5 insertions(+)

diff --git a/libavcodec/avs.c b/libavcodec/avs.c
index 66724d47b7..fc158c761e 100644
--- a/libavcodec/avs.c
+++ b/libavcodec/avs.c
@@ -99,6 +99,8 @@ avs_decode_frame(AVCodecContext * avctx,
 case AVS_I_FRAME:
 p->pict_type = AV_PICTURE_TYPE_I;
 p->key_frame = 1;
+break;
+
 case AVS_P_FRAME_3X3:
 vect_w = 3;
 vect_h = 3;
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index f1f4989231..66aa8a6b47 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3046,6 +3046,7 @@ static int encode_thread(AVCodecContext *c, void *arg){
 break;
 case AV_CODEC_ID_MPEG2VIDEO:
 if(s->mb_x==0 && s->mb_y!=0) is_gob_start=1;
+break;
 case AV_CODEC_ID_MPEG1VIDEO:
 if(s->mb_skip_run) is_gob_start=0;
 break;
diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index 99e05c78ec..58350e8cfe 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -155,6 +155,7 @@ static int get_aiff_header(AVFormatContext *s, int size,
 break;
 case AV_CODEC_ID_ADPCM_G726LE:
 par->bits_per_coded_sample = 5;
+break;
 case AV_CODEC_ID_ADPCM_IMA_WS:
 case AV_CODEC_ID_ADPCM_G722:
 case AV_CODEC_ID_MACE6:
diff --git a/libavformat/lmlm4.c b/libavformat/lmlm4.c
index d0cf8feb03..67d44e9962 100644
--- a/libavformat/lmlm4.c
+++ b/libavformat/lmlm4.c
@@ -109,6 +109,7 @@ static int lmlm4_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 switch (frame_type) {
 case LMLM4_I_FRAME:
 pkt->flags = AV_PKT_FLAG_KEY;
+break;
 case LMLM4_P_FRAME:
 case LMLM4_B_FRAME:
 pkt->stream_index = 0;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

[Carl Eugen Hoyos]

2017-12-31 22:26 GMT+01:00 Carl Eugen Hoyos :
> 2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
>> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
>>> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
>>> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
>>> >> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>>> >
>>> >>>  for (i = 0; i < entries && !pb->eof_reached; i++) {
>>> >>> -int sample_duration;
>>> >>> +int sample_duration, ret;
>>> >>>  unsigned int sample_count;
>>> >>> +if (i > sc->stts_count) {
>>> >>> +ret = av_reallocp_array(>stts_data,
>>> >>> +FFMIN(sc->stts_count * 2LL, 
>>> >>> entries),
>>> >>> +sizeof(*sc->stts_data));
>>> >>
>>> >> this should use a variant of av_fast_realloc
>>> >
>>> > Do you prefer the new patch?
>>> > The old variant here looks slightly saner to me.
>>>
>>> Attached is what you possibly had in mind.
>>>
>>> Please review, Carl Eugen
>>
>>>  mov.c |   13 +++--
>>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>> cc7986179fe0ddc394457e8543d9ae907b49373c  
>>> 0001-lavf-mov-Use-av_fast_realloc-in-mov_read_stts.patch
>>> From f5fcd9ed1e5ce604c358a3787f1977277005ebb5 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sat, 30 Dec 2017 14:34:41 +0100
>>> Subject: [PATCH] lavf/mov: Use av_fast_realloc() in mov_read_stts().
>>>
>>> Avoids large allocations for short files with invalid stts entry.
>>> Fixes bugzilla 1102.
>>> ---
>>>  libavformat/mov.c |   13 +++--
>>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>>> index 2064473..1e97652 100644
>>> --- a/libavformat/mov.c
>>> +++ b/libavformat/mov.c
>>> @@ -2850,13 +2850,22 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
>>> *pb, MOVAtom atom)
>>>  av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
>>>  av_free(sc->stts_data);
>>>  sc->stts_count = 0;
>>> -sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
>>> -if (!sc->stts_data)
>>> +if (entries >= INT_MAX / sizeof(*sc->stts_data))
>>>  return AVERROR(ENOMEM);
>>
>> this leaves a stale pointer on error in sc->stts_data
>
> New patch attached.

Which would not have worked as intended, new variant attached.

Carl Eugen
From 9eaf0b56245820194e8e1bee0e3730f3c7362158 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 31 Dec 2017 22:30:57 +0100
Subject: [PATCH] lavf/mov: Use av_fast_realloc() in mov_read_stts().

Avoids large allocations for short files with invalid stts entry.
Fixes bugzilla 1102.
---
 libavformat/mov.c |   17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2064473..22faecf 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2830,7 +2830,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
 MOVStreamContext *sc;
-unsigned int i, entries;
+unsigned int i, entries, alloc_size = 0;
 int64_t duration=0;
 int64_t total_sample_count=0;
 
@@ -2848,15 +2848,24 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 
 if (sc->stts_data)
 av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
-av_free(sc->stts_data);
+av_freep(>stts_data);
 sc->stts_count = 0;
-sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
-if (!sc->stts_data)
+if (entries >= INT_MAX / sizeof(*sc->stts_data))
 return AVERROR(ENOMEM);
 
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
 unsigned int sample_count;
+unsigned min_entries = FFMIN(FFMAX(i, 1024 * 1024), entries);
+MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
+ min_entries * sizeof(*sc->stts_data));
+if (!stts_data) {
+av_freep(>stts_data);
+sc->stts_count = 0;
+return AVERROR(ENOMEM);
+}
+sc->stts_count = min_entries;
+sc->stts_data = stts_data;
 
 sample_count=avio_rb32(pb);
 sample_duration = avio_rb32(pb);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

[Carl Eugen Hoyos]

2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
>> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
>> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
>> >> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>> >
>> >>>  for (i = 0; i < entries && !pb->eof_reached; i++) {
>> >>> -int sample_duration;
>> >>> +int sample_duration, ret;
>> >>>  unsigned int sample_count;
>> >>> +if (i > sc->stts_count) {
>> >>> +ret = av_reallocp_array(>stts_data,
>> >>> +FFMIN(sc->stts_count * 2LL, 
>> >>> entries),
>> >>> +sizeof(*sc->stts_data));
>> >>
>> >> this should use a variant of av_fast_realloc
>> >
>> > Do you prefer the new patch?
>> > The old variant here looks slightly saner to me.
>>
>> Attached is what you possibly had in mind.
>>
>> Please review, Carl Eugen
>
>>  mov.c |   13 +++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>> cc7986179fe0ddc394457e8543d9ae907b49373c  
>> 0001-lavf-mov-Use-av_fast_realloc-in-mov_read_stts.patch
>> From f5fcd9ed1e5ce604c358a3787f1977277005ebb5 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 30 Dec 2017 14:34:41 +0100
>> Subject: [PATCH] lavf/mov: Use av_fast_realloc() in mov_read_stts().
>>
>> Avoids large allocations for short files with invalid stts entry.
>> Fixes bugzilla 1102.
>> ---
>>  libavformat/mov.c |   13 +++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 2064473..1e97652 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -2850,13 +2850,22 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>  av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
>>  av_free(sc->stts_data);
>>  sc->stts_count = 0;
>> -sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
>> -if (!sc->stts_data)
>> +if (entries >= INT_MAX / sizeof(*sc->stts_data))
>>  return AVERROR(ENOMEM);
>
> this leaves a stale pointer on error in sc->stts_data

New patch attached.

Thank you, Carl Eugen
From 42fc4aabccb5b5da0db2fd312187d90b303e96f7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 31 Dec 2017 22:25:29 +0100
Subject: [PATCH] lavf/mov: Use av_fast_realloc() in mov_read_stts().

Avoids large allocations for short files with invalid stts entry.
Fixes bugzilla 1102.
---
 libavformat/mov.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2064473..ee86c65 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2848,15 +2848,24 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 
 if (sc->stts_data)
 av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
-av_free(sc->stts_data);
+av_freep(>stts_data);
 sc->stts_count = 0;
-sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
-if (!sc->stts_data)
+if (entries >= INT_MAX / sizeof(*sc->stts_data))
 return AVERROR(ENOMEM);
 
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
 unsigned int sample_count;
+unsigned alloc_size = 0, min_entries = FFMIN(FFMAX(i, 1024 * 1024), entries);
+MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
+ min_entries * sizeof(*sc->stts_data));
+if (!stts_data) {
+av_freep(>stts_data);
+sc->stts_count = 0;
+return AVERROR(ENOMEM);
+}
+sc->stts_count = min_entries;
+sc->stts_data = stts_data;
 
 sample_count=avio_rb32(pb);
 sample_duration = avio_rb32(pb);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

[Michael Niedermayer]

On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
> >> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
> >
> >>>  for (i = 0; i < entries && !pb->eof_reached; i++) {
> >>> -int sample_duration;
> >>> +int sample_duration, ret;
> >>>  unsigned int sample_count;
> >>> +if (i > sc->stts_count) {
> >>> +ret = av_reallocp_array(>stts_data,
> >>> +FFMIN(sc->stts_count * 2LL, entries),
> >>> +sizeof(*sc->stts_data));
> >>
> >> this should use a variant of av_fast_realloc
> >
> > Do you prefer the new patch?
> > The old variant here looks slightly saner to me.
> 
> Attached is what you possibly had in mind.
> 
> Please review, Carl Eugen

>  mov.c |   13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> cc7986179fe0ddc394457e8543d9ae907b49373c  
> 0001-lavf-mov-Use-av_fast_realloc-in-mov_read_stts.patch
> From f5fcd9ed1e5ce604c358a3787f1977277005ebb5 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 30 Dec 2017 14:34:41 +0100
> Subject: [PATCH] lavf/mov: Use av_fast_realloc() in mov_read_stts().
> 
> Avoids large allocations for short files with invalid stts entry.
> Fixes bugzilla 1102.
> ---
>  libavformat/mov.c |   13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2064473..1e97652 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2850,13 +2850,22 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
>  av_free(sc->stts_data);
>  sc->stts_count = 0;
> -sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
> -if (!sc->stts_data)
> +if (entries >= INT_MAX / sizeof(*sc->stts_data))
>  return AVERROR(ENOMEM);

this leaves a stale pointer on error in sc->stts_data

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] mpeg: add experimental support for PSMF audio.

[Michael Niedermayer]

On Sun, Dec 31, 2017 at 05:46:04PM +0800, mi...@brew.sh wrote:
> From: Maxim Poliakovski 
> 
> Changes by Misty De Meo :
> 
> atrac3plus_parser: remove return statements for invalid data
> 
> atrac3plus_parser: use libavcodec's oma
> 
> atrac3plus_parser: pass along unexpected data unaltered
> 
> Change by Michael "Bazz" Bazzinotti :
> 
> atrac3plus_parser: don't always fail video for "2nd frame portion found"
> 
> Signed-off-by: Misty De Meo 
[...]
> +static int ff_atrac3p_parse(AVCodecParserContext *s,
> + AVCodecContext *avctx,
> + const uint8_t **poutbuf, int *poutbuf_size,
> + const uint8_t *buf, int buf_size)
> +{
> +Atrac3PlusParseContext *ctx = s->priv_data;
> +const uint8_t *hdr_buf = buf;
> +size_t bytes_remain;
> +int frame_size, hdr_bytes = 8;
> +int next = 0;
> +int second_portion_found = 0;
> +
> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES || !buf_size) {
> +next = buf_size;
> +} else {
> +if (buf_size >= 2) {
> +bytes_remain = AV_RB16(buf);
> +
> +if (bytes_remain != 0xFD0) {
> +second_portion_found = bytes_remain && !ctx->pc.index && 
> !ctx->hdr_bytes_needed;
> +/* Got something unexpected; either this means we got
> +   the second part of a frame and not the first part,
> +   or more likely these aren't ATRAC3+ packets in the
> +   format we're expecting. For example, it might mean
> +   the source data is from ATRAC3+ in RIFF WAVE, which
> +   doesn't use the same format as ATRAC3+ in MPEG.
> +   Just pass this along unaltered. */
> +if (second_portion_found && !ctx->got_bytes) {
> +*poutbuf = buf;
> +*poutbuf_size = buf_size;
> +return buf_size;
> +}
> +
> +next += 2;
> +buf  += 2;
> +buf_size -= 2;
> +hdr_buf = buf;
> +
> +if (second_portion_found) {
> +ctx->got_bytes = 0;
> +goto process;
> +}
> +
> +if (ctx->hdr_bytes_needed) {bytes_remain
> +if (buf_size >= ctx->hdr_bytes_needed) {
> +memcpy(>hdr[8 - ctx->hdr_bytes_needed],
> +   buf, ctx->hdr_bytes_needed);
> +hdr_bytes = ctx->hdr_bytes_needed;
> +ctx->hdr_bytes_needed = 0;
> +hdr_buf = ctx->hdr;
> +}
> +} else if (bytes_remain) {
> +if (buf_size < bytes_remain) {

> +av_log(avctx, AV_LOG_ERROR,
> +   "Couldn't combine frame: bytes needed=%d, 
> bytes supplied=%d\n",
> +   bytes_remain, buf_size);

Types mismatch

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] psmf: add FATE tests

[Michael Niedermayer]

On Sun, Dec 31, 2017 at 05:46:07PM +0800, mi...@brew.sh wrote:
> From: Misty De Meo 
> 
> ---
>  tests/Makefile  |  1 +
>  tests/fate/psmf.mak | 23 +++
>  2 files changed, 24 insertions(+)
>  create mode 100644 tests/fate/psmf.mak
> 
> diff --git a/tests/Makefile b/tests/Makefile
> index fd3713fe81..c569091fcb 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -165,6 +165,7 @@ include $(SRC_PATH)/tests/fate/pcm.mak
>  include $(SRC_PATH)/tests/fate/pixlet.mak
>  include $(SRC_PATH)/tests/fate/probe.mak
>  include $(SRC_PATH)/tests/fate/prores.mak
> +include $(SRC_PATH)/tests/fate/psmf.mak
>  include $(SRC_PATH)/tests/fate/qt.mak
>  include $(SRC_PATH)/tests/fate/qtrle.mak
>  include $(SRC_PATH)/tests/fate/real.mak
> diff --git a/tests/fate/psmf.mak b/tests/fate/psmf.mak
> new file mode 100644
> index 00..0d83daad49
> --- /dev/null
> +++ b/tests/fate/psmf.mak
> @@ -0,0 +1,23 @@
> +#
> +# Test detecting ATRAC-3 audio in Sony MPEG files
> +#
> +
> +PROBE_CODEC_NAME_COMMAND = \
> + ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \
> + -select_streams a -print_format default=noprint_wrappers=1 -bitexact -v > 0
> +
> +FATE_PSMF_FFPROBE = fate-psmf-probe-6 \
> + fate-psmf-probe-EV01_01_0500D
> +
> +fate-psmf-probe-6: SRC = $(TARGET_SAMPLES)/psmf/6.MPS
> +fate-psmf-probe-6: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
> +fate-psmf-probe-6: CMP = oneline
> +fate-psmf-probe-6: REF = codec_name=atrac3p
> +fate-psmf-probe-EV01_01_0500D: SRC = $(TARGET_SAMPLES)/psmf/EV01_01_0500D.PMF
> +fate-psmf-probe-EV01_01_0500D: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i 
> "$(SRC)"
> +fate-psmf-probe-EV01_01_0500D: CMP = oneline
> +fate-psmf-probe-EV01_01_0500D: REF = codec_name=atrac3p
> +
> +FATE_SAMPLES_FFPROBE += $(FATE_PSMF_FFPROBE)
> +
> +fate-psmf: $(FATE_PSMF_FFPROBE)

This breaks:
fate-mpegts-probe-latm

i guess the PROBE_CODEC_NAME_COMMAND is what is causing this

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Paul B Mahol]

On 12/31/17, Derek Buitenhuis  wrote:
> On 12/31/2017 2:08 PM, Paul B Mahol wrote:
> Why do they change?
> Do I understand correctly that the files get bigger (~5%)?
> If yes, wouldn't that indicate that the patch is not a good idea?

 Its because of different scaling path. Have nothing to do with
 good or bad idea.
>>>
>>> Thank you, imo this indicates the utvideo rgb tests
>>> should be fixed to use rgb input.
>>
>> Patch welcome.
>
> Shouldn't it be easy to force it in utvideo.mak? That would
> avoid the unnecessary FATE changes totally, and IMO, is preferable
> to changing them back later.

No because its swscale nonsense.

If input is rgb, output is unchanged with this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Derek Buitenhuis]

On 12/31/2017 2:04 PM, Carl Eugen Hoyos wrote:
> This is not helpful;-(
> Is it so unlikely that the patch has small gain for gbr
> (theoretically compensated by existing fast conversion
> from gbr to rgb) but large impact for rgb (with slow
> conversion from rgb into gbr)?

I went and tested the speed difference with and without this
patch, with rgb24 input. You'll be happy to know it came out
to be pretty much exactly the same speed after averaging 100
runs of each.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Derek Buitenhuis]

On 12/31/2017 2:08 PM, Paul B Mahol wrote:
 Why do they change?
 Do I understand correctly that the files get bigger (~5%)?
 If yes, wouldn't that indicate that the patch is not a good idea?
>>>
>>> Its because of different scaling path. Have nothing to do with
>>> good or bad idea.
>>
>> Thank you, imo this indicates the utvideo rgb tests
>> should be fixed to use rgb input.
> 
> Patch welcome.

Shouldn't it be easy to force it in utvideo.mak? That would
avoid the unnecessary FATE changes totally, and IMO, is preferable
to changing them back later.

- Derek

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Derek Buitenhuis]

On 12/31/2017 2:21 PM, Carl Eugen Hoyos wrote:
> The real-world issue I see is screen-recording.
> 
> Given that these are small functions and the obvious user advantage
> I really believe supporting both pix_fmts is the best solution.

Generic RGB packing has no place inside the encoder and decoder, IMO.
We've decided against it several times in the past, as well, such as
the cinepak encoder.

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

Re: [FFmpeg-devel] [PATCH] tcp: properly return EOF

[wm4]

On Sat, 30 Dec 2017 13:22:37 -0800
Aaron Levinson  wrote:

> On 12/30/2017 8:44 AM, wm4 wrote:
> > There is no POSIX error code for EOF - recv() signals EOF by simply
> > returning 0. But libavformat recently changed its conventionts and  
> 
> "conventionts" -> "conventions"
> 
> > requires an explicit AVERROR_EOF, or it might get into an endless retry
> > loop, consuming 100% CPU while doing nothing.
> > ---
> >   libavformat/tcp.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> > index fef0729da6..8773493df1 100644
> > --- a/libavformat/tcp.c
> > +++ b/libavformat/tcp.c
> > @@ -225,6 +225,8 @@ static int tcp_read(URLContext *h, uint8_t *buf, int 
> > size)
> >   return ret;
> >   }
> >   ret = recv(s->fd, buf, size, 0);
> > +if (ret == 0)
> > +return AVERROR_EOF;
> >   return ret < 0 ? ff_neterrno() : ret;
> >   }
> >   
> >   
> 
> LGTM

Pushed, with the typo fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Carl Eugen Hoyos]

2017-12-31 15:16 GMT+01:00 Paul B Mahol :
> On 12/31/17, Carl Eugen Hoyos  wrote:
>> 2017-12-31 10:48 GMT+01:00 Paul B Mahol :
>>
>>>  static void mangle_rgb_planes(uint8_t *dst[4], ptrdiff_t dst_stride,
>>
>> Why don't you add a new function mangle_gbr_planes() and
>> keep rgb encoding? The function is not very large.
>
> No. UtVideo expect planar rgb and planar rgb should be given to it.

The real-world issue I see is screen-recording.

Given that these are small functions and the obvious user advantage
I really believe supporting both pix_fmts is the best solution.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Paul B Mahol]

On 12/31/17, Carl Eugen Hoyos  wrote:
> 2017-12-31 10:48 GMT+01:00 Paul B Mahol :
>
>>  static void mangle_rgb_planes(uint8_t *dst[4], ptrdiff_t dst_stride,
>
> Why don't you add a new function mangle_gbr_planes() and
> keep rgb encoding? The function is not very large.

No. UtVideo expect planar rgb and planar rgb should be given to it.

This is also to keep sync with decoder, which dropped rgb packed support.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: move the old decoding/encoding API under and ifdef

[James Almer]

On 12/31/2017 10:07 AM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/avcodec.h | 4 +++-
>  libavcodec/version.h | 5 -
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c13deb599f..5a27211b80 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4558,6 +4558,7 @@ int avcodec_enum_to_chroma_pos(int *xpos, int *ypos, 
> enum AVChromaLocation pos);
>   */
>  enum AVChromaLocation avcodec_chroma_pos_to_enum(int xpos, int ypos);
>  
> +#if FF_API_OLD_CODING
>  /**
>   * Decode the audio frame of size avpkt->size from avpkt->data into frame.
>   *
> @@ -4609,7 +4610,7 @@ enum AVChromaLocation avcodec_chroma_pos_to_enum(int 
> xpos, int ypos);
>   * decoding, otherwise the number of bytes consumed from the input
>   * AVPacket is returned.
>   *
> -* @deprecated Use avcodec_send_packet() and avcodec_receive_frame().
> + * @deprecated Use avcodec_send_packet() and avcodec_receive_frame().
>   */
>  attribute_deprecated
>  int avcodec_decode_audio4(AVCodecContext *avctx, AVFrame *frame,
> @@ -4664,6 +4665,7 @@ attribute_deprecated
>  int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
>   int *got_picture_ptr,
>   const AVPacket *avpkt);
> +#endif
>  
>  /**
>   * Decode a subtitle message.
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 47a15d52b8..2886e76860 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -127,7 +127,10 @@
>  #define FF_API_USER_VISIBLE_AVHWACCEL (LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif
>  #ifndef FF_API_LOCKMGR
> -#define FF_API_LOCKMGR (LIBAVCODEC_VERSION_MAJOR < 59)
> +#define FF_API_LOCKMGR   (LIBAVCODEC_VERSION_MAJOR < 59)
> +#endif
> +#ifndef FF_API_OLD_CODING
> +#define FF_API_OLD_CODING(LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif

You haven't wrapped the actual implementations in decode.c and encode.c

In any case, the cosmetic changes here look good but should be in a
separate patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Carl Eugen Hoyos]

2017-12-31 10:48 GMT+01:00 Paul B Mahol :

>  static void mangle_rgb_planes(uint8_t *dst[4], ptrdiff_t dst_stride,

Why don't you add a new function mangle_gbr_planes() and
keep rgb encoding? The function is not very large.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Paul B Mahol]

On 12/31/17, Carl Eugen Hoyos  wrote:
> 2017-12-31 14:49 GMT+01:00 Paul B Mahol :
>> On 12/31/17, Carl Eugen Hoyos  wrote:
>>> 2017-12-31 10:48 GMT+01:00 Paul B Mahol :
 Signed-off-by: Paul B Mahol 
 ---
  libavcodec/utvideoenc.c   |  47 +---
  tests/ref/fate/utvideoenc_rgb_left| 100
 +-
  tests/ref/fate/utvideoenc_rgb_median  | 100
 +-
  tests/ref/fate/utvideoenc_rgb_none| 100
 +-
  tests/ref/fate/utvideoenc_rgba_left   | 100
 +-
  tests/ref/fate/utvideoenc_rgba_median | 100
 +-
  tests/ref/fate/utvideoenc_rgba_none   | 100
 +-
  7 files changed, 327 insertions(+), 320 deletions(-)
>>>
>>> Is there a speed impact?
>>> (Or actually: How much faster is gbr encoding, how much
>>> slower rgb encoding?)
>>
>> Very very fast, very very slow.
>
> This is not helpful;-(
> Is it so unlikely that the patch has small gain for gbr
> (theoretically compensated by existing fast conversion
> from gbr to rgb) but large impact for rgb (with slow
> conversion from rgb into gbr)?

No.

>
 diff --git a/tests/ref/fate/utvideoenc_rgb_left
 b/tests/ref/fate/utvideoenc_rgb_left
 index a1d200096a..1ee7c58564 100644
 --- a/tests/ref/fate/utvideoenc_rgb_left
 +++ b/tests/ref/fate/utvideoenc_rgb_left
>>>
>>> Why do they change?
>>> Do I understand correctly that the files get bigger (~5%)?
>>> If yes, wouldn't that indicate that the patch is not a good idea?
>>
>> Its because of different scaling path. Have nothing to do with
>> good or bad idea.
>
> Thank you, imo this indicates the utvideo rgb tests
> should be fixed to use rgb input.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Carl Eugen Hoyos]

2017-12-31 14:49 GMT+01:00 Paul B Mahol :
> On 12/31/17, Carl Eugen Hoyos  wrote:
>> 2017-12-31 10:48 GMT+01:00 Paul B Mahol :
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/utvideoenc.c   |  47 +---
>>>  tests/ref/fate/utvideoenc_rgb_left| 100
>>> +-
>>>  tests/ref/fate/utvideoenc_rgb_median  | 100
>>> +-
>>>  tests/ref/fate/utvideoenc_rgb_none| 100
>>> +-
>>>  tests/ref/fate/utvideoenc_rgba_left   | 100
>>> +-
>>>  tests/ref/fate/utvideoenc_rgba_median | 100
>>> +-
>>>  tests/ref/fate/utvideoenc_rgba_none   | 100
>>> +-
>>>  7 files changed, 327 insertions(+), 320 deletions(-)
>>
>> Is there a speed impact?
>> (Or actually: How much faster is gbr encoding, how much
>> slower rgb encoding?)
>
> Very very fast, very very slow.

This is not helpful;-(
Is it so unlikely that the patch has small gain for gbr
(theoretically compensated by existing fast conversion
from gbr to rgb) but large impact for rgb (with slow
conversion from rgb into gbr)?

>>> diff --git a/tests/ref/fate/utvideoenc_rgb_left
>>> b/tests/ref/fate/utvideoenc_rgb_left
>>> index a1d200096a..1ee7c58564 100644
>>> --- a/tests/ref/fate/utvideoenc_rgb_left
>>> +++ b/tests/ref/fate/utvideoenc_rgb_left
>>
>> Why do they change?
>> Do I understand correctly that the files get bigger (~5%)?
>> If yes, wouldn't that indicate that the patch is not a good idea?
>
> Its because of different scaling path. Have nothing to do with
> good or bad idea.

Thank you, imo this indicates the utvideo rgb tests
should be fixed to use rgb input.

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Paul B Mahol]

On 12/31/17, Carl Eugen Hoyos  wrote:
> 2017-12-31 10:48 GMT+01:00 Paul B Mahol :
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/utvideoenc.c   |  47 +---
>>  tests/ref/fate/utvideoenc_rgb_left| 100
>> +-
>>  tests/ref/fate/utvideoenc_rgb_median  | 100
>> +-
>>  tests/ref/fate/utvideoenc_rgb_none| 100
>> +-
>>  tests/ref/fate/utvideoenc_rgba_left   | 100
>> +-
>>  tests/ref/fate/utvideoenc_rgba_median | 100
>> +-
>>  tests/ref/fate/utvideoenc_rgba_none   | 100
>> +-
>>  7 files changed, 327 insertions(+), 320 deletions(-)
>
> Is there a speed impact?
> (Or actually: How much faster is gbr encoding, how much slower rgb
> encoding?)

Very very fast, very very slow.

>
>> diff --git a/tests/ref/fate/utvideoenc_rgb_left
>> b/tests/ref/fate/utvideoenc_rgb_left
>> index a1d200096a..1ee7c58564 100644
>> --- a/tests/ref/fate/utvideoenc_rgb_left
>> +++ b/tests/ref/fate/utvideoenc_rgb_left
>
> Why do they change?
> Do I understand correctly that the files get bigger (~5%)?
> If yes, wouldn't that indicate that the patch is not a good idea?

Its because of different scaling path. Have nothing to do with good or bad idea.

>
> Please add a micro version bump, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Carl Eugen Hoyos]

2017-12-31 10:48 GMT+01:00 Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/utvideoenc.c   |  47 +---
>  tests/ref/fate/utvideoenc_rgb_left| 100 
> +-
>  tests/ref/fate/utvideoenc_rgb_median  | 100 
> +-
>  tests/ref/fate/utvideoenc_rgb_none| 100 
> +-
>  tests/ref/fate/utvideoenc_rgba_left   | 100 
> +-
>  tests/ref/fate/utvideoenc_rgba_median | 100 
> +-
>  tests/ref/fate/utvideoenc_rgba_none   | 100 
> +-
>  7 files changed, 327 insertions(+), 320 deletions(-)

Is there a speed impact?
(Or actually: How much faster is gbr encoding, how much slower rgb encoding?)

> diff --git a/tests/ref/fate/utvideoenc_rgb_left 
> b/tests/ref/fate/utvideoenc_rgb_left
> index a1d200096a..1ee7c58564 100644
> --- a/tests/ref/fate/utvideoenc_rgb_left
> +++ b/tests/ref/fate/utvideoenc_rgb_left

Why do they change?
Do I understand correctly that the files get bigger (~5%)?
If yes, wouldn't that indicate that the patch is not a good idea?

Please add a micro version bump, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: mark AV_CODEC_CAP_SUBFRAMES as deprecated

[Rostislav Pehlivanov]

On 31 December 2017 at 13:13, wm4  wrote:

> On Sun, 31 Dec 2017 13:07:28 +
> Rostislav Pehlivanov  wrote:
>
> > The new decoding API supports 1 avpkt -> multiple avframes natively.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/avcodec.h | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 5a27211b80..7e74c3b01c 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -985,6 +985,7 @@ typedef struct RcOverride{
> >   */
> >  #define AV_CODEC_CAP_SMALL_LAST_FRAME(1 <<  6)
> >
> > +#if FF_API_OLD_CODING
> >  /**
> >   * Codec can output multiple frames per AVPacket
> >   * Normally demuxers return one frame at a time, demuxers which do not
> do
> > @@ -995,8 +996,10 @@ typedef struct RcOverride{
> >   * may return multiple frames in a packet. This has many disadvantages
> like
> >   * prohibiting stream copy in many cases thus it should only be
> considered
> >   * as a last resort.
> > + * @deprecated the new decoding API handles this natively
> >   */
> >  #define AV_CODEC_CAP_SUBFRAMES   (1 <<  8)
> > +#endif
> >  /**
> >   * Codec is experimental and is thus avoided in favor of non
> experimental
> >   * encoders
>
> That is completely orthogonal. The old API didn't require checking this
> either. (And some codecs are incorrectly marked anyway.)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Either way, we should deprecate this so its removed at the same time as the
old api.
The incorrectly marked codecs will be fixed when we port all decoders and
encoders to the new api.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: mark AV_CODEC_CAP_SUBFRAMES as deprecated

[wm4]

On Sun, 31 Dec 2017 13:07:28 +
Rostislav Pehlivanov  wrote:

> The new decoding API supports 1 avpkt -> multiple avframes natively.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/avcodec.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5a27211b80..7e74c3b01c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -985,6 +985,7 @@ typedef struct RcOverride{
>   */
>  #define AV_CODEC_CAP_SMALL_LAST_FRAME(1 <<  6)
>  
> +#if FF_API_OLD_CODING
>  /**
>   * Codec can output multiple frames per AVPacket
>   * Normally demuxers return one frame at a time, demuxers which do not do
> @@ -995,8 +996,10 @@ typedef struct RcOverride{
>   * may return multiple frames in a packet. This has many disadvantages like
>   * prohibiting stream copy in many cases thus it should only be considered
>   * as a last resort.
> + * @deprecated the new decoding API handles this natively
>   */
>  #define AV_CODEC_CAP_SUBFRAMES   (1 <<  8)
> +#endif
>  /**
>   * Codec is experimental and is thus avoided in favor of non experimental
>   * encoders

That is completely orthogonal. The old API didn't require checking this
either. (And some codecs are incorrectly marked anyway.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec: mark AV_CODEC_CAP_SUBFRAMES as deprecated

[Rostislav Pehlivanov]

The new decoding API supports 1 avpkt -> multiple avframes natively.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/avcodec.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5a27211b80..7e74c3b01c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -985,6 +985,7 @@ typedef struct RcOverride{
  */
 #define AV_CODEC_CAP_SMALL_LAST_FRAME(1 <<  6)
 
+#if FF_API_OLD_CODING
 /**
  * Codec can output multiple frames per AVPacket
  * Normally demuxers return one frame at a time, demuxers which do not do
@@ -995,8 +996,10 @@ typedef struct RcOverride{
  * may return multiple frames in a packet. This has many disadvantages like
  * prohibiting stream copy in many cases thus it should only be considered
  * as a last resort.
+ * @deprecated the new decoding API handles this natively
  */
 #define AV_CODEC_CAP_SUBFRAMES   (1 <<  8)
+#endif
 /**
  * Codec is experimental and is thus avoided in favor of non experimental
  * encoders
-- 
2.15.1.620.gb9897f4670

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

[FFmpeg-devel] [PATCH 1/2] avcodec: move the old decoding/encoding API under and ifdef

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/avcodec.h | 4 +++-
 libavcodec/version.h | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c13deb599f..5a27211b80 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4558,6 +4558,7 @@ int avcodec_enum_to_chroma_pos(int *xpos, int *ypos, enum 
AVChromaLocation pos);
  */
 enum AVChromaLocation avcodec_chroma_pos_to_enum(int xpos, int ypos);
 
+#if FF_API_OLD_CODING
 /**
  * Decode the audio frame of size avpkt->size from avpkt->data into frame.
  *
@@ -4609,7 +4610,7 @@ enum AVChromaLocation avcodec_chroma_pos_to_enum(int 
xpos, int ypos);
  * decoding, otherwise the number of bytes consumed from the input
  * AVPacket is returned.
  *
-* @deprecated Use avcodec_send_packet() and avcodec_receive_frame().
+ * @deprecated Use avcodec_send_packet() and avcodec_receive_frame().
  */
 attribute_deprecated
 int avcodec_decode_audio4(AVCodecContext *avctx, AVFrame *frame,
@@ -4664,6 +4665,7 @@ attribute_deprecated
 int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
  int *got_picture_ptr,
  const AVPacket *avpkt);
+#endif
 
 /**
  * Decode a subtitle message.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 47a15d52b8..2886e76860 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -127,7 +127,10 @@
 #define FF_API_USER_VISIBLE_AVHWACCEL (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
 #ifndef FF_API_LOCKMGR
-#define FF_API_LOCKMGR (LIBAVCODEC_VERSION_MAJOR < 59)
+#define FF_API_LOCKMGR   (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
+#ifndef FF_API_OLD_CODING
+#define FF_API_OLD_CODING(LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
 
 
-- 
2.15.1.620.gb9897f4670

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

Re: [FFmpeg-devel] [PATCH, V2] avformat/concat: Fix wrong wrapped timestamp

[Nicolas George]

Wu Zhiqiang (2017-12-30):
> Thanks for the patch, it works fine to me.
> Disable is good enough to prevent unnecessary wrap control.

Thanks for the testing. Patch pushed.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/6] mpeg: add experimental support for PSMF audio.

[misty]

From: Maxim Poliakovski 

Changes by Misty De Meo :

atrac3plus_parser: remove return statements for invalid data

atrac3plus_parser: use libavcodec's oma

atrac3plus_parser: pass along unexpected data unaltered

Change by Michael "Bazz" Bazzinotti :

atrac3plus_parser: don't always fail video for "2nd frame portion found"

Signed-off-by: Misty De Meo 
---
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/atrac3plus_parser.c | 170 +
 libavformat/mpeg.c |  27 ++-
 4 files changed, 198 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/atrac3plus_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ca72138c02..e0e3f1ebac 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -977,6 +977,7 @@ OBJS-$(CONFIG_AAC_PARSER)  += aac_parser.o 
aac_ac3_parser.o \
   mpeg4audio.o
 OBJS-$(CONFIG_AC3_PARSER)  += ac3tab.o aac_ac3_parser.o
 OBJS-$(CONFIG_ADX_PARSER)  += adx_parser.o adx.o
+OBJS-$(CONFIG_ATRAC3P_PARSER)  += atrac3plus_parser.o
 OBJS-$(CONFIG_BMP_PARSER)  += bmp_parser.o
 OBJS-$(CONFIG_CAVSVIDEO_PARSER)+= cavs_parser.o
 OBJS-$(CONFIG_COOK_PARSER) += cook_parser.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ed1e7ab06e..81d5d2814a 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -623,6 +623,7 @@ static void register_all(void)
 REGISTER_PARSER(AAC_LATM,   aac_latm);
 REGISTER_PARSER(AC3,ac3);
 REGISTER_PARSER(ADX,adx);
+REGISTER_PARSER(ATRAC3P,atrac3p);
 REGISTER_PARSER(BMP,bmp);
 REGISTER_PARSER(CAVSVIDEO,  cavsvideo);
 REGISTER_PARSER(COOK,   cook);
diff --git a/libavcodec/atrac3plus_parser.c b/libavcodec/atrac3plus_parser.c
new file mode 100644
index 00..4b3ef2c926
--- /dev/null
+++ b/libavcodec/atrac3plus_parser.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2016 Michael "Bazz" Bazzinotti 
+ * Copyright (C) 2014 Maxim Poliakovski
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "parser.h"
+#include "get_bits.h"
+#include "oma.h"
+
+typedef struct Atrac3PlusParseContext {
+ParseContext pc;
+uint8_t hdr[8];
+int hdr_bytes_needed;
+int sample_rate, channel_id, frame_size;
+uint8_t got_bytes;
+} Atrac3PlusParseContext;
+
+static int parse_sound_frame_header(Atrac3PlusParseContext *c,
+const uint8_t *buf)
+{
+uint16_t atrac_config;
+
+if (AV_RB16(buf) != 0x0FD0)
+return AVERROR_INVALIDDATA;
+
+atrac_config = AV_RB16([2]);
+c->sample_rate = oma_srate_tab[(atrac_config >> 13) & 7] * 100;
+c->channel_id  = (atrac_config >> 10) & 7;
+c->frame_size  = ((atrac_config & 0x3FF) * 8) + 8;
+
+if (!c->channel_id || !c->sample_rate || !c->frame_size)
+return AVERROR_INVALIDDATA;
+
+return 0;
+}
+
+static int ff_atrac3p_parse(AVCodecParserContext *s,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+Atrac3PlusParseContext *ctx = s->priv_data;
+const uint8_t *hdr_buf = buf;
+size_t bytes_remain;
+int frame_size, hdr_bytes = 8;
+int next = 0;
+int second_portion_found = 0;
+
+if (s->flags & PARSER_FLAG_COMPLETE_FRAMES || !buf_size) {
+next = buf_size;
+} else {
+if (buf_size >= 2) {
+bytes_remain = AV_RB16(buf);
+
+if (bytes_remain != 0xFD0) {
+second_portion_found = bytes_remain && !ctx->pc.index && 
!ctx->hdr_bytes_needed;
+/* Got something unexpected; either this means we got
+   the second part of a frame and not the first part,
+   or more likely these aren't ATRAC3+ packets in the
+   format we're expecting. For example, it might mean
+   the source data is from ATRAC3+ in RIFF WAVE, which
+

[FFmpeg-devel] [PATCH 5/6] mpeg: fix use of deprecated struct

[misty]

From: Misty De Meo 

---
 libavformat/mpeg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index a366ece0ed..210424faf3 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -547,8 +547,8 @@ redo:
 len--;
 for (i = 0; i < s->nb_streams; i++) {
 st = s->streams[i];
-if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
-st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+st->codecpar->codec_id == AV_CODEC_ID_ATRAC3P &&
 st->id - 0x1BD0 == (startcode & 0xF))
 goto found;
 }
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 0/6] mpeg: add experimental support for PSMF audio.

[misty]

From: Misty De Meo 

I think this version of the patch should address the issue. If frames
can't be parsed, the original data is passed through unaltered. From
what I can tell about the RIFF WAVE .at3 files, they don't use the
format being parsed at all and don't require parsing. With the updated
version of this patch, they play fine.
The new fate atrac3p conversion test behaves the same on both master
and with these patches, confirming there aren't any regressions.

Here's the media used in the tests. In response to your previous
feedback, I've reduced the PSMF test files to 64KB each; that's
enough for the ffprobe tests to succeed.

https://public.drac.at/bgm01.at3
https://public.drac.at/bgm01.s16
https://public.drac.at/6.MPS
https://public.drac.at/EV01_01_0500D.PMF

Maxim Poliakovski (1):
  mpeg: add experimental support for PSMF audio.

Misty De Meo (5):
  fate: add atrac3p conversion test
  oma: move some constants into libavcodec
  Fix detecting ATRAC3 audio from MPS files
  mpeg: fix use of deprecated struct
  psmf: add FATE tests

 Changelog |   1 +
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/atrac3plus_parser.c| 170 ++
 libavformat/oma.c => libavcodec/oma.h |  27 +++---
 libavcodec/version.h  |   2 +-
 libavformat/Makefile  |   4 +-
 libavformat/mpeg.c|  15 +++
 libavformat/mpeg.h|   1 +
 libavformat/oma.h |  21 ++---
 libavformat/omadec.c  |  13 +--
 libavformat/omaenc.c  |   7 +-
 libavformat/version.h |   2 +-
 tests/Makefile|   1 +
 tests/fate/atrac.mak  |   4 +
 tests/fate/psmf.mak   |  23 +
 16 files changed, 254 insertions(+), 39 deletions(-)
 create mode 100644 libavcodec/atrac3plus_parser.c
 rename libavformat/oma.c => libavcodec/oma.h (65%)
 create mode 100644 tests/fate/psmf.mak

-- 
2.15.1

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

[FFmpeg-devel] [PATCH] avcodec/utvideoenc: switch to planar RGB formats

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/utvideoenc.c   |  47 +---
 tests/ref/fate/utvideoenc_rgb_left| 100 +-
 tests/ref/fate/utvideoenc_rgb_median  | 100 +-
 tests/ref/fate/utvideoenc_rgb_none| 100 +-
 tests/ref/fate/utvideoenc_rgba_left   | 100 +-
 tests/ref/fate/utvideoenc_rgba_median | 100 +-
 tests/ref/fate/utvideoenc_rgba_none   | 100 +-
 7 files changed, 327 insertions(+), 320 deletions(-)

diff --git a/libavcodec/utvideoenc.c b/libavcodec/utvideoenc.c
index 840742caf7..9073be885d 100644
--- a/libavcodec/utvideoenc.c
+++ b/libavcodec/utvideoenc.c
@@ -67,12 +67,12 @@ static av_cold int utvideo_encode_init(AVCodecContext 
*avctx)
 c->slice_stride= FFALIGN(avctx->width, 32);
 
 switch (avctx->pix_fmt) {
-case AV_PIX_FMT_RGB24:
+case AV_PIX_FMT_GBRP:
 c->planes= 3;
 avctx->codec_tag = MKTAG('U', 'L', 'R', 'G');
 original_format  = UTVIDEO_RGB;
 break;
-case AV_PIX_FMT_RGBA:
+case AV_PIX_FMT_GBRAP:
 c->planes= 4;
 avctx->codec_tag = MKTAG('U', 'L', 'R', 'A');
 original_format  = UTVIDEO_RGBA;
@@ -243,36 +243,43 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 
 static void mangle_rgb_planes(uint8_t *dst[4], ptrdiff_t dst_stride,
-  uint8_t *src, int step, ptrdiff_t stride,
+  uint8_t *const src[4], int planes, const int 
stride[4],
   int width, int height)
 {
 int i, j;
 int k = 2 * dst_stride;
+const uint8_t *sg = src[0];
+const uint8_t *sb = src[1];
+const uint8_t *sr = src[2];
+const uint8_t *sa = src[3];
 unsigned int g;
 
 for (j = 0; j < height; j++) {
-if (step == 3) {
-for (i = 0; i < width * step; i += step) {
-g = src[i + 1];
+if (planes == 3) {
+for (i = 0; i < width; i++) {
+g = sg[i];
 dst[0][k] = g;
 g+= 0x80;
-dst[1][k] = src[i + 2] - g;
-dst[2][k] = src[i + 0] - g;
+dst[1][k] = sb[i] - g;
+dst[2][k] = sr[i] - g;
 k++;
 }
 } else {
-for (i = 0; i < width * step; i += step) {
-g = src[i + 1];
+for (i = 0; i < width; i++) {
+g = sg[i];
 dst[0][k] = g;
 g+= 0x80;
-dst[1][k] = src[i + 2] - g;
-dst[2][k] = src[i + 0] - g;
-dst[3][k] = src[i + 3];
+dst[1][k] = sb[i] - g;
+dst[2][k] = sr[i] - g;
+dst[3][k] = sa[i];
 k++;
 }
+sa += stride[3];
 }
 k += dst_stride - width;
-src += stride;
+sg += stride[0];
+sb += stride[1];
+sr += stride[2];
 }
 }
 
@@ -572,14 +579,14 @@ static int utvideo_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 }
 
 /* In case of RGB, mangle the planes to Ut Video's format */
-if (avctx->pix_fmt == AV_PIX_FMT_RGBA || avctx->pix_fmt == 
AV_PIX_FMT_RGB24)
-mangle_rgb_planes(c->slice_buffer, c->slice_stride, pic->data[0],
-  c->planes, pic->linesize[0], width, height);
+if (avctx->pix_fmt == AV_PIX_FMT_GBRAP || avctx->pix_fmt == 
AV_PIX_FMT_GBRP)
+mangle_rgb_planes(c->slice_buffer, c->slice_stride, >data[0],
+  c->planes, pic->linesize, width, height);
 
 /* Deal with the planes */
 switch (avctx->pix_fmt) {
-case AV_PIX_FMT_RGB24:
-case AV_PIX_FMT_RGBA:
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRAP:
 for (i = 0; i < c->planes; i++) {
 ret = encode_plane(avctx, c->slice_buffer[i] + 2 * c->slice_stride,
c->slice_buffer[i], c->slice_stride, i,
@@ -690,7 +697,7 @@ AVCodec ff_utvideo_encoder = {
 .close  = utvideo_encode_close,
 .capabilities   = AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
 .pix_fmts   = (const enum AVPixelFormat[]) {
-  AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA, 
AV_PIX_FMT_YUV422P,
+  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, 
AV_PIX_FMT_YUV422P,
   AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P, 
AV_PIX_FMT_NONE
   },
 };
diff --git a/tests/ref/fate/utvideoenc_rgb_left 
b/tests/ref/fate/utvideoenc_rgb_left
index a1d200096a..1ee7c58564 100644
--- a/tests/ref/fate/utvideoenc_rgb_left
+++ b/tests/ref/fate/utvideoenc_rgb_left
@@ -8,53 +8,53 @@
 #dimensions 0: 352x288
 #sar 0: 0/1
 #stream#, dts,pts, duration, size, hash
-0, 

[FFmpeg-devel] [PATCH 6/6] psmf: add FATE tests

[misty]

From: Misty De Meo 

---
 tests/Makefile  |  1 +
 tests/fate/psmf.mak | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 tests/fate/psmf.mak

diff --git a/tests/Makefile b/tests/Makefile
index fd3713fe81..c569091fcb 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -165,6 +165,7 @@ include $(SRC_PATH)/tests/fate/pcm.mak
 include $(SRC_PATH)/tests/fate/pixlet.mak
 include $(SRC_PATH)/tests/fate/probe.mak
 include $(SRC_PATH)/tests/fate/prores.mak
+include $(SRC_PATH)/tests/fate/psmf.mak
 include $(SRC_PATH)/tests/fate/qt.mak
 include $(SRC_PATH)/tests/fate/qtrle.mak
 include $(SRC_PATH)/tests/fate/real.mak
diff --git a/tests/fate/psmf.mak b/tests/fate/psmf.mak
new file mode 100644
index 00..0d83daad49
--- /dev/null
+++ b/tests/fate/psmf.mak
@@ -0,0 +1,23 @@
+#
+# Test detecting ATRAC-3 audio in Sony MPEG files
+#
+
+PROBE_CODEC_NAME_COMMAND = \
+   ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=codec_name \
+   -select_streams a -print_format default=noprint_wrappers=1 -bitexact -v 0
+
+FATE_PSMF_FFPROBE = fate-psmf-probe-6 \
+   fate-psmf-probe-EV01_01_0500D
+
+fate-psmf-probe-6: SRC = $(TARGET_SAMPLES)/psmf/6.MPS
+fate-psmf-probe-6: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
+fate-psmf-probe-6: CMP = oneline
+fate-psmf-probe-6: REF = codec_name=atrac3p
+fate-psmf-probe-EV01_01_0500D: SRC = $(TARGET_SAMPLES)/psmf/EV01_01_0500D.PMF
+fate-psmf-probe-EV01_01_0500D: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i 
"$(SRC)"
+fate-psmf-probe-EV01_01_0500D: CMP = oneline
+fate-psmf-probe-EV01_01_0500D: REF = codec_name=atrac3p
+
+FATE_SAMPLES_FFPROBE += $(FATE_PSMF_FFPROBE)
+
+fate-psmf: $(FATE_PSMF_FFPROBE)
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 4/6] Fix detecting ATRAC3 audio from MPS files

[misty]

From: Misty De Meo 

MPS files are MPEG files used on PSP Video discs. They lack
the PSMF header used by .pms files, and so the special casing
in the original patch fails to support their audio. This patch
fixes this by unconditionally reading a new byte for the startcode
for PRIVATE_STREAM_1 sections, and doing the comparison on that
to find ATRAC-3 streams. In my testing, it works fine for both MPS
and PSMF files.
---
 Changelog  |  1 +
 libavformat/mpeg.c | 38 ++
 libavformat/mpeg.h |  1 +
 3 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/Changelog b/Changelog
index ee48876128..67f28ea839 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
 - video setrange filter
 - nsp demuxer
 - support LibreSSL (via libtls)
+- ATRAC-3 support for Sony PSP MPEG files
 
 
 version 3.4:
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 895c6fb231..a366ece0ed 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -128,7 +128,6 @@ typedef struct MpegDemuxContext {
 int sofdec;
 int dvd;
 int imkh_cctv;
-int sony_psmf; // true if Play Station Movie file signature is present
 #if CONFIG_VOBSUB_DEMUXER
 AVFormatContext *sub_ctx;
 FFDemuxSubtitlesQueue q[32];
@@ -148,8 +147,6 @@ static int mpegps_read_header(AVFormatContext *s)
 avio_get_str(s->pb, 6, buffer, sizeof(buffer));
 if (!memcmp("IMKH", buffer, 4)) {
 m->imkh_cctv = 1;
-} else if (!memcmp("PSMF00", buffer, 6)) {
-m->sony_psmf = 1;
 } else if (!memcmp("Sofdec", buffer, 6)) {
 m->sofdec = 1;
 } else
@@ -444,7 +441,7 @@ redo:
 goto redo;
 }
 
-if (startcode == PRIVATE_STREAM_1 && !m->sony_psmf) {
+if (startcode == PRIVATE_STREAM_1) {
 startcode = avio_r8(s->pb);
 len--;
 }
@@ -544,28 +541,21 @@ redo:
 else
 request_probe= 1;
 type = AVMEDIA_TYPE_VIDEO;
-} else if (startcode == PRIVATE_STREAM_1 && m->sony_psmf) {
-uint8_t stream_id;
-
-if (len < 2)
-goto skip;
-stream_id = avio_r8(s->pb);
+// Sony PSP video with ATRAC-3 audio
+} else if (!(startcode & STREAM_TYPE_AUDIO_ATRAC3)) {
 avio_r8(s->pb); // skip padding
-len -= 2;
-if (!(stream_id & 0xF0)) { // seems like we got an ATRAC stream
-/* check if an appropriate stream already exists */
-for (i = 0; i < s->nb_streams; i++) {
-st = s->streams[i];
-if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
-st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
-st->id - 0x1BD0 == (stream_id & 0xF))
-goto found;
-}
-
-startcode = 0x1BD0 + (stream_id & 0xF);
-type  = AVMEDIA_TYPE_AUDIO;
-codec_id  = AV_CODEC_ID_ATRAC3P;
+len--;
+for (i = 0; i < s->nb_streams; i++) {
+st = s->streams[i];
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
+st->codec->codec_id == AV_CODEC_ID_ATRAC3P &&
+st->id - 0x1BD0 == (startcode & 0xF))
+goto found;
 }
+
+startcode = 0x1BD0 + (startcode & 0xF);
+type  = AVMEDIA_TYPE_AUDIO;
+codec_id  = AV_CODEC_ID_ATRAC3P;
 } else if (startcode == PRIVATE_STREAM_2) {
 type = AVMEDIA_TYPE_DATA;
 codec_id = AV_CODEC_ID_DVD_NAV;
diff --git a/libavformat/mpeg.h b/libavformat/mpeg.h
index 617e36cba8..efbadec8ba 100644
--- a/libavformat/mpeg.h
+++ b/libavformat/mpeg.h
@@ -58,6 +58,7 @@
 #define STREAM_TYPE_VIDEO_CAVS  0x42
 
 #define STREAM_TYPE_AUDIO_AC3   0x81
+#define STREAM_TYPE_AUDIO_ATRAC30xF0
 
 static const int lpcm_freq_tab[4] = { 48000, 96000, 44100, 32000 };
 
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 2/6] oma: move some constants into libavcodec

[misty]

From: Misty De Meo 

Most of the constants in libavcodec/oma aren't specific to
libavformat; moving them into libavcodec makes them available to
libavcodec as well as keeping them compatible with libavformat.

ff_oma_codec_tags uses a libavformat-specific type, so it has been
left in libavformat.
---
 libavformat/oma.c => libavcodec/oma.h | 27 +--
 libavcodec/version.h  |  2 +-
 libavformat/Makefile  |  4 ++--
 libavformat/oma.h | 21 +
 libavformat/omadec.c  | 13 +++--
 libavformat/omaenc.c  |  7 ---
 libavformat/version.h |  2 +-
 7 files changed, 37 insertions(+), 39 deletions(-)
 rename libavformat/oma.c => libavcodec/oma.h (65%)

diff --git a/libavformat/oma.c b/libavcodec/oma.h
similarity index 65%
rename from libavformat/oma.c
rename to libavcodec/oma.h
index f7ae3c9948..f091ef24ca 100644
--- a/libavformat/oma.c
+++ b/libavcodec/oma.h
@@ -18,25 +18,22 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#ifndef AVCODEC_OMA_H
+#define AVCODEC_OMA_H
+
+#include 
+
 #include "internal.h"
-#include "oma.h"
-#include "libavcodec/avcodec.h"
 #include "libavutil/channel_layout.h"
 
-const uint16_t ff_oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0 };
+#define EA3_HEADER_SIZE 96
+#define ID3v2_EA3_MAGIC "ea3"
+#define OMA_ENC_HEADER_SIZE 16
 
-const AVCodecTag ff_oma_codec_tags[] = {
-{ AV_CODEC_ID_ATRAC3,  OMA_CODECID_ATRAC3},
-{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P   },
-{ AV_CODEC_ID_MP3, OMA_CODECID_MP3   },
-{ AV_CODEC_ID_PCM_S16BE,   OMA_CODECID_LPCM  },
-{ AV_CODEC_ID_ATRAC3PAL,   OMA_CODECID_ATRAC3PAL },
-{ AV_CODEC_ID_ATRAC3AL,OMA_CODECID_ATRAC3AL  },
-{ 0 },
-};
+static const uint16_t oma_srate_tab[8] = { 320, 441, 480, 882, 960, 0 };
 
 /** map ATRAC-X channel id to internal channel layout */
-const uint64_t ff_oma_chid_to_native_layout[7] = {
+static const uint64_t oma_chid_to_native_layout[7] = {
 AV_CH_LAYOUT_MONO,
 AV_CH_LAYOUT_STEREO,
 AV_CH_LAYOUT_SURROUND,
@@ -47,4 +44,6 @@ const uint64_t ff_oma_chid_to_native_layout[7] = {
 };
 
 /** map ATRAC-X channel id to total number of channels */
-const int ff_oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
+static const int oma_chid_to_num_channels[7] = {1, 2, 3, 4, 6, 7, 8};
+
+#endif /* AVCODEC_OMA_H */
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d55de89797..d48857578d 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR   8
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cb70eac920..ef0365e6e2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -358,8 +358,8 @@ OBJS-$(CONFIG_OGG_MUXER) += oggenc.o \
 vorbiscomment.o
 OBJS-$(CONFIG_OGV_MUXER) += oggenc.o \
 vorbiscomment.o
-OBJS-$(CONFIG_OMA_DEMUXER)   += omadec.o pcm.o oma.o
-OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o oma.o id3v2enc.o
+OBJS-$(CONFIG_OMA_DEMUXER)   += omadec.o pcm.o
+OBJS-$(CONFIG_OMA_MUXER) += omaenc.o rawenc.o id3v2enc.o
 OBJS-$(CONFIG_OPUS_MUXER)+= oggenc.o \
 vorbiscomment.o
 OBJS-$(CONFIG_PAF_DEMUXER)   += paf.o
diff --git a/libavformat/oma.h b/libavformat/oma.h
index 36fd0125e4..41972830ec 100644
--- a/libavformat/oma.h
+++ b/libavformat/oma.h
@@ -21,14 +21,8 @@
 #ifndef AVFORMAT_OMA_H
 #define AVFORMAT_OMA_H
 
-#include 
-
 #include "internal.h"
 
-#define EA3_HEADER_SIZE 96
-#define ID3v2_EA3_MAGIC "ea3"
-#define OMA_ENC_HEADER_SIZE 16
-
 enum {
 OMA_CODECID_ATRAC3  = 0,
 OMA_CODECID_ATRAC3P = 1,
@@ -39,11 +33,14 @@ enum {
 OMA_CODECID_ATRAC3AL  = 34,
 };
 
-extern const uint16_t ff_oma_srate_tab[8];
-
-extern const AVCodecTag ff_oma_codec_tags[];
-
-extern const uint64_t ff_oma_chid_to_native_layout[7];
-extern const int ff_oma_chid_to_num_channels[7];
+static const AVCodecTag oma_codec_tags[] = {
+{ AV_CODEC_ID_ATRAC3,  OMA_CODECID_ATRAC3},
+{ AV_CODEC_ID_ATRAC3P, OMA_CODECID_ATRAC3P   },
+{ AV_CODEC_ID_MP3, OMA_CODECID_MP3   },
+{ AV_CODEC_ID_PCM_S16BE,   OMA_CODECID_LPCM  },
+{ AV_CODEC_ID_ATRAC3PAL,   OMA_CODECID_ATRAC3PAL },
+{ AV_CODEC_ID_ATRAC3AL,OMA_CODECID_ATRAC3AL  },
+{ 0 },
+};
 
 #endif /* AVFORMAT_OMA_H */
diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 

[FFmpeg-devel] [PATCH 1/6] fate: add atrac3p conversion test

[misty]

From: Misty De Meo 

---
 tests/fate/atrac.mak | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/fate/atrac.mak b/tests/fate/atrac.mak
index acf79a539c..1707373890 100644
--- a/tests/fate/atrac.mak
+++ b/tests/fate/atrac.mak
@@ -31,6 +31,10 @@ FATE_ATRAC3P += fate-atrac3p-2
 fate-atrac3p-2: CMD = pcm -i $(TARGET_SAMPLES)/atrac3p/sonateno14op27-2-cut.aa3
 fate-atrac3p-2: REF = $(SAMPLES)/atrac3p/sonateno14op27-2-cut.pcm
 
+FATE_ATRAC3P += fate-atrac3p-3
+fate-atrac3p-3: CMD = pcm -i $(TARGET_SAMPLES)/atrac3p/bgm01.at3
+fate-atrac3p-3: REF = $(SAMPLES)/atrac3p/bgm01.s16
+
 FATE_ATRAC3P-$(call DEMDEC, OMA, ATRAC3P) += $(FATE_ATRAC3P)
 
 FATE_ATRAC_ALL = $(FATE_ATRAC1-yes) $(FATE_ATRAC3-yes) $(FATE_ATRAC3P-yes)
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH][RFC]lavu/mem: Do not realloc in av_fast_alloc() if size == min_size

[Paul B Mahol]

On 12/30/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> FFmpeg has an arbitrary allocation limit (2G iirc), av_fast_realloc()
> increases the allocation even if the requested is equal the already
> allocated size. I believe this can lead to unnecessary OOM (no
> testcase) if the requested (and already allocated) size is close to
> our limit.
> Additionally, this avoids an over-allocation for the mov stts patch I just
> sent.
> Attached patch changes the behaviour introduced 15 years ago.
>
> Please comment, Carl Eugen
>

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