[FFmpeg-devel] FLIF Encoder & Decoder Project for GSOC 2020

[Kartik Khullar]

I am 2nd year Computer Engineering Student at TIET, Patiala. I am
interested in FLIF Encoder and Decoder Project. I am informing so as to
prevent clash between other potential applicants. I will be working on its
Qualification Task. I have previously studied theory and mathematics behind
JPEG Compression using DCT, also I am good at C/C++ and have worked using
git before. Also any help from mentor's side will be helpful for me.
Thank You.
Kartik K. Khullar
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FLIF Encoder & Decoder Project for GSOC 2020

[Jai Luthra]

On Sun, Feb 23, 2020 at 02:54:42PM +0530, Kartik Khullar wrote:

I am 2nd year Computer Engineering Student at TIET, Patiala. I am
interested in FLIF Encoder and Decoder Project. I am informing so as to
prevent clash between other potential applicants. I will be working on its
Qualification Task.


Hey Kartik, thanks for letting us know!

I have previously studied theory and mathematics behind JPEG Compression 
using DCT, also I am good at C/C++ and have worked using git before. Also any 
help from mentor's side will be helpful for me.


DSP knowledge is a great plus. FLIF does not use DCT but uses other lossless 
transformation passes as given in the spec [1].


Pick a couple of the passes and/or other components of FLIF like parsing the 
bitstream for packets/headers or the MANIAC entropy coder. Understand them 
through the spec and the reference codec, and write a module under lavc. 
Decoding part is usually easier to start with, but it is up to you.


Let us know whatever component(s) you pick, and if you have any doubts ask 
away here or on the #ffmpeg-devel IRC.



Thank You.
Kartik K. Khullar


[1]: https://flif.info/spec.html

--
Jai (darkapex)


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Nicolas George]

Gyan Doshi (12020-02-23):
> > It saves some steps in shell scripts,  avoiding having to correlate
> > stream index with id.
> Any more comments?

I find this somewhat feeble. How does it justify including the stream id
(something that few formats support) more than any other field of the
stream? If this was a relational database, you would be about to commit
heresy.

Also, I think you forgot to update the docs, including the XML schema
and such things.

But on the whole, I am rather unconvinced.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Gyan Doshi]

On 23-02-2020 03:53 pm, Nicolas George wrote:

Gyan Doshi (12020-02-23):

It saves some steps in shell scripts,  avoiding having to correlate
stream index with id.

Any more comments?

I find this somewhat feeble. How does it justify including the stream id
(something that few formats support) more than any other field of the
stream? If this was a relational database, you would be about to commit
heresy.


stream_index isn't fixed in fftools for a given live MPEG-TS input 
across instances so can't be reliably used to id streams. This field 
can.  Same can't be said for other fields.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Nicolas George]

Gyan Doshi (12020-02-23):
> stream_index isn't fixed in fftools for a given live MPEG-TS input across
> instances so can't be reliably used to id streams. This field can.  Same
> can't be said for other fields.

Yes, but “identifying across instances” is a specific need. Why is it
more important than “knowing the codec”?

You need to make a strong case for this field being special.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Gyan Doshi]

On 23-02-2020 04:22 pm, Nicolas George wrote:

Gyan Doshi (12020-02-23):

stream_index isn't fixed in fftools for a given live MPEG-TS input across
instances so can't be reliably used to id streams. This field can.  Same
can't be said for other fields.

Yes, but “identifying across instances” is a specific need. Why is it
more important than “knowing the codec”?

You need to make a strong case for this field being special.


If one needs to map a specific stream from a multi program TS input in 
another instance, based on packet/frames analysis,  then this helps with 
making a quick and direct id.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Nicolas George]

Gyan Doshi (12020-02-23):
> If one needs to map a specific stream from a multi program TS input in
> another instance, based on packet/frames analysis,  then this helps with
> making a quick and direct id.

And if one needs to map a specific stream from a Matroska to its
codec, something else is needed. But all the information is already in
the streams section, it only needs to be used properly.

If there is no stronger case for it, I think we should skip this
feature.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Michael Niedermayer]

From: Parker Ernest <@>

commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II

Signed-off-by: Michael Niedermayer 
---
 libswscale/x86/yuv2rgb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index c12e88cbb5..4791e5b93a 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -83,6 +83,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
 #if HAVE_X86ASM
 int cpu_flags = av_get_cpu_flags();
 
+#if HAVE_SSSE3
 if (EXTERNAL_SSSE3(cpu_flags)) {
 switch (c->dstFormat) {
 case AV_PIX_FMT_RGB32:
@@ -111,6 +112,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
 return yuv420_rgb15_ssse3;
 }
 }
+#endif
 
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 switch (c->dstFormat) {
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[James Darnley]

On 2020-02-23 13:22, Michael Niedermayer wrote:
> From: Parker Ernest <@>
> 
> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/x86/yuv2rgb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
> index c12e88cbb5..4791e5b93a 100644
> --- a/libswscale/x86/yuv2rgb.c
> +++ b/libswscale/x86/yuv2rgb.c
> @@ -83,6 +83,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>  #if HAVE_X86ASM
>  int cpu_flags = av_get_cpu_flags();
>  
> +#if HAVE_SSSE3
>  if (EXTERNAL_SSSE3(cpu_flags)) {
>  switch (c->dstFormat) {
>  case AV_PIX_FMT_RGB32:
> @@ -111,6 +112,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>  return yuv420_rgb15_ssse3;
>  }
>  }
> +#endif
>  
>  if (EXTERNAL_MMXEXT(cpu_flags)) {
>  switch (c->dstFormat) {
> 

What?  Why doesn't the the EXTERNAL_SSSE3 macro stop the code from
entering that branch?  The #if would only stop the section from being
compiled with --disable-ssse3.  A normal build would still enter that
branch on that CPU.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Paul B Mahol]

lgtm

On 2/23/20, Michael Niedermayer  wrote:
> From: Parker Ernest <@>
>
> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/x86/yuv2rgb.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
> index c12e88cbb5..4791e5b93a 100644
> --- a/libswscale/x86/yuv2rgb.c
> +++ b/libswscale/x86/yuv2rgb.c
> @@ -83,6 +83,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>  #if HAVE_X86ASM
>  int cpu_flags = av_get_cpu_flags();
>
> +#if HAVE_SSSE3
>  if (EXTERNAL_SSSE3(cpu_flags)) {
>  switch (c->dstFormat) {
>  case AV_PIX_FMT_RGB32:
> @@ -111,6 +112,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>  return yuv420_rgb15_ssse3;
>  }
>  }
> +#endif
>
>  if (EXTERNAL_MMXEXT(cpu_flags)) {
>  switch (c->dstFormat) {
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Jan Ekström]

On Sun, Feb 23, 2020 at 8:15 AM Gyan Doshi  wrote:
>
>
>
> On 20-02-2020 10:05 am, Gyan Doshi wrote:
> >
> >
> > On 20-02-2020 04:52 am, Jan Ekström wrote:
> >> Hi,
> >>
> >> On Wed, Feb 19, 2020 at 8:31 AM Gyan Doshi  wrote:
> >>> Required for reliably identifying streams in MPEGTS-like live inputs.
> >>> ---
> >> Can you please explain to me how would this be any different from
> >> adding `-show_programs -show_streams` and checking out the listing of
> >> those first?
> >
> > It saves some steps in shell scripts,  avoiding having to correlate
> > stream index with id.
>
> Any more comments?
>
> Gyan

Thanks for being honest. I had some tired days and couldn't respond
right away, unfortunately.

Now, the problem is that ffprobe in general is a thing that at least
on a general look dumps the structures as they come from the API. You
have AVStreams under streams, AVPrograms under programs, AVPackets
under packets, AVFrames (and AVSubtitles) under frames and so forth.
This basically breaks that general rule/abstraction, since AVPackets
do not have stream_ids there (right now).

And in this case, such a filtering would only work if you already know
the exact PID(s) you are interested in. As in, "I do not need to look
at the stream or program->stream listing at all for extra
information". That in a more general case tends to usually not be the
case. Only problem that I can recall for simpler scripts is that the
streams and programs tend to get dumped after the rest of the things,
not before it, If I recall correctly (this makes sense as the state of
those could change between the start of parsing and the end of
parsing). If this is the case, and you want to parse things in a live
"stream of data" (as in, not finishing up a full "document" as one
does with XML or JSON output), then that could be done with a separate
option. But of course limited to the state of programs and streams at
the start of processing. Alternatively then that data could be updated
during parsing if the format enables duplicate entries.

Thus I think there are multiple ways forward with this:
1. Find a reasoning to also add the stream_id to be included in
AVPacket (generally speaking possibly unlikely, since in the API you
can just reference the relevant AVStream). That way it would become a
part of AVPacket and thus the dump would be to OK to have that
included.
2. I am still not 100% sure what your shell scripts would be doing,
but possibly implementing stream id based stream selection in ffprobe
as an application could be useful if you are attempting to filter out
all other streams than PIDs X,Y,Z (since I think ffmpeg.c already has
this implemented)? You will still have to parse the programs->streams
or streams to figure out which is which if you want to select multiple
at a time, but at least in case of singular PIDs this should simplify
your life?
3. If ffprobe currently outputs the streams and programs at the end
and that is a problem with the streaming data that you feed into your
shell script, make that configurable with possibly streaming updates
for formats that support that? That way you still will have to parse
those streams, but it becomes possible to do it in a streaming manner
in case that is your issue currently.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Jean-Baptiste Kempf]

Yo,

On Sat, Feb 22, 2020, at 22:18, Josh de Kock wrote:
> This allows for easy shortlog/log parsing, useful in determining
> eligible members of the general assembly for the new FFmpeg voting
> system.

I think this is a good idea.
But are you sure all of those are in the right order? (aka preferred email is 
shown)

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Josh de Kock]

On Sun, Feb 23, 2020, at 2:12 PM, Jean-Baptiste Kempf wrote:
> [...]
>
> I think this is a good idea.
> But are you sure all of those are in the right order? (aka preferred 
> email is shown)

It looks mostly right to me, of course individuals will need to manually
verify it for themselves (but it can always be changed later).

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/ac3_parser: recognize LE bitstream variant

[Paul B Mahol]

will apply

On 2/21/20, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/ac3_parser.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
> index 1e203ae6ac..ba171653ef 100644
> --- a/libavcodec/ac3_parser.c
> +++ b/libavcodec/ac3_parser.c
> @@ -201,6 +201,12 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext
> *hdr_info,
>  AC3HeaderInfo hdr;
>  GetBitContext gbc;
>
> +if (tmp.u8[1] == 0x77 && tmp.u8[2] == 0x0b) {
> +FFSWAP(uint8_t, tmp.u8[1], tmp.u8[2]);
> +FFSWAP(uint8_t, tmp.u8[3], tmp.u8[4]);
> +FFSWAP(uint8_t, tmp.u8[5], tmp.u8[6]);
> +}
> +
>  init_get_bits(&gbc, tmp.u8+8-AC3_HEADER_SIZE, 54);
>  err = ff_ac3_parse_header(&gbc, &hdr);
>
> --
> 2.17.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[James Darnley]

On 2020-02-23 15:12, Jean-Baptiste Kempf wrote:
> Yo,
> 
> On Sat, Feb 22, 2020, at 22:18, Josh de Kock wrote:
>> This allows for easy shortlog/log parsing, useful in determining
>> eligible members of the general assembly for the new FFmpeg voting
>> system.
> 
> I think this is a good idea.
> But are you sure all of those are in the right order? (aka preferred email is 
> shown)
> 

What is "preferred email" when you have 2 roles?  My commits on the job
get obe.tv (or are supposed to) and ones made in my own time get
gmail.com (or are supposed to).

Is it: when you screw up what email should you be shouted at on?

I guess since I probably send more discussion email from gmail.com,
maybe it is that one.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Josh de Kock]

On Sun, Feb 23, 2020, at 2:36 PM, James Darnley wrote:
> [...]
> 
> What is "preferred email" when you have 2 roles?  My commits on the job
> get obe.tv (or are supposed to) and ones made in my own time get
> gmail.com (or are supposed to).
> 
> Is it: when you screw up what email should you be shouted at on?
> 
> I guess since I probably send more discussion email from gmail.com,
> maybe it is that one.

It's if you want your two emails to be associated. If you don't
associate them and you don't get >20 commits in the last 36
months on either individually then you won't be eligible for the
general assembly. You can still see which commits are on each
email (since this is important for copyright reasons).

It is just a visual thing: I will swap your association to show
your gmail email first.
-- 
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat: Add AMQP version 0-9-1 protocol support

[Andriy Gelman]

On Sun, 09. Feb 17:30, Andriy Gelman wrote:
> On Sun, 09. Feb 14:32, Timo Rothenpieler wrote:
> > On 01.02.2020 20:02, Andriy Gelman wrote:
> > > From: Andriy Gelman 
> > > 
> > > Supports connecting to a RabbitMQ broker via AMQP version 0-9-1. The
> > > broker can redistribute content to other clients based on "exchange" and
> > > "routing_key" fields.
> > > ---
> > > 
> > > Compilation notes:
> > > - Requires librabbitmq-dev package (on ubuntu).
> > > - The pkg-config libprabbitmq.pc has a corrupt entry.
> > >The line "Libs.private: rt; -lpthread" should be changed to
> > >"Libs.private: -lrt -lpthread". I have made a bug report.
> > > - Compile FFmpeg with --enable-librabbitmq
> > > 
> > > To run an example:
> > > #
> > > # Start the RabbitMQ broker (I use docker)
> > > # The following starts the broker on localhost:5672. A webui is available 
> > > on
> > > # localhost:15672 (User/password is "guest" by default)
> > > #
> > > $ docker run -it --rm --name rabbitmq -p 127.0.0.1:5672:5672 -p 
> > > 127.0.0.1:15672:15672 rabbitmq:3-management
> > > 
> > > #
> > > # Stream to the RabbitMQ broker:
> > > #
> > > $ ./ffmpeg -re -f lavfi -i yuvtestsrc -codec:v libx264 -f mpegts 
> > > -routing_key "amqp" -exchange "amq.direct" amqp://localhost:5672
> > > 
> > > #
> > > # Connect any number of clients to fetch data from the broker:
> > > # The clients are filtered by the routing_key and exchange.
> > > #
> > > $ ./ffplay -routing_key "amqp" -exchange "amq.direct" 
> > > amqp://localhost:5672
> > > 
> 
> > 
> > Isn't RabbitMQ, and any message broker like it, more designed to pipe short
> > messages around?
> > I'd imagine it's really not designed to shovel huge amounts of data, like a
> > full on video stream, around.
> 
> I didn't have any problems streaming to/from the broker, but I have to 
> evaluate
> at which point it breaks. I'll share these numbers with ffmpeg-devel.
> 

I did a test on my intel i7-6600U CPU @ 2.6GHz with 16GB ram   

- One RabbitMQ broker started with: 
$ docker run -it --rm --name rabbitmq -p 127.0.0.1:5672:5672 -p 
127.0.0.1:15672:15672 rabbitmq:3-management

- 1 client streaming to the broker (1280x720, 30fps, bitrate: 1236kb/s) 
$ ./ffmpeg -re input.mp4 -codec:v copy -an -f mpegts amqp://localhost

- 300 clients connecting to the broker and writing the output to null:
$ ./ffmpeg -i amqp://localhost -codec:v copy -f null -

- 2 clients playing the stream with ffplay
$ ./ffplay -i amqp://localhost

All the connections were visible on the broker monitor, and streams were running
at speed ~1.0x
At this point all my cores were close to 100%.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Thilo Borgmann]

Am 22.02.20 um 22:18 schrieb Josh de Kock:
> This allows for easy shortlog/log parsing, useful in determining
> eligible members of the general assembly for the new FFmpeg voting
> system.
> 
> Signed-off-by: Josh de Kock 
> ---
> 
> This list was automatically generated based off of commits from
> people with the same names. If you want this adjusted/your
> mapping added in this commit then please comment.

How is it automatically generated?

-Thilo

> 
>  .mailmap | 16 
>  1 file changed, 16 insertions(+)
>  create mode 100644 .mailmap
> 
> diff --git a/.mailmap b/.mailmap
> new file mode 100644
> index 00..347d3f1a9d
> --- /dev/null
> +++ b/.mailmap
> @@ -0,0 +1,16 @@
> + 
> + 
> + 
> + 
> +  
> + 
> + 
> +  
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Carl Eugen Hoyos]

Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
:
>
> From: Parker Ernest <@>
>
> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II

Does the commit break build on specific CPUs or specific toolchains?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[James Almer]

On 2/23/2020 9:33 AM, Paul B Mahol wrote:
> lgtm

No, it's not ok. The EXTERNAL_SSSE3() macro should be enough to prevent
any of these functions from running on old CPUs.

It would help actually knowing what kind of failure is the user getting.

> 
> On 2/23/20, Michael Niedermayer  wrote:
>> From: Parker Ernest <@>
>>
>> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
>> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libswscale/x86/yuv2rgb.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
>> index c12e88cbb5..4791e5b93a 100644
>> --- a/libswscale/x86/yuv2rgb.c
>> +++ b/libswscale/x86/yuv2rgb.c
>> @@ -83,6 +83,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>>  #if HAVE_X86ASM
>>  int cpu_flags = av_get_cpu_flags();
>>
>> +#if HAVE_SSSE3
>>  if (EXTERNAL_SSSE3(cpu_flags)) {
>>  switch (c->dstFormat) {
>>  case AV_PIX_FMT_RGB32:
>> @@ -111,6 +112,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>>  return yuv420_rgb15_ssse3;
>>  }
>>  }
>> +#endif
>>
>>  if (EXTERNAL_MMXEXT(cpu_flags)) {
>>  switch (c->dstFormat) {
>> --
>> 2.17.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Paul B Mahol]

On 2/23/20, James Almer  wrote:
> On 2/23/2020 9:33 AM, Paul B Mahol wrote:
>> lgtm
>
> No, it's not ok. The EXTERNAL_SSSE3() macro should be enough to prevent
> any of these functions from running on old CPUs.

this is about building.

>
> It would help actually knowing what kind of failure is the user getting.
>
>>
>> On 2/23/20, Michael Niedermayer  wrote:
>>> From: Parker Ernest <@>
>>>
>>> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
>>> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libswscale/x86/yuv2rgb.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
>>> index c12e88cbb5..4791e5b93a 100644
>>> --- a/libswscale/x86/yuv2rgb.c
>>> +++ b/libswscale/x86/yuv2rgb.c
>>> @@ -83,6 +83,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>>>  #if HAVE_X86ASM
>>>  int cpu_flags = av_get_cpu_flags();
>>>
>>> +#if HAVE_SSSE3
>>>  if (EXTERNAL_SSSE3(cpu_flags)) {
>>>  switch (c->dstFormat) {
>>>  case AV_PIX_FMT_RGB32:
>>> @@ -111,6 +112,7 @@ av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
>>>  return yuv420_rgb15_ssse3;
>>>  }
>>>  }
>>> +#endif
>>>
>>>  if (EXTERNAL_MMXEXT(cpu_flags)) {
>>>  switch (c->dstFormat) {
>>> --
>>> 2.17.1
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] tools/target_dec_fuzzer: Adjust threshold for zerocodec

[Michael Niedermayer]

Fixes: Timeout (147sec -> 1sec)
Fixes: 
20764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ZEROCODEC_fuzzer-5068274603917312

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fuzzer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 2487b6ca94..9b8eafd7c4 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -167,6 +167,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_TRUEMOTION2: maxpixels  /= 1024;  break;
 case AV_CODEC_ID_VP7: maxpixels  /= 256;   break;
 case AV_CODEC_ID_VP9: maxpixels  /= 4096;  break;
+case AV_CODEC_ID_ZEROCODEC:   maxpixels  /= 128;   break;
 }
 
 
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/mvdec: Check stream numbers

[Michael Niedermayer]

Fixes: null pointer dereference
Fixes: 
20768/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5638648978735104.fuzz

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mvdec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
index f9f7e38137..64166a84b1 100644
--- a/libavformat/mvdec.c
+++ b/libavformat/mvdec.c
@@ -363,6 +363,12 @@ static int mv_read_header(AVFormatContext *avctx)
 if ((ret = read_table(avctx, NULL, parse_global_var)) < 0)
 return ret;
 
+if (mv->nb_audio_tracks < 0  || mv->nb_video_tracks < 0 ||
+   (mv->nb_audio_tracks == 0 && mv->nb_video_tracks == 0)) {
+av_log(avctx, AV_LOG_ERROR, "Stream count is invalid.\n");
+return AVERROR_INVALIDDATA;
+}
+
 if (mv->nb_audio_tracks > 1) {
 avpriv_request_sample(avctx, "Multiple audio streams support");
 return AVERROR_PATCHWELCOME;
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavcodec/amfenc_hevc.c: Fix video fast forward hanging issue on HEVC AMF.

[nyanmisaka]

Change wrong gops_per_idr default value from 60 to 1 as per AMD AMF documents.
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/doc/AMF_Video_Encode_API.pdf

Fixed: http://trac.ffmpeg.org/ticket/7272
---
 libavcodec/amfenc_hevc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..b0cb57cb96 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -69,7 +69,7 @@ static const AVOption options[] = {
 { "gop","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_GOP_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 { "idr","", 0, AV_OPT_TYPE_CONST, { .i64 = 
AMF_VIDEO_ENCODER_HEVC_HEADER_INSERTION_MODE_IDR_ALIGNED }, 0, 0, VE, "hdrmode" 
},
 
-{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 60 },  0, INT_MAX, VE },
+{ "gops_per_idr","GOPs per IDR 0-no IDR will be inserted",  
OFFSET(gops_per_idr),  AV_OPT_TYPE_INT,  { .i64 = 1 },  0, INT_MAX, VE },
 { "preanalysis","Enable preanalysis",   
OFFSET(preanalysis),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "vbaq",   "Enable VBAQ",  
OFFSET(enable_vbaq),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
 { "enforce_hrd","Enforce HRD",  
OFFSET(enforce_hrd),   AV_OPT_TYPE_BOOL, { .i64 = 0  },  0, 1, VE},
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Hendrik Leppkes]

On Sun, Feb 23, 2020 at 6:26 PM Paul B Mahol  wrote:
>
> On 2/23/20, James Almer  wrote:
> > On 2/23/2020 9:33 AM, Paul B Mahol wrote:
> >> lgtm
> >
> > No, it's not ok. The EXTERNAL_SSSE3() macro should be enough to prevent
> > any of these functions from running on old CPUs.
>
> this is about building.
>

We don't protect other parts of the SIMD code with preprocessor
checks, we only typically do it for AVX2, but not any of the SSE
variants, so at the very least some clarity would be appreciated why
and when this is needed. Because the commit message does not.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Michael Niedermayer]

On Sun, Feb 23, 2020 at 05:03:36PM +0100, Carl Eugen Hoyos wrote:
> Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
> :
> >
> > From: Parker Ernest <@>
> >
> > commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> > x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
> 
> Does the commit break build on specific CPUs or specific toolchains?

I dont know what the testcase was the author encountered, i just posted
this here as the author wanted me to post it for him.
but a simple
make distclean ; ./configure --disable-ssse3 && make -j32
replicates the build failure here (see below for the errors)

We do have the 
extern void RENAME(ff_yuv_420_rgb32)(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
 const uint8_t *pv_index, const uint64_t 
*pointer_c_dither,
 const uint8_t *py_2index);
...

under #if HAVE_SSSE3

so i think either that needs to be changed or the code using it needs to be
similarly protected.
the if(...)
is not good enough because it is not something failingh at linking stage but
already before because the compiler has no idea what the identifer even is.
(compared to knowing what it is but not having a implemenetation later, which
 works as disabled code and optimized out references dont fail to link)



libswscale/x86/yuv2rgb.c: In function ‘ff_yuv2rgb_init_x86’:
libswscale/x86/yuv2rgb.c:91:24: error: ‘yuva420_rgb32_ssse3’ undeclared (first 
use in this function); did you mean ‘yuva420_rgb32_mmx’?
 return yuva420_rgb32_ssse3;
^~~
yuva420_rgb32_mmx
libswscale/x86/yuv2rgb.c:91:24: note: each undeclared identifier is reported 
only once for each function it appears in
libswscale/x86/yuv2rgb.c:95:24: error: ‘yuv420_rgb32_ssse3’ undeclared (first 
use in this function); did you mean ‘yuva420_rgb32_ssse3’?
 return yuv420_rgb32_ssse3;
^~
yuva420_rgb32_ssse3
libswscale/x86/yuv2rgb.c:99:24: error: ‘yuva420_bgr32_ssse3’ undeclared (first 
use in this function); did you mean ‘yuva420_rgb32_ssse3’?
 return yuva420_bgr32_ssse3;
^~~
yuva420_rgb32_ssse3
libswscale/x86/yuv2rgb.c:103:24: error: ‘yuv420_bgr32_ssse3’ undeclared (first 
use in this function); did you mean ‘yuva420_bgr32_ssse3’?
 return yuv420_bgr32_ssse3;
^~
yuva420_bgr32_ssse3
libswscale/x86/yuv2rgb.c:105:20: error: ‘yuv420_rgb24_ssse3’ undeclared (first 
use in this function); did you mean ‘yuv420_rgb32_ssse3’?
 return yuv420_rgb24_ssse3;
^~
yuv420_rgb32_ssse3
libswscale/x86/yuv2rgb.c:107:20: error: ‘yuv420_bgr24_ssse3’ undeclared (first 
use in this function); did you mean ‘yuv420_rgb24_ssse3’?
 return yuv420_bgr24_ssse3;
^~
yuv420_rgb24_ssse3
libswscale/x86/yuv2rgb.c:109:20: error: ‘yuv420_rgb16_ssse3’ undeclared (first 
use in this function); did you mean ‘yuv420_rgb24_ssse3’?
 return yuv420_rgb16_ssse3;
^~
yuv420_rgb24_ssse3
libswscale/x86/yuv2rgb.c:111:20: error: ‘yuv420_rgb15_ssse3’ undeclared (first 
use in this function); did you mean ‘yuv420_rgb16_ssse3’?
 return yuv420_rgb15_ssse3;
^~
yuv420_rgb16_ssse3
ffbuild/common.mak:59: recipe for target 'libswscale/x86/yuv2rgb.o' failed
make: *** [libswscale/x86/yuv2rgb.o] Error 1
make: *** Waiting for unfinished jobs

[...]

-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[James Almer]

On 2/23/2020 2:58 PM, Michael Niedermayer wrote:
> On Sun, Feb 23, 2020 at 05:03:36PM +0100, Carl Eugen Hoyos wrote:
>> Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> From: Parker Ernest <@>
>>>
>>> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
>>> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
>>
>> Does the commit break build on specific CPUs or specific toolchains?
> 
> I dont know what the testcase was the author encountered, i just posted
> this here as the author wanted me to post it for him.
> but a simple
> make distclean ; ./configure --disable-ssse3 && make -j32
> replicates the build failure here (see below for the errors)
> 
> We do have the 
> extern void RENAME(ff_yuv_420_rgb32)(x86_reg index, uint8_t *image, const 
> uint8_t *pu_index,
>  const uint8_t *pv_index, const uint64_t 
> *pointer_c_dither,
>  const uint8_t *py_2index);
> ...
> 
> under #if HAVE_SSSE3
> 
> so i think either that needs to be changed or the code using it needs to be
> similarly protected.
> the if(...)
> is not good enough because it is not something failingh at linking stage but
> already before because the compiler has no idea what the identifer even is.
> (compared to knowing what it is but not having a implemenetation later, which
>  works as disabled code and optimized out references dont fail to link)

This would also happen with --disable-mmxext.

IMO, the #if HAVE_* checks should be removed and always include all
three instances of yuv2rgb_template.c.
The actual asm code is always assembled after all, and as Hendrik
mentioned, we only ever make AVX functions or higher optional, mainly
because of assembler support and because disabling such instruction sets
also affects alignment and stride constants across the codebase.

> 
> 
> 
> libswscale/x86/yuv2rgb.c: In function ‘ff_yuv2rgb_init_x86’:
> libswscale/x86/yuv2rgb.c:91:24: error: ‘yuva420_rgb32_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuva420_rgb32_mmx’?
>  return yuva420_rgb32_ssse3;
> ^~~
> yuva420_rgb32_mmx
> libswscale/x86/yuv2rgb.c:91:24: note: each undeclared identifier is reported 
> only once for each function it appears in
> libswscale/x86/yuv2rgb.c:95:24: error: ‘yuv420_rgb32_ssse3’ undeclared (first 
> use in this function); did you mean ‘yuva420_rgb32_ssse3’?
>  return yuv420_rgb32_ssse3;
> ^~
> yuva420_rgb32_ssse3
> libswscale/x86/yuv2rgb.c:99:24: error: ‘yuva420_bgr32_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuva420_rgb32_ssse3’?
>  return yuva420_bgr32_ssse3;
> ^~~
> yuva420_rgb32_ssse3
> libswscale/x86/yuv2rgb.c:103:24: error: ‘yuv420_bgr32_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuva420_bgr32_ssse3’?
>  return yuv420_bgr32_ssse3;
> ^~
> yuva420_bgr32_ssse3
> libswscale/x86/yuv2rgb.c:105:20: error: ‘yuv420_rgb24_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuv420_rgb32_ssse3’?
>  return yuv420_rgb24_ssse3;
> ^~
> yuv420_rgb32_ssse3
> libswscale/x86/yuv2rgb.c:107:20: error: ‘yuv420_bgr24_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuv420_rgb24_ssse3’?
>  return yuv420_bgr24_ssse3;
> ^~
> yuv420_rgb24_ssse3
> libswscale/x86/yuv2rgb.c:109:20: error: ‘yuv420_rgb16_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuv420_rgb24_ssse3’?
>  return yuv420_rgb16_ssse3;
> ^~
> yuv420_rgb24_ssse3
> libswscale/x86/yuv2rgb.c:111:20: error: ‘yuv420_rgb15_ssse3’ undeclared 
> (first use in this function); did you mean ‘yuv420_rgb16_ssse3’?
>  return yuv420_rgb15_ssse3;
> ^~
> yuv420_rgb16_ssse3
> ffbuild/common.mak:59: recipe for target 'libswscale/x86/yuv2rgb.o' failed
> make: *** [libswscale/x86/yuv2rgb.o] Error 1
> make: *** Waiting for unfinished jobs
> 
> [...]
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 1/3] avcodec/v4l2_m2m_enc: Reduce log verbosity for some params

[Andriy Gelman]

From: Andriy Gelman 

Currently the user gets unhelpful warnings when some default parameters
are not supported by the device. The verbosity of these log messages has
been changed to AV_LOG_DEBUG.

Signed-off-by: Andriy Gelman 
---
 libavcodec/v4l2_m2m_enc.c | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index c9f1741bfd0..859feb7bde7 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -47,7 +47,7 @@ static inline void v4l2_set_timeperframe(V4L2m2mContext *s, 
unsigned int num, un
 av_log(s->avctx, AV_LOG_WARNING, "Failed to set timeperframe");
 }
 
-static inline void v4l2_set_ext_ctrl(V4L2m2mContext *s, unsigned int id, 
signed int value, const char *name)
+static inline void v4l2_set_ext_ctrl(V4L2m2mContext *s, unsigned int id, 
signed int value, const char *name, int log_warning)
 {
 struct v4l2_ext_controls ctrls = { { 0 } };
 struct v4l2_ext_control ctrl = { 0 };
@@ -62,12 +62,13 @@ static inline void v4l2_set_ext_ctrl(V4L2m2mContext *s, 
unsigned int id, signed
 ctrl.id = id;
 
 if (ioctl(s->fd, VIDIOC_S_EXT_CTRLS, &ctrls) < 0)
-av_log(s->avctx, AV_LOG_WARNING, "Failed to set %s: %s\n", name, 
strerror(errno));
+av_log(s->avctx, log_warning || errno != EINVAL ? AV_LOG_WARNING : 
AV_LOG_DEBUG,
+   "Failed to set %s: %s\n", name, strerror(errno));
 else
 av_log(s->avctx, AV_LOG_DEBUG, "Encoder: %s = %d\n", name, value);
 }
 
-static inline int v4l2_get_ext_ctrl(V4L2m2mContext *s, unsigned int id, signed 
int *value, const char *name)
+static inline int v4l2_get_ext_ctrl(V4L2m2mContext *s, unsigned int id, signed 
int *value, const char *name, int log_warning)
 {
 struct v4l2_ext_controls ctrls = { { 0 } };
 struct v4l2_ext_control ctrl = { 0 };
@@ -83,7 +84,8 @@ static inline int v4l2_get_ext_ctrl(V4L2m2mContext *s, 
unsigned int id, signed i
 
 ret = ioctl(s->fd, VIDIOC_G_EXT_CTRLS, &ctrls);
 if (ret < 0) {
-av_log(s->avctx, AV_LOG_WARNING, "Failed to get %s\n", name);
+av_log(s->avctx, log_warning || errno != EINVAL ? AV_LOG_WARNING : 
AV_LOG_DEBUG,
+   "Failed to get %s\n", name);
 return ret;
 }
 
@@ -145,8 +147,8 @@ static int v4l2_check_b_frame_support(V4L2m2mContext *s)
 if (s->avctx->max_b_frames)
 av_log(s->avctx, AV_LOG_WARNING, "Encoder does not support b-frames 
yet\n");
 
-v4l2_set_ext_ctrl(s, MPEG_CID(B_FRAMES), 0, "number of B-frames");
-v4l2_get_ext_ctrl(s, MPEG_CID(B_FRAMES), &s->avctx->max_b_frames, "number 
of B-frames");
+v4l2_set_ext_ctrl(s, MPEG_CID(B_FRAMES), 0, "number of B-frames", 0);
+v4l2_get_ext_ctrl(s, MPEG_CID(B_FRAMES), &s->avctx->max_b_frames, "number 
of B-frames", 0);
 if (s->avctx->max_b_frames == 0)
 return 0;
 
@@ -175,9 +177,9 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
 v4l2_set_timeperframe(s, avctx->framerate.num, avctx->framerate.den);
 
 /* set ext ctrls */
-v4l2_set_ext_ctrl(s, MPEG_CID(HEADER_MODE), 
MPEG_VIDEO(HEADER_MODE_SEPARATE), "header mode");
-v4l2_set_ext_ctrl(s, MPEG_CID(BITRATE) , avctx->bit_rate, "bit rate");
-v4l2_set_ext_ctrl(s, MPEG_CID(GOP_SIZE), avctx->gop_size,"gop size");
+v4l2_set_ext_ctrl(s, MPEG_CID(HEADER_MODE), 
MPEG_VIDEO(HEADER_MODE_SEPARATE), "header mode", 0);
+v4l2_set_ext_ctrl(s, MPEG_CID(BITRATE) , avctx->bit_rate, "bit rate", 1);
+v4l2_set_ext_ctrl(s, MPEG_CID(GOP_SIZE), avctx->gop_size,"gop size", 1);
 
 av_log(avctx, AV_LOG_DEBUG,
 "Encoder Context: id (%d), profile (%d), frame rate(%d/%d), number 
b-frames (%d), "
@@ -187,26 +189,30 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
 
 switch (avctx->codec_id) {
 case AV_CODEC_ID_H264:
+if (avctx->profile != FF_PROFILE_UNKNOWN) {
 val = v4l2_h264_profile_from_ff(avctx->profile);
 if (val < 0)
 av_log(avctx, AV_LOG_WARNING, "h264 profile not found\n");
 else
-v4l2_set_ext_ctrl(s, MPEG_CID(H264_PROFILE), val, "h264 profile");
+v4l2_set_ext_ctrl(s, MPEG_CID(H264_PROFILE), val, "h264 profile", 
1);
+}
 qmin_cid = MPEG_CID(H264_MIN_QP);
 qmax_cid = MPEG_CID(H264_MAX_QP);
 qmin = 0;
 qmax = 51;
 break;
 case AV_CODEC_ID_MPEG4:
+if (avctx->profile != FF_PROFILE_UNKNOWN) {
 val = v4l2_mpeg4_profile_from_ff(avctx->profile);
 if (val < 0)
 av_log(avctx, AV_LOG_WARNING, "mpeg4 profile not found\n");
 else
-v4l2_set_ext_ctrl(s, MPEG_CID(MPEG4_PROFILE), val, "mpeg4 
profile");
+v4l2_set_ext_ctrl(s, MPEG_CID(MPEG4_PROFILE), val, "mpeg4 
profile", 1);
+}
 qmin_cid = MPEG_CID(MPEG4_MIN_QP);
 qmax_cid = MPEG_CID(MPEG4_MAX_QP);
 if (avctx->flags & AV_CODEC_FLAG_QPEL)
-v4l2_set_ext_ctrl(s, MPEG_CID(MPEG4_Q

[FFmpeg-devel] [PATCH v4 3/3] avcodec/v4l2_m2m_enc: Support changing qmin/qmax

[Andriy Gelman]

From: Andriy Gelman 

Hard coded parameters for qmin and qmax are currently used to initialize
v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
are set.

Signed-off-by: Andriy Gelman 
---
 libavcodec/v4l2_m2m_enc.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index 0098d5314bb..500a0b757e5 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -31,6 +31,7 @@
 #include "v4l2_context.h"
 #include "v4l2_m2m.h"
 #include "v4l2_fmt.h"
+#include "internal.h"
 
 #define MPEG_CID(x) V4L2_CID_MPEG_VIDEO_##x
 #define MPEG_VIDEO(x) V4L2_MPEG_VIDEO_##x
@@ -239,11 +240,16 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
 return 0;
 }
 
-if (qmin != avctx->qmin || qmax != avctx->qmax)
-av_log(avctx, AV_LOG_WARNING, "Encoder adjusted: qmin (%d), qmax 
(%d)\n", qmin, qmax);
+if (avctx->qmin >= 0)
+qmin = avctx->qmin;
 
-v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer scale", 0);
-v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale", 0);
+if (avctx->qmax >= 0)
+qmax = avctx->qmax;
+
+v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer scale",
+  avctx->qmin >= 0);
+v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale",
+  avctx->qmax >= 0);
 
 return 0;
 }
@@ -356,6 +362,12 @@ static const AVOption options[] = {
 { NULL },
 };
 
+static const AVCodecDefault v4l2_m2m_defaults[] = {
+{ "qmin", "-1" },
+{ "qmax", "-1" },
+{ NULL },
+};
+
 #define M2MENC_CLASS(NAME) \
 static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
 .class_name = #NAME "_v4l2m2m_encoder", \
@@ -377,6 +389,7 @@ static const AVOption options[] = {
 .send_frame = v4l2_send_frame, \
 .receive_packet = v4l2_receive_packet, \
 .close  = v4l2_encode_close, \
+.defaults   = v4l2_m2m_defaults, \
 .capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
 .wrapper_name   = "v4l2m2m", \
 };
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 2/3] avcodec/v4l2_m2m_enc: Enable frame level rate control by default

[Andriy Gelman]

From: Andriy Gelman 

Without this setting, bitrate and qmin/qmax options have no
affect on the s5p-mfc hardware encoder.

Signed-off-by: Andriy Gelman 
---
 libavcodec/v4l2_m2m_enc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index 859feb7bde7..0098d5314bb 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -179,6 +179,7 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
 /* set ext ctrls */
 v4l2_set_ext_ctrl(s, MPEG_CID(HEADER_MODE), 
MPEG_VIDEO(HEADER_MODE_SEPARATE), "header mode", 0);
 v4l2_set_ext_ctrl(s, MPEG_CID(BITRATE) , avctx->bit_rate, "bit rate", 1);
+v4l2_set_ext_ctrl(s, MPEG_CID(FRAME_RC_ENABLE), 1, "frame level rate 
control", 0);
 v4l2_set_ext_ctrl(s, MPEG_CID(GOP_SIZE), avctx->gop_size,"gop size", 1);
 
 av_log(avctx, AV_LOG_DEBUG,
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Hendrik Leppkes]

On Sun, Feb 23, 2020 at 6:58 PM Michael Niedermayer  wrote:
>
> On Sun, Feb 23, 2020 at 05:03:36PM +0100, Carl Eugen Hoyos wrote:
> > Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
> > :
> > >
> > > From: Parker Ernest <@>
> > >
> > > commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> > > x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
> >
> > Does the commit break build on specific CPUs or specific toolchains?
>
> I dont know what the testcase was the author encountered, i just posted
> this here as the author wanted me to post it for him.
> but a simple
> make distclean ; ./configure --disable-ssse3 && make -j32
> replicates the build failure here (see below for the errors)
>
> We do have the
> extern void RENAME(ff_yuv_420_rgb32)(x86_reg index, uint8_t *image, const 
> uint8_t *pu_index,
>  const uint8_t *pv_index, const uint64_t 
> *pointer_c_dither,
>  const uint8_t *py_2index);
> ...
>
> under #if HAVE_SSSE3
>
> so i think either that needs to be changed or the code using it needs to be
> similarly protected.

The extern declaration should be removed from that guard then, like
other SIMD code in the codebase.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Josh de Kock]

On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote:
> [...]
> 
> How is it automatically generated?

I wrote a small script to parse author names/emails and group
emails together based on names. In the future, additions should
be added manually.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

[Michael Niedermayer]

On Sat, Feb 22, 2020 at 09:47:20AM +0100, Clément Bœsch wrote:
> On Fri, Feb 14, 2020 at 03:26:30AM +, Soft Works wrote:
> > Hi,
> > 
> 
> Hi,
> 
> > I am looking for some guidance regarding future plans about processing 
> > subtitle streams in filter graphs.
> > 
> > Please correct me where I'm wrong - this is the situation as I've 
> > understood it so far:
> [...]
> 
> Your analysis was pretty much on point. I've been away from FFmpeg development
> from around the time of that patchset. While I can't recommend a course of
> action, I can elaborate on what was blocking and missing. Beware that this is
> reconstructed from my unreliable memory and I may forget important points.
> 
> Last state can be found at 
> https://github.com/ubitux/FFmpeg/tree/subtitles-new-api
> 
> The last WIP commit includes a TODO.txt which I'm sharing here for the
> record:
> 
> > TODO:
> > - heartbeat mechanism
> > - drop sub2video (needs heartbeat)
> > - properly deal with -ss and -t (need strim filter?)
> > - sub_start_display/sub_end_display needs to be honored
> > - find a test case for dvbsub as it's likely broken (ffmpeg.c hack is
> >   removed and should be replaced by a EAGAIN logic in lavc/utils.c)
> > - make it pass FATE:
> >   * fix cc/subcc
> >   * broke various other stuff
> > - Changelog/APIchanges
> > - proper API doxy
> > - update lavfi/subtitles?
> > - merge [avs]null filters
> > - filters doc
> > - avcodec_default_get_buffer2?
> > - how to transfer subtitle header down to libavfilter?
> 
> The biggest TODO entry right now is the heartbeat mechanism which is required
> for being able to drop the sub2video hack. You've seen that discussed in the
> thread.
> 
> Thing is, that branch is already a relatively invasive and may include
> controversial API change. Typically, the way I decided to handle subtitle
> text/rectangle allocation within AVSubtitle is "different" but I couldn't come
> up with a better solution. Basically, we have to fit them in AVFrame for a
> clean integration within FFmpeg ecosystem, but subtitles are not simple 
> buffers
> like audio and video can be: they have to be backed by more complex dynamic
> structures.
> 
> Also unfortunately, addressing the problem through an iterative process is
> extremely difficult in the current situation due to historical technical debt.
> You may have noticed that the decode and encode subtitles API are a few
> generations behind the audio and video ones. The reason it wasn't modernized
> earlier was because it was already a pita in the past.
> 

> The subtitles refactor requires to see the big picture and all the problems at
> once. 

really ?
just hypothetically, and playing the devils advocat here.
what would happen if one problem or set of problems is solved at a time ?

Maybe the thinking should not be "what are all the things that might need
to be considered"
but rather "what is the minimum set of things that need to be considered"
to make the first step towards a better API/first git push



> Since the core change (subtitles in AVFrame) requires the introduction of
> a new subtitles structure and API, it also involve addressing the shortcomings
> of the original API (or maybe we could tolerate a new API that actually looks
> like the old?). So even if we ignore the subtitle-in-avframe thing, we don't
> have a clear answer for a sane API that handles everything. Here is a
> non-exhaustive list of stuff that we have to take into account while thinking
> about that:
> 
> - text subtitles with and without markup

> - sparsity, overlapping

heartbeat frames would eliminate sparsity
what happens if you forbid overlapping ?
I mean if i just imagine for a moment that a video stream carries some data
256 color palette in 4 parts and these get updated in a way that overlapps in
time like you talk about in subtitles.
This isnt a problem for video, we just have the whole palette anywhere it is
needed
And similarly a B frame updates parts of the pixels of the previous and next
frame yet our AVFrame contains whole bitmaps.

at the stage of encoding such subtitle AVFrame back to "binary" data, the 
encoder
would have to merge identical subtitle parts if that is supported.


> - different semantics for duration (duration available, no known duration,
>   event-based clearing, ...)

This one is annoying (though similar to video where its just not so much an
issue as video is generally regularly spaced)
But does this actually impact the API in any way ?
decoder -> avframe -> encoder
(if some information is missing some look 
ahead/buffer/filter/converter/whatever may be needed but the API wouldnt 
change i think and that should work with any API)


> - closed captions / teletext

What happens if you ignore these at this stage?


> - bitmap subtitles and their potential colorspaces (each rectangle as an
>   AVFrame is way overkill but technically that's exactly what it is)

then a AVFrame needs to represent a collection of rectangles.
Its either 1 or N for the de

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mvdec: Check stream numbers

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: null pointer dereference
> Fixes: 
> 20768/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5638648978735104.fuzz
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mvdec.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
> index f9f7e38137..64166a84b1 100644
> --- a/libavformat/mvdec.c
> +++ b/libavformat/mvdec.c
> @@ -363,6 +363,12 @@ static int mv_read_header(AVFormatContext *avctx)
>  if ((ret = read_table(avctx, NULL, parse_global_var)) < 0)
>  return ret;
>  
> +if (mv->nb_audio_tracks < 0  || mv->nb_video_tracks < 0 ||
> +   (mv->nb_audio_tracks == 0 && mv->nb_video_tracks == 0)) {
> +av_log(avctx, AV_LOG_ERROR, "Stream count is invalid.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
>  if (mv->nb_audio_tracks > 1) {
>  avpriv_request_sample(avctx, "Multiple audio streams support");
>  return AVERROR_PATCHWELCOME;
> 
LGTM.

- Andreas

PS: Is it actually allowed to set the channel_layout to stereo if
there are more than two channels (as set_channels() does)?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] configure: Enable section_data_rel_ro for OpenBSD aarch64 / arm

[Brad Smith]

configure: Enable section_data_rel_ro for OpenBSD aarch64 / arm

Signed-off-by: Brad Smith 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index ab761c7183..06e3a7b2a8 100755
--- a/configure
+++ b/configure
@@ -5305,6 +5305,7 @@ case $target_os in
 ;;
 openbsd|bitrig)
 disable symver
+enable section_data_rel_ro
 striptype=""
 SHFLAGS='-shared'
 SLIB_INSTALL_NAME='$(SLIBNAME).$(LIBMAJOR).$(LIBMINOR)'
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 6/7] avformat/segafilmenc: Combine several checks

[Andreas Rheinhardt]

Andreas Rheinhardt:
> by moving them around.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/segafilmenc.c | 26 +-
>  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> index 4f881f4f2f..137f153331 100644
> --- a/libavformat/segafilmenc.c
> +++ b/libavformat/segafilmenc.c
> @@ -155,7 +155,6 @@ static int get_audio_codec_id(enum AVCodecID codec_id)
>  
>  static int film_init(AVFormatContext *format_context)
>  {
> -AVStream *audio = NULL;
>  FILMOutputContext *film = format_context->priv_data;
>  film->audio_index = -1;
>  film->video_index = -1;
> @@ -171,8 +170,12 @@ static int film_init(AVFormatContext *format_context)
>  av_log(format_context, AV_LOG_ERROR, "Sega FILM allows a 
> maximum of one audio stream.\n");
>  return AVERROR(EINVAL);
>  }
> +if (get_audio_codec_id(st->codecpar->codec_id) < 0) {
> +av_log(format_context, AV_LOG_ERROR,
> +   "Incompatible audio stream format.\n");
> +return AVERROR(EINVAL);
> +}
>  film->audio_index = i;
> -audio = st;
>  }
>  
>  if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
> @@ -200,11 +203,6 @@ static int film_init(AVFormatContext *format_context)
>  return AVERROR(EINVAL);
>  }
>  
> -if (audio != NULL && get_audio_codec_id(audio->codecpar->codec_id) < 0) {
> -av_log(format_context, AV_LOG_ERROR, "Incompatible audio stream 
> format.\n");
> -return AVERROR(EINVAL);
> -}
> -
>  return 0;
>  }
>  
> @@ -269,11 +267,9 @@ static int film_write_header(AVFormatContext 
> *format_context)
>  {
>  int ret = 0;
>  int64_t sample_table_size, stabsize, headersize;
> -int8_t audio_codec;
>  AVIOContext *pb = format_context->pb;
>  FILMOutputContext *film = format_context->priv_data;
>  FILMPacket *prev, *packet;
> -AVStream *audio = NULL;
>  AVStream *video = NULL;
>  
>  /* Calculate how much we need to reserve for the header;
> @@ -290,13 +286,6 @@ static int film_write_header(AVFormatContext 
> *format_context)
>  /* Seek back to the beginning to start writing the header now */
>  avio_seek(pb, 0, SEEK_SET);
>  
> -if (film->audio_index > -1)
> -audio = format_context->streams[film->audio_index];
> -
> -if (audio != NULL) {
> -audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
> -}
> -
>  /* First, write the FILM header; this is very simple */
>  
>  ffio_wfourcc(pb, "FILM");
> @@ -327,7 +316,10 @@ static int film_write_header(AVFormatContext 
> *format_context)
>  avio_wb32(pb, video->codecpar->width);
>  avio_w8(pb, 24); /* Bits per pixel - observed to always be 24 */
>  
> -if (audio != NULL) {
> +if (film->audio_index > -1) {
> +AVStream *audio = format_context->streams[film->audio_index];
> +int audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
> +
>  avio_w8(pb, audio->codecpar->channels); /* Audio channels */
>  avio_w8(pb, audio->codecpar->bits_per_coded_sample); /* Audio bit 
> depth */
>  avio_w8(pb, audio_codec); /* Compression - 0 is PCM, 2 is ADX */
> 
Ping for the last two unmerged patches of this patchset.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Escape braces in a regex, fixing warnings with newer perl

[Martin Storsjö]

On Tue, 18 Feb 2020, myp...@gmail.com wrote:


On Mon, Feb 17, 2020 at 3:46 PM Martin Storsjö  wrote:


Perl 5.28 warns about this, saying it will be fatal in Perl 5.32.

Signed-off-by: Martin Storsjö 
---
 gas-preprocessor.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index b2a4bcc..e3805e0 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -1102,7 +1102,7 @@ sub handle_serialized_line {
 }

 # Convert "ld1 {v0.4h-v3.4h}" into "ld1 {v0.4h,v1.4h,v2.4h,v3.4h}"
-if ($line =~ 
/(?:ld|st)\d\s+({\s*v(\d+)\.(\d[bhsdBHSD])\s*-\s*v(\d+)\.(\d[bhsdBHSD])\s*})/) {
+if ($line =~ 
/(?:ld|st)\d\s+(\{\s*v(\d+)\.(\d[bhsdBHSD])\s*-\s*v(\d+)\.(\d[bhsdBHSD])\s*\})/)
 {
 my $regspec = $1;
 my $reg1 = $2;
 my $layout1 = $3;
--

LGTM, verified


Thanks, pushed.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

[Nicolas George]

Michael Niedermayer (12020-02-23):
> really ?
> just hypothetically, and playing the devils advocat here.
> what would happen if one problem or set of problems is solved at a time ?

Odds are a design decision made early would prove insufficient to solve
a later problem.

> what happens if you forbid overlapping ?

We break perfectly valid subtitles. Unlike B-frames, overlapping
subtitles is part of the semantic.

> > - different semantics for duration (duration available, no known duration,
> >   event-based clearing, ...)
> This one is annoying (though similar to video where its just not so much an
> issue as video is generally regularly spaced)
> But does this actually impact the API in any way ?
> decoder -> avframe -> encoder

decoder → avframe → filters → avframe → encoder

Many filters need timing to work.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[James Darnley]

On 2020-02-23 18:58, Michael Niedermayer wrote:
> On Sun, Feb 23, 2020 at 05:03:36PM +0100, Carl Eugen Hoyos wrote:
>> Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
>> :
>>>
>>> From: Parker Ernest <@>
>>>
>>> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
>>> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
>>
>> Does the commit break build on specific CPUs or specific toolchains?
> 
> I dont know what the testcase was the author encountered, i just posted
> this here as the author wanted me to post it for him.
> but a simple
> make distclean ; ./configure --disable-ssse3 && make -j32
> replicates the build failure here (see below for the errors)

Okay, it breaks the build when you do --disable-sse3.  I see that too.

It is okay to fix that any way you want.  This patch is fine by me but
please don't imply that it fixes a run time error in the commit message,
which is what I first thought.

I see a discussion has sprung up on the best way to fix it so I guess
that has to be resolved first.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

[Marton Balint]

On Sun, 23 Feb 2020, Nicolas George wrote:


Michael Niedermayer (12020-02-23):

really ?
just hypothetically, and playing the devils advocat here.
what would happen if one problem or set of problems is solved at a time ?


Odds are a design decision made early would prove insufficient to solve
a later problem.


what happens if you forbid overlapping ?


We break perfectly valid subtitles. Unlike B-frames, overlapping
subtitles is part of the semantic.


Two overlapping subtitles can be broken into 3 non-overlapping subtitles, 
the middle one containing both the rectangles of the two. The same can be 
done for more overlaps in a similar fashion.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Setting default G0 character set for teletext decoder

[Marton Balint]

On Wed, 19 Feb 2020, k.savkov wrote:

I can also provide sample files, for which this option is needed, where can I 
upload them?


No need, the why is more important, so I extended the help text and 
applied your patch.


Thanks,
Marton



On 18.02.2020 23:48, Marton Balint wrote:



On Tue, 18 Feb 2020, k.savkov wrote:

Some providers don't send info about character set, so default (latin) is 
used when decoding. I added option to force desired language with function 
vbi_teletext_set_default_region. You can see what character set code maps 
to what language in Table 32 ETS 300 706,  Section 15.


docs/decoders.texi update is missing.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/9] avformat/libsrt: fix timeout unit confusion between milisec and microsec

[Marton Balint]

On Sat, 22 Feb 2020, Marton Balint wrote:




On Mon, 17 Feb 2020, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavformat/libsrt.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


Ping for the series, will apply soon.


Applied the series.

Regards,
Marton



Regards,
Marton



diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index d7faa603f5..1d748f0e81 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -210,7 +210,7 @@ static int libsrt_network_wait_fd_timeout(URLContext 

*h, int eid, int fd, int wr

}
}

-static int libsrt_listen(int eid, int fd, const struct sockaddr *addr, 

socklen_t addrlen, URLContext *h, int timeout)
+static int libsrt_listen(int eid, int fd, const struct sockaddr *addr, 

socklen_t addrlen, URLContext *h, int64_t timeout)

{
int ret;
int reuse = 1;
@@ -243,7 +243,7 @@ static int libsrt_listen(int eid, int fd, const struct 

sockaddr *addr, socklen_t

return ret;
}

-static int libsrt_listen_connect(int eid, int fd, const struct sockaddr 

*addr, socklen_t addrlen, int timeout, URLContext *h, int will_try_next)
+static int libsrt_listen_connect(int eid, int fd, const struct sockaddr 

*addr, socklen_t addrlen, int64_t timeout, URLContext *h, int will_try_next)

{
int ret;

@@ -447,7 +447,7 @@ static int libsrt_setup(URLContext *h, const char *uri, 

int flags)

}
if (s->mode == SRT_MODE_LISTENER) {
// multi-client
-if ((ret = libsrt_listen(s->eid, fd, cur_ai->ai_addr, 

cur_ai->ai_addrlen, h, open_timeout / 1000)) < 0)
+if ((ret = libsrt_listen(s->eid, fd, cur_ai->ai_addr, 

cur_ai->ai_addrlen, h, open_timeout)) < 0)

goto fail1;
fd = ret;
} else {
@@ -458,7 +458,7 @@ static int libsrt_setup(URLContext *h, const char *uri, 

int flags)

}

if ((ret = libsrt_listen_connect(s->eid, fd, cur_ai->ai_addr, 

cur_ai->ai_addrlen,
-  open_timeout / 1000, h, 

!!cur_ai->ai_next)) < 0) {
+  open_timeout, h, 

!!cur_ai->ai_next)) < 0) {

if (ret == AVERROR_EXIT)
goto fail1;
else
--
2.16.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

[Nicolas George]

Marton Balint (12020-02-23):
> Two overlapping subtitles can be broken into 3 non-overlapping subtitles,

No, they can't: being the same subtitle or not is part of the semantic.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale/x86/yuv2rgb: Fix build without SSSE3

[Carl Eugen Hoyos]

Am So., 23. Feb. 2020 um 23:43 Uhr schrieb James Darnley
:
>
> On 2020-02-23 18:58, Michael Niedermayer wrote:
> > On Sun, Feb 23, 2020 at 05:03:36PM +0100, Carl Eugen Hoyos wrote:
> >> Am So., 23. Feb. 2020 um 13:30 Uhr schrieb Michael Niedermayer
> >> :
> >>>
> >>> From: Parker Ernest <@>
> >>>
> >>> commit fc6a5883d6af8cae0e96af84dda0ad74b360a084 breaks build on
> >>> x86_64 CPUs which do not have SSSE3, e.g. AMD Phenom-II
> >>
> >> Does the commit break build on specific CPUs or specific toolchains?
> >
> > I dont know what the testcase was the author encountered, i just posted
> > this here as the author wanted me to post it for him.
> > but a simple
> > make distclean ; ./configure --disable-ssse3 && make -j32
> > replicates the build failure here (see below for the errors)
>
> Okay, it breaks the build when you do --disable-sse3.  I see that too.
>
> It is okay to fix that any way you want.  This patch is fine by me but

> please don't imply that it fixes a run time error in the commit message,
> which is what I first thought.

I also feel that mentioning a specific cpu instead of --disable-ssse3 is
misleading.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/svq1dec: Check that there is data left after the hader

[Moritz Barsnick]

On Wed, Feb 19, 2020 at 00:59:18 +0100, Michael Niedermayer wrote:
> Subject: [FFmpeg-devel] [PATCH 3/4] avcodec/svq1dec: Check that there is data 
> left after the hader

Nit: hader -> header

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 19/21] vaapi_encode_h265: Use common handling for HDR metadata

[Mark Thompson]

---
 libavcodec/vaapi_encode_h265.c | 45 +-
 1 file changed, 6 insertions(+), 39 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 538862a9d5..443139dfdb 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -750,39 +750,10 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 AVMasteringDisplayMetadata *mdm =
 (AVMasteringDisplayMetadata *)sd->data;
 
-// SEI is needed when both the primaries and luminance are set
+// Only needed when both primaries and luminance are set.
 if (mdm->has_primaries && mdm->has_luminance) {
-H265RawSEIMasteringDisplayColourVolume *mdcv =
-&priv->sei_mastering_display;
-const int mapping[3] = {1, 2, 0};
-const int chroma_den = 5;
-const int luma_den   = 1;
-
-for (i = 0; i < 3; i++) {
-const int j = mapping[i];
-mdcv->display_primaries_x[i] =
-FFMIN(lrint(chroma_den *
-av_q2d(mdm->display_primaries[j][0])),
-  chroma_den);
-mdcv->display_primaries_y[i] =
-FFMIN(lrint(chroma_den *
-av_q2d(mdm->display_primaries[j][1])),
-  chroma_den);
-}
-
-mdcv->white_point_x =
-FFMIN(lrint(chroma_den * av_q2d(mdm->white_point[0])),
-  chroma_den);
-mdcv->white_point_y =
-FFMIN(lrint(chroma_den * av_q2d(mdm->white_point[1])),
-  chroma_den);
-
-mdcv->max_display_mastering_luminance =
-lrint(luma_den * av_q2d(mdm->max_luminance));
-mdcv->min_display_mastering_luminance =
-FFMIN(lrint(luma_den * av_q2d(mdm->min_luminance)),
-  mdcv->max_display_mastering_luminance);
-
+ff_cbs_h265_fill_sei_mastering_display(
+&priv->sei_mastering_display, mdm);
 priv->sei_needed |= SEI_MASTERING_DISPLAY;
 }
 }
@@ -795,13 +766,9 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
 
 if (sd) {
-AVContentLightMetadata *clm =
-(AVContentLightMetadata *)sd->data;
-H265RawSEIContentLightLevelInfo *clli =
-&priv->sei_content_light_level;
-
-clli->max_content_light_level = FFMIN(clm->MaxCLL,  65535);
-clli->max_pic_average_light_level = FFMIN(clm->MaxFALL, 65535);
+ff_cbs_h265_fill_sei_content_light_level(
+&priv->sei_content_light_level,
+(const AVContentLightMetadata*)sd->data);
 
 priv->sei_needed |= SEI_CONTENT_LIGHT_LEVEL;
 }
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 20/21] h264_metadata_bsf: Refactor the filter function into smaller parts

[Mark Thompson]

---
 libavcodec/h264_metadata_bsf.c | 436 ++---
 1 file changed, 237 insertions(+), 199 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index d96a50dbf7..b2304373bf 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -54,6 +54,7 @@ typedef struct H264MetadataContext {
 int done_first_au;
 
 int aud;
+H264RawAUD aud_nal;
 
 AVRational sample_aspect_ratio;
 
@@ -76,6 +77,7 @@ typedef struct H264MetadataContext {
 int crop_bottom;
 
 const char *sei_user_data;
+H264RawSEIPayload sei_user_data_payload;
 
 int delete_filler;
 
@@ -87,6 +89,59 @@ typedef struct H264MetadataContext {
 } H264MetadataContext;
 
 
+static int h264_metadata_insert_aud(AVBSFContext *bsf,
+CodedBitstreamFragment *au)
+{
+H264MetadataContext *ctx = bsf->priv_data;
+int primary_pic_type_mask = 0xff;
+int err, i, j;
+
+static const int primary_pic_type_table[] = {
+0x084, // 2, 7
+0x0a5, // 0, 2, 5, 7
+0x0e7, // 0, 1, 2, 5, 6, 7
+0x210, // 4, 9
+0x318, // 3, 4, 8, 9
+0x294, // 2, 4, 7, 9
+0x3bd, // 0, 2, 3, 4, 5, 7, 8, 9
+0x3ff, // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
+};
+
+for (i = 0; i < au->nb_units; i++) {
+if (au->units[i].type == H264_NAL_SLICE ||
+au->units[i].type == H264_NAL_IDR_SLICE) {
+H264RawSlice *slice = au->units[i].content;
+for (j = 0; j < FF_ARRAY_ELEMS(primary_pic_type_table); j++) {
+if (!(primary_pic_type_table[j] &
+  (1 << slice->header.slice_type)))
+primary_pic_type_mask &= ~(1 << j);
+}
+}
+}
+for (j = 0; j < FF_ARRAY_ELEMS(primary_pic_type_table); j++)
+if (primary_pic_type_mask & (1 << j))
+break;
+if (j >= FF_ARRAY_ELEMS(primary_pic_type_table)) {
+av_log(bsf, AV_LOG_ERROR, "No usable primary_pic_type: "
+   "invalid slice types?\n");
+return AVERROR_INVALIDDATA;
+}
+
+ctx->aud_nal = (H264RawAUD) {
+.nal_unit_header.nal_unit_type = H264_NAL_AUD,
+.primary_pic_type = j,
+};
+
+err = ff_cbs_insert_unit_content(ctx->cbc, au,
+ 0, H264_NAL_AUD, &ctx->aud_nal, NULL);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to insert AUD.\n");
+return err;
+}
+
+return 0;
+}
+
 static int h264_metadata_update_sps(AVBSFContext *bsf,
 H264RawSPS *sps)
 {
@@ -275,217 +330,60 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 return 0;
 }
 
-static int h264_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
+static int h264_metadata_handle_display_orientation(AVBSFContext *bsf,
+AVPacket *pkt,
+CodedBitstreamFragment *au,
+int seek_point)
 {
 H264MetadataContext *ctx = bsf->priv_data;
-CodedBitstreamFragment *au = &ctx->access_unit;
-int err, i, j, has_sps;
-H264RawAUD aud;
+int err, i, j;
 
-err = ff_bsf_get_packet_ref(bsf, pkt);
-if (err < 0)
-return err;
+for (i = au->nb_units - 1; i >= 0; i--) {
+H264RawSEI *sei;
+if (au->units[i].type != H264_NAL_SEI)
+continue;
+sei = au->units[i].content;
 
-err = ff_cbs_read_packet(ctx->cbc, au, pkt);
-if (err < 0) {
-av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
-goto fail;
-}
+for (j = sei->payload_count - 1; j >= 0; j--) {
+H264RawSEIDisplayOrientation *disp;
+int32_t *matrix;
 
-if (au->nb_units == 0) {
-av_log(bsf, AV_LOG_ERROR, "No NAL units in packet.\n");
-err = AVERROR_INVALIDDATA;
-goto fail;
-}
-
-// If an AUD is present, it must be the first NAL unit.
-if (au->units[0].type == H264_NAL_AUD) {
-if (ctx->aud == REMOVE)
-ff_cbs_delete_unit(ctx->cbc, au, 0);
-} else {
-if (ctx->aud == INSERT) {
-static const int primary_pic_type_table[] = {
-0x084, // 2, 7
-0x0a5, // 0, 2, 5, 7
-0x0e7, // 0, 1, 2, 5, 6, 7
-0x210, // 4, 9
-0x318, // 3, 4, 8, 9
-0x294, // 2, 4, 7, 9
-0x3bd, // 0, 2, 3, 4, 5, 7, 8, 9
-0x3ff, // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
-};
-int primary_pic_type_mask = 0xff;
-
-for (i = 0; i < au->nb_units; i++) {
-if (au->units[i].type == H264_NAL_SLICE ||
-au->units[i].type == H264_NAL_IDR_SLICE) {
-H264RawSlice *slice = au->units[i].content;
-for (j = 0; j < FF_ARRAY_ELEMS(primary_pic_type_table)

[FFmpeg-devel] [PATCH v4 21/21] h264_metadata_bsf: Improve interpretation of input display matrices

[Mark Thompson]

The previous code here only worked in more limited cases.
---
 libavcodec/h264_metadata_bsf.c | 42 +++---
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index b2304373bf..8fc02c5f41 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -397,23 +397,39 @@ static int 
h264_metadata_handle_display_orientation(AVBSFContext *bsf,
 data = av_packet_get_side_data(pkt, AV_PKT_DATA_DISPLAYMATRIX, &size);
 if (data && size >= 9 * sizeof(int32_t)) {
 int32_t matrix[9];
+double dmatrix[9];
 int hflip, vflip;
-double angle;
+double scale_x, scale_y, angle;
 
 memcpy(matrix, data, sizeof(matrix));
 
-hflip = vflip = 0;
-if (matrix[0] < 0 && matrix[4] > 0)
-hflip = 1;
-else if (matrix[0] > 0 && matrix[4] < 0)
-vflip = 1;
-av_display_matrix_flip(matrix, hflip, vflip);
+for (i = 0; i < 9; i++)
+dmatrix[i] = matrix[i] / 65536.0;
+
+// Extract scale factors.
+scale_x = hypot(dmatrix[0], dmatrix[3]);
+scale_y = hypot(dmatrix[1], dmatrix[4]);
+
+// Select flips to make the main diagonal positive.
+hflip = dmatrix[0] < 0.0;
+vflip = dmatrix[4] < 0.0;
+if (hflip)
+scale_x = -scale_x;
+if (vflip)
+scale_y = -scale_y;
+
+// Rescale.
+for (i = 0; i < 9; i += 3) {
+dmatrix[i] /= scale_x;
+dmatrix[i + 1] /= scale_y;
+}
 
-angle = av_display_rotation_get(matrix);
+// Extract rotation.
+angle = atan2(dmatrix[3], dmatrix[0]);
 
-if (!(angle >= -180.0 && angle <= 180.0 /* also excludes NaN */) ||
-matrix[2] != 0 || matrix[5] != 0 ||
-matrix[6] != 0 || matrix[7] != 0) {
+if (!(angle >= -M_PI && angle <= M_PI) ||
+matrix[2] != 0.0 || matrix[5] != 0.0 ||
+matrix[6] != 0.0 || matrix[7] != 0.0) {
 av_log(bsf, AV_LOG_WARNING, "Input display matrix is not "
"representable in H.264 parameters.\n");
 } else {
@@ -421,8 +437,8 @@ static int 
h264_metadata_handle_display_orientation(AVBSFContext *bsf,
 disp->ver_flip = vflip;
 disp->anticlockwise_rotation =
 (uint16_t)rint((angle >= 0.0 ? angle
- : angle + 360.0) *
-   65536.0 / 360.0);
+ : angle + 2 * M_PI) *
+   32768.0 / M_PI);
 write = 1;
 }
 }
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 18/21] cbs_h265: Add functions to turn HDR metadata into SEI

[Mark Thompson]

---
 libavcodec/Makefile   |  2 +-
 libavcodec/cbs_h265.c | 99 +++
 libavcodec/cbs_h265.h | 18 
 3 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/cbs_h265.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0c4547f3a1..1ce079687b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -65,7 +65,7 @@ OBJS-$(CONFIG_CABAC)   += cabac.o
 OBJS-$(CONFIG_CBS) += cbs.o
 OBJS-$(CONFIG_CBS_AV1) += cbs_av1.o
 OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o cbs_h264.o h2645_parse.o
-OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o h2645_parse.o
+OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o cbs_h265.o h2645_parse.o
 OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
 OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
 OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
diff --git a/libavcodec/cbs_h265.c b/libavcodec/cbs_h265.c
new file mode 100644
index 00..590977cf00
--- /dev/null
+++ b/libavcodec/cbs_h265.c
@@ -0,0 +1,99 @@
+/*
+ * 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 "libavutil/mathematics.h"
+#include "libavutil/mastering_display_metadata.h"
+
+#include "cbs_h265.h"
+
+
+static uint32_t rescale_clip(AVRational value, uint32_t scale, uint32_t max)
+{
+int64_t scaled = av_rescale(scale, value.num, value.den);
+return av_clip64(scaled, 0, max);
+}
+
+static uint32_t rescale_fraction(AVRational value, uint32_t max)
+{
+return rescale_clip(value, max, max);
+}
+
+void 
ff_cbs_h265_fill_sei_mastering_display(H265RawSEIMasteringDisplayColourVolume 
*mdcv,
+const AVMasteringDisplayMetadata 
*mdm)
+{
+memset(mdcv, 0, sizeof(*mdcv));
+
+if (mdm->has_primaries) {
+// The values in the metadata structure are fractions between 0 and 1,
+// while the SEI message contains fixed-point values with an increment
+// of 0.2.  So, scale up by 5 to convert between them.
+
+for (int a = 0; a < 3; a++) {
+// The metadata structure stores this in RGB order, but the SEI
+// wants it in GBR order.
+int b = (a + 1) % 3;
+mdcv->display_primaries_x[a] =
+rescale_fraction(mdm->display_primaries[b][0], 5);
+mdcv->display_primaries_y[a] =
+rescale_fraction(mdm->display_primaries[b][1], 5);
+}
+
+mdcv->white_point_x = rescale_fraction(mdm->white_point[0], 5);
+mdcv->white_point_y = rescale_fraction(mdm->white_point[1], 5);
+}
+
+if (mdm->has_luminance) {
+// Metadata are rational values in candelas per square metre, SEI
+// contains fixed point in units of 0.0001 candelas per square
+// metre.  So scale up by 1 to convert between them, and clip to
+// ensure that we don't overflow.
+
+mdcv->max_display_mastering_luminance =
+rescale_clip(mdm->max_luminance, 1, UINT32_MAX);
+mdcv->min_display_mastering_luminance =
+rescale_clip(mdm->min_luminance, 1, UINT32_MAX);
+
+// The spec has a hard requirement that min is less than the max,
+// and the SEI-writing code enforces that.
+if (!(mdcv->min_display_mastering_luminance <
+  mdcv->max_display_mastering_luminance)) {
+if (mdcv->max_display_mastering_luminance == UINT32_MAX)
+mdcv->min_display_mastering_luminance =
+mdcv->max_display_mastering_luminance - 1;
+else
+mdcv->max_display_mastering_luminance =
+mdcv->min_display_mastering_luminance + 1;
+}
+} else {
+mdcv->max_display_mastering_luminance = 1;
+mdcv->min_display_mastering_luminance = 0;
+}
+}
+
+void ff_cbs_h265_fill_sei_content_light_level(H265RawSEIContentLightLevelInfo 
*cll,
+  const AVContentLightMetadata 
*clm)
+{
+memset(cll, 0, sizeof(*cll));
+
+// Both the metadata and the SEI are in units of candelas per square
+// metre, so we only need to clip to ensure that they are in the valid
+ 

[FFmpeg-devel] [PATCH v4 01/21] cbs: Mention all codecs in unit type comment

[Mark Thompson]

---
 libavcodec/cbs.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 9ca1fbd609..cb3081e2c6 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -45,8 +45,10 @@ struct CodedBitstreamType;
 /**
  * The codec-specific type of a bitstream unit.
  *
+ * AV1: obu_type
  * H.264 / AVC: nal_unit_type
  * H.265 / HEVC: nal_unit_type
+ * JPEG: marker value (without 0xff prefix)
  * MPEG-2: start code value (without prefix)
  * VP9: unused, set to zero (every unit is a frame)
  */
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 05/21] cbs_h264: Use table-based alloc/free

[Mark Thompson]

---
 libavcodec/cbs_h2645.c | 163 ++---
 1 file changed, 70 insertions(+), 93 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index c8347ba5fa..7e2cd4b00c 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -443,52 +443,6 @@ static int cbs_h2645_read_more_rbsp_data(GetBitContext 
*gbc)
 #undef allocate
 
 
-static void cbs_h264_free_pps(void *opaque, uint8_t *content)
-{
-H264RawPPS *pps = (H264RawPPS*)content;
-av_buffer_unref(&pps->slice_group_id_ref);
-av_freep(&content);
-}
-
-static void cbs_h264_free_sei_payload(H264RawSEIPayload *payload)
-{
-switch (payload->payload_type) {
-case H264_SEI_TYPE_BUFFERING_PERIOD:
-case H264_SEI_TYPE_PIC_TIMING:
-case H264_SEI_TYPE_PAN_SCAN_RECT:
-case H264_SEI_TYPE_RECOVERY_POINT:
-case H264_SEI_TYPE_DISPLAY_ORIENTATION:
-case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
-case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
-break;
-case H264_SEI_TYPE_USER_DATA_REGISTERED:
-av_buffer_unref(&payload->payload.user_data_registered.data_ref);
-break;
-case H264_SEI_TYPE_USER_DATA_UNREGISTERED:
-av_buffer_unref(&payload->payload.user_data_unregistered.data_ref);
-break;
-default:
-av_buffer_unref(&payload->payload.other.data_ref);
-break;
-}
-}
-
-static void cbs_h264_free_sei(void *opaque, uint8_t *content)
-{
-H264RawSEI *sei = (H264RawSEI*)content;
-int i;
-for (i = 0; i < sei->payload_count; i++)
-cbs_h264_free_sei_payload(&sei->payload[i]);
-av_freep(&content);
-}
-
-static void cbs_h264_free_slice(void *opaque, uint8_t *content)
-{
-H264RawSlice *slice = (H264RawSlice*)content;
-av_buffer_unref(&slice->data_ref);
-av_freep(&content);
-}
-
 static void cbs_h265_free_vps(void *opaque, uint8_t *content)
 {
 H265RawVPS *vps = (H265RawVPS*)content;
@@ -790,15 +744,14 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 if (err < 0)
 return err;
 
+err = ff_cbs_alloc_unit_content2(ctx, unit);
+if (err < 0)
+return err;
+
 switch (unit->type) {
 case H264_NAL_SPS:
 {
-H264RawSPS *sps;
-
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*sps), NULL);
-if (err < 0)
-return err;
-sps = unit->content;
+H264RawSPS *sps = unit->content;
 
 err = cbs_h264_read_sps(ctx, &gbc, sps);
 if (err < 0)
@@ -812,12 +765,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 case H264_NAL_SPS_EXT:
 {
-err = ff_cbs_alloc_unit_content(ctx, unit,
-sizeof(H264RawSPSExtension),
-NULL);
-if (err < 0)
-return err;
-
 err = cbs_h264_read_sps_extension(ctx, &gbc, unit->content);
 if (err < 0)
 return err;
@@ -826,13 +773,7 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 case H264_NAL_PPS:
 {
-H264RawPPS *pps;
-
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*pps),
-&cbs_h264_free_pps);
-if (err < 0)
-return err;
-pps = unit->content;
+H264RawPPS *pps = unit->content;
 
 err = cbs_h264_read_pps(ctx, &gbc, pps);
 if (err < 0)
@@ -848,15 +789,9 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 case H264_NAL_IDR_SLICE:
 case H264_NAL_AUXILIARY_SLICE:
 {
-H264RawSlice *slice;
+H264RawSlice *slice = unit->content;
 int pos, len;
 
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*slice),
-&cbs_h264_free_slice);
-if (err < 0)
-return err;
-slice = unit->content;
-
 err = cbs_h264_read_slice_header(ctx, &gbc, &slice->header);
 if (err < 0)
 return err;
@@ -882,11 +817,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 case H264_NAL_AUD:
 {
-err = ff_cbs_alloc_unit_content(ctx, unit,
-sizeof(H264RawAUD), NULL);
-if (err < 0)
-return err;
-
 err = cbs_h264_read_aud(ctx, &gbc, unit->content);
 if (err < 0)
 return err;
@@ -895,11 +825,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 case H264_NAL_SEI:
 {
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H264RawSEI),
-&cbs_h264_free_sei);
-if (err < 0)
-return err;
-
 err = cbs_h264_read_sei(ctx, &gbc, unit->content);

[FFmpeg-devel] [PATCH v4 16/21] cbs_h264: Add a function to turn stereo 3D metadata into SEI

[Mark Thompson]

---
 libavcodec/cbs_h264.c | 47 +++
 libavcodec/cbs_h264.h |  8 
 2 files changed, 55 insertions(+)

diff --git a/libavcodec/cbs_h264.c b/libavcodec/cbs_h264.c
index 75759c7f25..cc52f68550 100644
--- a/libavcodec/cbs_h264.c
+++ b/libavcodec/cbs_h264.c
@@ -16,6 +16,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/stereo3d.h"
+
 #include "cbs_h264.h"
 
 int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
@@ -104,3 +106,48 @@ void ff_cbs_h264_delete_sei_message(CodedBitstreamContext 
*ctx,
 (sei->payload_count - position) * sizeof(*sei->payload));
 }
 }
+
+void 
ff_cbs_h264_fill_sei_frame_packing_arrangement(H264RawSEIFramePackingArrangement
 *fp,
+const AVStereo3D *st)
+{
+static const int type_map[] = {
+[AV_STEREO3D_2D]  = 6,
+[AV_STEREO3D_SIDEBYSIDE]  = 3,
+[AV_STEREO3D_TOPBOTTOM]   = 4,
+[AV_STEREO3D_FRAMESEQUENCE]   = 5,
+[AV_STEREO3D_CHECKERBOARD]= 0,
+[AV_STEREO3D_SIDEBYSIDE_QUINCUNX] = 3,
+[AV_STEREO3D_LINES]   = 2,
+[AV_STEREO3D_COLUMNS] = 1,
+};
+
+memset(fp, 0, sizeof(*fp));
+
+if (st->type >= FF_ARRAY_ELEMS(type_map))
+return;
+
+fp->frame_packing_arrangement_type = type_map[st->type];
+
+fp->quincunx_sampling_flag =
+st->type == AV_STEREO3D_CHECKERBOARD ||
+st->type == AV_STEREO3D_SIDEBYSIDE_QUINCUNX;
+
+if (st->type == AV_STEREO3D_2D)
+fp->content_interpretation_type = 0;
+else if (st->flags & AV_STEREO3D_FLAG_INVERT)
+fp->content_interpretation_type = 2;
+else
+fp->content_interpretation_type = 1;
+
+if (st->type == AV_STEREO3D_FRAMESEQUENCE) {
+if (st->flags & AV_STEREO3D_FLAG_INVERT)
+fp->current_frame_is_frame0_flag =
+st->view == AV_STEREO3D_VIEW_RIGHT;
+else
+fp->current_frame_is_frame0_flag =
+st->view == AV_STEREO3D_VIEW_LEFT;
+}
+
+fp->frame_packing_arrangement_repetition_period =
+st->type != AV_STEREO3D_FRAMESEQUENCE;
+}
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 512674ec07..76211c976b 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -525,4 +525,12 @@ void ff_cbs_h264_delete_sei_message(CodedBitstreamContext 
*ctx,
 CodedBitstreamUnit *nal_unit,
 int position);
 
+struct AVStereo3D;
+/**
+ * Fill an SEI Frame Packing Arrangement structure with values derived from
+ * the AVStereo3D side-data structure.
+ */
+void 
ff_cbs_h264_fill_sei_frame_packing_arrangement(H264RawSEIFramePackingArrangement
 *fp,
+const struct AVStereo3D 
*st);
+
 #endif /* AVCODEC_CBS_H264_H */
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 11/21] cbs_av1: Use table-based alloc/free

[Mark Thompson]

---
 libavcodec/cbs_av1.c | 85 
 1 file changed, 39 insertions(+), 46 deletions(-)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 16eb7143b6..34b2634ece 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -812,50 +812,6 @@ fail:
 return err;
 }
 
-static void cbs_av1_free_tile_data(AV1RawTileData *td)
-{
-av_buffer_unref(&td->data_ref);
-}
-
-static void cbs_av1_free_padding(AV1RawPadding *pd)
-{
-av_buffer_unref(&pd->payload_ref);
-}
-
-static void cbs_av1_free_metadata(AV1RawMetadata *md)
-{
-switch (md->metadata_type) {
-case AV1_METADATA_TYPE_ITUT_T35:
-av_buffer_unref(&md->metadata.itut_t35.payload_ref);
-break;
-}
-}
-
-static void cbs_av1_free_obu(void *opaque, uint8_t *content)
-{
-AV1RawOBU *obu = (AV1RawOBU*)content;
-
-switch (obu->header.obu_type) {
-case AV1_OBU_TILE_GROUP:
-cbs_av1_free_tile_data(&obu->obu.tile_group.tile_data);
-break;
-case AV1_OBU_FRAME:
-cbs_av1_free_tile_data(&obu->obu.frame.tile_group.tile_data);
-break;
-case AV1_OBU_TILE_LIST:
-cbs_av1_free_tile_data(&obu->obu.tile_list.tile_data);
-break;
-case AV1_OBU_METADATA:
-cbs_av1_free_metadata(&obu->obu.metadata);
-break;
-case AV1_OBU_PADDING:
-cbs_av1_free_padding(&obu->obu.padding);
-break;
-}
-
-av_freep(&obu);
-}
-
 static int cbs_av1_ref_tile_data(CodedBitstreamContext *ctx,
  CodedBitstreamUnit *unit,
  GetBitContext *gbc,
@@ -890,8 +846,7 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
 GetBitContext gbc;
 int err, start_pos, end_pos;
 
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*obu),
-&cbs_av1_free_obu);
+err = ff_cbs_alloc_unit_content2(ctx, unit);
 if (err < 0)
 return err;
 obu = unit->content;
@@ -1260,11 +1215,49 @@ static void cbs_av1_close(CodedBitstreamContext *ctx)
 av_buffer_unref(&priv->frame_header_ref);
 }
 
+static void cbs_av1_free_metadata(void *unit, uint8_t *content)
+{
+AV1RawOBU *obu = (AV1RawOBU*)content;
+AV1RawMetadata *md;
+
+av_assert0(obu->header.obu_type == AV1_OBU_METADATA);
+md = &obu->obu.metadata;
+
+switch (md->metadata_type) {
+case AV1_METADATA_TYPE_ITUT_T35:
+av_buffer_unref(&md->metadata.itut_t35.payload_ref);
+break;
+}
+}
+
+static const CodedBitstreamUnitTypeDescriptor cbs_av1_unit_types[] = {
+CBS_UNIT_TYPE_POD(AV1_OBU_SEQUENCE_HEADER,AV1RawOBU),
+CBS_UNIT_TYPE_POD(AV1_OBU_TEMPORAL_DELIMITER, AV1RawOBU),
+CBS_UNIT_TYPE_POD(AV1_OBU_FRAME_HEADER,   AV1RawOBU),
+CBS_UNIT_TYPE_POD(AV1_OBU_REDUNDANT_FRAME_HEADER, AV1RawOBU),
+
+CBS_UNIT_TYPE_INTERNAL_REF(AV1_OBU_TILE_GROUP, AV1RawOBU,
+   obu.tile_group.tile_data.data),
+CBS_UNIT_TYPE_INTERNAL_REF(AV1_OBU_FRAME,  AV1RawOBU,
+   obu.frame.tile_group.tile_data.data),
+CBS_UNIT_TYPE_INTERNAL_REF(AV1_OBU_TILE_LIST,  AV1RawOBU,
+   obu.tile_list.tile_data.data),
+CBS_UNIT_TYPE_INTERNAL_REF(AV1_OBU_PADDING,AV1RawOBU,
+   obu.padding.payload),
+
+CBS_UNIT_TYPE_COMPLEX(AV1_OBU_METADATA, AV1RawOBU,
+  &cbs_av1_free_metadata),
+
+CBS_UNIT_TYPE_END_OF_LIST
+};
+
 const CodedBitstreamType ff_cbs_type_av1 = {
 .codec_id  = AV_CODEC_ID_AV1,
 
 .priv_data_size= sizeof(CodedBitstreamAV1Context),
 
+.unit_types= cbs_av1_unit_types,
+
 .split_fragment= &cbs_av1_split_fragment,
 .read_unit = &cbs_av1_read_unit,
 .write_unit= &cbs_av1_write_obu,
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 09/21] cbs_h265: Use table-based alloc/free

[Mark Thompson]

---
 libavcodec/cbs_h2645.c | 198 +++--
 1 file changed, 94 insertions(+), 104 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 84cb70b863..62d253d042 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -443,71 +443,6 @@ static int cbs_h2645_read_more_rbsp_data(GetBitContext 
*gbc)
 #undef allocate
 
 
-static void cbs_h265_free_vps(void *opaque, uint8_t *content)
-{
-H265RawVPS *vps = (H265RawVPS*)content;
-av_buffer_unref(&vps->extension_data.data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_sps(void *opaque, uint8_t *content)
-{
-H265RawSPS *sps = (H265RawSPS*)content;
-av_buffer_unref(&sps->extension_data.data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_pps(void *opaque, uint8_t *content)
-{
-H265RawPPS *pps = (H265RawPPS*)content;
-av_buffer_unref(&pps->extension_data.data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_slice(void *opaque, uint8_t *content)
-{
-H265RawSlice *slice = (H265RawSlice*)content;
-av_buffer_unref(&slice->data_ref);
-av_freep(&content);
-}
-
-static void cbs_h265_free_sei_payload(H265RawSEIPayload *payload)
-{
-switch (payload->payload_type) {
-case HEVC_SEI_TYPE_BUFFERING_PERIOD:
-case HEVC_SEI_TYPE_PICTURE_TIMING:
-case HEVC_SEI_TYPE_PAN_SCAN_RECT:
-case HEVC_SEI_TYPE_RECOVERY_POINT:
-case HEVC_SEI_TYPE_DISPLAY_ORIENTATION:
-case HEVC_SEI_TYPE_ACTIVE_PARAMETER_SETS:
-case HEVC_SEI_TYPE_DECODED_PICTURE_HASH:
-case HEVC_SEI_TYPE_TIME_CODE:
-case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
-case HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
-case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
-case HEVC_SEI_TYPE_ALPHA_CHANNEL_INFO:
-break;
-case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
-av_buffer_unref(&payload->payload.user_data_registered.data_ref);
-break;
-case HEVC_SEI_TYPE_USER_DATA_UNREGISTERED:
-av_buffer_unref(&payload->payload.user_data_unregistered.data_ref);
-break;
-default:
-av_buffer_unref(&payload->payload.other.data_ref);
-break;
-}
-}
-
-static void cbs_h265_free_sei(void *opaque, uint8_t *content)
-{
-H265RawSEI *sei = (H265RawSEI*)content;
-int i;
-for (i = 0; i < sei->payload_count; i++)
-cbs_h265_free_sei_payload(&sei->payload[i]);
-av_freep(&content);
-}
-
 static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
const H2645Packet *packet)
@@ -869,16 +804,14 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 if (err < 0)
 return err;
 
+err = ff_cbs_alloc_unit_content2(ctx, unit);
+if (err < 0)
+return err;
+
 switch (unit->type) {
 case HEVC_NAL_VPS:
 {
-H265RawVPS *vps;
-
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*vps),
-&cbs_h265_free_vps);
-if (err < 0)
-return err;
-vps = unit->content;
+H265RawVPS *vps = unit->content;
 
 err = cbs_h265_read_vps(ctx, &gbc, vps);
 if (err < 0)
@@ -891,13 +824,7 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 break;
 case HEVC_NAL_SPS:
 {
-H265RawSPS *sps;
-
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*sps),
-&cbs_h265_free_sps);
-if (err < 0)
-return err;
-sps = unit->content;
+H265RawSPS *sps = unit->content;
 
 err = cbs_h265_read_sps(ctx, &gbc, sps);
 if (err < 0)
@@ -911,13 +838,7 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 
 case HEVC_NAL_PPS:
 {
-H265RawPPS *pps;
-
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*pps),
-&cbs_h265_free_pps);
-if (err < 0)
-return err;
-pps = unit->content;
+H265RawPPS *pps = unit->content;
 
 err = cbs_h265_read_pps(ctx, &gbc, pps);
 if (err < 0)
@@ -946,15 +867,9 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 case HEVC_NAL_IDR_N_LP:
 case HEVC_NAL_CRA_NUT:
 {
-H265RawSlice *slice;
+H265RawSlice *slice = unit->content;
 int pos, len;
 
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*slice),
-&cbs_h265_free_slice);
-if (err < 0)
-return err;
-slice = unit->content;
-
 err = cbs_h265_read_slice_segment_header(ctx, &gbc, 
&slice->header);
 if (err < 0)
 return err;
@@ -

[FFmpeg-devel] [PATCH v4 07/21] cbs_h2645: Ensure that non-refcounted parameter sets are fully copied

[Mark Thompson]

Only copying the main structure is not necessarily sufficient - there
could be references to substructures.
---
 libavcodec/cbs_h2645.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 7e2cd4b00c..84cb70b863 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -708,18 +708,20 @@ static int cbs_h26 ## h26n ## _replace_ ## 
ps_var(CodedBitstreamContext *ctx, \
 CodedBitstreamH26 ## h26n ## Context *priv = ctx->priv_data; \
 H26 ## h26n ## Raw ## ps_name *ps_var = unit->content; \
 unsigned int id = ps_var->id_element; \
+int err; \
 if (id >= FF_ARRAY_ELEMS(priv->ps_var)) { \
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid " #ps_name \
" id : %d.\n", id); \
 return AVERROR_INVALIDDATA; \
 } \
+err = ff_cbs_make_unit_refcounted(ctx, unit); \
+if (err < 0) \
+return err; \
 if (priv->ps_var[id] == priv->active_ ## ps_var) \
 priv->active_ ## ps_var = NULL ; \
 av_buffer_unref(&priv->ps_var ## _ref[id]); \
-if (unit->content_ref) \
-priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
-else \
-priv->ps_var ## _ref[id] = av_buffer_alloc(sizeof(*ps_var)); \
+av_assert0(unit->content_ref); \
+priv->ps_var ## _ref[id] = av_buffer_ref(unit->content_ref); \
 if (!priv->ps_var ## _ref[id]) \
 return AVERROR(ENOMEM); \
 priv->ps_var[id] = (H26 ## h26n ## Raw ## ps_name *)priv->ps_var ## 
_ref[id]->data; \
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 13/21] cbs: Expose the function to insert a new empty unit into a fragment

[Mark Thompson]

This will be helpful when adding new SEI to an existing access unit.
---
 libavcodec/cbs.c | 10 +-
 libavcodec/cbs.h |  7 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 91788f6dfb..12a742b40a 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -680,9 +680,9 @@ int ff_cbs_alloc_unit_data(CodedBitstreamContext *ctx,
 return 0;
 }
 
-static int cbs_insert_unit(CodedBitstreamContext *ctx,
-   CodedBitstreamFragment *frag,
-   int position)
+int ff_cbs_insert_unit(CodedBitstreamContext *ctx,
+   CodedBitstreamFragment *frag,
+   int position)
 {
 CodedBitstreamUnit *units;
 
@@ -742,7 +742,7 @@ int ff_cbs_insert_unit_content(CodedBitstreamContext *ctx,
 content_ref = NULL;
 }
 
-err = cbs_insert_unit(ctx, frag, position);
+err = ff_cbs_insert_unit(ctx, frag, position);
 if (err < 0) {
 av_buffer_unref(&content_ref);
 return err;
@@ -781,7 +781,7 @@ int ff_cbs_insert_unit_data(CodedBitstreamContext *ctx,
 return AVERROR(ENOMEM);
 }
 
-err = cbs_insert_unit(ctx, frag, position);
+err = ff_cbs_insert_unit(ctx, frag, position);
 if (err < 0) {
 av_buffer_unref(&data_ref);
 return err;
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index eb7f4b878b..09b06a047d 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -370,6 +370,13 @@ int ff_cbs_alloc_unit_data(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit,
size_t size);
 
+/**
+ * Insert a new empty unit into a fragment.
+ */
+int ff_cbs_insert_unit(CodedBitstreamContext *ctx,
+   CodedBitstreamFragment *frag,
+   int position);
+
 /**
  * Insert a new unit into a fragment with the given content.
  *
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 08/21] h264_redundant_pps: Make it reference-compatible

[Mark Thompson]

From: Andreas Rheinhardt 

Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were parsed. This patch makes h264_redundant_pps
compatible with the reality of reference-counted parameter sets.

Signed-off-by: Andreas Rheinhardt 
Signed-off-by: Mark Thompson 
---
 libavcodec/h264_redundant_pps_bsf.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264_redundant_pps_bsf.c 
b/libavcodec/h264_redundant_pps_bsf.c
index 8405738c4b..4d5dd9a90f 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -40,8 +40,19 @@ typedef struct H264RedundantPPSContext {
 
 
 static int h264_redundant_pps_fixup_pps(H264RedundantPPSContext *ctx,
-H264RawPPS *pps)
+CodedBitstreamUnit *unit)
 {
+H264RawPPS *pps;
+int err;
+
+// The changes we are about to perform affect the parsing process,
+// so we must make sure that the PPS is writable, otherwise the
+// parsing of future slices will be incorrect and even raise errors.
+err = ff_cbs_make_unit_writable(ctx->input, unit);
+if (err < 0)
+return err;
+pps = unit->content;
+
 // Record the current value of pic_init_qp in order to fix up
 // following slices, then overwrite with the global value.
 ctx->current_pic_init_qp = pps->pic_init_qp_minus26 + 26;
@@ -88,7 +99,7 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf, 
AVPacket *pkt)
 if (nal->type == H264_NAL_SPS)
 au_has_sps = 1;
 if (nal->type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, nal->content);
+err = h264_redundant_pps_fixup_pps(ctx, nal);
 if (err < 0)
 goto fail;
 if (!au_has_sps) {
@@ -144,7 +155,7 @@ static int h264_redundant_pps_init(AVBSFContext *bsf)
 
 for (i = 0; i < au->nb_units; i++) {
 if (au->units[i].type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, au->units[i].content);
+err = h264_redundant_pps_fixup_pps(ctx, &au->units[i]);
 if (err < 0)
 goto fail;
 }
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 04/21] cbs: Add macros to support defining unit type tables

[Mark Thompson]

---
 libavcodec/cbs_internal.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 615f514a85..2922878ed0 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -166,6 +166,30 @@ int ff_cbs_write_signed(CodedBitstreamContext *ctx, 
PutBitContext *pbc,
 #define MIN_INT_BITS(length) (-(INT64_C(1) << ((length) - 1)))
 
 
+#define CBS_UNIT_TYPE_POD(type, structure) { \
+.nb_unit_types  = 1, \
+.unit_types = { type }, \
+.content_type   = CBS_CONTENT_TYPE_POD, \
+.content_size   = sizeof(structure), \
+}
+#define CBS_UNIT_TYPE_INTERNAL_REF(type, structure, ref_field) { \
+.nb_unit_types  = 1, \
+.unit_types = { type }, \
+.content_type   = CBS_CONTENT_TYPE_INTERNAL_REFS, \
+.content_size   = sizeof(structure), \
+.nb_ref_offsets = 1, \
+.ref_offsets= { offsetof(structure, ref_field) }, \
+}
+#define CBS_UNIT_TYPE_COMPLEX(type, structure, free_func) { \
+.nb_unit_types  = 1, \
+.unit_types = { type }, \
+.content_type   = CBS_CONTENT_TYPE_COMPLEX, \
+.content_size   = sizeof(structure), \
+.content_free   = free_func, \
+}
+#define CBS_UNIT_TYPE_END_OF_LIST { .nb_unit_types = 0 }
+
+
 extern const CodedBitstreamType ff_cbs_type_av1;
 extern const CodedBitstreamType ff_cbs_type_h264;
 extern const CodedBitstreamType ff_cbs_type_h265;
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 10/21] cbs_vp9: Use table-based alloc/free

[Mark Thompson]

---
 libavcodec/cbs_vp9.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index ec82f11c76..343bf51275 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -480,13 +480,6 @@ static int cbs_vp9_split_fragment(CodedBitstreamContext 
*ctx,
 return 0;
 }
 
-static void cbs_vp9_free_frame(void *opaque, uint8_t *content)
-{
-VP9RawFrame *frame = (VP9RawFrame*)content;
-av_buffer_unref(&frame->data_ref);
-av_freep(&frame);
-}
-
 static int cbs_vp9_read_unit(CodedBitstreamContext *ctx,
  CodedBitstreamUnit *unit)
 {
@@ -498,8 +491,7 @@ static int cbs_vp9_read_unit(CodedBitstreamContext *ctx,
 if (err < 0)
 return err;
 
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*frame),
-&cbs_vp9_free_frame);
+err = ff_cbs_alloc_unit_content2(ctx, unit);
 if (err < 0)
 return err;
 frame = unit->content;
@@ -643,11 +635,18 @@ static int 
cbs_vp9_assemble_fragment(CodedBitstreamContext *ctx,
 return 0;
 }
 
+static const CodedBitstreamUnitTypeDescriptor cbs_vp9_unit_types[] = {
+CBS_UNIT_TYPE_INTERNAL_REF(0, VP9RawFrame, data),
+CBS_UNIT_TYPE_END_OF_LIST
+};
+
 const CodedBitstreamType ff_cbs_type_vp9 = {
 .codec_id  = AV_CODEC_ID_VP9,
 
 .priv_data_size= sizeof(CodedBitstreamVP9Context),
 
+.unit_types= cbs_vp9_unit_types,
+
 .split_fragment= &cbs_vp9_split_fragment,
 .read_unit = &cbs_vp9_read_unit,
 .write_unit= &cbs_vp9_write_unit,
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 02/21] cbs: Ensure that reference fields always follow the associated pointer

[Mark Thompson]

Hvaing these together allows us to find both pointers given the address
of only one of them.
---
 libavcodec/cbs_av1.h   |  6 +++---
 libavcodec/cbs_h264.h  | 18 +-
 libavcodec/cbs_h265.h  | 16 
 libavcodec/cbs_jpeg.h  |  2 +-
 libavcodec/cbs_mpeg2.h | 10 +-
 libavcodec/cbs_vp9.h   |  2 +-
 6 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index fdc629b00c..8925c45772 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -284,8 +284,8 @@ typedef struct AV1RawFrameHeader {
 
 typedef struct AV1RawTileData {
 uint8_t *data;
-size_t   data_size;
 AVBufferRef *data_ref;
+size_t   data_size;
 } AV1RawTileData;
 
 typedef struct AV1RawTileGroup {
@@ -346,8 +346,8 @@ typedef struct AV1RawMetadataITUTT35 {
 uint8_t itu_t_t35_country_code_extension_byte;
 
 uint8_t *payload;
-size_t   payload_size;
 AVBufferRef *payload_ref;
+size_t   payload_size;
 } AV1RawMetadataITUTT35;
 
 typedef struct AV1RawMetadataTimecode {
@@ -379,8 +379,8 @@ typedef struct AV1RawMetadata {
 
 typedef struct AV1RawPadding {
 uint8_t *payload;
-size_t   payload_size;
 AVBufferRef *payload_ref;
+size_t   payload_size;
 } AV1RawPadding;
 
 
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 9f7c2a0d30..65659ae52c 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -277,16 +277,16 @@ typedef struct H264RawSEIPanScanRect {
 typedef struct H264RawSEIUserDataRegistered {
 uint8_t itu_t_t35_country_code;
 uint8_t itu_t_t35_country_code_extension_byte;
-uint8_t *data;
-size_t data_length;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_length;
 } H264RawSEIUserDataRegistered;
 
 typedef struct H264RawSEIUserDataUnregistered {
 uint8_t uuid_iso_iec_11578[16];
-uint8_t *data;
-size_t data_length;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_length;
 } H264RawSEIUserDataUnregistered;
 
 typedef struct H264RawSEIRecoveryPoint {
@@ -334,9 +334,9 @@ typedef struct H264RawSEIPayload {
 H264RawSEIAlternativeTransferCharacteristics
 alternative_transfer_characteristics;
 struct {
-uint8_t *data;
-size_t data_length;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_length;
 } other;
 } payload;
 } H264RawSEIPayload;
@@ -429,10 +429,10 @@ typedef struct H264RawSliceHeader {
 typedef struct H264RawSlice {
 H264RawSliceHeader header;
 
-uint8_t *data;
-size_t   data_size;
-int  data_bit_start;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_size;
+int  data_bit_start;
 } H264RawSlice;
 
 typedef struct H264RawFiller {
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index ad746bf35f..f5eb5af5b2 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -184,8 +184,8 @@ typedef struct H265RawVUI {
 
 typedef struct H265RawPSExtensionData {
 uint8_t *data;
-size_t bit_length;
 AVBufferRef *data_ref;
+size_t bit_length;
 } H265RawPSExtensionData;
 
 typedef struct H265RawVPS {
@@ -541,10 +541,10 @@ typedef struct  H265RawSliceHeader {
 typedef struct H265RawSlice {
 H265RawSliceHeader header;
 
-uint8_t *data;
-size_t   data_size;
-int  data_bit_start;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_size;
+int  data_bit_start;
 } H265RawSlice;
 
 
@@ -600,15 +600,15 @@ typedef struct H265RawSEIUserDataRegistered {
 uint8_t itu_t_t35_country_code;
 uint8_t itu_t_t35_country_code_extension_byte;
 uint8_t *data;
-size_t   data_length;
 AVBufferRef *data_ref;
+size_t   data_length;
 } H265RawSEIUserDataRegistered;
 
 typedef struct H265RawSEIUserDataUnregistered {
 uint8_t uuid_iso_iec_11578[16];
 uint8_t *data;
-size_t   data_length;
 AVBufferRef *data_ref;
+size_t   data_length;
 } H265RawSEIUserDataUnregistered;
 
 typedef struct H265RawSEIRecoveryPoint {
@@ -710,9 +710,9 @@ typedef struct H265RawSEIPayload {
 alternative_transfer_characteristics;
 H265RawSEIAlphaChannelInfo alpha_channel_info;
 struct {
-uint8_t *data;
-size_t data_length;
+uint8_t *data;
 AVBufferRef *data_ref;
+size_t   data_length;
 } other;
 } payload;
 } H265RawSEIPayload;
diff --git a/libavcodec/cbs_jpeg.h b/libavcodec/cbs_jpeg.h
index ff1961106f..6305f0ee86 100644
--- a/libavcodec/cbs_jpeg.h
+++ b/libavcodec/cbs_jpeg.h
@@ -80,8 +80,8 @@ typedef struct JPEGRawScanHeader {
 typedef struct JPEGRawScan {
 JPEGRawScanHeader header;
 uint8_t  *data;
-size_tdata_size;
 AVBufferRef  *data_ref;
+size_tdata_

[FFmpeg-devel] [PATCH v4 14/21] cbs_h264: Simplify SEI addition

[Mark Thompson]

At the same time, move the H.264 SEI functions to a new file - the combined
H.26[45] CBS file is already very large, and these functions do not require
any of the common read/write elements.
---
 libavcodec/Makefile|   2 +-
 libavcodec/cbs_h264.c  | 106 +
 libavcodec/cbs_h264.h  |  11 +
 libavcodec/cbs_h2645.c |  96 +
 4 files changed, 120 insertions(+), 95 deletions(-)
 create mode 100644 libavcodec/cbs_h264.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 12704af6bd..0c4547f3a1 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -64,7 +64,7 @@ OBJS-$(CONFIG_BSWAPDSP)+= bswapdsp.o
 OBJS-$(CONFIG_CABAC)   += cabac.o
 OBJS-$(CONFIG_CBS) += cbs.o
 OBJS-$(CONFIG_CBS_AV1) += cbs_av1.o
-OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o h2645_parse.o
+OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o cbs_h264.o h2645_parse.o
 OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o h2645_parse.o
 OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
 OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
diff --git a/libavcodec/cbs_h264.c b/libavcodec/cbs_h264.c
new file mode 100644
index 00..75759c7f25
--- /dev/null
+++ b/libavcodec/cbs_h264.c
@@ -0,0 +1,106 @@
+/*
+ * 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 "cbs_h264.h"
+
+int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *au,
+H264RawSEIPayload *payload)
+{
+H264RawSEI *sei = NULL;
+int err, i;
+
+// Find an existing SEI NAL unit to add to.
+for (i = 0; i < au->nb_units; i++) {
+if (au->units[i].type == H264_NAL_SEI) {
+sei = au->units[i].content;
+if (sei->payload_count < H264_MAX_SEI_PAYLOADS)
+break;
+
+sei = NULL;
+}
+}
+
+if (!sei) {
+// Need to make a new SEI NAL unit.  Insert it before the first
+// slice data NAL unit; if no slice data, add at the end.
+CodedBitstreamUnit *unit;
+
+for (i = 0; i < au->nb_units; i++) {
+if (au->units[i].type == H264_NAL_SLICE ||
+au->units[i].type == H264_NAL_IDR_SLICE)
+break;
+}
+
+err = ff_cbs_insert_unit(ctx, au, i);
+if (err < 0)
+goto fail;
+unit = &au->units[i];
+
+err = ff_cbs_alloc_unit_content2(ctx, unit);
+if (err < 0) {
+ff_cbs_delete_unit(ctx, au, i);
+goto fail;
+}
+sei = unit->content;
+
+*sei = (H264RawSEI) {
+.nal_unit_header = {
+.nal_unit_type = H264_NAL_SEI,
+},
+};
+}
+
+memcpy(&sei->payload[sei->payload_count], payload, sizeof(*payload));
+++sei->payload_count;
+
+return 0;
+fail:
+ff_cbs_h264_free_sei_payload(payload);
+return err;
+}
+
+void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
+CodedBitstreamFragment *au,
+CodedBitstreamUnit *nal,
+int position)
+{
+H264RawSEI *sei = nal->content;
+
+av_assert0(nal->type == H264_NAL_SEI);
+av_assert0(position >= 0 && position < sei->payload_count);
+
+if (position == 0 && sei->payload_count == 1) {
+// Deleting NAL unit entirely.
+int i;
+
+for (i = 0; i < au->nb_units; i++) {
+if (&au->units[i] == nal)
+break;
+}
+
+ff_cbs_delete_unit(ctx, au, i);
+} else {
+ff_cbs_h264_free_sei_payload(&sei->payload[position]);
+
+--sei->payload_count;
+memmove(sei->payload + position,
+sei->payload + position + 1,
+(sei->payload_count - position) * sizeof(*sei->payload));
+}
+}
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 65659ae52c..abc0c1b732 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -466,11 +466,22 @@ typedef struct CodedBitstreamH264Context {
 } CodedBitstreamH264Context;
 
 
+/**
+ * Free an SEI payload

[FFmpeg-devel] [PATCH v4 06/21] cbs: Add support functions for handling unit content references

[Mark Thompson]

Use the unit type table to determine what we need to do to clone the
internals of the unit content when making copies for refcounting or
writeability.  (This will still fail for units with complex content
if they do not have a defined clone function.)

Setup and naming from a patch by Andreas Rheinhardt
, but with the implementation
changed to use the unit type information if possible rather than
requiring a codec-specific function.
---
 libavcodec/cbs.c  | 172 ++
 libavcodec/cbs.h  |  29 +++
 libavcodec/cbs_internal.h |   1 +
 3 files changed, 202 insertions(+)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 6cc559e545..91788f6dfb 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -881,3 +881,175 @@ int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
 
 return 0;
 }
+
+static int cbs_clone_unit_content(AVBufferRef **clone_ref,
+  CodedBitstreamUnit *unit,
+  const CodedBitstreamUnitTypeDescriptor *desc)
+{
+uint8_t *src, *copy;
+uint8_t **src_ptr, **copy_ptr;
+AVBufferRef **src_buf, **copy_buf;
+int err, i;
+
+av_assert0(unit->content);
+src = unit->content;
+
+copy = av_malloc(desc->content_size);
+if (!copy)
+return AVERROR(ENOMEM);
+
+memcpy(copy, src, desc->content_size);
+
+for (i = 0; i < desc->nb_ref_offsets; i++) {
+src_ptr  = (uint8_t**)(src + desc->ref_offsets[i]);
+src_buf  = (AVBufferRef**)(src_ptr + 1);
+copy_ptr = (uint8_t**)(copy + desc->ref_offsets[i]);
+copy_buf = (AVBufferRef**)(copy_ptr + 1);
+
+if (!*src_ptr) {
+av_assert0(!*src_buf);
+continue;
+}
+if (!*src_buf) {
+// We can't handle a non-refcounted pointer here - we don't
+// have enough information to handle whatever structure lies
+// at the other end of it.
+err = AVERROR(EINVAL);
+goto fail;
+}
+
+// src_ptr is required to point somewhere inside src_buf.  If it
+// doesn't, there is a bug somewhere.
+av_assert0(*src_ptr >= (*src_buf)->data &&
+   *src_ptr <  (*src_buf)->data + (*src_buf)->size);
+
+*copy_buf = av_buffer_ref(*src_buf);
+if (!*copy_buf) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+err = av_buffer_make_writable(copy_buf);
+if (err < 0) {
+av_buffer_unref(copy_buf);
+goto fail;
+}
+
+*copy_ptr = (*copy_buf)->data + (*src_ptr - (*src_buf)->data);
+}
+
+*clone_ref = av_buffer_create(copy, desc->content_size,
+  desc->content_free ? desc->content_free :
+  cbs_default_free_unit_content,
+  (void*)desc, 0);
+if (!*clone_ref) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+return 0;
+
+fail:
+for (--i; i >= 0; i--)
+av_buffer_unref((AVBufferRef**)(copy + desc->ref_offsets[i]));
+av_freep(©);
+*clone_ref = NULL;
+return err;
+}
+
+int ff_cbs_make_unit_refcounted(CodedBitstreamContext *ctx,
+CodedBitstreamUnit *unit)
+{
+const CodedBitstreamUnitTypeDescriptor *desc;
+AVBufferRef *ref;
+int err;
+
+av_assert0(unit->content);
+if (unit->content_ref) {
+// Already refcounted, nothing to do.
+return 0;
+}
+
+desc = cbs_find_unit_type_desc(ctx, unit);
+if (!desc)
+return AVERROR(ENOSYS);
+
+switch (desc->content_type) {
+case CBS_CONTENT_TYPE_POD:
+ref = av_buffer_alloc(desc->content_size);
+if (!ref)
+return AVERROR(ENOMEM);
+memcpy(ref->data, unit->content, desc->content_size);
+err = 0;
+break;
+
+case CBS_CONTENT_TYPE_INTERNAL_REFS:
+err = cbs_clone_unit_content(&ref, unit, desc);
+break;
+
+case CBS_CONTENT_TYPE_COMPLEX:
+if (!desc->content_clone)
+return AVERROR_PATCHWELCOME;
+err = desc->content_clone(&ref, unit);
+break;
+
+default:
+av_assert0(0 && "Invalid content type.");
+}
+
+if (err < 0)
+return err;
+
+unit->content_ref = ref;
+unit->content = ref->data;
+return 0;
+}
+
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+  CodedBitstreamUnit *unit)
+{
+const CodedBitstreamUnitTypeDescriptor *desc;
+AVBufferRef *ref;
+int err;
+
+// This can only be applied to refcounted units.
+err = ff_cbs_make_unit_refcounted(ctx, unit);
+if (err < 0)
+return err;
+av_assert0(unit->content && unit->content_ref);
+
+if (av_buffer_is_writable(unit->content_ref))
+return 0;
+
+desc = cbs_find_unit_type_desc(ctx, unit);
+if (!desc)
+return AVERROR(ENOSYS);
+
+   

[FFmpeg-devel] [PATCH v4 15/21] cbs_h264: Add support for frame packing arrangement SEI messages

[Mark Thompson]

---
 libavcodec/cbs_h264.h | 24 
 libavcodec/cbs_h2645.c|  1 +
 libavcodec/cbs_h264_syntax_template.c | 40 +++
 3 files changed, 65 insertions(+)

diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index abc0c1b732..512674ec07 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -296,6 +296,29 @@ typedef struct H264RawSEIRecoveryPoint {
 uint8_t changing_slice_group_idc;
 } H264RawSEIRecoveryPoint;
 
+typedef struct H264RawSEIFramePackingArrangement {
+uint32_t frame_packing_arrangement_id;
+uint8_t  frame_packing_arrangement_cancel_flag;
+
+uint8_t  frame_packing_arrangement_type;
+uint8_t  quincunx_sampling_flag;
+uint8_t  content_interpretation_type;
+uint8_t  spatial_flipping_flag;
+uint8_t  frame0_flipped_flag;
+uint8_t  field_views_flag;
+uint8_t  current_frame_is_frame0_flag;
+uint8_t  frame0_self_contained_flag;
+uint8_t  frame1_self_contained_flag;
+uint8_t  frame0_grid_position_x;
+uint8_t  frame0_grid_position_y;
+uint8_t  frame1_grid_position_x;
+uint8_t  frame1_grid_position_y;
+uint8_t  frame_packing_arrangement_reserved_byte;
+uint16_t frame_packing_arrangement_repetition_period;
+
+uint8_t  frame_packing_arrangement_extension_flag;
+} H264RawSEIFramePackingArrangement;
+
 typedef struct H264RawSEIDisplayOrientation {
 uint8_t display_orientation_cancel_flag;
 uint8_t hor_flip;
@@ -329,6 +352,7 @@ typedef struct H264RawSEIPayload {
 H264RawSEIUserDataRegistered user_data_registered;
 H264RawSEIUserDataUnregistered user_data_unregistered;
 H264RawSEIRecoveryPoint recovery_point;
+H264RawSEIFramePackingArrangement frame_packing_arrangement;
 H264RawSEIDisplayOrientation display_orientation;
 H264RawSEIMasteringDisplayColourVolume mastering_display_colour_volume;
 H264RawSEIAlternativeTransferCharacteristics
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index f0bd5cacc8..8cea55509b 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1328,6 +1328,7 @@ void ff_cbs_h264_free_sei_payload(H264RawSEIPayload 
*payload)
 case H264_SEI_TYPE_PIC_TIMING:
 case H264_SEI_TYPE_PAN_SCAN_RECT:
 case H264_SEI_TYPE_RECOVERY_POINT:
+case H264_SEI_TYPE_FRAME_PACKING:
 case H264_SEI_TYPE_DISPLAY_ORIENTATION:
 case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
 case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index 878d348b94..e68944d3b8 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -779,6 +779,42 @@ static int FUNC(sei_recovery_point)(CodedBitstreamContext 
*ctx, RWContext *rw,
 return 0;
 }
 
+static int FUNC(sei_frame_packing_arrangement)(CodedBitstreamContext *ctx, 
RWContext *rw,
+   
H264RawSEIFramePackingArrangement *current)
+{
+int err;
+
+HEADER("Frame Packing Arrangement");
+
+ue(frame_packing_arrangement_id, 0, UINT32_MAX - 1);
+flag(frame_packing_arrangement_cancel_flag);
+
+if (!current->frame_packing_arrangement_cancel_flag) {
+u(7, frame_packing_arrangement_type, 0, 7);
+flag(quincunx_sampling_flag);
+u(6, content_interpretation_type, 0, 2);
+flag(spatial_flipping_flag);
+flag(frame0_flipped_flag);
+flag(field_views_flag);
+flag(current_frame_is_frame0_flag);
+flag(frame0_self_contained_flag);
+flag(frame1_self_contained_flag);
+if (!current->quincunx_sampling_flag &&
+current->frame_packing_arrangement_type != 5) {
+ub(4, frame0_grid_position_x);
+ub(4, frame0_grid_position_y);
+ub(4, frame1_grid_position_x);
+ub(4, frame1_grid_position_y);
+}
+u(8, frame_packing_arrangement_reserved_byte, 0, 0);
+ue(frame_packing_arrangement_repetition_period, 0, 16384);
+}
+
+flag(frame_packing_arrangement_extension_flag);
+
+return 0;
+}
+
 static int FUNC(sei_display_orientation)(CodedBitstreamContext *ctx, RWContext 
*rw,
  H264RawSEIDisplayOrientation *current)
 {
@@ -879,6 +915,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 CHECK(FUNC(sei_display_orientation)
   (ctx, rw, ¤t->payload.display_orientation));
 break;
+case H264_SEI_TYPE_FRAME_PACKING:
+CHECK(FUNC(sei_frame_packing_arrangement)
+  (ctx, rw, ¤t->payload.frame_packing_arrangement));
+break;
 case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
 CHECK(FUNC(sei_mastering_display_colour_volume)
   (ctx, rw, ¤t->payload.mastering_display_colour_volume));
-- 
2.25.0

___
ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH v4 17/21] vaapi_encode_h264: Support stereo 3D metadata

[Mark Thompson]

Insert frame packing arrangement messages into the stream when input
frames have associated stereo 3D side-data.
---
 doc/encoders.texi  |  3 +++
 libavcodec/vaapi_encode_h264.c | 25 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e23b6b32fe..62b6902197 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3065,6 +3065,9 @@ Include picture timing parameters 
(@emph{buffering_period} and
 @emph{pic_timing} messages).
 @item recovery_point
 Include recovery points where appropriate (@emph{recovery_point} messages).
+@item frame_packing
+Include stereo 3D metadata if the input frames have it
+(@emph{frame_packing_arrangement} messages).
 @end table
 
 @end table
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f4965d8b09..58eae613c4 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -25,6 +25,7 @@
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
+#include "libavutil/stereo3d.h"
 
 #include "avcodec.h"
 #include "cbs.h"
@@ -39,6 +40,7 @@ enum {
 SEI_TIMING = 0x01,
 SEI_IDENTIFIER = 0x02,
 SEI_RECOVERY_POINT = 0x04,
+SEI_FRAME_PACKING  = 0x20,
 };
 
 // Random (version 4) ISO 11578 UUID.
@@ -96,6 +98,7 @@ typedef struct VAAPIEncodeH264Context {
 H264RawSEIBufferingPeriod  sei_buffering_period;
 H264RawSEIPicTimingsei_pic_timing;
 H264RawSEIRecoveryPointsei_recovery_point;
+H264RawSEIFramePackingArrangement sei_frame_packing;
 H264RawSEIUserDataUnregistered sei_identifier;
 char  *sei_identifier_string;
 
@@ -251,6 +254,12 @@ static int 
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
 sei->payload[i].payload.recovery_point = priv->sei_recovery_point;
 ++i;
 }
+if (priv->sei_needed & SEI_FRAME_PACKING) {
+sei->payload[i].payload_type = H264_SEI_TYPE_FRAME_PACKING;
+sei->payload[i].payload.frame_packing_arrangement =
+priv->sei_frame_packing;
+++i;
+}
 
 sei->payload_count = i;
 av_assert0(sei->payload_count > 0);
@@ -700,6 +709,17 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 priv->sei_needed |= SEI_RECOVERY_POINT;
 }
 
+if (priv->sei & SEI_FRAME_PACKING) {
+AVFrameSideData *sd = av_frame_get_side_data(pic->input_image,
+ AV_FRAME_DATA_STEREO3D);
+if (sd) {
+ff_cbs_h264_fill_sei_frame_packing_arrangement(
+&priv->sei_frame_packing, (const AVStereo3D*)sd->data);
+}
+
+priv->sei_needed |= SEI_FRAME_PACKING;
+}
+
 vpic->CurrPic = (VAPictureH264) {
 .picture_id  = pic->recon_surface,
 .frame_idx   = hpic->frame_num,
@@ -1271,7 +1291,7 @@ static const AVOption vaapi_encode_h264_options[] = {
 
 { "sei", "Set SEI to include",
   OFFSET(sei), AV_OPT_TYPE_FLAGS,
-  { .i64 = SEI_IDENTIFIER | SEI_TIMING | SEI_RECOVERY_POINT },
+  { .i64 = SEI_IDENTIFIER | SEI_TIMING | SEI_RECOVERY_POINT | 
SEI_FRAME_PACKING },
   0, INT_MAX, FLAGS, "sei" },
 { "identifier", "Include encoder version identifier",
   0, AV_OPT_TYPE_CONST, { .i64 = SEI_IDENTIFIER },
@@ -1282,6 +1302,9 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "recovery_point", "Include recovery points where appropriate",
   0, AV_OPT_TYPE_CONST, { .i64 = SEI_RECOVERY_POINT },
   INT_MIN, INT_MAX, FLAGS, "sei" },
+{ "frame_packing", "Include frame packing arrangement for stereo 3D",
+  0, AV_OPT_TYPE_CONST, { .i64 = SEI_FRAME_PACKING },
+  INT_MIN, INT_MAX, FLAGS, "sei" },
 
 { "profile", "Set profile (profile_idc and constraint_set*_flag)",
   OFFSET(profile), AV_OPT_TYPE_INT,
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 12/21] cbs_mpeg2: Use table-based alloc/free

[Mark Thompson]

---
 libavcodec/cbs_mpeg2.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 0e5d08ecbf..fabf8f7412 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -140,28 +140,6 @@
 #undef infer
 
 
-static void cbs_mpeg2_free_picture_header(void *opaque, uint8_t *content)
-{
-MPEG2RawPictureHeader *picture = (MPEG2RawPictureHeader*)content;
-av_buffer_unref(&picture->extra_information_picture.extra_information_ref);
-av_freep(&content);
-}
-
-static void cbs_mpeg2_free_user_data(void *opaque, uint8_t *content)
-{
-MPEG2RawUserData *user = (MPEG2RawUserData*)content;
-av_buffer_unref(&user->user_data_ref);
-av_freep(&content);
-}
-
-static void cbs_mpeg2_free_slice(void *opaque, uint8_t *content)
-{
-MPEG2RawSlice *slice = (MPEG2RawSlice*)content;
-
av_buffer_unref(&slice->header.extra_information_slice.extra_information_ref);
-av_buffer_unref(&slice->data_ref);
-av_freep(&content);
-}
-
 static int cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
 CodedBitstreamFragment *frag,
 int header)
@@ -231,16 +209,14 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 if (err < 0)
 return err;
 
+err = ff_cbs_alloc_unit_content2(ctx, unit);
+if (err < 0)
+return err;
+
 if (MPEG2_START_IS_SLICE(unit->type)) {
-MPEG2RawSlice *slice;
+MPEG2RawSlice *slice = unit->content;
 int pos, len;
 
-err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*slice),
-&cbs_mpeg2_free_slice);
-if (err < 0)
-return err;
-slice = unit->content;
-
 err = cbs_mpeg2_read_slice_header(ctx, &gbc, &slice->header);
 if (err < 0)
 return err;
@@ -264,12 +240,7 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 #define START(start_code, type, read_func, free_func) \
 case start_code: \
 { \
-type *header; \
-err = ff_cbs_alloc_unit_content(ctx, unit, \
-sizeof(*header), free_func); \
-if (err < 0) \
-return err; \
-header = unit->content; \
+type *header = unit->content; \
 err = cbs_mpeg2_read_ ## read_func(ctx, &gbc, header); \
 if (err < 0) \
 return err; \
@@ -420,11 +391,40 @@ static int 
cbs_mpeg2_assemble_fragment(CodedBitstreamContext *ctx,
 return 0;
 }
 
+static const CodedBitstreamUnitTypeDescriptor cbs_mpeg2_unit_types[] = {
+CBS_UNIT_TYPE_INTERNAL_REF(MPEG2_START_PICTURE, MPEG2RawPictureHeader,
+   extra_information_picture.extra_information),
+
+{
+.nb_unit_types = CBS_UNIT_TYPE_RANGE,
+.unit_type_range_start = 0x01,
+.unit_type_range_end   = 0xaf,
+
+.content_type   = CBS_CONTENT_TYPE_INTERNAL_REFS,
+.content_size   = sizeof(MPEG2RawSlice),
+.nb_ref_offsets = 2,
+.ref_offsets= { offsetof(MPEG2RawSlice, 
header.extra_information_slice.extra_information),
+offsetof(MPEG2RawSlice, data) },
+},
+
+CBS_UNIT_TYPE_INTERNAL_REF(MPEG2_START_USER_DATA, MPEG2RawUserData,
+   user_data),
+
+CBS_UNIT_TYPE_POD(MPEG2_START_SEQUENCE_HEADER, MPEG2RawSequenceHeader),
+CBS_UNIT_TYPE_POD(MPEG2_START_EXTENSION,   MPEG2RawExtensionData),
+CBS_UNIT_TYPE_POD(MPEG2_START_SEQUENCE_END,MPEG2RawSequenceEnd),
+CBS_UNIT_TYPE_POD(MPEG2_START_GROUP,   
MPEG2RawGroupOfPicturesHeader),
+
+CBS_UNIT_TYPE_END_OF_LIST
+};
+
 const CodedBitstreamType ff_cbs_type_mpeg2 = {
 .codec_id  = AV_CODEC_ID_MPEG2VIDEO,
 
 .priv_data_size= sizeof(CodedBitstreamMPEG2Context),
 
+.unit_types= cbs_mpeg2_unit_types,
+
 .split_fragment= &cbs_mpeg2_split_fragment,
 .read_unit = &cbs_mpeg2_read_unit,
 .write_unit= &cbs_mpeg2_write_unit,
-- 
2.25.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 20/21] h264_metadata_bsf: Refactor the filter function into smaller parts

[Andreas Rheinhardt]

Mark Thompson:
> +// If an AUD is present, it must be the first NAL unit.
> +if (au->units[0].type == H264_NAL_AUD) {
> +if (ctx->aud == REMOVE)
> +ff_cbs_delete_unit(ctx->cbc, au, 0);
> +} else {
> +if (ctx->aud == INSERT)
> +h264_metadata_insert_aud(bsf, au);

Why is this unchecked?

- Andreas

PS: More detailled review comes later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 03/21] cbs: Describe allocate/free methods in tabular form

[Mark Thompson]

Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Structure containing references to refcounted buffers - these can use
  a common free function when the offsets of all the internal references
  are known.
* More complex structures - these still require ad-hoc treatment.

For each codec we can then maintain a table of descriptors for each set of
equivalent unit types, defining the mechanism needed to allocate/free that
unit content.  This is not required to be used immediately - a new alloc
function supports this, but does not replace the old one which works without
referring to these tables.
---
 libavcodec/cbs.c  | 69 +++
 libavcodec/cbs.h  |  9 +
 libavcodec/cbs_internal.h | 60 ++
 3 files changed, 138 insertions(+)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 0bd5e1ac5d..6cc559e545 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -812,3 +812,72 @@ void ff_cbs_delete_unit(CodedBitstreamContext *ctx,
 frag->units + position + 1,
 (frag->nb_units - position) * sizeof(*frag->units));
 }
+
+static void cbs_default_free_unit_content(void *opaque, uint8_t *data)
+{
+const CodedBitstreamUnitTypeDescriptor *desc = opaque;
+if (desc->content_type == CBS_CONTENT_TYPE_INTERNAL_REFS) {
+int i;
+for (i = 0; i < desc->nb_ref_offsets; i++) {
+void **ptr = (void**)(data + desc->ref_offsets[i]);
+av_buffer_unref((AVBufferRef**)(ptr + 1));
+}
+}
+av_free(data);
+}
+
+static const CodedBitstreamUnitTypeDescriptor
+*cbs_find_unit_type_desc(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit)
+{
+const CodedBitstreamUnitTypeDescriptor *desc;
+int i, j;
+
+if (!ctx->codec->unit_types)
+return NULL;
+
+for (i = 0;; i++) {
+desc = &ctx->codec->unit_types[i];
+if (desc->nb_unit_types == 0)
+break;
+if (desc->nb_unit_types == CBS_UNIT_TYPE_RANGE) {
+if (unit->type >= desc->unit_type_range_start &&
+unit->type <= desc->unit_type_range_end)
+return desc;
+} else {
+for (j = 0; j < desc->nb_unit_types; j++) {
+if (desc->unit_types[j] == unit->type)
+return desc;
+}
+}
+}
+return NULL;
+}
+
+int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
+   CodedBitstreamUnit *unit)
+{
+const CodedBitstreamUnitTypeDescriptor *desc;
+
+av_assert0(!unit->content && !unit->content_ref);
+
+desc = cbs_find_unit_type_desc(ctx, unit);
+if (!desc)
+return AVERROR(ENOSYS);
+
+unit->content = av_mallocz(desc->content_size);
+if (!unit->content)
+return AVERROR(ENOMEM);
+
+unit->content_ref =
+av_buffer_create(unit->content, desc->content_size,
+ desc->content_free ? desc->content_free
+: cbs_default_free_unit_content,
+ (void*)desc, 0);
+if (!unit->content_ref) {
+av_freep(&unit->content);
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index cb3081e2c6..2a5959a2b0 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -352,6 +352,15 @@ int ff_cbs_alloc_unit_content(CodedBitstreamContext *ctx,
   size_t size,
   void (*free)(void *opaque, uint8_t *content));
 
+/**
+ * Allocate a new internal content buffer matching the type of the unit.
+ *
+ * The content will be zeroed.
+ */
+int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
+   CodedBitstreamUnit *unit);
+
+
 /**
  * Allocate a new internal data buffer of the given size in the unit.
  *
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 4c5a535ca6..615f514a85 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -25,11 +25,71 @@
 #include "put_bits.h"
 
 
+enum {
+// Unit content is a simple structure.
+CBS_CONTENT_TYPE_POD,
+// Unit content contains some references to other structures, but all
+// managed via buffer reference counting.  The descriptor defines the
+// structure offsets of every buffer reference.
+CBS_CONTENT_TYPE_INTERNAL_REFS,
+// Unit content is something more complex.  The descriptor defines
+// special functions to manage the content.
+CBS_CONTENT_TYPE_COMPLEX,
+};
+
+enum {
+  // Maximum number of unit types described by the same unit type
+  // descriptor.
+  CBS_MAX_UNIT_TYPES = 16,
+  // Maximum number of reference buffer offsets in any one unit.
+  CBS_MAX_REF_OFFSETS = 2,
+  // Special value used in a unit type descriptor to

Re: [FFmpeg-devel] [PATCH] hwcontext_vaapi: Only accept a render node when deriving from DRM device

[Mark Thompson]

On 18/02/2020 14:23, Anton Khirnov wrote:
> Quoting Mark Thompson (2020-02-16 21:59:54)
>> If we are given a non-render node, try to find the matching render node and
>> fail if that isn't possible.
>>
>> libva will not accept a non-render device which is not DRM master, because
>> it requires legacy DRM authentication to succeed in that case:
>> .  This
>> is annoying for kmsgrab because in most recording situations DRM master is
>> already held by something else (such as a windowing system), leading to
>> device derivation not working and forcing the user to create the target
>> VAAPI device separately.
>> ---
>> Fixes a longstanding annoyance with -vf hwmap=derive_device=vaapi.
>>
>> (E.g. .)
> 
> Looks reasonable.

Applied.

Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit VAAPI decode support

[Mark Thompson]

On 15/01/2020 07:02, Linjie Fu wrote:
> Add decode support for 4:2:2 8-bt and 10-bit HEVC Range Extension clips.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/hevcdec.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 19b0cd8..f60bcf6 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -427,6 +427,12 @@ static enum AVPixelFormat get_format(HEVCContext *s, 
> const HEVCSPS *sps)
>  *fmt++ = AV_PIX_FMT_CUDA;
>  #endif
>  break;
> +case AV_PIX_FMT_YUV422P:
> +case AV_PIX_FMT_YUV422P10LE:
> +#if CONFIG_HEVC_VAAPI_HWACCEL
> +   *fmt++ = AV_PIX_FMT_VAAPI;
> +#endif
> +break;
>  case AV_PIX_FMT_YUV420P12:
>  case AV_PIX_FMT_YUV444P10:
>  case AV_PIX_FMT_YUV444P12:
> 

We seem to have agreement that the Y210 / wider YUYV is fine (bit-packed Y410 
was the case people had problems with) and everything else looks good, so set 
tested and applied.

Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit VAAPI decode support

[Carl Eugen Hoyos]

Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson :

> We seem to have agreement that the Y210 / wider YUYV is fine

Why do you think so?
I was under the impression that we have agreement that this
has to be discussed further.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit VAAPI decode support

[Mark Thompson]

On 24/02/2020 00:37, Carl Eugen Hoyos wrote:
> Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson :
> 
>> We seem to have agreement that the Y210 / wider YUYV is fine
> 
> Why do you think so?
> I was under the impression that we have agreement that this
> has to be discussed further.

All of the dispute was about the bit-packed formats (Y410 = V210, and similar 
in RGB), and the other cases (Y210 = 10-bit YUYV, 0YUV = packed 8-bit YUV with 
padding) only got caught up in that discussion because they were originally 
submitted in the same patch.  I also clarified on IRC with Kieran that his mail 
replying to this patch 
() 
was referring to that case.

Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit VAAPI decode support

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Monday, February 24, 2020 08:25
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit
> VAAPI decode support
> 
> On 15/01/2020 07:02, Linjie Fu wrote:
> > Add decode support for 4:2:2 8-bt and 10-bit HEVC Range Extension clips.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/hevcdec.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 19b0cd8..f60bcf6 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -427,6 +427,12 @@ static enum AVPixelFormat
> get_format(HEVCContext *s, const HEVCSPS *sps)
> >  *fmt++ = AV_PIX_FMT_CUDA;
> >  #endif
> >  break;
> > +case AV_PIX_FMT_YUV422P:
> > +case AV_PIX_FMT_YUV422P10LE:
> > +#if CONFIG_HEVC_VAAPI_HWACCEL
> > +   *fmt++ = AV_PIX_FMT_VAAPI;
> > +#endif
> > +break;
> >  case AV_PIX_FMT_YUV420P12:
> >  case AV_PIX_FMT_YUV444P10:
> >  case AV_PIX_FMT_YUV444P12:
> >
> 
> We seem to have agreement that the Y210 / wider YUYV is fine (bit-packed
> Y410 was the case people had problems with) and everything else looks good,
> so set tested and applied.
> 
> Thanks,
> 
> - Mark

Thanks a lot for the review and suggestions.

Regards,
Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 06/21] cbs: Add support functions for handling unit content references

[Andreas Rheinhardt]

Mark Thompson:
> Use the unit type table to determine what we need to do to clone the
> internals of the unit content when making copies for refcounting or
> writeability.  (This will still fail for units with complex content
> if they do not have a defined clone function.)
> 
> Setup and naming from a patch by Andreas Rheinhardt
> , but with the implementation

You may use my new email here.

> changed to use the unit type information if possible rather than
> requiring a codec-specific function.
> ---
>  libavcodec/cbs.c  | 172 ++
>  libavcodec/cbs.h  |  29 +++
>  libavcodec/cbs_internal.h |   1 +
>  3 files changed, 202 insertions(+)
> 
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 6cc559e545..91788f6dfb 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -881,3 +881,175 @@ int ff_cbs_alloc_unit_content2(CodedBitstreamContext 
> *ctx,
>  
>  return 0;
>  }
> +
> +static int cbs_clone_unit_content(AVBufferRef **clone_ref,
> +  CodedBitstreamUnit *unit,
> +  const CodedBitstreamUnitTypeDescriptor 
> *desc)
> +{
> +uint8_t *src, *copy;
> +uint8_t **src_ptr, **copy_ptr;
> +AVBufferRef **src_buf, **copy_buf;
> +int err, i;
> +
> +av_assert0(unit->content);
> +src = unit->content;
> +
> +copy = av_malloc(desc->content_size);
> +if (!copy)
> +return AVERROR(ENOMEM);
> +
> +memcpy(copy, src, desc->content_size);

One can use av_memdup() for malloc+memcpy.

> +
> +for (i = 0; i < desc->nb_ref_offsets; i++) {
> +src_ptr  = (uint8_t**)(src + desc->ref_offsets[i]);
> +src_buf  = (AVBufferRef**)(src_ptr + 1);
> +copy_ptr = (uint8_t**)(copy + desc->ref_offsets[i]);
> +copy_buf = (AVBufferRef**)(copy_ptr + 1);

In patch #2 you intend to make the AVBufferRef * directly follow the
pointer so that the above works. This has two drawbacks: It probably
works on all systems we care about, but it is not spec-compliant as a
compiler may add padding between these two elements. And furthermore
it forces you to make these ugly casts above.

How about the following approach: The *data pointer and the *data_ref
pointer will always be put into a dedicated structure (maybe even with
the size field?) ChildBuf (better name welcome) or whatever and the
descriptor contains the offset of these ChildBufs. Here is a scetch:

struct ChildBuf {
uint8_t *data;
AVBufferRef *data_ref;
} ChildBuf;

  const ChildBuf *src_child = (const ChildBuf *)(src +
desc->child_offsets[i]);
  ChildBuf *copy_child = (ChildBuf *)(copy + desc->ref_offsets[i]);

  if (!src_child->data) {
av_assert0(!src_child->data_ref);
continue;
  }
...
  copy_child->data_ref = av_buffer_ref(src_child->data_ref);

I admit it would probably involve more writing (unless you can come up
with a really short name).

> +
> +if (!*src_ptr) {
> +av_assert0(!*src_buf);
> +continue;
> +}
> +if (!*src_buf) {
> +// We can't handle a non-refcounted pointer here - we don't
> +// have enough information to handle whatever structure lies
> +// at the other end of it.
> +err = AVERROR(EINVAL);
> +goto fail;
> +}
> +
> +// src_ptr is required to point somewhere inside src_buf.  If it
> +// doesn't, there is a bug somewhere.
> +av_assert0(*src_ptr >= (*src_buf)->data &&
> +   *src_ptr <  (*src_buf)->data + (*src_buf)->size);
> +
> +*copy_buf = av_buffer_ref(*src_buf);
> +if (!*copy_buf) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +err = av_buffer_make_writable(copy_buf);

Making the child buf writable is neither necessary for fixing the
original problem, because h264_redundant_pps does not modifiy the
child buffer; nor is there any benefit to it: If unit->content_ref is
already writable, the child buffers will not be made writable, so that
a caller can not rely on the child buffers being writable after
ff_cbs_make_unit_writable() so that if he wants to modify them, a
further av_buffer_make_writable() for them is necessary.
Furthermore, if one only wants to modify e.g. a slice header that is
currently not writable (for whatever reason), one would also make the
internal ref (i.e. the unit's data) writable, which is expensive, but
one has no real choice because ff_cbs_make_unit_writable() does it
automatically.

> +if (err < 0) {
> +av_buffer_unref(copy_buf);
> +goto fail;
> +}
> +
> +*copy_ptr = (*copy_buf)->data + (*src_ptr - (*src_buf)->data);
> +}
> +
> +*clone_ref = av_buffer_create(copy, desc->content_size,
> +  desc->content_free ? desc->content_free :
> +  cbs_default_free_unit_content,
> +  

Re: [FFmpeg-devel] [PATCH v4 16/21] cbs_h264: Add a function to turn stereo 3D metadata into SEI

[Andreas Rheinhardt]

Mark Thompson:
> ---
>  libavcodec/cbs_h264.c | 47 +++
>  libavcodec/cbs_h264.h |  8 
>  2 files changed, 55 insertions(+)
> 
> diff --git a/libavcodec/cbs_h264.c b/libavcodec/cbs_h264.c
> index 75759c7f25..cc52f68550 100644
> --- a/libavcodec/cbs_h264.c
> +++ b/libavcodec/cbs_h264.c
> @@ -16,6 +16,8 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> +#include "libavutil/stereo3d.h"
> +
>  #include "cbs_h264.h"
>  
>  int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
> @@ -104,3 +106,48 @@ void 
> ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
>  (sei->payload_count - position) * sizeof(*sei->payload));
>  }
>  }
> +
> +void 
> ff_cbs_h264_fill_sei_frame_packing_arrangement(H264RawSEIFramePackingArrangement
>  *fp,
> +const AVStereo3D *st)
> +{
> +static const int type_map[] = {

Why not uint8_t instead of int? After all,
frame_packing_arrangement_type is an uint8_t.

> +[AV_STEREO3D_2D]  = 6,
> +[AV_STEREO3D_SIDEBYSIDE]  = 3,
> +[AV_STEREO3D_TOPBOTTOM]   = 4,
> +[AV_STEREO3D_FRAMESEQUENCE]   = 5,
> +[AV_STEREO3D_CHECKERBOARD]= 0,
> +[AV_STEREO3D_SIDEBYSIDE_QUINCUNX] = 3,
> +[AV_STEREO3D_LINES]   = 2,
> +[AV_STEREO3D_COLUMNS] = 1,
> +};
> +
> +memset(fp, 0, sizeof(*fp));
> +
> +if (st->type >= FF_ARRAY_ELEMS(type_map))
> +return;
> +
> +fp->frame_packing_arrangement_type = type_map[st->type];
> +
> +fp->quincunx_sampling_flag =
> +st->type == AV_STEREO3D_CHECKERBOARD ||
> +st->type == AV_STEREO3D_SIDEBYSIDE_QUINCUNX;
> +
> +if (st->type == AV_STEREO3D_2D)
> +fp->content_interpretation_type = 0;
> +else if (st->flags & AV_STEREO3D_FLAG_INVERT)
> +fp->content_interpretation_type = 2;
> +else
> +fp->content_interpretation_type = 1;
> +
> +if (st->type == AV_STEREO3D_FRAMESEQUENCE) {
> +if (st->flags & AV_STEREO3D_FLAG_INVERT)
> +fp->current_frame_is_frame0_flag =
> +st->view == AV_STEREO3D_VIEW_RIGHT;
> +else
> +fp->current_frame_is_frame0_flag =
> +st->view == AV_STEREO3D_VIEW_LEFT;
> +}
> +
> +fp->frame_packing_arrangement_repetition_period =
> +st->type != AV_STEREO3D_FRAMESEQUENCE;
> +}
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index 512674ec07..76211c976b 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -525,4 +525,12 @@ void 
> ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
>  CodedBitstreamUnit *nal_unit,
>  int position);
>  
> +struct AVStereo3D;
> +/**
> + * Fill an SEI Frame Packing Arrangement structure with values derived from
> + * the AVStereo3D side-data structure.
> + */
> +void 
> ff_cbs_h264_fill_sei_frame_packing_arrangement(H264RawSEIFramePackingArrangement
>  *fp,
> +const struct AVStereo3D 
> *st);
> +
>  #endif /* AVCODEC_CBS_H264_H */
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add .mailmap

[Steven Liu]

> 2020年2月24日 上午4:40，Josh de Kock  写道：
> 
> On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote:
>> [...]
>> 
>> How is it automatically generated?
> 
> I wrote a small script to parse author names/emails and group
> emails together based on names. In the future, additions should
> be added manually.
> 
How can I get the script :D

Thanks

Steven

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".