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

[Bang He]

On Wed, Jan 3, 2018 at 5:24 AM, Michael Niedermayer 
wrote:

> On Sun, Dec 31, 2017 at 05:46:02PM +0800, mi...@brew.sh wrote:
> > 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
>
> the reference file is a bit big but test works andf LGTM
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
how to run the test?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/rtpdec_jpeg: Treat stream type 64 like 0.

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 05:43:01AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch intends to fix ticket #5975, rfc 2435 says stream type
> 64 should be treated like 0.
> 
> Please review, Carl Eugen

>  rtpdec_jpeg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 6c39ed6cee670ad983250a1dd2566d9aa58b7abf  
> 0001-lavf-rtpdec_jpeg-Treat-jpeg-type-64-like-0.patch
> From 690f2fccf766f3cbb23a1ef45e235e25c355b197 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 5 Jan 2018 05:40:30 +0100
> Subject: [PATCH] lavf/rtpdec_jpeg: Treat jpeg type 64 like 0.
> 
> Fixes ticket #5975.
> ---
>  libavformat/rtpdec_jpeg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c
> index 465d9bc..3a33e3a 100644
> --- a/libavformat/rtpdec_jpeg.c
> +++ b/libavformat/rtpdec_jpeg.c
> @@ -162,7 +162,7 @@ static int jpeg_create_header(uint8_t *buf, int size, 
> uint32_t type, uint32_t w,
>  bytestream2_put_be16(, w);
>  bytestream2_put_byte(, 3); /* number of components */
>  bytestream2_put_byte(, 1); /* component number */
> -bytestream2_put_byte(, (2 << 4) | (type ? 2 : 1)); /* 
> hsample/vsample */
> +bytestream2_put_byte(, (2 << 4) | (type & ~64 ? 2 : 1)); /* 
> hsample/vsample */

isnt 64 masked out already ?
"type &= ~0x40;"

am i missing something ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH 1/2] adpcm: consume remainder after consuming XA chunks

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 08:06:48PM +1100, mi...@brew.sh wrote:
> From: Misty De Meo 
> 
> ---
>  libavcodec/adpcm.c | 7 +++
>  1 file changed, 7 insertions(+)

will apply

thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH 2/2] aiff: add explicit goto got_sound

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 08:06:49PM +1100, mi...@brew.sh wrote:
> From: Misty De Meo 
> 
> ---
>  Changelog | 1 +
>  libavformat/aiffdec.c | 3 +++
>  2 files changed, 4 insertions(+)

will apply

thanks

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 10:26:42PM +0100, Jerome Martinez wrote:
> On 05/01/2018 16:14, Tobias Rapp wrote:
> >On 05.01.2018 11:18, Jerome Martinez wrote:
> >>0001-FFV1-make-RGB48-support-as-non-experimental.patch
> >>
> >>From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001
> >>From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
> >>Date: Fri, 5 Jan 2018 11:09:01 +0100
> >>Subject: [PATCH] FFV1: make RGB48 support as non-experimental
> >
> >make => mark
> 
> I reused a commit text from history, both words words were in it.
> Anyway, attached is the updated .patch with the suggested subject line.



> 
> >
> >BTW: common subject line format would be something like "avcodec/ffv1enc:
> >mark RGB48 support as non-experimental"
> 

>  ffv1enc.c |4 
>  1 file changed, 4 deletions(-)
> acfc60c913b311b148f2eeef2d2d6ea9e37afcf7  
> 0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch
> From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
> Date: Fri, 5 Jan 2018 11:09:01 +0100
> Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental
> 
> Resulting bitstream was tested with a conformance checker
> using the last draft of FFV1 specifications.

But has the way this is stored been optimized ?

Once its marked as non exerimental all future decoders must support the exact
way. It can no longer then be changed, so we need to be really sure the design
is optimal first.
Are we ?
who has checked alternatives? what where the reasons why the alternatives
were not choosen?
for example consider get_context(), what it does with >8bit may or may not
be optimal
iam interrested to work on that in fact, ive a quite long and growing list
of other volunteer jobs to do though ...


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

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

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 10:34:44PM +1100, mi...@brew.sh wrote:
> 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] = {

Moving tables into header files which are included in multiple files
within the lib
libavformat/omadec.c:#include "libavcodec/oma.h"
libavformat/omadec.c:#include "oma.h"
libavformat/omaenc.c:#include "libavcodec/oma.h"
libavformat/omaenc.c:#include "oma.h"

would lead to duplicate versions of these tables within the lib
not a major issue as these are tiny but existing code does not do
such duplication. I think we should not add such intra lib
duplication


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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Carl Eugen Hoyos]

2018-01-05 23:58 GMT+01:00 Jacob Trimble :
> On Fri, Jan 5, 2018 at 2:01 PM, Carl Eugen Hoyos  wrote:
>> 2018-01-05 22:29 GMT+01:00 Jacob Trimble :
>>> On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  
>>> wrote:
 2018-01-05 20:49 GMT+01:00 Jacob Trimble 
 :

> +entry_count = avio_rb32(pb);
> +encryption_index->auxiliary_offsets = 
> av_malloc_array(sizeof(size_t), entry_count);

 (sizeof(variable) instead of sizeof(type), please.)

 But since this could be used for a dos attack, please change this
 to something similar to 1112ba01.
 If it is easy to avoid it, very short files should not allocate
 gigabytes.
>>>
>>> Switched to calculating the size based on the number of remaining
>>> bytes and returning an error if it doesn't match what is read.
>>
>> Sorry if I miss something:
>>
>>> +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 
>>> 0 ? 4 : 8);
>>> +if (avio_rb32(pb) != entry_count) {
>>> +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
>>> +return AVERROR_INVALIDDATA;
>>> +}
>>> +encryption_index->auxiliary_offsets =
>>> +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
>>> entry_count);
>>
>> Does this avoid a 1G allocation for a file of a few bytes?
>>
>> Didn't you simply increase the number of needed bytes to change in a valid
>> mov file to behave maliciously from one to two?
>
> From what I can tell, the mov_read_default method (which is what reads
> child atoms) will verify "atom.size" to fit inside the parent atom.
> This means that for "atom.size" to be excessively large for the file
> size, the input would need to be non-seekable (since I think the
> top-level atom uses the file size) and all the atoms would need to
> have invalid sizes.

(I did not check this but I am not convinced the sample I fixed last
week is so sophisticated.)

> But technically I guess it is possible.

Thank you.

> But this is basically malloc some number of bytes then read that many
> bytes.  The only alternative I can think of (in the face of
> non-seekable inputs) is to try-read in chunks until we hit EOF or the
> end of the expected size.  This seems like a lot of extra work that is

> not mirrored elsewhere.

On the contrary.

But you are right, I forgot to write that you have to add an "if (!eof)"
to the reading loops, see the function that above commit changed.

> There are several cases where this isn't explicitly checked.

Yes, and they will be fixed, please don't add another one.

> Also, how does this attack work?  If the number is way too big, well
> get EOM and error out.

Which not only causes dos but also makes checking for other (if you
like: more dangerous) issues more difficult which is bad. We already
know that there are cases where the issue is hard to avoid, I believe
this is not such a case.

It is possible to create (valid) samples that allocate a huge amount
of memory but very small files should not immediately allocate an
amount of several G.

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 2:01 PM, Carl Eugen Hoyos  wrote:
> 2018-01-05 22:29 GMT+01:00 Jacob Trimble :
>> On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  wrote:
>>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble 
>>> :
>>>
 +entry_count = avio_rb32(pb);
 +encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), 
 entry_count);
>>>
>>> (sizeof(variable) instead of sizeof(type), please.)
>>>
>>> But since this could be used for a dos attack, please change this
>>> to something similar to 1112ba01.
>>> If it is easy to avoid it, very short files should not allocate
>>> gigabytes.
>>
>> Switched to calculating the size based on the number of remaining
>> bytes and returning an error if it doesn't match what is read.
>
> Sorry if I miss something:
>
>> +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 
>> ? 4 : 8);
>> +if (avio_rb32(pb) != entry_count) {
>> +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +encryption_index->auxiliary_offsets =
>> +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
>> entry_count);
>
> Does this avoid a 1G allocation for a file of a few bytes?
>
> Didn't you simply increase the number of needed bytes to change in a valid
> mov file to behave maliciously from one to two?
>

From what I can tell, the mov_read_default method (which is what reads
child atoms) will verify "atom.size" to fit inside the parent atom.
This means that for "atom.size" to be excessively large for the file
size, the input would need to be non-seekable (since I think the
top-level atom uses the file size) and all the atoms would need to
have invalid sizes.  But technically I guess it is possible.

But this is basically malloc some number of bytes then read that many
bytes.  The only alternative I can think of (in the face of
non-seekable inputs) is to try-read in chunks until we hit EOF or the
end of the expected size.  This seems like a lot of extra work that is
not mirrored elsewhere.  There are several cases where this isn't
explicitly checked.

Also, how does this attack work?  If the number is way too big, well
get EOM and error out.  If it is large but there is enough memory,
we'll hit EOF and error out.  Would it be better to explicitly check
for EOF to avoid the loop running for longer than needed?  Or how
about freeing the memory on error so we don't keep the useless memory
around on the error case (even though the app will probably just free
the context anyway).

> Thank you, Carl Eugen
> ___
> 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] [RFC] avcodec/avcodec.h: Add encryption info side data

[James Almer]

On 1/5/2018 7:32 PM, Michael Niedermayer wrote:
> On Fri, Jan 05, 2018 at 08:27:41PM +0100, wm4 wrote:
>> On Fri, 5 Jan 2018 10:22:31 -0800
>> Jacob Trimble  wrote:
>>
>>> Just noticed the new files were in libavcodec, moved to libavutil.
>>> Can someone please review this so it can be pushed.  I have the MP4
>>> implementation ready and I would like to get that reviewed and pushed
>>> as soon as possible.
>>
>> I'd assume we'd wait with applying this until the mp4 patch that uses
>> it is reviewed. I'm fine with this patch and I think it can be pushed
>> as it is, although I just noticed an APIchanges entry and minor version
>> bump is actually missing. You could add them when sending the final
>> patch set.
>>
> 
>> Maybe getting confirmation from Michael Niedermayer that it's safe to
>> proceed would be good (i.e. that the patch will be accepted without
>> major changes).
> 
> if everyone is ok with the design and no regressions are found than iam ok
> with it as well

This being in libavutil, the two functions using AVPacket should be
changed to take and return a byte array instead, that the caller
manually either got from side data, or will afterwards adds as side data.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 08:27:41PM +0100, wm4 wrote:
> On Fri, 5 Jan 2018 10:22:31 -0800
> Jacob Trimble  wrote:
> 
> > Just noticed the new files were in libavcodec, moved to libavutil.
> > Can someone please review this so it can be pushed.  I have the MP4
> > implementation ready and I would like to get that reviewed and pushed
> > as soon as possible.
> 
> I'd assume we'd wait with applying this until the mp4 patch that uses
> it is reviewed. I'm fine with this patch and I think it can be pushed
> as it is, although I just noticed an APIchanges entry and minor version
> bump is actually missing. You could add them when sending the final
> patch set.
> 

> Maybe getting confirmation from Michael Niedermayer that it's safe to
> proceed would be good (i.e. that the patch will be accepted without
> major changes).

if everyone is ok with the design and no regressions are found than iam ok
with it as well


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Michael Niedermayer]

On Fri, Jan 05, 2018 at 10:22:31AM -0800, Jacob Trimble wrote:
> On Tue, Jan 2, 2018 at 9:57 AM, Jacob Trimble  wrote:
> > On Wed, Dec 20, 2017 at 4:31 PM, wm4  wrote:
> >> On Wed, 20 Dec 2017 15:10:43 -0800
> >> Jacob Trimble  wrote:
> >>
> >>> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep 17 00:00:00 2001
> >>> From: Jacob Trimble 
> >>> Date: Tue, 5 Dec 2017 14:52:22 -0800
> >>> Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.
> >>>
> >>> This new side-data will contain info on how a packet is encrypted.
> >>> This allows the app to handle packet decryption.
> >>>
> >>> Signed-off-by: Jacob Trimble 
> >>> ---
> >>
> >> Looks generally good to me, a few minor cosmetic comments below.
> >>
> >>>  libavcodec/Makefile  |   2 +
> >>>  libavcodec/avcodec.h |  13 
> >>>  libavcodec/encryption_info.c | 139 
> >>> +++
> >>>  libavcodec/encryption_info.h | 121 +
> >>>  4 files changed, 275 insertions(+)
> >>>  create mode 100644 libavcodec/encryption_info.c
> >>>  create mode 100644 libavcodec/encryption_info.h
> >>>
> >>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >>> index ab7893f560..11ad642c6c 100644
> >>> --- a/libavcodec/Makefile
> >>> +++ b/libavcodec/Makefile
> >>> @@ -10,6 +10,7 @@ HEADERS = ac3_parser.h  
> >>> \
> >>>dirac.h   \
> >>>dv_profile.h  \
> >>>dxva2.h   \
> >>> +  encryption_info.h \
> >>>jni.h \
> >>>mediacodec.h  \
> >>>qsv.h \
> >>> @@ -36,6 +37,7 @@ OBJS = ac3_parser.o 
> >>> \
> >>> dirac.o  \
> >>> dv_profile.o \
> >>> encode.o \
> >>> +   encryption_info.o\
> >>> imgconvert.o \
> >>> jni.o\
> >>> mathtables.o \
> >>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >>> index 5db6a81320..b43638ebc5 100644
> >>> --- a/libavcodec/avcodec.h
> >>> +++ b/libavcodec/avcodec.h
> >>> @@ -1327,6 +1327,19 @@ enum AVPacketSideDataType {
> >>>   */
> >>>  AV_PKT_DATA_A53_CC,
> >>>
> >>> +/**
> >>> + * This side data is encryption "initialization data".
> >>> + * For MP4 this is the entire 'pssh' box.
> >>> + * For WebM this is the key ID.
> >>> + */
> >>> +AV_PKT_DATA_ENCRYPTION_INIT_DATA,
> >>> +
> >>> +/**
> >>> + * This side data contains encryption info for how to decrypt the 
> >>> packet.
> >>> + * The format is not part of ABI, use av_encryption_info_* methods 
> >>> to access.
> >>> + */
> >>> +AV_PKT_DATA_ENCRYPTION_INFO,
> >>> +
> >>>  /**
> >>>   * The number of side data types.
> >>>   * This is not part of the public API/ABI in the sense that it may
> >>> diff --git a/libavcodec/encryption_info.c b/libavcodec/encryption_info.c
> >>> new file mode 100644
> >>> index 00..59ee4c41a9
> >>> --- /dev/null
> >>> +++ b/libavcodec/encryption_info.c
> >>> @@ -0,0 +1,139 @@
> >>> +/**
> >>> + * 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 "encryption_info.h"
> >>> +#include "libavutil/avassert.h"
> >>> +#include "libavutil/intreadwrite.h"
> >>> +
> >>> +#define FF_ENCRYPTION_INFO_EXTRA 

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Michael Niedermayer]

On Mon, Dec 18, 2017 at 11:17:48AM -0800, Jacob Trimble wrote:
> >> @@ -1327,6 +1384,19 @@ enum AVPacketSideDataType {
> >>   */
> >>  AV_PKT_DATA_A53_CC,
> >>
> >> +/**
> >> + * This side data is encryption "initialization data".
> >> + * For MP4 this is the entire 'pssh' box.
> >> + * For WebM this is the key ID.
> >> + */
> >> +AV_PKT_DATA_ENCRYPTION_INIT_DATA,
> >
> > So its basically like extradata is for a codec ?
> > If so it should be defined similarly as opaque encryption scheme specific 
> > data.
> > It should not be container specific.
> > Data taken from one container should be storable in another if both support
> > the features used
> 
> Yes, that's the idea.  Unfortunately the data is specific to a
> container.  This isn't taken from the common encryption spec, but from
> the EME spec.  The "EME initialization data registry" specifies
> several fixed formats for initialization data that are all specific to
> a container.  
> 
> It would be possible to parse the PSSH boxes and just push the generic
> data to the app.  This would allow new containers to hold the same
> data; then the app could wrap it back in a generic PSSH box for EME.
> But that would remove the key ID information that exists in v1 PSSH
> boxes.  Some apps parse the PSSH boxes and filter the initialization
> based on whether they already have those key IDs to avoid creating too
> many sessions.  So I would like to expose the whole PSSH box in the
> side data so apps can do that.

The format of teh side data should be choosen so that demuxers and encoders
producing it can interoperate with muxers and decoders consuming it.

Please correct me if iam wrong but if some containers can store more than
others, then the "other" containers would not use that extra information nor
set it but it could still be using a compatible representation for 
interoperability


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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Carl Eugen Hoyos]

2018-01-05 22:29 GMT+01:00 Jacob Trimble :
> On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  wrote:
>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>>
>>> +entry_count = avio_rb32(pb);
>>> +encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), 
>>> entry_count);
>>
>> (sizeof(variable) instead of sizeof(type), please.)
>>
>> But since this could be used for a dos attack, please change this
>> to something similar to 1112ba01.
>> If it is easy to avoid it, very short files should not allocate
>> gigabytes.
>
> Switched to calculating the size based on the number of remaining
> bytes and returning an error if it doesn't match what is read.

Sorry if I miss something:

> +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / (version == 0 
> ? 4 : 8);
> +if (avio_rb32(pb) != entry_count) {
> +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in saio\n");
> +return AVERROR_INVALIDDATA;
> +}
> +encryption_index->auxiliary_offsets =
> +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
> entry_count);

Does this avoid a 1G allocation for a file of a few bytes?

Didn't you simply increase the number of needed bytes to change in a valid
mov file to behave maliciously from one to two?

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

Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to upload samples to the fate suite

[Michael Niedermayer]

On Mon, Jan 01, 2018 at 01:17:18PM +0100, Michael Niedermayer wrote:
> Suggested-by: Compn
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/fate.texi | 20 
>  1 file changed, 20 insertions(+)

will apply


[...]
-- 
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 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[James Almer]

On 1/5/2018 6:29 PM, Jacob Trimble wrote:
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index eb3fb71e2a..9ff4a809b7 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5835,6 +5835,177 @@ static int mov_read_senc(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, 
> AVIOContext *pb, MOVEncryptionIndex *encryption_index)
> +{
> +AVEncryptionInfo **sample;
> +int64_t prev_pos;
> +size_t sample_count, sample_info_size, i;
> +int ret = 0;
> +
> +if (encryption_index->nb_encrypted_samples)
> +return 0;
> +sample_count = encryption_index->auxiliary_info_sample_count;
> +if (encryption_index->auxiliary_offsets_count != 1) {
> +av_log(c->fc, AV_LOG_ERROR, "Multiple auxiliary info chunks are not 
> supported\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
> +encryption_index->encrypted_samples = 
> av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);

Number of elements should be the first argument, and size of each
element the second argument.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos  wrote:
> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>
>> +entry_count = avio_rb32(pb);
>> +encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), 
>> entry_count);
>
> (sizeof(variable) instead of sizeof(type), please.)
>
> But since this could be used for a dos attack, please change this
> to something similar to 1112ba01.
> If it is easy to avoid it, very short files should not allocate
> gigabytes.

Switched to calculating the size based on the number of remaining
bytes and returning an error if it doesn't match what is read.

>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 3c60b4bf10f8711a8db70bf74cc5e4b8ce3d50e0 Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Fix parsing of saio/siaz atoms in encrypted
 content.

This doesn't support saio atoms with more than one offset.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |   6 ++
 libavformat/mov.c  | 186 +
 2 files changed, 192 insertions(+)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3794b1f0fd..3de8053da2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -114,6 +114,12 @@ typedef struct MOVEncryptionIndex {
 // settings will be used.
 unsigned int nb_encrypted_samples;
 AVEncryptionInfo **encrypted_samples;
+
+uint8_t* auxiliary_info_sizes;
+size_t auxiliary_info_sample_count;
+uint8_t auxiliary_info_default_size;
+size_t* auxiliary_offsets;  ///< Absolute seek position
+size_t auxiliary_offsets_count;
 } MOVEncryptionIndex;
 
 typedef struct MOVFragmentStreamInfo {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index eb3fb71e2a..9ff4a809b7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5835,6 +5835,177 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, AVIOContext *pb, MOVEncryptionIndex *encryption_index)
+{
+AVEncryptionInfo **sample;
+int64_t prev_pos;
+size_t sample_count, sample_info_size, i;
+int ret = 0;
+
+if (encryption_index->nb_encrypted_samples)
+return 0;
+sample_count = encryption_index->auxiliary_info_sample_count;
+if (encryption_index->auxiliary_offsets_count != 1) {
+av_log(c->fc, AV_LOG_ERROR, "Multiple auxiliary info chunks are not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
+encryption_index->encrypted_samples = av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
+if (!encryption_index->encrypted_samples)
+return AVERROR(ENOMEM);
+encryption_index->nb_encrypted_samples = sample_count;
+
+prev_pos = avio_tell(pb);
+if (avio_seek(pb, encryption_index->auxiliary_offsets[0], SEEK_SET) != encryption_index->auxiliary_offsets[i]) {
+av_log(c->fc, AV_LOG_INFO, "Failed to seek for auxiliary info, will only parse senc atoms for encryption info\n");
+goto finish;
+}
+
+for (i = 0; i < sample_count; i++) {
+sample = _index->encrypted_samples[i];
+sample_info_size = encryption_index->auxiliary_info_default_size
+   ? encryption_index->auxiliary_info_default_size
+   : encryption_index->auxiliary_info_sizes[i];
+
+ret = mov_read_sample_encryption_info(c, pb, sc, sample, sample_info_size > sc->cenc.per_sample_iv_size);
+if (ret < 0)
+goto finish;
+}
+
+finish:
+avio_seek(pb, prev_pos, SEEK_SET);
+return ret;
+}
+
+static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+MOVEncryptionIndex *encryption_index;
+MOVStreamContext *sc;
+int ret;
+unsigned int sample_count, has_saiz_type;
+
+ret = get_current_encryption_info(c, _index, );
+if (ret != 1)
+  return ret;
+
+if (encryption_index->nb_encrypted_samples) {
+// This can happen if we have both saio/saiz and senc atoms.
+av_log(c->fc, AV_LOG_DEBUG, "ignoring duplicate encryption info in saiz\n");
+return 0;
+}
+
+if (encryption_index->auxiliary_info_sample_count) {
+av_log(c->fc, AV_LOG_ERROR, "duplicate saiz atom\n");
+return AVERROR_INVALIDDATA;
+}
+
+avio_r8(pb); /* version */
+has_saiz_type = avio_rb24(pb) & 0x01;  /* flags */
+if (has_saiz_type) {
+if (avio_rb32(pb) != sc->cenc.default_encrypted_sample->scheme) {
+av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with non-zero aux_info_type\n");
+return 0;
+}
+if (avio_rb32(pb) != 0) {
+av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with 

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Jerome Martinez]

On 05/01/2018 16:14, Tobias Rapp wrote:

On 05.01.2018 11:18, Jerome Martinez wrote:

0001-FFV1-make-RGB48-support-as-non-experimental.patch

From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] FFV1: make RGB48 support as non-experimental


make => mark


I reused a commit text from history, both words words were in it.
Anyway, attached is the updated .patch with the suggested subject line.



BTW: common subject line format would be something like 
"avcodec/ffv1enc: mark RGB48 support as non-experimental" 


From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental

Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 09df4c0c57..c0c1558ffe 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -630,10 +630,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->bits_per_raw_sample = 16;
 s->use32bit = 1;
 s->version = FFMAX(s->version, 1);
-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(avctx, AV_LOG_ERROR, "16bit RGB is experimental and under 
development, only use it for experiments\n");
-return AVERROR_INVALIDDATA;
-}
 break;
 case AV_PIX_FMT_0RGB32:
 s->colorspace = 1;
-- 
2.13.3.windows.1

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

Re: [FFmpeg-devel] DAV files sample

[Carl Eugen Hoyos]

2018-01-05 15:33 GMT+01:00 Haaroon M. Yousaf :
> I’ve got a camera system that outputs DAV files.

Am I correct that the camera also records audio?

> When converted to MP4 through ffmpeg, the output mp4 video is fine.
> However there are many errors in regards to “data partitioning is not
>  being implemented” or “A non-intra slice in IDR NAL unit”.
>
> Would you like a sample/copy of this DAV file? It is 59,000 KB.

Yes, please.
Ideally, one that would allow to show a/v desync, like a pen knocking
on a table.

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: Expose encryption info to the app.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 12:43 PM, Carl Eugen Hoyos  wrote:
> 2018-01-05 20:49 GMT+01:00 Jacob Trimble :
>
>> +AV_WB32(side_data, size);
>> +AV_WL32(side_data + 4, MKTAG('p','s','s','h'));
>
> I didn't check:
> Is this what applications on both big- and little-endian expect?

Yes.  This should match the MP4 atom, so the size and 'pssh' string
should be big-endian.

>
> Carl Eugen
> ___
> 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

[FFmpeg-devel] [PATCH 2/2] tools/uncoded_frame: remove usage of avfilter_link_get_channels()

[James Almer]

Signed-off-by: James Almer 
---
 tools/uncoded_frame.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/uncoded_frame.c b/tools/uncoded_frame.c
index 3ca2ba4bbe..c044741701 100644
--- a/tools/uncoded_frame.c
+++ b/tools/uncoded_frame.c
@@ -178,7 +178,7 @@ int main(int argc, char **argv)
 break;
 case AVMEDIA_TYPE_AUDIO:
 st->stream->codec->channel_layout = st->link->channel_layout;
-st->stream->codec->channels = avfilter_link_get_channels(st->link);
+st->stream->codec->channels = st->link->channels;
 st->stream->codec->sample_rate = st->link->sample_rate;
 st->stream->codec->sample_fmt = st->link->format;
 st->stream->codec->codec_id =
-- 
2.15.0

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

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

[Misty De Meo]

Sorry about that - that was the placeholder title of a commit I
squashed into the mpeg commit, and forgot to remove when rebasing.
I'll remove it from the commit message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avfilter: deprecate avfilter_link_get_channels()

[James Almer]

And move the channels field to the public section of the struct.

Signed-off-by: James Almer 
---
 doc/APIchanges |  4 
 libavfilter/avfilter.c |  2 ++
 libavfilter/avfilter.h | 15 ++-
 libavfilter/version.h  |  5 -
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 38c1be61c7..6e48c8707e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-01-xx - xxx - lavfi 7.11.101 - avfilter.h
+  Deprecate avfilter_link_get_channels(), and make AVFilterLink->channels
+  public.
+
 2017-xx-xx - xxx - lavr 4.0.0 - avresample.h
   Deprecate the entire library. Merged years ago to provide compatibility
   with Libav, it remained unmaintained by the FFmpeg project and duplicated
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index ff7df672fd..ea75467a75 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -183,10 +183,12 @@ void avfilter_link_free(AVFilterLink **link)
 av_freep(link);
 }
 
+#if FF_API_FILTER_GET_SET
 int avfilter_link_get_channels(AVFilterLink *link)
 {
 return link->channels;
 }
+#endif
 
 void ff_filter_set_ready(AVFilterContext *filter, unsigned priority)
 {
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 47546c15e5..410d8bbdd7 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -448,6 +448,11 @@ struct AVFilterLink {
  */
 AVRational time_base;
 
+/**
+ * Number of channels.
+ */
+int channels;
+
 /*
  * All fields below this line are not part of the public API. They
  * may not be used outside of libavfilter and can be changed and
@@ -551,11 +556,6 @@ struct AVFilterLink {
  */
 int max_samples;
 
-/**
- * Number of channels.
- */
-int channels;
-
 /**
  * Link processing flags.
  */
@@ -647,10 +647,15 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
  */
 void avfilter_link_free(AVFilterLink **link);
 
+#if FF_API_FILTER_GET_SET
 /**
  * Get the number of channels of a link.
+ * @deprecated This accessor used to be provided for ABI compatibility, and
+ * does not need to be used anymore.
  */
+attribute_deprecated
 int avfilter_link_get_channels(AVFilterLink *link);
+#endif
 
 /**
  * Set the closed field of a link.
diff --git a/libavfilter/version.h b/libavfilter/version.h
index c07f4d30d9..0f11721822 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   7
 #define LIBAVFILTER_VERSION_MINOR  11
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
@@ -55,5 +55,8 @@
 #ifndef FF_API_LAVR_OPTS
 #define FF_API_LAVR_OPTS(LIBAVFILTER_VERSION_MAJOR < 8)
 #endif
+#ifndef FF_API_FILTER_GET_SET
+#define FF_API_FILTER_GET_SET   (LIBAVFILTER_VERSION_MAJOR < 8)
+#endif
 
 #endif /* AVFILTER_VERSION_H */
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Carl Eugen Hoyos]

2018-01-05 20:49 GMT+01:00 Jacob Trimble :

> +entry_count = avio_rb32(pb);
> +encryption_index->auxiliary_offsets = av_malloc_array(sizeof(size_t), 
> entry_count);

(sizeof(variable) instead of sizeof(type), please.)

But since this could be used for a dos attack, please change this
to something similar to 1112ba01.
If it is easy to avoid it, very short files should not allocate
gigabytes.

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

[FFmpeg-devel] DAV files sample

[Haaroon M. Yousaf]

I’ve got a camera system that outputs DAV files. 
When converted to MP4 through ffmpeg, the output mp4 video is fine. 
However there are many errors in regards to “data partitioning is not being 
implemented” or “A non-intra slice in IDR NAL unit”. 

Would you like a sample/copy of this DAV file? It is 59,000 KB. 

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: Expose encryption info to the app.

[Carl Eugen Hoyos]

2018-01-05 20:49 GMT+01:00 Jacob Trimble :

> +AV_WB32(side_data, size);
> +AV_WL32(side_data + 4, MKTAG('p','s','s','h'));

I didn't check:
Is this what applications on both big- and little-endian expect?

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

Re: [FFmpeg-devel] [PATCH 8/8] decklink: Add support for compressed AC-3 output over SDI

[Devin Heitmueller]

Hi Aaron,

>>  +static int create_s337_payload(AVPacket *pkt, enum AVCodecID codec_id, 
>> uint8_t **outbuf, int *outsize)
>> +{
>> +uint8_t *s337_payload;
>> +uint8_t *s337_payload_start;
>> +int i;
>> +
>> +/* Encapsulate AC3 syncframe into SMPTE 337 packet */
>> +*outsize = (pkt->size + 4) * sizeof(uint16_t);
>> +s337_payload = (uint8_t *) av_mallocz(*outsize);
>> +if (s337_payload == NULL)
>> +return AVERROR(ENOMEM);
>> +
>> +*outbuf = s337_payload;
> 
> Should not store s337_payload in outbuf until the end of the function and 
> returning success.  If it fails prematurely (say with the call to 
> AVERROR(EINVAL)), the caller may rightfully interpret this to mean that 
> outbuf has not been filled in and let outbuf leak.  In the case of failure, 
> this function should call av_free() on s337_payload.  Also technically true 
> for outsize as well--best to only modify output parameters when success is 
> guaranteed.

I actually had it that way in the original version, but it got moved during 
some refactoring.  That said, agreed it makes sense for the function to take 
responsibility for freeing the memory and not setting the output until the end 
of the function.

>>  -if (ctx->dlo->ScheduleAudioSamples(pkt->data, sample_count, pkt->pts,
>> +if (st->codecpar->codec_id == AV_CODEC_ID_AC3) {
>> +/* Encapsulate AC3 syncframe into SMPTE 337 packet */
>> +ret = create_s337_payload(pkt, st->codecpar->codec_id,
>> +  , _count);
>> +if (ret != 0)
> 
> Assuming that you make the change discussed above to create_s337_payload(), 
> can change to return ret here in case of failure.

Agreed

> 
>> +goto done;
>> +} else {
>> +sample_count = pkt->size / (ctx->channels << 1);
>> +outbuf = pkt->data;
>> +}
>> +
>> +if (ctx->dlo->ScheduleAudioSamples(outbuf, sample_count, pkt->pts,
>> bmdAudioSampleRate48kHz, NULL) != 
>> S_OK) {
> 
> Simple approach that eliminates the need for using goto and the done label:  
> store the return value of ScheduleAudioSamples() in a local variable.  Then, 
> free outbuf if appropriate.  Then handle the ScheduleAudioSamples() failure 
> case.  Eliminating the goto will also make the code easier to understand, and 
> it will result in the memory being deallocated immediately after it is no 
> longer needed.

Sure, with the above change we’ve now only got one case where we have to free 
the memory, there’s no need for the goto.

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

Re: [FFmpeg-devel] [PATCH 3/8] decklink: Introduce support for capture of multiple audio streams

[Devin Heitmueller]

Hello Matthias,

Thanks for the feedback.  Comments inline:

> On Jan 2, 2018, at 4:52 AM, Matthias Hunstock  wrote:
> 
> Am 29.12.2017 um 19:12 schrieb Devin Heitmueller:
>> To support the existing use case where multi-channel audio can be
>> captured (i.e. 7.1)
> 
> Just to be clear, the current use case is NOT to capture multi-channel
> audio like 7.1. It's just to capture all of the mono SDI channels into
> one FFmpeg-internal audio stream and FFmpeg calls 8 channels "7.1”.

Right.  The existing capture module can capture 2, 8, or 16 mono channels IIRC, 
and they’re all bundled as a single stream.  The underlying channel map is 
unspecified and has to be tweaked through a filter if needed.
> 
> As you already noticed, the audio mapping is far from standardized and
> has to be adapted anyway in most use cases... having said that, I find
> the option value "discrete" misleading. I would expect every channel to
> be in a separate stream when reading that, but I'm not a native english
> speaker. What about e.g. "bundled”?

No objection here.  The term “discrete” is just what the broadcast industry 
uses when sending uncompressed multi-channel audio over SDI (e.g. when dealing 
with 5.1 or 7.1).  That said, even in the “pairs” model I’m introducing it’s 
entirely possible that some of those pairs will be components to a 5.1, so I 
have no objection to using the vague term “bundled” since it boils down to all 
the possible audio channels available from the card.

> 
> Last but not least, I cannot find an update to the documentation in this
> patch ;)

Yup, that is indeed needed.  Will include in next patch.

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

Re: [FFmpeg-devel] [PATCH 3/8] decklink: Introduce support for capture of multiple audio streams

[Devin Heitmueller]

>> +if (ctx->max_audio_channels > DECKLINK_MAX_AUDIO_CHANNELS) {
>> +av_log(avctx, AV_LOG_WARNING, "Decklink card reported support for 
>> more channels than ffmpeg supports\n");
> 
> "Decklink" -> "DeckLink", "ffmpeg" -> "FFmpeg".  Also, I think it is 
> preferable to not state "FFmpeg" in this log message, as technically this is 
> in libavdevice.  If, say, libav were to merge your changes into their 
> codebase, then this particular log message would make that annoying.  Could 
> be something as simple as "Max audio channels for DeckLink reduced from %d to 
> %d.\n”.

Ok, no objection

>>  class decklink_output_callback;
>>  class decklink_input_callback;
>>  @@ -71,6 +75,7 @@ struct decklink_ctx {
>>  int bmd_height;
>>  int bmd_field_dominance;
>>  int supports_vanc;
>> +int64_t max_audio_channels;
> 
> Rationale for using an int64_t here when an int would likely be sufficient?  
> I understand that GetInt() takes an int64_t as input, but you could use a 
> temporary int64_t with GetInt() and store the value in a int 
> max_audio_channels.

I was just trying to avoid an intermediate variable and a cast.  Figured the 
added code wasn’t worth the trouble just to save eight bytes on a structure 
that there will likely only ever be one instance of.  No objection to doing 
what you’ve proposed though.

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[James Almer]

On 1/5/2018 4:49 PM, Jacob Trimble wrote:
> diff --git a/libavutil/aes_ctr.c b/libavutil/aes_ctr.c
> index e9c568fe0d..6ed69c8e10 100644
> --- a/libavutil/aes_ctr.c
> +++ b/libavutil/aes_ctr.c
> @@ -38,10 +38,9 @@ struct AVAESCTR *av_aes_ctr_alloc(void)
>  return av_mallocz(sizeof(struct AVAESCTR));
>  }
>  
> -void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv)
> +void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv)
>  {
> -memcpy(a->counter, iv, AES_CTR_IV_SIZE);
> -memset(a->counter + AES_CTR_IV_SIZE, 0, sizeof(a->counter) - 
> AES_CTR_IV_SIZE);
> +memcpy(a->counter, iv, sizeof(a->counter));
>  a->block_offset = 0;
>  }
>  
> @@ -52,12 +51,14 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a)
>  
>  void av_aes_ctr_set_random_iv(struct AVAESCTR *a)
>  {
> -uint32_t iv[2];
> +uint32_t iv[4];
>  
>  iv[0] = av_get_random_seed();
>  iv[1] = av_get_random_seed();
> +iv[2] = 0;
> +iv[3] = 0;
>  
> -av_aes_ctr_set_iv(a, (uint8_t*)iv);
> +av_aes_ctr_set_full_iv(a, (uint8_t*)iv);
>  }
>  
>  int av_aes_ctr_init(struct AVAESCTR *a, const uint8_t *key)
> diff --git a/libavutil/aes_ctr.h b/libavutil/aes_ctr.h
> index f596fa6a46..5995b37bec 100644
> --- a/libavutil/aes_ctr.h
> +++ b/libavutil/aes_ctr.h
> @@ -67,9 +67,9 @@ const uint8_t* av_aes_ctr_get_iv(struct AVAESCTR *a);
>  void av_aes_ctr_set_random_iv(struct AVAESCTR *a);
>  
>  /**
> - * Forcefully change the iv
> + * Forcefully change the "full" 16-byte iv, including the counter
>   */
> -void av_aes_ctr_set_iv(struct AVAESCTR *a, const uint8_t* iv);
> +void av_aes_ctr_set_full_iv(struct AVAESCTR *a, const uint8_t* iv);
>  
>  /**
>   * Increment the top 64 bit of the iv (performed after each frame)

You can't remove API just like that without a deprecation period.
Add a new av_aes_ctr_set_full_iv() function, and either leave
av_aes_ctr_set_iv() alone or deprecate it if it effectively becomes
superfluous after adding the new function.

Also, this patch needs to be split in three. One for the aes_crt
changes, one for the encryption_info changes, and one for mov changes,
with a minor libavutil version bump for the former two, and the
corresponding APIChanges entry.
Alternatively, you could also squash the new encryption_info API from
this patch into the one that actually introduces the entire feature.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

On Fri, Jan 5, 2018 at 11:49 AM, Jacob Trimble  wrote:
>> [...]

This adds two new fate tests that need to be uploaded by someone:

https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-frag-encrypted.mp4
https://storage.googleapis.com/shaka-demo-assets/_bugs/ffmpeg-fate-files/mov-tenc-only-encrypted.mp4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/rkmpp : Fix broken build and remove some useless code

[LongChair .]

Yes this was bound to very old versions afaik.

Mpp repo was squashed and we didn't have any version requirement

Current version is 1.3.7, if i trust my repo fork, previous version was 
1.0.0, so we could add that as a requirement.


On 05/01/2018 20:30, wm4 wrote:
> On Fri, 5 Jan 2018 19:22:00 +
> "LongChair ."  wrote:
>
>> Yes the newly used  control operation seems to have always been there
>> anyways, so there shouldn't be much compatibility issues.
> I mean the second patch removes a workaround for some old misbehavior,
> right? So it should probably be made sure that the user can't use an
> old version.
>
> Also please avoid https://en.wikipedia.org/wiki/Top_posting#Top-posting
> on the list.
> ___
> 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

[FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Jacob Trimble]

This doesn't support saio atoms with more than one offset.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |   6 ++
 libavformat/mov.c  | 174 +
 2 files changed, 180 insertions(+)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3794b1f0fd..3de8053da2 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -114,6 +114,12 @@ typedef struct MOVEncryptionIndex {
 // settings will be used.
 unsigned int nb_encrypted_samples;
 AVEncryptionInfo **encrypted_samples;
+
+uint8_t* auxiliary_info_sizes;
+size_t auxiliary_info_sample_count;
+uint8_t auxiliary_info_default_size;
+size_t* auxiliary_offsets;  ///< Absolute seek position
+size_t auxiliary_offsets_count;
 } MOVEncryptionIndex;
 
 typedef struct MOVFragmentStreamInfo {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index eb3fb71e2a..554b2be8bd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5835,6 +5835,165 @@ static int mov_read_senc(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_parse_auxiliary_info(MOVContext *c, MOVStreamContext *sc, 
AVIOContext *pb, MOVEncryptionIndex *encryption_index)
+{
+AVEncryptionInfo **sample;
+int64_t prev_pos;
+size_t sample_count, sample_info_size, i;
+int ret = 0;
+
+if (encryption_index->nb_encrypted_samples)
+return 0;
+sample_count = encryption_index->auxiliary_info_sample_count;
+if (encryption_index->auxiliary_offsets_count != 1) {
+av_log(c->fc, AV_LOG_ERROR, "Multiple auxiliary info chunks are not 
supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
+encryption_index->encrypted_samples = 
av_mallocz_array(sizeof(AVEncryptionInfo*), sample_count);
+if (!encryption_index->encrypted_samples)
+return AVERROR(ENOMEM);
+encryption_index->nb_encrypted_samples = sample_count;
+
+prev_pos = avio_tell(pb);
+if (avio_seek(pb, encryption_index->auxiliary_offsets[0], SEEK_SET) != 
encryption_index->auxiliary_offsets[i]) {
+av_log(c->fc, AV_LOG_INFO, "Failed to seek for auxiliary info, will 
only parse senc atoms for encryption info\n");
+goto finish;
+}
+
+for (i = 0; i < sample_count; i++) {
+sample = _index->encrypted_samples[i];
+sample_info_size = encryption_index->auxiliary_info_default_size
+   ? encryption_index->auxiliary_info_default_size
+   : encryption_index->auxiliary_info_sizes[i];
+
+ret = mov_read_sample_encryption_info(c, pb, sc, sample, 
sample_info_size > sc->cenc.per_sample_iv_size);
+if (ret < 0)
+goto finish;
+}
+
+finish:
+avio_seek(pb, prev_pos, SEEK_SET);
+return ret;
+}
+
+static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+MOVEncryptionIndex *encryption_index;
+MOVStreamContext *sc;
+int ret;
+unsigned int sample_count;
+
+ret = get_current_encryption_info(c, _index, );
+if (ret != 1)
+  return ret;
+
+if (encryption_index->nb_encrypted_samples) {
+// This can happen if we have both saio/saiz and senc atoms.
+av_log(c->fc, AV_LOG_DEBUG, "ignoring duplicate encryption info in 
saiz\n");
+return 0;
+}
+
+if (encryption_index->auxiliary_info_sample_count) {
+av_log(c->fc, AV_LOG_ERROR, "duplicate saiz atom\n");
+return AVERROR_INVALIDDATA;
+}
+
+avio_r8(pb); /* version */
+if (avio_rb24(pb) & 0x01) {  /* flags */
+if (avio_rb32(pb) != sc->cenc.default_encrypted_sample->scheme) {
+av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with non-zero 
aux_info_type\n");
+return 0;
+}
+if (avio_rb32(pb) != 0) {
+av_log(c->fc, AV_LOG_DEBUG, "ignoring saiz box with non-zero 
aux_info_type_parameter\n");
+return 0;
+}
+}
+
+encryption_index->auxiliary_info_default_size = avio_r8(pb);
+sample_count = avio_rb32(pb);
+encryption_index->auxiliary_info_sample_count = sample_count;
+
+if (encryption_index->auxiliary_info_default_size == 0) {
+encryption_index->auxiliary_info_sizes = av_malloc(sample_count);
+if (!encryption_index->auxiliary_info_sizes)
+return AVERROR(ENOMEM);
+if (avio_read(pb, encryption_index->auxiliary_info_sizes, 
sample_count) != sample_count) {
+av_log(c->fc, AV_LOG_ERROR, "failed to read the auxiliary info\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
+if (encryption_index->auxiliary_offsets_count) {
+return mov_parse_auxiliary_info(c, sc, pb, encryption_index);
+}
+
+return 0;
+}
+
+static int mov_read_saio(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+MOVEncryptionIndex *encryption_index;
+MOVStreamContext *sc;
+int i, ret;
+unsigned int version, entry_count;
+
+ret = 

[FFmpeg-devel] [PATCH 3/3] avformat/mov: Expose encryption info to the app.

[Jacob Trimble]

This exposes encryption info from the container to the app.  This
includes key ID, IV, and subsample byte ranges.  The info is passed
using the new side-data AV_PKT_DATA_ENCRYPTION_INIT_DATA.

Signed-off-by: Jacob Trimble 
---
 libavformat/mov.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 554b2be8bd..abd59d8c7b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5994,6 +5994,32 @@ static int mov_read_saio(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_pssh(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+uint8_t* side_data;
+size_t size;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+size = atom.size + 8;
+side_data = av_stream_new_side_data(st, AV_PKT_DATA_ENCRYPTION_INIT_DATA, 
size);
+if (!side_data) {
+return AVERROR(ENOMEM);
+}
+
+AV_WB32(side_data, size);
+AV_WL32(side_data + 4, MKTAG('p','s','s','h'));
+if (avio_read(pb, side_data + 8, atom.size) != atom.size) {
+av_log(c->fc, AV_LOG_ERROR, "failed to read the pssh atom\n");
+return AVERROR_INVALIDDATA;
+}
+
+return 0;
+}
+
 static int mov_read_schm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
@@ -6233,6 +6259,8 @@ static int cenc_filter(MOVContext *mov, MOVStreamContext 
*sc, AVPacket *pkt, int
 
 if (mov->decryption_key) {
 return cenc_decrypt(mov, sc, encrypted_sample, pkt->data, 
pkt->size);
+} else {
+return av_encryption_info_add_side_data(pkt, encrypted_sample);
 }
 }
 
@@ -6366,6 +6394,7 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
 { MKTAG('s','e','n','c'), mov_read_senc },
 { MKTAG('s','a','i','z'), mov_read_saiz },
 { MKTAG('s','a','i','o'), mov_read_saio },
+{ MKTAG('p','s','s','h'), mov_read_pssh },
 { MKTAG('s','c','h','m'), mov_read_schm },
 { MKTAG('s','c','h','i'), mov_read_default },
 { MKTAG('t','e','n','c'), mov_read_tenc },
-- 
2.16.0.rc0.223.g4a4ac83678-goog

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

[FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.

This doesn't support:
- Different sample descriptor holding different encryption info.
  - Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.

This removes support for saio/saiz atoms, but it was incorrect before.
A follow-up change will add correct support for those.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |  20 +-
 libavformat/mov.c  | 404 +
 libavutil/aes_ctr.c|  11 +-
 libavutil/aes_ctr.h|   4 +-
 libavutil/encryption_info.c|  17 ++
 libavutil/encryption_info.h|   6 +
 libavutil/tests/aes_ctr.c  |   2 +-
 tests/fate/mov.mak |   8 +
 tests/ref/fate/mov-frag-encrypted  |  57 +
 tests/ref/fate/mov-tenc-only-encrypted |  57 +
 10 files changed, 426 insertions(+), 160 deletions(-)
 create mode 100644 tests/ref/fate/mov-frag-encrypted
 create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 65676fb0f5..3794b1f0fd 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include "libavutil/encryption_info.h"
 #include "libavutil/mastering_display_metadata.h"
 #include "libavutil/spherical.h"
 #include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
 unsigned int index;
 } MOVSbgp;
 
+typedef struct MOVEncryptionIndex {
+// Individual encrypted samples.  If there are no elements, then the 
default
+// settings will be used.
+unsigned int nb_encrypted_samples;
+AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
 typedef struct MOVFragmentStreamInfo {
 int id;
 int64_t sidx_pts;
 int64_t first_tfra_pts;
 int64_t tfdt_dts;
 int index_entry;
+MOVEncryptionIndex *encryption_index;
 } MOVFragmentStreamInfo;
 
 typedef struct MOVFragmentIndexItem {
@@ -214,15 +223,10 @@ typedef struct MOVStreamContext {
 
 int has_sidx;  // If there is an sidx entry for this stream.
 struct {
-int use_subsamples;
-uint8_t* auxiliary_info;
-uint8_t* auxiliary_info_end;
-uint8_t* auxiliary_info_pos;
-uint8_t auxiliary_info_default_size;
-uint8_t* auxiliary_info_sizes;
-size_t auxiliary_info_sizes_count;
-int64_t auxiliary_info_index;
 struct AVAESCTR* aes_ctr;
+unsigned int per_sample_iv_size;  // Either 0, 8, or 16.
+AVEncryptionInfo *default_encrypted_sample;
+MOVEncryptionIndex *encryption_index;
 } cenc;
 } MOVStreamContext;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 22faecfc17..eb3fb71e2a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1324,6 +1324,7 @@ static int update_frag_index(MOVContext *c, int64_t 
offset)
 frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
 frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
 frag_stream_info[i].index_entry = -1;
+frag_stream_info[i].encryption_index = NULL;
 }
 
 if (index < c->frag_index.nb_items)
@@ -5710,117 +5711,224 @@ static int mov_read_frma(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
-static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+/**
+ * Gets the current encryption info and associated current stream context.  If
+ * we are parsing a track fragment, this will return the specific encryption
+ * info for this fragment; otherwise this will return the global encryption
+ * info for the current stream.
+ */
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex 
**encryption_index, MOVStreamContext **sc)
 {
+MOVFragmentStreamInfo *frag_stream_info;
 AVStream *st;
-MOVStreamContext *sc;
-size_t auxiliary_info_size;
+int i;
 
-if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
-return 0;
+frag_stream_info = get_current_frag_stream_info(>frag_index);
+if (frag_stream_info) {
+for (i = 0; i < c->fc->nb_streams; i++) {
+if (c->fc->streams[i]->id == frag_stream_info->id) {
+  st = c->fc->streams[i];
+  break;
+}
+}
+if (i == c->fc->nb_streams)
+return 0;
+*sc = st->priv_data;
 
-st = c->fc->streams[c->fc->nb_streams - 1];
-sc = st->priv_data;
+if (!frag_stream_info->encryption_index) {
+frag_stream_info->encryption_index = 
av_mallocz(sizeof(MOVEncryptionIndex));
+if (!frag_stream_info->encryption_index)
+   

Re: [FFmpeg-devel] [PATCH] fate: add PERSIST_RPARAM_A_RExt_Sony_3 hevc conformance test

[James Almer]

On 10/10/2017 7:32 AM, Michael Niedermayer wrote:
> On Mon, Oct 09, 2017 at 09:34:17PM -0300, James Almer wrote:
>> The PERSIST_RPARAM_A_RExt_Sony_1 bitstream has an out-of-range value
>> and has therefore been superseded.
>> It is otherwise identical, and decodes the same.
>>
>> Signed-off-by: James Almer 
>> ---
>>  tests/fate/hevc.mak| 3 
>> +--
>>  ...RAM_A_RExt_Sony_1 => hevc-conformance-PERSIST_RPARAM_A_RExt_Sony_3} | 0
>>  2 files changed, 1 insertion(+), 2 deletions(-)
>>  rename tests/ref/fate/{hevc-conformance-PERSIST_RPARAM_A_RExt_Sony_1 => 
>> hevc-conformance-PERSIST_RPARAM_A_RExt_Sony_3} (100%)
>>
>> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
>> index 2e798eca60..423b0630c7 100644
>> --- a/tests/fate/hevc.mak
>> +++ b/tests/fate/hevc.mak
>> @@ -167,7 +167,7 @@ HEVC_SAMPLES_444_8BIT = \
>>  
>>  HEVC_SAMPLES_444_12BIT =\
>>  IPCM_B_RExt_NEC \
>> -PERSIST_RPARAM_A_RExt_Sony_1\
>> +PERSIST_RPARAM_A_RExt_Sony_3\
>>  SAO_A_RExt_MediaTek_1   \
> 
> I think we should add but not replace tests
> 
> what created a file with a out of range value can have created more
> or could have been used as reference. 

Alright, added the new test without replacing the old one.
Still, though, it will have to be removed if we port the hevc decoder to
the cbs API, where range checks are strict.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/8] decklink: Add support for SCTE-104 to decklink capture

[Devin Heitmueller]

> On Dec 30, 2017, at 3:11 AM, Aaron Levinson  wrote:
> 
> On 12/29/2017 10:12 AM, Devin Heitmueller wrote:
>> Make use of libklvanc to parse SCTE-104 packets and announce them
>> as a new stream.  Right now we just pass the payload straight
>> through, but once this is hoooked into libklscte35 we'll be able
> 
> "hoooked" -> “hooked"

Ok.

>> +}
>> +st->codecpar->codec_type  = AVMEDIA_TYPE_DATA;
>> +st->time_base.den = ctx->bmd_tb_den;
>> +st->time_base.num = ctx->bmd_tb_num;
> 
> I wonder if there is any reason to set time_base here.  Aren't the triggers 
> relatively infrequent?

The triggers are relatively infrequent, but we want them to be frame accurate 
and when they do occur they may happen in bursts over multiple frames, and we 
want the clock to be accurate enough to ensure they are inserted into the 
correct video frame.  Putting them on the same clock as the video helps with 
that.

Devin

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

Re: [FFmpeg-devel] [PATCH 6/8] Add suppoort for using libklvanc from within decklink capture module

[Devin Heitmueller]

Hi Aaron,

> On Dec 30, 2017, at 2:34 AM, Aaron Levinson  wrote:
> 
> Patch title:  "suppoort" -> "support", also "decklink" -> “DeckLink"

Ok.

>>ff_decklink_cleanup(avctx);
>>  avpacket_queue_end(>queue);
>> +klvanc_context_destroy(ctx->vanc_ctx);
> 
> Shouldn't this last line be wrapped in #if CONFIG_LIBKLVANC?  I suggest 
> building this on Linux with and without libklvanc, and I also suggest 
> building it (and ideally testing it) on Windows without libklvanc as well.  
> DeckLink is also supported on OS/X.

Yup, that was a mistake I made preparing the latest patch.  The #ifdef guard 
got left out.

I do typically test-compile on both Linux and OS X both with and without the 
library present, but that process got skipped this time around (which was an 
error on my part).

I have confirmed though that was the only build error when the library isn’t 
present.

> 
>>av_freep(>ctx);
>>  @@ -1193,6 +1315,17 @@ av_cold int ff_decklink_read_header(AVFormatContext 
>> *avctx)
>>avpacket_queue_init (avctx, >queue);
>>  +#if CONFIG_LIBKLVANC
>> +if (klvanc_context_create(>vanc_ctx) < 0) {
>> +av_log(avctx, AV_LOG_ERROR, "Cannot create VANC library context\n");
>> +ret = AVERROR(ENOMEM);
> 
> Perhaps appropriate to use the return value of klvanc_context_create() as 
> input to AVERROR().

I think it’s usually bad practice to blindly return what a third party library 
returns.  Usually the error should be converted into some ffmpeg specific error 
code which the caller might actually know what to do with.  In this case I just 
return ENOMEM since that’s the only actual failure case possible in the call.

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

Re: [FFmpeg-devel] [PATCH 5/8] Support encoding of Active Format Description (AFD) in libx264

[Devin Heitmueller]

Hi Aaron,

>> +ret = ff_alloc_afd_sei(frame, 0, _data, _size);
>> +if (ret < 0) {
>> +for (i = 0; i < num_payloads; i++)
>> +av_free(x4->pic.extra_sei.payloads[i].payload);
>> +av_free(x4->pic.extra_sei.payloads);
> 
> Seems like it would be appropriate to use av_freep() for the last one to make 
> sure that payloads is zeroed out before returning.  Applies in other places.

No objection.

>>  int64_t ff_guess_coded_bitrate(AVCodecContext *avctx)
>>  {
>>  AVRational framerate = avctx->framerate;
> 
> I don't know enough about this to review the technical aspects of this code, 
> but I will say that these changes don't help those users that are encoding in 
> H.264 but using hardware encoders such as Intel QuickSync.

Correct.  As indicated in the original patch description, other encoders would 
need to be modified to take advantage of the feature if desired.  I’ll be doing 
VA-API soon enough since that is a use case I need, but the maintainers of the 
other hwaccel will have to decide whether to support it.  As with the A53 SEI, 
the business for constructing the payload is in utils.c, but each encoder will 
have to add code to send the SEI to the encoder (the means of which is specific 
to the encoder and cannot be common code).

If the other encoders make no changes then the AFD payload will be silently 
discarded, hence they are no worse off then they are today.

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

Re: [FFmpeg-devel] avcodec/rkmpp : Fix broken build and remove some useless code

[wm4]

On Fri, 5 Jan 2018 19:22:00 +
"LongChair ."  wrote:

> Yes the newly used  control operation seems to have always been there 
> anyways, so there shouldn't be much compatibility issues.

I mean the second patch removes a workaround for some old misbehavior,
right? So it should probably be made sure that the user can't use an
old version.

Also please avoid https://en.wikipedia.org/wiki/Top_posting#Top-posting
on the list.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/8] libavdevice/decklink: Add support for EIA-708 output over SDI

[Devin Heitmueller]

Hi Aaron,

Comments inline:
> 
> Most of the changes in this set of patches appear to only be relevant in the 
> case that libklvanc is enabled.  Nevertheless, a number of the changes are 
> not wrapped in #if CONFIG_LIBKLVANC, which means that they will be exercised 
> even if libklvanc is not available.  Most of these changes are benign, but 
> the change to use bmdVideoOutputVANC by default may not be benign.  I'm 
> unclear on any side effects of specifying bmdVideoOutputVANC for the output 
> flags instead of bmdVideoOutputFlagDefault.  If this change, for example, 
> exposes a bug in Blackmagic on Windows, where libklvanc is almost certainly 
> not currently available, then this code, which has previously been working on 
> Windows, will suddenly stop working, and for no good reason other than the 
> code is a bit cleaner without #if CONFIG_LIBKLVANC. I'm not saying that such 
> a Blackmagic bug exists (although it wouldn't surprise me if such a bug does 
> exist), but if the user doesn't have libklvanc available when building, as 
> will be the case for almost all users out there, it seems preferable not to 
> expose them to potential issues.  

I’ll do a check and see what is still being used if CONFIG_LIBKLVANC isn’t 
enabled.  Indeed, the focus has been on Linux and OS X, and I haven’t had a 
chance to do any work under Windows (and frankly I don’t really have any plans 
to at this point).

I did make an effort to ensure the code wasn’t being run if the library wasn’t 
present, but I obviously didn’t give it enough attention.

> I think this is also a good argument for having the libklvanc functionality 
> in FFmpeg proper.

There are numerous arguments for why it’s done as a separate library.  Feel 
free to read the responses to the other patch submissions.  I’m happy to 
discuss though in greater detail if desired.

> 
> I'd also argue that, even if CONFIG_LIBKLVANC is available, it should only 
> specify the VANC output flag in the case that VANC will actually be used.  
> Just because VANC is supported doesn't mean it should be used.

This cannot be determined when enabling the video output in cases such as with 
AFD and EIA-708, where the data is announced as side data to the AVFrame (i.e. 
that info isn’t available to us at the write_header phase).  Based on testing 
with a number of versions of the SDK and platforms, enabling it appears to be 
quite safe.  The cases where you get into trouble tend to be when generating 
the actual VANC lines (e.g. overflowing the buffer, etc).
> 
> After this point, assuming that SetAncillaryData() is implemented properly, 
> the reference count for vanc should be 2.  This code owns the "first" 
> reference, and the frame object owns the "second" reference. This code should 
> call Release() on vanc after this point, regardless of the return value of 
> SetAncillaryData().

Ok.  I’ll have to look closer at the reference counting.  I thought it was just 
cribbed from the decklink samples, but I’ll have to better understand what is 
going on here.

>> @@ -393,6 +532,9 @@ av_cold int ff_decklink_write_header(AVFormatContext 
>> *avctx)
>>  ctx->list_formats = cctx->list_formats;
>>  ctx->preroll  = cctx->preroll;
>>  cctx->ctx = ctx;
>> +#if CONFIG_LIBKLVANC
>> +klvanc_context_create(>vanc_ctx);
>> +#endif
> 
> Based on my perusal of the implementation of klvanc_context_create(), the 
> function may fail, yet any failure conditions are not handled here. 
> Admittedly, the only failure case I see in an out of memory error.

Yup, missing an error check.  Will fix.

Devin

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

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[wm4]

On Fri, 5 Jan 2018 10:22:31 -0800
Jacob Trimble  wrote:

> Just noticed the new files were in libavcodec, moved to libavutil.
> Can someone please review this so it can be pushed.  I have the MP4
> implementation ready and I would like to get that reviewed and pushed
> as soon as possible.

I'd assume we'd wait with applying this until the mp4 patch that uses
it is reviewed. I'm fine with this patch and I think it can be pushed
as it is, although I just noticed an APIchanges entry and minor version
bump is actually missing. You could add them when sending the final
patch set.

Maybe getting confirmation from Michael Niedermayer that it's safe to
proceed would be good (i.e. that the patch will be accepted without
major changes).

It's also possible that others are fine with pushing it now, but I'd
argue it should wait until something uses it.

(Personally I don't really appreciate the complexity of exporting this
metadata, when libavformat can already decrypt the data internally. But
I suppose it has valid use cases.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/8] decklink: Add support for output of Active Format Description (AFD)

[Devin Heitmueller]

Hello Aaron,

Thanks for the feedback.  Comments inline.

On Sat, Dec 30, 2017 at 12:34 AM, Aaron Levinson
 wrote:

> Technically, there are a number of 2K and 4K video modes supported by some
> DeckLink cards that have a 16x9 aspect ratio as well.  This code would treat
> such video modes at 4:3.  The various 4K DCI video modes supported by
> Blackmagic use an aspect ratio of 256:135, although perhaps it is sufficient
> to treat those as 16:9.  Perhaps the logic should be, anything with a width
> of 1280 or greater (or a height of 720 or greater) is 16:9--everything else
> can be treated as 4:3.

While SMPTE 2016-1 doesn't support anything above 1080p, I'm not
against a bit of future-proofing, in particular given this code is
already pretty ugly.

My thought would be to do (width / height) and if the value is (<=
1.33) then treat it as 4x3.  Otherwise treat it as 16:9.  That seems
general enough, and will ensure that any higher resolutions which get
introduced won't require a code change.

> Admittedly, libklvanc may not support VANC for 2K and 4K video anyway, but
> the Blackmagic devices do support it, so if you want to rule those out, then
> some explicit code to only support up to 720p/1080i (maybe 1080p?) probably
> ought to be added.

I'm not against such a change, given I haven't done any 4K testing.
Once some validation has been done then we can look to pull the check
out.

> On a separate note, based on a similar review I did awhile back, if this set
> of patches only supports a specific set of video modes, then there probably
> ought to be checks to make sure the code changes are only exercised for
> those video modes.

The goal at this point is to support all the video modes typically
seen in the broadcast industry.  We've got a flag called
"ctx->supports_vanc" which drives whether any of the VANC processing
happens, and I guess we could have some sort of list of supported
formats and the rest would have it disabled.  Then we an add the 4K
and RGB modes once they get some attention.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/rkmpp : Fix broken build and remove some useless code

[LongChair .]

Yes the newly used  control operation seems to have always been there 
anyways, so there shouldn't be much compatibility issues.


On 05/01/2018 20:19, wm4 wrote:
> On Fri, 5 Jan 2018 19:02:25 +
> "LongChair ."  wrote:
>
>> Hi,
>>
>> Here are two patches that should :
>>
>> - fix https://trac.ffmpeg.org/ticket/6834.
>>
>> - remove code that looked a bit hackish and which is not necessary anymore.
>>
>> The first patch is required as mpp removed some control operation from
>> the API, breaking the build.
>>
>> The second one is related to mpp fixes that make things work better.
>>
>> Both patches have been tested on ROCK64.
>>
>> More details are included in the patch themselves.
> LGTM - I assume the configure changes in the first patch guarantee that
> the second patch won't break with old mpp versions, since it raises the
> required version high enough.
>
> I can push the patches tomorrow or so, if nobody else has comments.
> ___
> 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] avcodec/rkmpp : Fix broken build and remove some useless code

[wm4]

On Fri, 5 Jan 2018 19:02:25 +
"LongChair ."  wrote:

> Hi,
> 
> Here are two patches that should :
> 
> - fix https://trac.ffmpeg.org/ticket/6834.
> 
> - remove code that looked a bit hackish and which is not necessary anymore.
> 
> The first patch is required as mpp removed some control operation from 
> the API, breaking the build.
> 
> The second one is related to mpp fixes that make things work better.
> 
> Both patches have been tested on ROCK64.
> 
> More details are included in the patch themselves.

LGTM - I assume the configure changes in the first patch guarantee that
the second patch won't break with old mpp versions, since it raises the
required version high enough.

I can push the patches tomorrow or so, if nobody else has comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Chinese DTMB streams playback issue

[Moritz Barsnick]

On Thu, Jan 04, 2018 at 20:42:33 -0500, Abylay Ospan wrote:
> I have made dump of DTMB streams (digital TV standard in China, like
> DVB-T in Europe, etc).
[...]
> Should I create ticket in https://trac.ffmpeg.org ?

Yes, please.

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

[FFmpeg-devel] avcodec/rkmpp : Fix broken build and remove some useless code

[LongChair .]

Hi,

Here are two patches that should :

- fix https://trac.ffmpeg.org/ticket/6834.

- remove code that looked a bit hackish and which is not necessary anymore.

The first patch is required as mpp removed some control operation from 
the API, breaking the build.

The second one is related to mpp fixes that make things work better.

Both patches have been tested on ROCK64.

More details are included in the patch themselves.

LongChair

From 49ecde4c7a5f87eff66d1ec44957cb0f914f3732 Mon Sep 17 00:00:00 2001
From: LongChair 
Date: Mon, 1 Jan 2018 15:47:54 +0100
Subject: [PATCH] avcodec/rkmpp : Fix broken build due to missing control
 operation

This patch is taking care of https://trac.ffmpeg.org/ticket/6834.
It seems that one of the control operations that was available to get the free decoders input slots was removed.
There is another control operation to retrieve the used slots. Given that the input slot count is hardcoded to 4 in mpp at this point, replacing the old control operation by the other one.

This was tested on Rockchip ROCK64.
---
 configure |  2 +-
 libavcodec/rkmppdec.c | 10 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 26da82072d..f1e4206ae8 100755
--- a/configure
+++ b/configure
@@ -5997,7 +5997,7 @@ enabled openssl   && { check_pkg_config openssl openssl openssl/ssl.h OP
die "ERROR: openssl not found"; }
 enabled rkmpp && { { require_pkg_config rkmpp rockchip_mpp rockchip/rk_mpi.h mpp_create ||
  die "ERROR : Rockchip MPP was not found."; } &&
-   { check_func_headers rockchip/rk_mpi_cmd.h "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
+   { check_func_headers rockchip/rk_mpi_cmd.h "MPP_DEC_GET_STREAM_COUNT" ||
  die "ERROR: Rockchip MPP is outdated, please get a more recent one."; } &&
{ enabled libdrm ||
  die "ERROR: rkmpp requires --enable-libdrm"; }
diff --git a/libavcodec/rkmppdec.c b/libavcodec/rkmppdec.c
index c57a6ded38..946b827918 100644
--- a/libavcodec/rkmppdec.c
+++ b/libavcodec/rkmppdec.c
@@ -40,6 +40,7 @@
 
 #define RECEIVE_FRAME_TIMEOUT   100
 #define FRAMEGROUP_MAX_FRAMES   16
+#define INPUT_MAX_PACKETS   4
 
 typedef struct {
 MppCtx ctx;
@@ -515,16 +516,17 @@ static int rkmpp_receive_frame(AVCodecContext *avctx, AVFrame *frame)
 RKMPPDecoder *decoder = (RKMPPDecoder *)rk_context->decoder_ref->data;
 int ret = MPP_NOK;
 AVPacket pkt = {0};
-RK_S32 freeslots;
+RK_S32 usedslots, freeslots;
 
 if (!decoder->eos_reached) {
 // we get the available slots in decoder
-ret = decoder->mpi->control(decoder->ctx, MPP_DEC_GET_FREE_PACKET_SLOT_COUNT, );
+ret = decoder->mpi->control(decoder->ctx, MPP_DEC_GET_STREAM_COUNT, );
 if (ret != MPP_OK) {
-av_log(avctx, AV_LOG_ERROR, "Failed to get decoder free slots (code = %d).\n", ret);
+av_log(avctx, AV_LOG_ERROR, "Failed to get decoder used slots (code = %d).\n", ret);
 return ret;
 }
 
+freeslots = INPUT_MAX_PACKETS - usedslots;
 if (freeslots > 0) {
 ret = ff_decode_get_packet(avctx, );
 if (ret < 0 && ret != AVERROR_EOF) {
@@ -541,7 +543,7 @@ static int rkmpp_receive_frame(AVCodecContext *avctx, AVFrame *frame)
 }
 
 // make sure we keep decoder full
-if (freeslots > 1 && decoder->first_frame)
+if (freeslots > 1)
 return AVERROR(EAGAIN);
 }
 
-- 
2.14.1

From 46523ce0fca740a69619e59398d329623800e501 Mon Sep 17 00:00:00 2001
From: LongChair 
Date: Tue, 2 Jan 2018 12:38:01 +0100
Subject: [PATCH] avcodec/rkmpp : remove stream start retries before first
 frame.

those were needed because of some odd mpp behavior that seems to have been fixed.
Makes the code cleaner.
---
 libavcodec/rkmppdec.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/libavcodec/rkmppdec.c b/libavcodec/rkmppdec.c
index 946b827918..143d05bd51 100644
--- a/libavcodec/rkmppdec.c
+++ b/libavcodec/rkmppdec.c
@@ -47,7 +47,6 @@ typedef struct {
 MppApi *mpi;
 MppBufferGroup frame_group;
 
-char first_frame;
 char first_packet;
 char eos_reached;
 
@@ -329,28 +328,14 @@ static int rkmpp_retrieve_frame(AVCodecContext *avctx, AVFrame *frame)
 MppBuffer buffer = NULL;
 AVDRMFrameDescriptor *desc = NULL;
 AVDRMLayerDescriptor *layer = NULL;
-int retrycount = 0;
 int mode;
 MppFrameFormat mppformat;
 uint32_t drmformat;
 
-// on start of decoding, MPP can return -1, which is supposed to be expected
-// this is due to some internal MPP init which is not completed, that will
-// only happen in the first few frames queries, but should not be 

Re: [FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

[Jacob Trimble]

On Tue, Jan 2, 2018 at 9:57 AM, Jacob Trimble  wrote:
> On Wed, Dec 20, 2017 at 4:31 PM, wm4  wrote:
>> On Wed, 20 Dec 2017 15:10:43 -0800
>> Jacob Trimble  wrote:
>>
>>> From 1508d19e9f7acf43d76010ce54d59ff204613601 Mon Sep 17 00:00:00 2001
>>> From: Jacob Trimble 
>>> Date: Tue, 5 Dec 2017 14:52:22 -0800
>>> Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.
>>>
>>> This new side-data will contain info on how a packet is encrypted.
>>> This allows the app to handle packet decryption.
>>>
>>> Signed-off-by: Jacob Trimble 
>>> ---
>>
>> Looks generally good to me, a few minor cosmetic comments below.
>>
>>>  libavcodec/Makefile  |   2 +
>>>  libavcodec/avcodec.h |  13 
>>>  libavcodec/encryption_info.c | 139 
>>> +++
>>>  libavcodec/encryption_info.h | 121 +
>>>  4 files changed, 275 insertions(+)
>>>  create mode 100644 libavcodec/encryption_info.c
>>>  create mode 100644 libavcodec/encryption_info.h
>>>
>>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>>> index ab7893f560..11ad642c6c 100644
>>> --- a/libavcodec/Makefile
>>> +++ b/libavcodec/Makefile
>>> @@ -10,6 +10,7 @@ HEADERS = ac3_parser.h
>>>   \
>>>dirac.h   \
>>>dv_profile.h  \
>>>dxva2.h   \
>>> +  encryption_info.h \
>>>jni.h \
>>>mediacodec.h  \
>>>qsv.h \
>>> @@ -36,6 +37,7 @@ OBJS = ac3_parser.o   
>>>   \
>>> dirac.o  \
>>> dv_profile.o \
>>> encode.o \
>>> +   encryption_info.o\
>>> imgconvert.o \
>>> jni.o\
>>> mathtables.o \
>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>> index 5db6a81320..b43638ebc5 100644
>>> --- a/libavcodec/avcodec.h
>>> +++ b/libavcodec/avcodec.h
>>> @@ -1327,6 +1327,19 @@ enum AVPacketSideDataType {
>>>   */
>>>  AV_PKT_DATA_A53_CC,
>>>
>>> +/**
>>> + * This side data is encryption "initialization data".
>>> + * For MP4 this is the entire 'pssh' box.
>>> + * For WebM this is the key ID.
>>> + */
>>> +AV_PKT_DATA_ENCRYPTION_INIT_DATA,
>>> +
>>> +/**
>>> + * This side data contains encryption info for how to decrypt the 
>>> packet.
>>> + * The format is not part of ABI, use av_encryption_info_* methods to 
>>> access.
>>> + */
>>> +AV_PKT_DATA_ENCRYPTION_INFO,
>>> +
>>>  /**
>>>   * The number of side data types.
>>>   * This is not part of the public API/ABI in the sense that it may
>>> diff --git a/libavcodec/encryption_info.c b/libavcodec/encryption_info.c
>>> new file mode 100644
>>> index 00..59ee4c41a9
>>> --- /dev/null
>>> +++ b/libavcodec/encryption_info.c
>>> @@ -0,0 +1,139 @@
>>> +/**
>>> + * 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 "encryption_info.h"
>>> +#include "libavutil/avassert.h"
>>> +#include "libavutil/intreadwrite.h"
>>> +
>>> +#define FF_ENCRYPTION_INFO_EXTRA 24
>>> +
>>> +// The format of the side data:
>>> +// u32be scheme
>>> +// u32be crypt_byte_block
>>> +// u32be skip_byte_block
>>> +// u32be key_id_size
>>> +// u32be iv_size
>>> +// u32be subsample_count
>>> +// u8[key_id_size] key_id
>>> +// u8[iv_size] iv
>>> +// {

Re: [FFmpeg-devel] Chinese DTMB streams playback issue

[Compn]

On Thu, 4 Jan 2018 20:42:33 -0500, Abylay Ospan 
wrote:

> Hello All,
> 
> I have made dump of DTMB streams (digital TV standard in China, like
> DVB-T in Europe, etc).

thanks for samples.

> Should I create ticket in https://trac.ffmpeg.org ?

yes, please create tickets. one ticket per file.

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

Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter: use a mutex instead of atomics in avfilter_register()

[James Almer]

On 1/5/2018 1:04 PM, wm4 wrote:
> On Thu,  4 Jan 2018 22:42:52 -0300
> James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/avfilter.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
>> index b98b32bacb..ff7df672fd 100644
>> --- a/libavfilter/avfilter.c
>> +++ b/libavfilter/avfilter.c
>> @@ -19,7 +19,6 @@
>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>>   */
>>  
>> -#include "libavutil/atomic.h"
>>  #include "libavutil/avassert.h"
>>  #include "libavutil/avstring.h"
>>  #include "libavutil/buffer.h"
>> @@ -33,6 +32,7 @@
>>  #include "libavutil/pixdesc.h"
>>  #include "libavutil/rational.h"
>>  #include "libavutil/samplefmt.h"
>> +#include "libavutil/thread.h"
>>  
>>  #define FF_INTERNAL_FIELDS 1
>>  #include "framequeue.h"
>> @@ -590,19 +590,26 @@ const AVFilter *avfilter_get_by_name(const char *name)
>>  return NULL;
>>  }
>>  
>> +static AVMutex filter_register_mutex = AV_MUTEX_INITIALIZER;
>> +
>>  int avfilter_register(AVFilter *filter)
>>  {
>> -AVFilter **f = last_filter;
>> +AVFilter **f;
>>  
>>  /* the filter must select generic or internal exclusively */
>>  av_assert0((filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE) != 
>> AVFILTER_FLAG_SUPPORT_TIMELINE);
>>  
>> -filter->next = NULL;
>> +ff_mutex_lock(_register_mutex);
>> +f = last_filter;
>>  
>> -while(*f || avpriv_atomic_ptr_cas((void * volatile *)f, NULL, filter))
>> +while (*f)
>>  f = &(*f)->next;
>> +*f = filter;
>> +filter->next = NULL;
>>  last_filter = >next;
>>  
>> +ff_mutex_unlock(_register_mutex);
>> +
>>  return 0;
>>  }
>>  
> 
> Also seems good.

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avformat: use mutexes instead of atomics in av_register_{input, output}_format()

[James Almer]

On 1/5/2018 1:03 PM, wm4 wrote:
> On Thu,  4 Jan 2018 22:41:38 -0300
> James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/format.c | 34 +++---
>>  1 file changed, 23 insertions(+), 11 deletions(-)
>>
>> diff --git a/libavformat/format.c b/libavformat/format.c
>> index 38ca2a3465..759b5b1ab4 100644
>> --- a/libavformat/format.c
>> +++ b/libavformat/format.c
>> @@ -19,10 +19,10 @@
>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>>   */
>>  
>> -#include "libavutil/atomic.h"
>>  #include "libavutil/avstring.h"
>>  #include "libavutil/bprint.h"
>>  #include "libavutil/opt.h"
>> +#include "libavutil/thread.h"
>>  
>>  #include "avio_internal.h"
>>  #include "avformat.h"
>> @@ -58,28 +58,40 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
>>  return first_oformat;
>>  }
>>  
>> +static AVMutex iformat_register_mutex = AV_MUTEX_INITIALIZER;
>> +
>>  void av_register_input_format(AVInputFormat *format)
>>  {
>> -AVInputFormat **p = last_iformat;
>> +AVInputFormat **p;
>> +
>> +ff_mutex_lock(_register_mutex);
>> +p = last_iformat;
>>  
>> -// Note, format could be added after the first 2 checks but that 
>> implies that *p is no longer NULL
>> -while(p != >next && !format->next && 
>> avpriv_atomic_ptr_cas((void * volatile *)p, NULL, format))
>> +while (*p)
>>  p = &(*p)->next;
>> +*p = format;
>> +format->next = NULL;
>> +last_iformat = >next;
>>  
>> -if (!format->next)
>> -last_iformat = >next;
>> +ff_mutex_unlock(_register_mutex);
>>  }
>>  
>> +static AVMutex oformat_register_mutex = AV_MUTEX_INITIALIZER;
>> +
>>  void av_register_output_format(AVOutputFormat *format)
>>  {
>> -AVOutputFormat **p = last_oformat;
>> +AVOutputFormat **p;
>> +
>> +ff_mutex_lock(_register_mutex);
>> +p = last_oformat;
>>  
>> -// Note, format could be added after the first 2 checks but that 
>> implies that *p is no longer NULL
>> -while(p != >next && !format->next && 
>> avpriv_atomic_ptr_cas((void * volatile *)p, NULL, format))
>> +while (*p)
>>  p = &(*p)->next;
>> +*p = format;
>> +format->next = NULL;
>> +last_oformat = >next;
>>  
>> -if (!format->next)
>> -last_oformat = >next;
>> +ff_mutex_unlock(_register_mutex);
>>  }
>>  
>>  int av_match_ext(const char *filename, const char *extensions)
> 
> Can't see anything wrong with it.

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

Re: [FFmpeg-devel] [PATCH 1/3 v2] avcodec/util: use a mutex instead of atomics in avcodec_register()

[James Almer]

On 1/5/2018 1:02 PM, wm4 wrote:
> On Thu,  4 Jan 2018 22:40:44 -0300
> James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/utils.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index dfbfe98d63..4d736d2e7d 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -26,7 +26,6 @@
>>   */
>>  
>>  #include "config.h"
>> -#include "libavutil/atomic.h"
>>  #include "libavutil/attributes.h"
>>  #include "libavutil/avassert.h"
>>  #include "libavutil/avstring.h"
>> @@ -127,17 +126,24 @@ int av_codec_is_decoder(const AVCodec *codec)
>>  return codec && (codec->decode || codec->receive_frame);
>>  }
>>  
>> +static AVMutex codec_register_mutex = AV_MUTEX_INITIALIZER;
>> +
>>  av_cold void avcodec_register(AVCodec *codec)
>>  {
>>  AVCodec **p;
>>  avcodec_init();
>> +
>> +ff_mutex_lock(_register_mutex);
>>  p = last_avcodec;
>> -codec->next = NULL;
>>  
>> -while(*p || avpriv_atomic_ptr_cas((void * volatile *)p, NULL, codec))
>> +while (*p)
>>  p = &(*p)->next;
>> +*p  = codec;
>> +codec->next = NULL;
>>  last_avcodec = >next;
>>  
>> +ff_mutex_unlock(_register_mutex);
>> +
>>  if (codec->init_static_data)
>>  codec->init_static_data(codec);
>>  }
> 
> Seems good, but should init_static_data really be outside of the lock?
> (Sure, it wasn't under a look before either, but still.)

I don't think calling avcodec_register() twice with the same AVCodec is
defined or supported at all, so outside of creating the linked list i
don't see any other potential race here. But i may be wrong.

In any case, that's something for a separate patch as it's a change in
behavior (and may make things slower), so pushed as is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3 v2] avfilter: use a mutex instead of atomics in avfilter_register()

[wm4]

On Thu,  4 Jan 2018 22:42:52 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavfilter/avfilter.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index b98b32bacb..ff7df672fd 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -19,7 +19,6 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> -#include "libavutil/atomic.h"
>  #include "libavutil/avassert.h"
>  #include "libavutil/avstring.h"
>  #include "libavutil/buffer.h"
> @@ -33,6 +32,7 @@
>  #include "libavutil/pixdesc.h"
>  #include "libavutil/rational.h"
>  #include "libavutil/samplefmt.h"
> +#include "libavutil/thread.h"
>  
>  #define FF_INTERNAL_FIELDS 1
>  #include "framequeue.h"
> @@ -590,19 +590,26 @@ const AVFilter *avfilter_get_by_name(const char *name)
>  return NULL;
>  }
>  
> +static AVMutex filter_register_mutex = AV_MUTEX_INITIALIZER;
> +
>  int avfilter_register(AVFilter *filter)
>  {
> -AVFilter **f = last_filter;
> +AVFilter **f;
>  
>  /* the filter must select generic or internal exclusively */
>  av_assert0((filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE) != 
> AVFILTER_FLAG_SUPPORT_TIMELINE);
>  
> -filter->next = NULL;
> +ff_mutex_lock(_register_mutex);
> +f = last_filter;
>  
> -while(*f || avpriv_atomic_ptr_cas((void * volatile *)f, NULL, filter))
> +while (*f)
>  f = &(*f)->next;
> +*f = filter;
> +filter->next = NULL;
>  last_filter = >next;
>  
> +ff_mutex_unlock(_register_mutex);
> +
>  return 0;
>  }
>  

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avformat: use mutexes instead of atomics in av_register_{input, output}_format()

[wm4]

On Thu,  4 Jan 2018 22:41:38 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavformat/format.c | 34 +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/libavformat/format.c b/libavformat/format.c
> index 38ca2a3465..759b5b1ab4 100644
> --- a/libavformat/format.c
> +++ b/libavformat/format.c
> @@ -19,10 +19,10 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> -#include "libavutil/atomic.h"
>  #include "libavutil/avstring.h"
>  #include "libavutil/bprint.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/thread.h"
>  
>  #include "avio_internal.h"
>  #include "avformat.h"
> @@ -58,28 +58,40 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
>  return first_oformat;
>  }
>  
> +static AVMutex iformat_register_mutex = AV_MUTEX_INITIALIZER;
> +
>  void av_register_input_format(AVInputFormat *format)
>  {
> -AVInputFormat **p = last_iformat;
> +AVInputFormat **p;
> +
> +ff_mutex_lock(_register_mutex);
> +p = last_iformat;
>  
> -// Note, format could be added after the first 2 checks but that implies 
> that *p is no longer NULL
> -while(p != >next && !format->next && avpriv_atomic_ptr_cas((void 
> * volatile *)p, NULL, format))
> +while (*p)
>  p = &(*p)->next;
> +*p = format;
> +format->next = NULL;
> +last_iformat = >next;
>  
> -if (!format->next)
> -last_iformat = >next;
> +ff_mutex_unlock(_register_mutex);
>  }
>  
> +static AVMutex oformat_register_mutex = AV_MUTEX_INITIALIZER;
> +
>  void av_register_output_format(AVOutputFormat *format)
>  {
> -AVOutputFormat **p = last_oformat;
> +AVOutputFormat **p;
> +
> +ff_mutex_lock(_register_mutex);
> +p = last_oformat;
>  
> -// Note, format could be added after the first 2 checks but that implies 
> that *p is no longer NULL
> -while(p != >next && !format->next && avpriv_atomic_ptr_cas((void 
> * volatile *)p, NULL, format))
> +while (*p)
>  p = &(*p)->next;
> +*p = format;
> +format->next = NULL;
> +last_oformat = >next;
>  
> -if (!format->next)
> -last_oformat = >next;
> +ff_mutex_unlock(_register_mutex);
>  }
>  
>  int av_match_ext(const char *filename, const char *extensions)

Can't see anything wrong with it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3 v2] avcodec/util: use a mutex instead of atomics in avcodec_register()

[wm4]

On Thu,  4 Jan 2018 22:40:44 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/utils.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index dfbfe98d63..4d736d2e7d 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -26,7 +26,6 @@
>   */
>  
>  #include "config.h"
> -#include "libavutil/atomic.h"
>  #include "libavutil/attributes.h"
>  #include "libavutil/avassert.h"
>  #include "libavutil/avstring.h"
> @@ -127,17 +126,24 @@ int av_codec_is_decoder(const AVCodec *codec)
>  return codec && (codec->decode || codec->receive_frame);
>  }
>  
> +static AVMutex codec_register_mutex = AV_MUTEX_INITIALIZER;
> +
>  av_cold void avcodec_register(AVCodec *codec)
>  {
>  AVCodec **p;
>  avcodec_init();
> +
> +ff_mutex_lock(_register_mutex);
>  p = last_avcodec;
> -codec->next = NULL;
>  
> -while(*p || avpriv_atomic_ptr_cas((void * volatile *)p, NULL, codec))
> +while (*p)
>  p = &(*p)->next;
> +*p  = codec;
> +codec->next = NULL;
>  last_avcodec = >next;
>  
> +ff_mutex_unlock(_register_mutex);
> +
>  if (codec->init_static_data)
>  codec->init_static_data(codec);
>  }

Seems good, but should init_static_data really be outside of the lock?
(Sure, it wasn't under a look before either, but still.)

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

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Tobias Rapp]

On 05.01.2018 11:18, Jerome Martinez wrote:

0001-FFV1-make-RGB48-support-as-non-experimental.patch

From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] FFV1: make RGB48 support as non-experimental


make => mark

BTW: common subject line format would be something like 
"avcodec/ffv1enc: mark RGB48 support as non-experimental"



Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 deletions(-)


Otherwise LGTM.

Regards,
Tobias

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

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

[James Almer]

On 12/22/2017 11:35 AM, mi...@brew.sh wrote:
> 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;
>  }

This needs to be squashed into the previous patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[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 afde768199..ca848cacbb 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -561,8 +561,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 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..d1378c8ac7
--- /dev/null
+++ b/tests/fate/psmf.mak
@@ -0,0 +1,23 @@
+#
+# Test detecting ATRAC-3 audio in Sony MPEG files
+#
+
+PSMF_PROBE_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 $(PSMF_PROBE_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 $(PSMF_PROBE_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 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 47a15d52b8..ec536bf7b6 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR   9
-#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 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

atrac3plus_parser: adjust bytes_remain type

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 cfacd6b70c..e3f7afbfe7 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..5aebdd5fbc
--- /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;
+uint16_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 

[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 | 50 +++---
 libavformat/mpeg.h |  1 +
 3 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/Changelog b/Changelog
index 3d966c202b..d4761ec7f9 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - deconvolve video filter
 - entropy video filter
 - hilbert audio filter source
+- ATRAC-3 support for Sony PSP MPEG files
 
 
 version 3.4:
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 895c6fb231..afde768199 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -148,8 +148,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 +442,7 @@ redo:
 goto redo;
 }
 
-if (startcode == PRIVATE_STREAM_1 && !m->sony_psmf) {
+if (startcode == PRIVATE_STREAM_1) {
 startcode = avio_r8(s->pb);
 len--;
 }
@@ -507,6 +505,19 @@ redo:
 goto found;
 }
 
+/* These bytes in the PES header can be used to identify
+ * the first ATRAC packets in a Sony ATRAC video */
+if (!m->sony_psmf) {
+avio_seek(s->pb, -4, SEEK_CUR);
+unsigned char atrac_buf[3];
+avio_read(s->pb, atrac_buf, 3);
+avio_skip(s->pb, 1);
+
+m->sony_psmf = memcmp(atrac_buf, "\x1E\x60\x08", 3) == 0 ||
+   memcmp(atrac_buf, "\x1E\x60\x04", 3) == 0 ||
+   memcmp(atrac_buf, "\x1E\x60\x14", 3) == 0;
+}
+
 es_type = m->psm_es_type[startcode & 0xff];
 if (es_type == STREAM_TYPE_VIDEO_MPEG1) {
 codec_id = AV_CODEC_ID_MPEG2VIDEO;
@@ -544,28 +555,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 < 0x20 && m->sony_psmf) {
 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 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

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

[misty]

From: Misty De Meo 

> this looks a bit odd
> shouldnt this test more than 4 bits of startcode ?

Yeah, that was a misreading on my part of the original patch. I need
a different approach.

I think I've found something that should work, though. I was talking to
Jan about this in IRC, and vgmtoolbox came up. It detects ATRAC audio
in MPEG files by checking for magic bytes in the PES private data:
https://sourceforge.net/p/vgmtoolbox/code/HEAD/tree/format/VGMToolbox/format/SonyPmfStream.cs#l19
I've updated the patch to set the sony_psmf flag if those bytes are
detected, and interpret all streams under 0x20 as ATRAC when that flag
is set. That's worked for all of the samples we have, both PSM and MPS,
and also works for a newer PS3 sample that Jan had. The fate MPEG tests
still pass, so I'm hopeful this doesn't introduce any false positives.

I've included an updated version of the full patchset.

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|  29 ++
 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, 268 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

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

[Misty De Meo]

> so this is unfinished code that work in progress ?
> if so, what is missing ?
> if not, then please write a better commit message

Sorry about that - that was the placeholder title of a commit I
squashed into the mpeg commit, and forgot to remove when rebasing.
I'll remove it from the commit message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Jerome Martinez]

1 year without RGB48 related patches, tested by a couple of users, 
tested with a FFV1 conformance checker, I suggest that FFV1 RGB48 
support in FFmpeg does not mandate anymore the user to add " -strict 
experimental" on the command line during encoding.


From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] FFV1: make RGB48 support as non-experimental

Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 09df4c0c57..c0c1558ffe 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -630,10 +630,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->bits_per_raw_sample = 16;
 s->use32bit = 1;
 s->version = FFMAX(s->version, 1);
-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
-av_log(avctx, AV_LOG_ERROR, "16bit RGB is experimental and under 
development, only use it for experiments\n");
-return AVERROR_INVALIDDATA;
-}
 break;
 case AV_PIX_FMT_0RGB32:
 s->colorspace = 1;
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 2/2] aiff: add explicit goto got_sound

[misty]

From: Misty De Meo 

---
 Changelog | 1 +
 libavformat/aiffdec.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Changelog b/Changelog
index 3d966c202b..63007a259d 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - deconvolve video filter
 - entropy video filter
 - hilbert audio filter source
+- aiff: add support for CD-ROM XA ADPCM
 
 
 version 3.4:
diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index a6c180fc8d..e87fbc5661 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -332,6 +332,9 @@ static int aiff_read_header(AVFormatContext *s)
 /* This field is unknown and its data seems to be irrelevant */
 avio_rb32(pb);
 st->codecpar->block_align = avio_rb32(pb);
+
+goto got_sound;
+break;
 case 0:
 if (offset > 0 && st->codecpar->block_align) // COMM && SSND
 goto got_sound;
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 0/2] adpcm: consume remainder after consuming XA chunks

[misty]

From: Misty De Meo 

> the initialization to 0 is unneeded

OK - updated in the included patch.

I've also included a second patch which adds an explicit goto and break
in aiffdec, on top of the patch you already applied, and the Changelog
entry that I forgot to include in that patch.

I realize it's a niche format, but how do you feel about including the
fate test for this? It's in this mail:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223413.html

Misty De Meo (2):
  adpcm: consume remainder after consuming XA chunks
  aiff: add explicit goto got_sound

 Changelog | 1 +
 libavcodec/adpcm.c| 7 +++
 libavformat/aiffdec.c | 3 +++
 3 files changed, 11 insertions(+)

-- 
2.15.1

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

[FFmpeg-devel] [PATCH 1/2] adpcm: consume remainder after consuming XA chunks

[misty]

From: Misty De Meo 

---
 libavcodec/adpcm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index be206c55ba..cd3bbd33c2 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1115,6 +1115,7 @@ static int adpcm_decode_frame(AVCodecContext *avctx, void 
*data,
 int16_t *out1 = samples_p[1];
 int samples_per_block = 28 * (3 - avctx->channels) * 4;
 int sample_offset = 0;
+int bytes_remaining;
 while (bytestream2_get_bytes_left() >= 128) {
 if ((ret = xa_decode(avctx, out0, out1, buf + 
bytestream2_tell(),
  >status[0], >status[1],
@@ -1123,6 +1124,12 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 bytestream2_skipu(, 128);
 sample_offset += samples_per_block;
 }
+/* Less than a full block of data left, e.g. when reading from
+ * 2324 byte per sector XA; the remainder is padding */
+bytes_remaining = bytestream2_get_bytes_left();
+if (bytes_remaining > 0) {
+bytestream2_skip(, bytes_remaining);
+}
 break;
 }
 case AV_CODEC_ID_ADPCM_IMA_EA_EACS:
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: add check bitstream method

[Hendrik Leppkes]

On Fri, Jan 5, 2018 at 9:13 AM, Steven Liu  wrote:
> rename mpegts_check_bitstream to ff_check_bitstream
> fix problem: remux from mp4(AVC Codec) to avi(AVC Codec)
> error message:
> [avi @ 0x7fac97003c00] H.264 bitstream malformed, no startcode found,
> use the video bitstream filter 'h264_mp4toannexb' to fix
> it ('-bsf:v h264_mp4toannexb' option with ffmpeg)
>

There are several issues with this patch -

The function naming and description is way too generic, it doesn't
indicate at all what it does - but lets skip that for now, since I
believe there are much bigger issues.
Secondly, avi and mpegts are very different formats, and probably
should not share such a function.

mpegts always needs AnnexB format, avi can actually "support" (and I
use that word losely, H264 in AVI is always a hack) both MP4-style and
AnnexB, which means AVI doesn't really need the BSF at all.
In AVI, you need to properly write a matching codec_tag however, H264
for AnnexB, and AVC1 for MP4-style  - if that is not being done, then
this should be fixed, and not a BSF being forced.

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

[FFmpeg-devel] [PATCH] avformat/avienc: add check bitstream method

[Steven Liu]

rename mpegts_check_bitstream to ff_check_bitstream
fix problem: remux from mp4(AVC Codec) to avi(AVC Codec)
error message:
[avi @ 0x7fac97003c00] H.264 bitstream malformed, no startcode found,
use the video bitstream filter 'h264_mp4toannexb' to fix
it ('-bsf:v h264_mp4toannexb' option with ffmpeg)

Signed-off-by: Steven Liu 
---
 libavformat/avienc.c| 1 +
 libavformat/mpegts.h| 5 +
 libavformat/mpegtsenc.c | 4 ++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ac0f04c354..a8782ef292 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -1002,6 +1002,7 @@ AVOutputFormat ff_avi_muxer = {
 .write_header   = avi_write_header,
 .write_packet   = avi_write_packet,
 .write_trailer  = avi_write_trailer,
+.check_bitstream = ff_check_bitstream,
 .codec_tag  = (const AVCodecTag * const []) {
 ff_codec_bmp_tags, ff_codec_wav_tags, 0
 },
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index 272e2be4f7..96610ee0a6 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -114,4 +114,9 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream 
*st, int stream_type
  */
 int ff_check_h264_startcode(AVFormatContext *s, const AVStream *st, const 
AVPacket *pkt);
 
+/**
+ * Check bitstream of stream
+ * @return <0 to stop processing
+ */
+int ff_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt);
 #endif /* AVFORMAT_MPEGTS_H */
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fdfa544ee2..866615f620 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1846,7 +1846,7 @@ static void mpegts_deinit(AVFormatContext *s)
 av_freep(>services);
 }
 
-static int mpegts_check_bitstream(struct AVFormatContext *s, const AVPacket 
*pkt)
+int ff_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
 {
 int ret = 1;
 AVStream *st = s->streams[pkt->stream_index];
@@ -1982,7 +1982,7 @@ AVOutputFormat ff_mpegts_muxer = {
 .write_packet   = mpegts_write_packet,
 .write_trailer  = mpegts_write_end,
 .deinit = mpegts_deinit,
-.check_bitstream = mpegts_check_bitstream,
+.check_bitstream = ff_check_bitstream,
 .flags  = AVFMT_ALLOW_FLUSH | AVFMT_VARIABLE_FPS,
 .priv_class = _muxer_class,
 };
-- 
2.14.3 (Apple Git-98)



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