Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Elliott Balsley

> On Jan 30, 2019, at 12:53, Carl Eugen Hoyos  wrote:
> 
> Imo, it is different in (nearly) every regard but as said, I don't see
> how this discussion can be fruitful in any way.
> 
If anyone else has an opinion, I would love to learn why Nvidia driver is 
considered a system library under GPL while Decklink driver is not. They are 
both closed source drivers required to run a hardware device. Nvidia driver is 
required to use nvenc, which does not need the nonfree flag.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Harish Krupo
Hello,

We are in the process of implementing HDR rendering support in the
Weston display compositor [1] (HDR discussion here [2]). When HDR
and SDR surfaces like a video buffer and a subtitle buffer are presented
together, the composition would take place as follows:
- If the display does not support HDR metadata:
  in-coming HDR surfaces would be tone mapped using opengl to SDR and
  blended with the other SDR surfaces. We are currently using the Hable
  operator for tone mapping.
- If the display supports setting HDR metadata:
  SDR surfaces would be tone mapped to HDR and blended with HDR surfaces.

The literature available for SDR->HDR tone mapping varies from simple
linear expansion of luminance to CNN based approaches. We wanted to know
your recommendations for an acceptable algorithm for SDR->HDR tone mapping.

Any help is greatly appreciated!

[1] https://gitlab.freedesktop.org/wayland/weston
[2] 
https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html

Thank you
Regards
Harish Krupo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Werner Robitza
On Thu, Feb 7, 2019 at 11:11 PM Lou Logan  wrote:
>
> On Thu, Feb 7, 2019, at 12:49 PM, Carl Eugen Hoyos wrote:
> >
> > This sounds like a strong reason not to add it to an FFmpeg
> > repository: It was claimed in the past that I am the only one
> > not supporting releases but the same was now repeated by
> > other developers.
>
> We can simply provide a note that recommends using git master by instructing 
> the user to include the homebrew --HEAD option.

That could easily be added to the formula's README and caveat section,
yes. I don't see that as a major roadblock. If you have a specific
text in mind that would emphasize that one or the other kind of
installation is not supported/recommended, feel free to suggest that
for inclusion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Jean-Baptiste Kempf
Hello,

On Wed, 6 Feb 2019, at 21:41, Werner Robitza wrote:
> Homebrew has, with its 2.0 release, removed all options for its core
> formulae [1], including ffmpeg. This means users can no longer add
> non-default dependencies that aren't included in the core formula [2].

> I propose that FFmpeg maintains its own ffmpeg formula under its
> GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).

Why do something special for homebrew, and not for all the other distributions?
Why is homebrew different? Are you going to merge all .spec files from all 
Linux distributions too?

> That creates a bit of a messy situation, as users are expecting to be
> able to build ffmpeg with additional libraries, including nonfree ones
> such as fdk-aac. This is no longer easily doable.

Helping people to build non-free distributions of FFmpeg is a very weird and 
dubious goal.
This is just helping other people violate the FFmpeg license.

> Please let me know your thoughts.

Do not use Github to develop. Github is not-free. Use Github to mirror, if you 
want, but not to develop.

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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Jean-Baptiste Kempf
Hello,

On Fri, 8 Feb 2019, at 09:01, Elliott Balsley wrote:
> > On Jan 30, 2019, at 12:53, Carl Eugen Hoyos  wrote:
> > Imo, it is different in (nearly) every regard but as said, I don't see
> > how this discussion can be fruitful in any way.
> > 
> If anyone else has an opinion, I would love to learn why Nvidia driver 
> is considered a system library under GPL while Decklink driver is not. 
> They are both closed source drivers required to run a hardware device. 
> Nvidia driver is required to use nvenc, which does not need the nonfree 
> flag.

Decklink SDK has a very weird EULA + headers license that makes it very dubious 
that it is free.
Decklink refuses to clarify for now. That warrants a non-free flag.
I know it's very weird, since the SDK has the source code of some of the kernel 
modules (but not of the glue).

Nvenc is different and has clear headers, and well known driver.

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


Re: [FFmpeg-devel] [PATCH] doc/examples: port muxing example to new send/receive API

2019-02-08 Thread Lennart Blanco
Hi

Have anyone had time to look at this patch?

Best Regards,
Lennart


On Mon, Feb 4, 2019 at 12:05 PM Lennart Blanco  wrote:

> Hi
>
> Noticed that the example code for muxing uses depricated API. This is my
> attempt to
> port the doc/examples/muxing.c to use the avcodec_send_frame() and
> avcodec_receive_packet() API.
>
> Regards,
> Lennart
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Jean-Baptiste Kempf
Hello,

On Fri, 8 Feb 2019, at 09:17, Harish Krupo wrote:
> The literature available for SDR->HDR tone mapping varies from simple
> linear expansion of luminance to CNN based approaches. We wanted to know
> your recommendations for an acceptable algorithm for SDR->HDR tone mapping.

You really need to talk to haasn from the libplacebo project.


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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.

2019-02-08 Thread Michael Niedermayer
On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote:
> This is robust for some corner case there is incorrect list1 count
> in pps header, but it's a P slice and can be decoded well.
> 
> Signed-off-by: Decai Lin 
> ---
>  libavcodec/h264_parse.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

will apply with a minor change clearing the contraditionary value

thanks

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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


Re: [FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data

2019-02-08 Thread Michael Niedermayer
On Thu, Feb 07, 2019 at 02:58:17PM -0800, chcunningham wrote:
> Bad content may contain stsc boxes with a first_chunk index that
> exceeds stco.entries (chunk_count). This ammends the existing check to
> include cases where chunk_count == 0. It also patches up the case
> when stsc refers to unknown chunks, but stts has no samples (so we
> can simply ignore stsc).
> ---
>  libavformat/mov.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)

will apply

thanks

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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


Re: [FFmpeg-devel] [PATCH v4] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Michael Niedermayer
On Thu, Feb 07, 2019 at 09:03:16PM +0100, Mathieu Duponchelle wrote:
> ---
>  doc/encoders.texi  |  3 +++
>  libavcodec/mpeg12enc.c | 31 +++
>  libavcodec/mpegvideo.h |  2 ++
>  3 files changed, 36 insertions(+)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..a283b9fddf 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence 
> display extension
>  indicating the source of the video pictures. The default is 
> @samp{unspecified},
>  can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
>  For maximum compatibility, use @samp{component}.
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Default is 1 (on).
>  @end table
>  
>  @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index d0b458e34b..15a3db9e6d 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
>  static uint8_t mpeg1_index_run[2][64];
>  static int8_t  mpeg1_max_level[2][64];
>  
> +#define A53_MAX_CC_COUNT 0x1f
> +
>  static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
>  {
>  int i;
> @@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, 
> int picture_number)
>  }
>  }
>  
> +if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
> +side_data = av_frame_get_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_A53_CC);
> +if (side_data) {
> +if (side_data->size <= A53_MAX_CC_COUNT) {
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(&s->pb, 8, 'G');   // 
> user_identifier
> +put_bits(&s->pb, 8, 'A');
> +put_bits(&s->pb, 8, '9');
> +put_bits(&s->pb, 8, '4');
> +put_bits(&s->pb, 8, 3); // 
> user_data_type_code

> +put_bits(&s->pb, 8,
> +(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
> flags, cc_count

what if size is not a multiple of 3 ?

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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


Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun

2019-02-08 Thread Michael Niedermayer
On Thu, Feb 07, 2019 at 08:03:01PM +, Derek Buitenhuis wrote:
> On 07/02/2019 19:30, Chris Cunningham wrote:
> > This will reject the file entirely. The testcase I have (can share once
> > chromium bug is fixed) was previously hitting an av_assert0 in
> > mov_read_trun, arguably also a total rejection ;). Recovery for this could
> > be pretty tricky since the dropped trun will break decode dependencies. I
> > would be surprised to find files with missing tfhd's in the wild (outside
> > of fuzzer / maliciously crafted sorts).
> 
> You would be surprised what kind of garbage things can produce...
> 
> In any case, sounds OK to me.

will apply

thanks

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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


Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Vittorio Giovara
On Fri, Feb 8, 2019 at 3:22 AM Harish Krupo 
wrote:

> Hello,
>
> We are in the process of implementing HDR rendering support in the
> Weston display compositor [1] (HDR discussion here [2]). When HDR
> and SDR surfaces like a video buffer and a subtitle buffer are presented
> together, the composition would take place as follows:
> - If the display does not support HDR metadata:
>   in-coming HDR surfaces would be tone mapped using opengl to SDR and
>   blended with the other SDR surfaces. We are currently using the Hable
>   operator for tone mapping.
> - If the display supports setting HDR metadata:
>   SDR surfaces would be tone mapped to HDR and blended with HDR surfaces.
>
> The literature available for SDR->HDR tone mapping varies from simple
> linear expansion of luminance to CNN based approaches. We wanted to know
> your recommendations for an acceptable algorithm for SDR->HDR tone mapping.
>
> Any help is greatly appreciated!
>
> [1] https://gitlab.freedesktop.org/wayland/weston
> [2]
> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html
>
> Thank you
> Regards
> Harish Krupo
>

In *theory* the tonemapping functions should be reversible, so if you use
vf_tonemap or vf_tonemap_opencl and properly expand the range via zimg
(vf_zscale) before compression it should work fine. However I have never
tried it myself, so I cannot guarantee that those filters will work as is.
Of course haasn from the libplacebo project might have better suggestions,
so you should really reach out to him.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread Michael Niedermayer
Hi

On Wed, Feb 06, 2019 at 05:13:03PM -0800, chcunningham wrote:
> From: chcunningham 

Is the name intended ? As this ends up as author name in git, and several
developers dislike this:
(and i cannot edit other authors names of course, that would be not right)

(from IRC)
 Could you stop committing things like this?
 his name is "Chris Cunningham", not "chcunningham"

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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


Re: [FFmpeg-devel] [PATCH v4] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Mathieu Duponchelle
On 2/8/19 11:58 AM, Michael Niedermayer wrote:
> what if size is not a multiple of 3 ?

Good point, more bytes will be written than advertised. Do you reckon
the input should be straight up refused? The other solution is to warn then
iterate over side_data->size rounded down to the closest 3 multiple.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v4] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Devin Heitmueller
> On Feb 8, 2019, at 9:47 AM, Mathieu Duponchelle  
> wrote:
> 
> On 2/8/19 11:58 AM, Michael Niedermayer wrote:
>> what if size is not a multiple of 3 ?
> 
> Good point, more bytes will be written than advertised. Do you reckon
> the input should be straight up refused? The other solution is to warn then
> iterate over side_data->size rounded down to the closest 3 multiple.

Yeah, so there are all sorts of ways the content could be screwed up and I 
don’t think we want to get into the business of having every encoder module try 
to validate it.  That said, a quick length check is reasonable to avoid a 
possible buffer overflow, so I would just write a log message and throw the 
entire array on the floor.

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

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


[FFmpeg-devel] [PATCH v5] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Mathieu Duponchelle
---
 doc/encoders.texi  |  3 +++
 libavcodec/mpeg12enc.c | 32 
 libavcodec/mpegvideo.h |  2 ++
 3 files changed, 37 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..a283b9fddf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence 
display extension
 indicating the source of the video pictures. The default is @samp{unspecified},
 can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
 For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Default is 1 (on).
 @end table
 
 @section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..0cbd011c61 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
 static uint8_t mpeg1_index_run[2][64];
 static int8_t  mpeg1_max_level[2][64];
 
+#define A53_MAX_CC_COUNT 0x1f
+
 static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
 {
 int i;
@@ -544,6 +546,36 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int 
picture_number)
 }
 }
 
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT && side_data->size % 3 == 
0) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G');   // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); // 
user_data_type_code
+put_bits(&s->pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
flags, cc_count
+put_bits(&s->pb, 8, 0xff);  // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff);  // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size (%d) can not exceed 93 bytes "
+"and must be a multiple of 3\n", side_data->size);
+}
+}
+}
+
 s->mb_y = 0;
 ff_mpeg1_encode_slice_header(s);
 }
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
 /* MPEG-2-specific - I wished not to have to support this mess. */
 int progressive_sequence;
 int mpeg_f_code[2][2];
+int a53_cc;
 
 // picture structure defines are loaded from mpegutils.h
 int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
 {"ps", "RTP payload size in bytes", 
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, 
INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)", 
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 }, 
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT, 
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc), 
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
 
 extern const AVOption ff_mpv_generic_options[];
 
-- 
2.20.1

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


[FFmpeg-devel] [PATCH v6] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Mathieu Duponchelle
---
 doc/encoders.texi  |  3 +++
 libavcodec/mpeg12enc.c | 32 
 libavcodec/mpegvideo.h |  2 ++
 3 files changed, 37 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..a283b9fddf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence 
display extension
 indicating the source of the video pictures. The default is @samp{unspecified},
 can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
 For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Default is 1 (on).
 @end table
 
 @section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..2bc5289d63 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
 static uint8_t mpeg1_index_run[2][64];
 static int8_t  mpeg1_max_level[2][64];
 
+#define A53_MAX_CC_COUNT 0x1f
+
 static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
 {
 int i;
@@ -544,6 +546,36 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int 
picture_number)
 }
 }
 
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size % 3 
== 0) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G');   // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); // 
user_data_type_code
+put_bits(&s->pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
flags, cc_count
+put_bits(&s->pb, 8, 0xff);  // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff);  // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size (%d) can not exceed 93 bytes "
+"and must be a multiple of 3\n", side_data->size);
+}
+}
+}
+
 s->mb_y = 0;
 ff_mpeg1_encode_slice_header(s);
 }
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
 /* MPEG-2-specific - I wished not to have to support this mess. */
 int progressive_sequence;
 int mpeg_f_code[2][2];
+int a53_cc;
 
 // picture structure defines are loaded from mpegutils.h
 int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
 {"ps", "RTP payload size in bytes", 
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, 
INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)", 
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 }, 
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT, 
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc), 
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
 
 extern const AVOption ff_mpv_generic_options[];
 
-- 
2.20.1

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


Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Harish Krupo
Hi Jean,

Jean-Baptiste Kempf  writes:

> Hello,
>
> On Fri, 8 Feb 2019, at 09:17, Harish Krupo wrote:
>> The literature available for SDR->HDR tone mapping varies from simple
>> linear expansion of luminance to CNN based approaches. We wanted to know
>> your recommendations for an acceptable algorithm for SDR->HDR tone mapping.
>
> You really need to talk to haasn from the libplacebo project.

Sure, will do so. Thanks!

Regards
Harish Krupo

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


Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Harish Krupo
Hi Vittorio,

Vittorio Giovara  writes:

> On Fri, Feb 8, 2019 at 3:22 AM Harish Krupo 
> wrote:
>
>> Hello,
>>
>> We are in the process of implementing HDR rendering support in the
>> Weston display compositor [1] (HDR discussion here [2]). When HDR
>> and SDR surfaces like a video buffer and a subtitle buffer are presented
>> together, the composition would take place as follows:
>> - If the display does not support HDR metadata:
>>   in-coming HDR surfaces would be tone mapped using opengl to SDR and
>>   blended with the other SDR surfaces. We are currently using the Hable
>>   operator for tone mapping.
>> - If the display supports setting HDR metadata:
>>   SDR surfaces would be tone mapped to HDR and blended with HDR surfaces.
>>
>> The literature available for SDR->HDR tone mapping varies from simple
>> linear expansion of luminance to CNN based approaches. We wanted to know
>> your recommendations for an acceptable algorithm for SDR->HDR tone mapping.
>>
>> Any help is greatly appreciated!
>>
>> [1] https://gitlab.freedesktop.org/wayland/weston
>> [2]
>> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html
>>
>> Thank you
>> Regards
>> Harish Krupo
>>
>
> In *theory* the tonemapping functions should be reversible, so if you use
> vf_tonemap or vf_tonemap_opencl and properly expand the range via zimg
> (vf_zscale) before compression it should work fine. However I have never
> tried it myself, so I cannot guarantee that those filters will work as is.
> Of course haasn from the libplacebo project might have better suggestions,
> so you should really reach out to him.

Thanks, will try reversing the algorithms. Sure, will contact Haasn.

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


Re: [FFmpeg-devel] SDR->HDR tone mapping algorithm?

2019-02-08 Thread Niklas Haas
Hi,

The important thing to consider is what constraints we are trying to
solve. And I think the expected behavior is that an SDR signal in SDR
mode should look identical to an SDR signal in HDR mode, to the end
user.

This is, of course, an impossible constraint to solve, since we don't
know anything about the display, either in HDR or in SDR mode. At best,
in the absence of this knowledge, we could make a guess (e.g. it's
roughly described by sRGB in SDR mode, and for HDR mode it roughly
follows the techniques outlined in ITU-R Report BT.2390). Better yet
would be to actually obtain this information from somewhere, but where?
(The user? ICC profile? EDID?).

But the bottom line is that to solve the "make SDR in HDR mode appear
identical to SDR in SDR mode" constraint, the curve you are trying to
invert is not your own tone mapping operator, but the tone mapping
operator implemented by the display (in HDR mode), which definitely
depends on what brightness level the display is targeting (in both SDR
and HDR modes).

For an ideal HDR display, this would simply be the PQ curve's exact
definition (i.e. noop tone mapping). But in practice, the display will
almost surely not be capable of displaying up to 10,000 nits, so it will
implement a tone mapping operator of some kind (even if it's as simple
as clipping the extra range). Some colorimetric/reference displays
actually do the latter, since they prefer clipping out-of-range signals
over distorting in-range ones. But most consumer displays will probably
do something similar to the hable curve, most likely in per-channel
modes.

For an ideal SDR display, it depends on who you ask (w.r.t what "ideal"
means). In the ITU-R world, an ideal SDR reference display implements
the BT.1886 transfer function. In practice, it's probably closer to a
pure power gamma 2.2 curve. Or maybe sRGB. We really have nothing else
to do here except either consult an ICC profile or just stick our head
in the sand and guess randomly.

--

I'd also like to comment on your compositor design proposal. A few notes:

1. It's always beneficial to do as few color conversion steps as
   possible, to minimize cumulative errors and optimize performance. If
   you use a 3DLUT as any step (e.g. for implementing an ICC-profile
   based mapping), the 3DLUT should be as "wide" as possible and cover
   as many operations as possible, so that the 3DLUT can be end-to-end
   optimized (by the CMM).

   If you insist on doing compositing in linear light, then I would
   probably composite in display-referred linear light and convert it to
   non-linear light during scanout (either by implementing the needed
   OETF + linear tone mapping operator via the VCGTs, or by doing a
   non-linear tone mapping pass). But I would recommend trying to avoid
   any second gamut conversion step (e.g. from BT.2020 to the display's
   space after compositing).

   Otherwise, I would composite directly in the target color space
   (saving us one final conversion step), which would obviously be
   preferable if there are no transparency effects to worry about.
   Maybe we could even switch dynamically between the two depending on
   whether any blending needs to occur? Assuming we can update the VCGTs
   atomically and without meaningful latency.

2. Rec 2020 is not (inherently) HDR. Also, the choice of color gamut has
   nothing to do with the choice of transfer function. I might have Rec
   709 HDR content. In general, when ingesting a buffer, the user should
   be responsible for tagging both its color primaries and its transfer
   function.

3. If you're compositing in linear light, then you most likely want to
   be using at least 16-bit per channel floating point buffers, with 1.0
   mapping to "SDR white", and HDR values being treated as above 1.0.

   This is also a good color space to use for ingesting buffers, since
   it allows treating SDR and HDR inputs "identically", but extreme
   caution must be applied due to the fact that with floating point
   buffers, we're left at the mercy of what the client wants to put into
   them (10^20? NaN? Negative values?). Extra metadata must still be
   communicated between the client and the compositor to ensure both
   sides agree on the signal range of the floating point buffer
   contents.

4. Applications need a way to bypass the color pipeline in the
   compositor, i.e. applications need a way to tag their buffers as
   "this buffer is in display N's native (SDR|HDR) color space". This of
   course only makes sense if applications both have a way of knowing
   what display N's native SDR/HDR color space is, as well as which
   display N they're being displayed (more) on. Such buffers should be
   preserved as much as possible end-to-end, ideally being just directly
   scanned out as-is.

5. Implementing a "good" HDR-to-SDR tone mapping operator; and even the
   question of whether to use the display'

Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Elliott Balsley

> On Feb 8, 2019, at 01:17, Jean-Baptiste Kempf  wrote:
> 
> Decklink SDK has a very weird EULA + headers license that makes it very 
> dubious that it is free.
> Decklink refuses to clarify for now. That warrants a non-free flag.
> I know it's very weird, since the SDK has the source code of some of the 
> kernel modules (but not of the glue).
> 
> Nvenc is different and has clear headers, and well known driver.
> 

I agree it is weird.  I will ping Blackmagic again for clarification, but based 
on their last statement I think it’s clear that the headers can be distributed 
under the Boost license contained in each file.
Quote: 
Access to the DeckLink SDK is governed by the EULA and is only available from 
the Blackmagic Design website. Applications that are built with the SDK are 
then licensed via the more permissive license contained within the SDK.

Carl seemed to agree that the headers are not the issue, but the Decklink 
driver is not considered a system library.  What makes Nvidia a system library 
if Decklink is not?  They are both closed source drivers used to control a PCIe 
card.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Werner Robitza
Hello,

Thanks for your comments.

On Fri, Feb 8, 2019 at 10:03 AM Jean-Baptiste Kempf  wrote:
> Why do something special for homebrew, and not for all the other 
> distributions?
> Why is homebrew different? Are you going to merge all .spec files from all 
> Linux distributions too?

I don't think it's really productive to talk about other Linux
distributions in this thread. That is really a different topic.

> > That creates a bit of a messy situation, as users are expecting to be
> > able to build ffmpeg with additional libraries, including nonfree ones
> > such as fdk-aac. This is no longer easily doable.
>
> Helping people to build non-free distributions of FFmpeg is a very weird and 
> dubious goal.
> This is just helping other people violate the FFmpeg license.

That is a matter of personal viewpoint contrasted with general opinion
about non-free FFmpeg, which I am 1) probably not the right person to
discuss with, given my lack of presence on this mailing list and 2)
the fact that the proposed formula simply mirrors what is already
possible. I may be missing the full picture or developer consensus
about how to handle this. I understand that there are folks who are
very passionate about this topic, and that others are not. I can only
observe that end users have the technical possibilities to build
FFmpeg in a non-free and non-redistributable fashion. I don't see why
it would be necessary to artificially restrict users in doing so.

> Do not use Github to develop. Github is not-free. Use Github to mirror, if 
> you want, but not to develop.

This formula could of course be mirrored from git.ffmpeg.org or
wherever if there were a policy of not developing on GitHub. That
said, I do see other repos on https://github.com/FFmpeg that are not
mirrored, so I assume there is no such rule.

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


Re: [FFmpeg-devel] [PATCH V2 1/2] add support for ROI-based encoding

2019-02-08 Thread Tom Han

Can I get an example of ROI file for a video?
Regards
-Tom

Sent from Mail for Windows 10

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


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread Chris Cunningham
I'll re-send with my full name.

On Fri, Feb 8, 2019 at 4:57 AM Michael Niedermayer 
wrote:

> Hi
>
> On Wed, Feb 06, 2019 at 05:13:03PM -0800, chcunningham wrote:
> > From: chcunningham 
>
> Is the name intended ? As this ends up as author name in git, and several
> developers dislike this:
> (and i cannot edit other authors names of course, that would be not right)
>
> (from IRC)
>  Could you stop committing things like this?
>  his name is "Chris Cunningham", not "chcunningham"
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew
> ..."
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread Chris Cunningham
Codec information may change while reading ogg packets. Update the
stream's internal avctx to match.
---
 libavformat/oggparseogm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index a07453760b..b07a5d55ba 100644
--- a/libavformat/oggparseogm.c
+++ b/libavformat/oggparseogm.c
@@ -114,6 +114,9 @@ ogm_header(AVFormatContext *s, int idx)
 bytestream2_get_buffer(&p, st->codecpar->extradata, 
st->codecpar->extradata_size);
 }
 }
+
+// Update internal avctx with changes to codecpar above.
+st->internal->need_context_update = 1;
 } else if (bytestream2_peek_byte(&p) == 3) {
 bytestream2_skip(&p, 7);
 if (bytestream2_get_bytes_left(&p) > 1)
-- 
2.20.1.791.gb4d0f1c61a-goog

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


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread James Almer
On 2/8/2019 12:17 AM, Chris Cunningham wrote:
> On Wed, Feb 6, 2019 at 6:03 PM James Almer  wrote:
> 
>> Can a valid ogm stream contain more than one header packet?
> 
> 
> Looking at ogg_packet oggdec.c, we read headers until hitting the first
> non-header (counted in ogg stream field nb_headers), so multiple headers
> per stream is probably ok.

Probably ok as in our code currently allows it? Because if the spec
disallows it, then that should be changed.

The ogg demuxer currently looks for at most an specific amount of
headers per stream. In general that means two, parameters and Vorbis
comment metadata, and when the first non header packet is found it stops
trying to read headers.

What i mean with more than one header packet is for example two or more
headers of a given type in the bitstream. I'm fairly sure only one of
each is expected, so parsing any of them a second time, which is what in
this sample of yours is resulting in codec_id NONE being propagated, is
probably not correct.

> But multiple codecs in a given stream seems
> supsect to me. Someone with more ogg expertise should chime in.
> 
> Because the
>> issue here as far as i can see is that ogm_header() is not validating
>> the output of ff_codec_get_id() and is happily accepting and propagating
>> AV_CODEC_ID_NONE as derived from it in a late packet, long after the
>> parser and everything else was already initialized.
>>
>> No other ogg module sets st->internal->need_context_update and all of
>> them may also end up calling the respective header reading function more
>> than once on invalid files, but unlike the ogm one, all of them hardcode
>> the codec_id instead of blindly accepting a potentially bogus value
>> derived from the bitstream.
>>
> 
> I'm open to hard-coding codec for gsm.

No, ogm can have all kinds of codecs, hence it being defined in the
bitstream. It should nonetheless have a check to make sure what's read
is not AV_CODEC_ID_NONE.

> One thing I notice is that the codec
> is just one of several codecpar fields that are potentially changing.
> If any of those change without need_context_update, it seems like values in
> the internal avctx could become stale?

That's why i was wondering if more than one header was allowed. I'm
fairly sure it's not, and the demuxer should ignore any further header
packet if it contains a header of a type already parsed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Lou Logan
On Fri, Feb 8, 2019, at 12:03 AM, Jean-Baptiste Kempf wrote:
>
> Helping people to build non-free distributions of FFmpeg is a very weird 
> and dubious goal.
> This is just helping other people violate the FFmpeg license.

You could say the same thing for other build scripts such as the AUR for Arch 
Linux. It's just a tool. Tools can be misused.

You could apply the same argument to our source code. Having --enable-nonfree 
in the source code helpspeople violate the license. But that's a completely 
different discussion.

I'm not saying it doesn't happen, and I haven't actively searched for it, but I 
don't personally recall any evidence of any homebrew users violating the 
license.

> Do not use Github to develop. Github is not-free.

I believe there are three reasons for the Github suggestion.

1. It makes the homebrew command trivially shorter/simpler for the user:
https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

2. More importantly, a question for those who volunteered (and potentially 
future contributors), would you be less inclined to maintain via a normal, 
non-Github git repo? Would the typical homebrew user know where to report 
issues? Where would they report issues? It's unfortunate that Github is not 
free, but we need to take account of the differences between communities and 
experience.

3. Someone is going to make this ffmpeg "formulae" (as they call it) which will 
become the most popular one among users. I bet it's most certainly going to be 
on Github. I think it's better that we have some ability to be able to edit it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 19:06, Werner Robitza wrote:
> Hello,
> 
> Thanks for your comments.
> 
> On Fri, Feb 8, 2019 at 10:03 AM Jean-Baptiste Kempf  wrote:
> > Why do something special for homebrew, and not for all the other 
> > distributions?
> > Why is homebrew different? Are you going to merge all .spec files from all 
> > Linux distributions too?
> 
> I don't think it's really productive to talk about other Linux
> distributions in this thread. That is really a different topic.

A contrario, this is the exact same topic.
Homebrew 2.0 is now cross-platform and is just a distribution packaging like 
any other "ports".
I don't see why this project should put one distribution mechanism before 
another.

Why not MSys2, why not Chocolatey, why not a BSD port? Those are not linux 
distributions.
What about macports, which is also on OSX, like Homebrew?

I disagree that there is something so special in Homebrew, that warrants it to 
be an exception to all the other distribution systems, especially since now 
Homebrew competes will all the other distribution systems.

> > > That creates a bit of a messy situation, as users are expecting to be
> > > able to build ffmpeg with additional libraries, including nonfree ones
> > > such as fdk-aac. This is no longer easily doable.
> >
> > Helping people to build non-free distributions of FFmpeg is a very weird 
> > and dubious goal.
> > This is just helping other people violate the FFmpeg license.
> 
> That is a matter of personal viewpoint contrasted with general opinion
> about non-free FFmpeg, which I am 1) probably not the right person to
> discuss with, given my lack of presence on this mailing list and 2)
> the fact that the proposed formula simply mirrors what is already
> possible. I may be missing the full picture or developer consensus
> about how to handle this. I understand that there are folks who are
> very passionate about this topic, and that others are not. I can only
> observe that end users have the technical possibilities to build
> FFmpeg in a non-free and non-redistributable fashion. I don't see why
> it would be necessary to artificially restrict users in doing so.

Those are 2 different things: 
- artificially restrict users in doing something,
- advertising and encouraging those capabilities and behaviors.

You can allow the users to do something, see the ffmpeg configure.
But advertising and encouraging those officially (from an official Github 
account) is very different.



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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Jean-Baptiste Kempf


On Fri, 8 Feb 2019, at 21:18, Lou Logan wrote:
> On Fri, Feb 8, 2019, at 12:03 AM, Jean-Baptiste Kempf wrote:
> >
> > Helping people to build non-free distributions of FFmpeg is a very weird 
> > and dubious goal.
> > This is just helping other people violate the FFmpeg license.
> 
> You could say the same thing for other build scripts such as the AUR for 
> Arch Linux. It's just a tool. Tools can be misused.

Yes, but it is not FFmpeg that is maintaining this AUR recipe.
Also, the AUR recipe does not push for non-free packages.

> You could apply the same argument to our source code. Having --enable-
> nonfree in the source code helpspeople violate the license. But that's a 
> completely different discussion.

Source code requires compilation and steps. You must know what you are doing 
when you enable --non-free, after cloning the source.
Not if it is done automatically in homebrew or another way.

> > Do not use Github to develop. Github is not-free.
> 
> I believe there are three reasons for the Github suggestion.
> 
> 1. It makes the homebrew command trivially shorter/simpler for the user:
> https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
> 
> 2. More importantly, a question for those who volunteered (and 
> potentially future contributors), would you be less inclined to maintain 
> via a normal, non-Github git repo? Would the typical homebrew user know 
> where to report issues? Where would they report issues? It's unfortunate 
> that Github is not free, but we need to take account of the differences 
> between communities and experience.
> 
> 3. Someone is going to make this ffmpeg "formulae" (as they call it) 
> which will become the most popular one among users. I bet it's most 
> certainly going to be on Github. I think it's better that we have some 
> ability to be able to edit it.

All those 3 reasons are fine, but they do not change the fact that they get the 
project to support this officially.
It's also by doing those choice like 2) that you accept binary-loaders for 
codecs, instead of RE-ing them: "because the user wants it".

If someone wants to do a Tap for homebrew, because the homebrew people decided 
to disregard their own users, I don't mind. But supporting it from the official 
FFmpeg project is a very different task, and if done, it should be done with 
open source tools (use gitlab if you like github so much), and without the evil 
options.


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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 18:31, Elliott Balsley wrote:
> 
> > On Feb 8, 2019, at 01:17, Jean-Baptiste Kempf  wrote:
> > 
> > Decklink SDK has a very weird EULA + headers license that makes it very 
> > dubious that it is free.
> > Decklink refuses to clarify for now. That warrants a non-free flag.
> > I know it's very weird, since the SDK has the source code of some of the 
> > kernel modules (but not of the glue).
> > 
> > Nvenc is different and has clear headers, and well known driver.
> > 
> 
> I agree it is weird.  I will ping Blackmagic again for clarification, 
> but based on their last statement I think it’s clear that the headers 
> can be distributed under the Boost license contained in each file.

That would be nice.

> Quote: 
> Access to the DeckLink SDK is governed by the EULA and is only available 
> from the Blackmagic Design website. Applications that are built with the 
> SDK are then licensed via the more permissive license contained within 
> the SDK.
> 
> Carl seemed to agree that the headers are not the issue, but the 
> Decklink driver is not considered a system library.  What makes Nvidia a 
> system library if Decklink is not?  They are both closed source drivers 
> used to control a PCIe card.

The source of the driver is in the Linux SDK package, but not of the 
controlling library.
(This is the opposite of the nVidia drivers, from my understanding)


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


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread Carl Eugen Hoyos
2019-02-08 21:07 GMT+01:00, James Almer :
> On 2/8/2019 12:17 AM, Chris Cunningham wrote:
>> On Wed, Feb 6, 2019 at 6:03 PM James Almer  wrote:
>>
>>> Can a valid ogm stream contain more than one header packet?
>>
>>
>> Looking at ogg_packet oggdec.c, we read headers until hitting the first
>> non-header (counted in ogg stream field nb_headers), so multiple headers
>> per stream is probably ok.
>
> Probably ok as in our code currently allows it? Because if the spec
> disallows it, then that should be changed.

If our current code allows it, it should not be changed without
a good reason and certainly not in a patch that fixes an abort.

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


Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

2019-02-08 Thread Carl Eugen Hoyos
2019-02-08 6:08 GMT+01:00, Gyan :
>
>
> On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
>> .
>> No strong opinion here, I hadn't realized that -crf 0 only works with
>> newer versions.
>>
>> Can you explain why crf alone has no effect and needs -b:v 0?
>> Isn't this a bug both with libvpx and libaom?
>>
>
> With crf present but VBV params absent, VPX operates using a constrained
> Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
> has a non-zero default -b of 200 kbps, this produces undesirable
> effects. If set to 0, VPX switches to constant quality.

Yes.
This looks like a bug to me.

> I do see this block though,
>
>  if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
>  enccfg.rc_min_quantizer =
>  enccfg.rc_max_quantizer = 0;
>  } else {
>  if (avctx->qmin >= 0)
>  enccfg.rc_min_quantizer = avctx->qmin;
>  if (avctx->qmax >= 0)
>  enccfg.rc_max_quantizer = avctx->qmax;
>  }
>
>
> Looks like the quantizer range is disabled only by using the deprecated
> option, or has this changed?

Is your question "Isn't 'lossless 1' necessary for lossless encoding"?

> Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
> 0  vs only -lossless 1, with the latter producing a slightly larger
> file, and its result showing a slightly larger SSIM score. Although
> neither produces a SSIM of 1, like libx264. Not truly lossless?

Please provide your input sample.

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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Lou Logan
On Fri, Feb 8, 2019, at 11:27 AM, Jean-Baptiste Kempf wrote:
>
> Also, the AUR recipe does not push for non-free packages.

The proposed homebrew formulae will not push for non-free packages. It will 
simply provide the options for the user to enable two non-free components 
(openssh and fdk-aac currently) if they desire. They have to be explicitly 
enabled by the user by manually including the appropriate option, such as 
"--with-fdk-aac".

> Source code requires compilation and steps. You must know what you are 
> doing when you enable --non-free, after cloning the source.
> Not if it is done automatically in homebrew or another way.

I do not believe the homebrew recipe will automatically enable any non-free 
components. Refer to "def install" in the draft formulae provided by Werner in 
this thread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Elliott Balsley

> The source of the driver is in the Linux SDK package, but not of the 
> controlling library.
> (This is the opposite of the nVidia drivers, from my understanding)

Could you explain what you mean by that? I think the source for both Blackmagic 
and Nvidia libraries are proprietary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v6] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Aman Gupta
On Fri, Feb 8, 2019 at 7:26 AM Mathieu Duponchelle 
wrote:

> ---
>  doc/encoders.texi  |  3 +++
>  libavcodec/mpeg12enc.c | 32 
>  libavcodec/mpegvideo.h |  2 ++
>  3 files changed, 37 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..a283b9fddf 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
> display extension
>  indicating the source of the video pictures. The default is
> @samp{unspecified},
>  can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
> @samp{mac}.
>  For maximum compatibility, use @samp{component}.
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Default is 1 (on).
>  @end table
>
>  @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index d0b458e34b..2bc5289d63 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
>  static uint8_t mpeg1_index_run[2][64];
>  static int8_t  mpeg1_max_level[2][64];
>
> +#define A53_MAX_CC_COUNT 0x1f
> +
>  static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
>  {
>  int i;
> @@ -544,6 +546,36 @@ void ff_mpeg1_encode_picture_header(MpegEncContext
> *s, int picture_number)
>  }
>  }
>
> +if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
> +side_data = av_frame_get_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_A53_CC);
> +if (side_data) {
> +if (side_data->size <= A53_MAX_CC_COUNT * 3 &&
> side_data->size % 3 == 0) {
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(&s->pb, 8, 'G');   //
> user_identifier
> +put_bits(&s->pb, 8, 'A');
> +put_bits(&s->pb, 8, '9');
> +put_bits(&s->pb, 8, '4');
> +put_bits(&s->pb, 8, 3); //
> user_data_type_code
> +put_bits(&s->pb, 8,
> +(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); //
> flags, cc_count
> +put_bits(&s->pb, 8, 0xff);  // em_data
> +
> +for (i = 0; i < side_data->size; i++)
> +put_bits(&s->pb, 8, side_data->data[i]);
> +
> +put_bits(&s->pb, 8, 0xff);  // marker_bits
> +} else {
> +av_log(s->avctx, AV_LOG_WARNING,
> +"Warning Closed Caption size (%d) can not exceed 93
> bytes "
> +"and must be a multiple of 3\n", side_data->size);
> +}
> +}
> +}
> +
>  s->mb_y = 0;
>  ff_mpeg1_encode_slice_header(s);
>  }
> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
> index bbc6b5646a..3e52f98390 100644
> --- a/libavcodec/mpegvideo.h
> +++ b/libavcodec/mpegvideo.h
> @@ -455,6 +455,7 @@ typedef struct MpegEncContext {
>  /* MPEG-2-specific - I wished not to have to support this mess. */
>  int progressive_sequence;
>  int mpeg_f_code[2][2];
> +int a53_cc;
>
>  // picture structure defines are loaded from mpegutils.h
>  int picture_structure;
> @@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
>  {"ps", "RTP payload size in bytes",
>  FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
> INT_MAX, FF_MPV_OPT_FLAGS }, \
>  {"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
> FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
> INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
>  {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre),
> AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> +{ "a53cc", "Use A53 Closed Captions (if available)",
> FF_MPV_OFFSET(a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS
> }, \
>

Could you remove the space after the { to match the other definitions above.


>
>  extern const AVOption ff_mpv_generic_options[];
>
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 22:11, Elliott Balsley wrote:
> 
> > The source of the driver is in the Linux SDK package, but not of the 
> > controlling library.
> > (This is the opposite of the nVidia drivers, from my understanding)
> 
> Could you explain what you mean by that? I think the source for both 
> Blackmagic and Nvidia libraries are proprietary.

In the SDK, you have some sources in the /usr/src folders.
It's probably not the full ones, you are probably correct, I did not spend 
enough time on it.

But this is a different case than nvenc.

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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 22:08, Lou Logan wrote:
> On Fri, Feb 8, 2019, at 11:27 AM, Jean-Baptiste Kempf wrote:
> >
> > Also, the AUR recipe does not push for non-free packages.
> 
> The proposed homebrew formulae will not push for non-free packages. It 
> will simply provide the options for the user to enable two non-free 
> components (openssh and fdk-aac currently) if they desire. They have to 
> be explicitly enabled by the user by manually including the appropriate 
> option, such as "--with-fdk-aac".

Yes, and this is exactly what I am objecting against.
It silently enables non-free, when you ask either. See L 146 and following.

And yes, I strongly advise against the project advertising those non-free 
options.

> > Source code requires compilation and steps. You must know what you are 
> > doing when you enable --non-free, after cloning the source.
> > Not if it is done automatically in homebrew or another way.
> 
> I do not believe the homebrew recipe will automatically enable any non-
> free components. Refer to "def install" in the draft formulae provided 
> by Werner in this thread.

See above and lines 146 and so on.


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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Elliott Balsley
> But this is a different case than nvenc.

How is it different? Nvenc links against  libraries in the proprietary Nvidia 
driver, for which source is not available. This is fine since Nvidia library is 
considered to be a system library under GPL. So why is Blackmagic not 
considered a system library?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread James Almer
On 2/8/2019 5:51 PM, Carl Eugen Hoyos wrote:
> 2019-02-08 21:07 GMT+01:00, James Almer :
>> On 2/8/2019 12:17 AM, Chris Cunningham wrote:
>>> On Wed, Feb 6, 2019 at 6:03 PM James Almer  wrote:
>>>
 Can a valid ogm stream contain more than one header packet?
>>>
>>>
>>> Looking at ogg_packet oggdec.c, we read headers until hitting the first
>>> non-header (counted in ogg stream field nb_headers), so multiple headers
>>> per stream is probably ok.
>>
>> Probably ok as in our code currently allows it? Because if the spec
>> disallows it, then that should be changed.
> 
> If our current code allows it, it should not be changed without
> a good reason and certainly not in a patch that fixes an abort.

Chris' patch is making the demuxer reinitialize the context due to
parameter changes taken from extra headers potentially found in the
bitstream. In contrast, my suggestion is to instead make the demuxer
skip said superfluous/duplicate headers if it turns out that extra
parameter headers are not expected, which seems to be the case given
that all the headers regardless of kind are expected to show up before
the very first data packet.

Both approaches will fix an assert in the parser as autoinserted by the
generic libavformat code, but it's not strictly limited to that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 22:27, Elliott Balsley wrote:
> > But this is a different case than nvenc.
> 
> How is it different? Nvenc links against  libraries in the proprietary 
> Nvidia driver, for which source is not available. This is fine since 
> Nvidia library is considered to be a system library under GPL. So why is 
> Blackmagic not considered a system library?

I'm probably missing something, but my understand was that nvenc was just 
calling the actual driver with a few trampoline functions. The kernel module is 
compilable, but the actual driver is not open source, and installed with the 
machine, but is called from the kernel module. Both are system libraries.

The Decklink part is similar, but has one extra layer of non-open source 
libraries that one need to install, and needs to be linked to.
And it's also very confusing in addition, because of the EULA and the SDK 
license.

Yes, it's similar, but no, it's not similar, because everything Decklink is 
confusing, and a mess.

Also, see the RE-ing clause of the LGPL for the Decklink library.

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


[FFmpeg-devel] [PATCH] avformat/matroskadec: Do not leak queued packets on sync errors

2019-02-08 Thread Michael Niedermayer
Fixes: memleak
Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-5649187601121280

Reported-by: Chris Cunningham 
Tested-by: Chris Cunningham 
Signed-off-by: Michael Niedermayer 
---
 libavformat/matroskadec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4ad99db7db..d7881d9c1d 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3541,7 +3541,7 @@ static int matroska_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 ret = matroska_resync(matroska, pos);
 }
 
-return ret;
+return 0;
 }
 
 static int matroska_read_seek(AVFormatContext *s, int stream_index,
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-08 Thread Marton Balint



On Fri, 8 Feb 2019, Carl Eugen Hoyos wrote:


Hi!

Attached patch fixes ticket #6320, tested with the sample from ticket #7069.

Please comment, Carl Eugen

From fdcd141a29f336925681193a9cdd3f4eaa5c368e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 8 Feb 2019 01:35:33 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
 utf-8.

Fixes ticket #6320.
---
 libavformat/mpegts.c |   33 +
 1 file changed, 33 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..dde610f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,9 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+#if CONFIG_ICONV
+#include 
+#endif

 /* maximum size in which we look for synchronization if
  * synchronization is lost */
@@ -674,6 +677,36 @@ static char *getstr8(const uint8_t **pp, const uint8_t 
*p_end)
 return NULL;
 if (len > p_end - p)
 return NULL;
+#if CONFIG_ICONV
+if (len && *p < 0x20) {
+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""
+};
+iconv_t cd;
+char *in, *out;
+size_t inlen = len - 1, outlen = inlen * 6;
+cd = iconv_open("UTF-8", encodings[*p]);


Can you add support for the ISO-8859-any case where p[0] == 0x10, p[1] == 0x00
and p[2] == any? I will upload a sample to the trac ticket.


+if (cd == (iconv_t)-1)
+goto no_iconv;
+str =
+out = av_malloc(outlen);


I prefer a single line equation. Also outlen + 1 would be much more safe 
because outlen can be 0.



+if (!str)
+return NULL;


you are leaking iconv context here.


+in = (char *)p + 1;
+if (iconv(cd, &in, &inlen, &out, &outlen) == -1) {
+iconv_close(cd);
+goto no_iconv;
+}


and here


+*out = 0;
+*pp = in;


maybe safer to use *pp = p + len, I am not sure iconv always consumes all the 
data.


+return str;
+}
+no_iconv:
+#endif
 str = av_malloc(len + 1);
 if (!str)
 return NULL;


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


[FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available

2019-02-08 Thread Mathieu Duponchelle
---
 doc/encoders.texi  |  3 +++
 libavcodec/mpeg12enc.c | 32 
 libavcodec/mpegvideo.h |  2 ++
 3 files changed, 37 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..a283b9fddf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence 
display extension
 indicating the source of the video pictures. The default is @samp{unspecified},
 can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
 For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Default is 1 (on).
 @end table
 
 @section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..2bc5289d63 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
 static uint8_t mpeg1_index_run[2][64];
 static int8_t  mpeg1_max_level[2][64];
 
+#define A53_MAX_CC_COUNT 0x1f
+
 static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
 {
 int i;
@@ -544,6 +546,36 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int 
picture_number)
 }
 }
 
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size % 3 
== 0) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G');   // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); // 
user_data_type_code
+put_bits(&s->pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); // 
flags, cc_count
+put_bits(&s->pb, 8, 0xff);  // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff);  // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size (%d) can not exceed 93 bytes "
+"and must be a multiple of 3\n", side_data->size);
+}
+}
+}
+
 s->mb_y = 0;
 ff_mpeg1_encode_slice_header(s);
 }
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..e1ff5f97dc 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
 /* MPEG-2-specific - I wished not to have to support this mess. */
 int progressive_sequence;
 int mpeg_f_code[2][2];
+int a53_cc;
 
 // picture structure defines are loaded from mpegutils.h
 int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
 {"ps", "RTP payload size in bytes", 
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, 
INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)", 
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 }, 
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
 {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT, 
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{"a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc), 
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
 
 extern const AVOption ff_mpv_generic_options[];
 
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH] configure: warn about disabled explicitly enabled components

2019-02-08 Thread Marton Balint



On Tue, 5 Feb 2019, Marton Balint wrote:


If we enable a component but a dependant library is disabled, then the enabled
component gets silently disabled. Warning about disabled explicitly enabled 
components
allows configure to show the missing dependencies and if --fatal-warnings is
used it can also fail if the user wants it so.

For example if libdav1d is not availble ./configure --enable-decoder=libdav1d
succeeds but the libdav1d decoder is not be enabled. After the patch configure
will warn about this:

WARNING: Disabled libdav1d_decoder because not all dependencies are satisfied: 
libdav1d

Signed-off-by: Marton Balint 
---
configure | 32 
1 file changed, 28 insertions(+), 4 deletions(-)



Ping.

Thanks,
Marton


diff --git a/configure b/configure
index e1412352fa..c1a203daa3 100755
--- a/configure
+++ b/configure
@@ -648,6 +648,12 @@ request(){
done
}

+warn_if_gets_disabled(){
+for var in $*; do
+WARN_IF_GETS_DISABLED_LIST="$WARN_IF_GETS_DISABLED_LIST $var"
+done
+}
+
enable(){
set_all yes $*
}
@@ -656,6 +662,14 @@ disable(){
set_all no $*
}

+disable_with_reason(){
+disable $1
+eval "${1}_disable_reason=\"$2\""
+if requested $1; then
+die "ERROR: $1 requested, but $2"
+fi
+}
+
enable_weak(){
set_weak yes $*
}
@@ -784,10 +798,10 @@ check_deps(){

[ -n "$dep_ifa" ] && { enabled_all $dep_ifa && enable_weak $cfg; }
[ -n "$dep_ifn" ] && { enabled_any $dep_ifn && enable_weak $cfg; }
-enabled_all  $dep_all || { disable $cfg && requested $cfg && die 
"ERROR: $cfg requested, but not all dependencies are satisfied: $dep_all"; }
-enabled_any  $dep_any || { disable $cfg && requested $cfg && die 
"ERROR: $cfg requested, but not any dependency is satisfied: $dep_any"; }
-disabled_all $dep_con || { disable $cfg && requested $cfg && die 
"ERROR: $cfg requested, but some conflicting dependencies are unsatisfied: $dep_con"; }
-disabled_any $dep_sel && { disable $cfg && requested $cfg && die 
"ERROR: $cfg requested, but some selected dependency is unsatisfied: $dep_sel"; }
+enabled_all  $dep_all || { disable_with_reason $cfg "not all 
dependencies are satisfied: $dep_all"; }
+enabled_any  $dep_any || { disable_with_reason $cfg "not any dependency 
is satisfied: $dep_any"; }
+disabled_all $dep_con || { disable_with_reason $cfg "some conflicting 
dependencies are unsatisfied: $dep_con"; }
+disabled_any $dep_sel && { disable_with_reason $cfg "some selected 
dependency is unsatisfied: $dep_sel"; }

enabled $cfg && enable_deep_weak $dep_sel $dep_sgs

@@ -3880,6 +3894,7 @@ for opt do
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match anything"
+test $action = enable && warn_if_gets_disabled $list
$action $list
;;
--enable-yasm|--disable-yasm)
@@ -7103,6 +7118,15 @@ echo "License: $license"

fi # test "$quiet" != "yes"

+if test -n "$WARN_IF_GETS_DISABLED_LIST"; then
+for cfg in $WARN_IF_GETS_DISABLED_LIST; do
+if disabled $cfg; then
+varname=${cfg}_disable_reason
+eval "warn \"Disabled $cfg because \$$varname\""
+fi
+done
+fi
+
if test -n "$WARNINGS"; then
printf "\n%s%s$WARNINGS%s" "$warn_color" "$bold_color" "$reset_color"
enabled fatal_warnings && exit 1
--
2.16.4

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

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


Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar

2019-02-08 Thread Michael Niedermayer
On Fri, Feb 08, 2019 at 05:07:03PM -0300, James Almer wrote:
> On 2/8/2019 12:17 AM, Chris Cunningham wrote:
> > On Wed, Feb 6, 2019 at 6:03 PM James Almer  wrote:
> > 
> >> Can a valid ogm stream contain more than one header packet?
> > 
> > 
> > Looking at ogg_packet oggdec.c, we read headers until hitting the first
> > non-header (counted in ogg stream field nb_headers), so multiple headers
> > per stream is probably ok.
> 
> Probably ok as in our code currently allows it? Because if the spec
> disallows it, then that should be changed.
> 
> The ogg demuxer currently looks for at most an specific amount of
> headers per stream. In general that means two, parameters and Vorbis
> comment metadata, and when the first non header packet is found it stops
> trying to read headers.
> 
> What i mean with more than one header packet is for example two or more
> headers of a given type in the bitstream. I'm fairly sure only one of
> each is expected, so parsing any of them a second time, which is what in
> this sample of yours is resulting in codec_id NONE being propagated, is
> probably not correct.
> 
> > But multiple codecs in a given stream seems
> > supsect to me. Someone with more ogg expertise should chime in.
> > 
> > Because the
> >> issue here as far as i can see is that ogm_header() is not validating
> >> the output of ff_codec_get_id() and is happily accepting and propagating
> >> AV_CODEC_ID_NONE as derived from it in a late packet, long after the
> >> parser and everything else was already initialized.
> >>
> >> No other ogg module sets st->internal->need_context_update and all of
> >> them may also end up calling the respective header reading function more
> >> than once on invalid files, but unlike the ogm one, all of them hardcode
> >> the codec_id instead of blindly accepting a potentially bogus value
> >> derived from the bitstream.
> >>
> > 
> > I'm open to hard-coding codec for gsm.
> 
> No, ogm can have all kinds of codecs, hence it being defined in the
> bitstream. It should nonetheless have a check to make sure what's read
> is not AV_CODEC_ID_NONE.
> 
> > One thing I notice is that the codec
> > is just one of several codecpar fields that are potentially changing.
> > If any of those change without need_context_update, it seems like values in
> > the internal avctx could become stale?
> 
> That's why i was wondering if more than one header was allowed. I'm
> fairly sure it's not, and the demuxer should ignore any further header
> packet if it contains a header of a type already parsed.

ogg allows chaining streams when they have differing serial numbers
https://xiph.org/ogg/doc/oggstream.html

i think ive seen actual files doing this

ogg_replace_stream() might assign these into existing avstreams i think

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Carl Eugen Hoyos
2019-02-08 22:51 GMT+01:00, Jean-Baptiste Kempf :

> The Decklink part is similar

I don't think it is similar: How can a driver for a very optional hardware
that nearly no user possesses and for which you have to download a
driver via a complicated procedure be called a system library?

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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Michael Niedermayer
On Fri, Feb 08, 2019 at 10:03:36AM +0100, Jean-Baptiste Kempf wrote:
> Hello,
> 
> On Wed, 6 Feb 2019, at 21:41, Werner Robitza wrote:
> > Homebrew has, with its 2.0 release, removed all options for its core
> > formulae [1], including ffmpeg. This means users can no longer add
> > non-default dependencies that aren't included in the core formula [2].
> 
> > I propose that FFmpeg maintains its own ffmpeg formula under its
> > GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
> 
> Why do something special for homebrew, and not for all the other 
> distributions?

I dont think anyone suggested that. Any other "distribution" should be treated
equal. I think homebrew is the first to suggest to have something put on 
git*/ffmpeg. Whatever we do (or do not do) here we should do the same if
another distro is in a similar situation and asks too.


> Why is homebrew different? Are you going to merge all .spec files from all 
> Linux distributions too?
> 
> > That creates a bit of a messy situation, as users are expecting to be
> > able to build ffmpeg with additional libraries, including nonfree ones
> > such as fdk-aac. This is no longer easily doable.
> 
> Helping people to build non-free distributions of FFmpeg is a very weird and 
> dubious goal.
> This is just helping other people violate the FFmpeg license.

obviously, that should not be done. 
And i would have thought that this also was not the goal


> 
> > Please let me know your thoughts.
> 
> Do not use Github to develop. Github is not-free. Use Github to mirror, if 
> you want, but not to develop.

i would suggest that too.

thanks

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

You can kill me, but you cannot change the truth.


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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Jean-Baptiste Kempf
On Fri, 8 Feb 2019, at 23:42, Carl Eugen Hoyos wrote:
> 2019-02-08 22:51 GMT+01:00, Jean-Baptiste Kempf :
> 
> > The Decklink part is similar
> 
> I don't think it is similar: How can a driver for a very optional hardware
> that nearly no user possesses and for which you have to download a
> driver via a complicated procedure be called a system library?

It is a dkms driver, exactly like nVidia. It could be packaged in the same way 
by the Linux distributions.
It is delivered within a tarball, with a Makefile, and a dkms conf.
So, yes, it is similar.

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


Re: [FFmpeg-devel] [PATCH] configure: warn about disabled explicitly enabled components

2019-02-08 Thread Carl Eugen Hoyos
2019-02-05 22:14 GMT+01:00, Marton Balint :
> If we enable a component but a dependant library is disabled, then the
> enabled
> component gets silently disabled. Warning about disabled explicitly enabled
> components
> allows configure to show the missing dependencies and if --fatal-warnings is
> used it can also fail if the user wants it so.
>
> For example if libdav1d is not availble ./configure
> --enable-decoder=libdav1d
> succeeds but the libdav1d decoder is not be enabled. After the patch
> configure
> will warn about this:
>
> WARNING: Disabled libdav1d_decoder because not all dependencies are
> satisfied: libdav1d

The patch produces many warnings for:
$ ./configure --disable-everything --enable-decoder=mp*
Is this intended?

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-08 Thread Carl Eugen Hoyos
2019-02-08 23:09 GMT+01:00, Marton Balint :
>
>
> On Fri, 8 Feb 2019, Carl Eugen Hoyos wrote:
>
>> Hi!
>>
>> Attached patch fixes ticket #6320, tested with the sample from ticket
>> #7069.
>>
>> Please comment, Carl Eugen
>>
>> From fdcd141a29f336925681193a9cdd3f4eaa5c368e Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Fri, 8 Feb 2019 01:35:33 +0100
>> Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
>>  utf-8.
>>
>> Fixes ticket #6320.
>> ---
>>  libavformat/mpegts.c |   33 +
>>  1 file changed, 33 insertions(+)
>>
>> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> index b04fd7b..dde610f 100644
>> --- a/libavformat/mpegts.c
>> +++ b/libavformat/mpegts.c
>> @@ -37,6 +37,9 @@
>>  #include "avio_internal.h"
>>  #include "mpeg.h"
>>  #include "isom.h"
>> +#if CONFIG_ICONV
>> +#include 
>> +#endif
>>
>>  /* maximum size in which we look for synchronization if
>>   * synchronization is lost */
>> @@ -674,6 +677,36 @@ static char *getstr8(const uint8_t **pp, const
>> uint8_t *p_end)
>>  return NULL;
>>  if (len > p_end - p)
>>  return NULL;
>> +#if CONFIG_ICONV
>> +if (len && *p < 0x20) {
>> +const char *encodings[] = {
>> +"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
>> "ISO-8859-8",
>> +"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "",
>> "ISO-8859-13",
>> +"ISO-8859-14", "ISO-8859-15", "", "", "", "",
>> +"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8",
>> "",
>> +"", "", "", "", "", "", "", "", ""
>> +};
>> +iconv_t cd;
>> +char *in, *out;
>> +size_t inlen = len - 1, outlen = inlen * 6;
>> +cd = iconv_open("UTF-8", encodings[*p]);
>
> Can you add support for the ISO-8859-any case where
> p[0] == 0x10, p[1] == 0x00
> and p[2] == any? I will upload a sample to the trac ticket.

New patch attached.

Thank you, Carl Eugen
From 9033f0a18727a7a576c4cc06b9985d6d922d46ad Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 00:49:51 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
 utf-8.

Fixes ticket #6320.
---
 libavformat/mpegts.c |   48 
 1 file changed, 48 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..1e27500 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,9 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+#if CONFIG_ICONV
+#include 
+#endif
 
 /* maximum size in which we look for synchronization if
  * synchronization is lost */
@@ -674,6 +677,51 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end)
 return NULL;
 if (len > p_end - p)
 return NULL;
+#if CONFIG_ICONV
+if (len && *p < 0x20) {
+char iso8859[] = "ISO-8859-00";
+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""
+};
+iconv_t cd;
+char *in, *out;
+size_t inlen = len - 1, outlen = inlen * 6 + 1;
+if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf && p[2] != 0xc) {
+if (p[2] < 10) {
+iso8859[9] += p[2];
+iso8859[10] = 0;
+} else {
+iso8859[9]++;
+iso8859[10] += p[2] - 10;
+}
+in = (char *)p + 3;
+cd = iconv_open("UTF-8", iso8859);
+} else {
+in = (char *)p + 1;
+cd = iconv_open("UTF-8", encodings[*p]);
+}
+if (cd == (iconv_t)-1)
+goto no_iconv;
+str = out = av_malloc(outlen);
+if (!str) {
+iconv_close(cd);
+return NULL;
+}
+if (iconv(cd, &in, &inlen, &out, &outlen) == -1) {
+iconv_close(cd);
+goto no_iconv;
+}
+iconv_close(cd);
+*out = 0;
+*pp = p + len;
+return str;
+}
+no_iconv:
+#endif
 str = av_malloc(len + 1);
 if (!str)
 return NULL;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH] configure: warn about disabled explicitly enabled components

2019-02-08 Thread Marton Balint



On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:


2019-02-05 22:14 GMT+01:00, Marton Balint :

If we enable a component but a dependant library is disabled, then the
enabled
component gets silently disabled. Warning about disabled explicitly enabled
components
allows configure to show the missing dependencies and if --fatal-warnings is
used it can also fail if the user wants it so.

For example if libdav1d is not availble ./configure
--enable-decoder=libdav1d
succeeds but the libdav1d decoder is not be enabled. After the patch
configure
will warn about this:

WARNING: Disabled libdav1d_decoder because not all dependencies are
satisfied: libdav1d


The patch produces many warnings for:
$ ./configure --disable-everything --enable-decoder=mp*
Is this intended?


It reports only disabled decoders which start with mp, so it works as it 
should the way I see it.


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


[FFmpeg-devel] [PATCH]lavu/parseutils: Allow to parse >100 hours

2019-02-08 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes ticket #7721 for the reporter.

Please comment, Carl Eugen
From ba6abc57d563bcc22607ff5d9f77fdce76000bf6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 01:20:43 +0100
Subject: [PATCH] lavu/parseutils: Allow to parse >= 100 hours.

Reported and tested by gamnark.
Fixes ticket #7721.
---
 libavutil/parseutils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 59bec6c..167e822 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -504,7 +504,7 @@ char *av_small_strptime(const char *p, const char *fmt, struct tm *dt)
 switch(c) {
 case 'H':
 case 'J':
-val = date_get_num(&p, 0, c == 'H' ? 23 : INT_MAX, 2);
+val = date_get_num(&p, 0, c == 'H' ? 23 : INT_MAX, c == 'H' ? 2 : 4);
 
 if (val == -1)
 return NULL;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-02-08 Thread Elliott Balsley

> my understand was that nvenc was just calling the actual driver with a few 
> trampoline functions. The kernel module is compilable, but the actual driver 
> is not open source, and installed with the machine, but is called from the 
> kernel module. Both are system libraries.
The Nvidia Driver is not part of the OS, it needs to be installed by the user.  
Some distros make it easier by including it in their package manager, but not 
on Windows or Mac.  I’m not sure what kinds of calls are made to the driver, 
but it is definitely required.

> The Decklink part is similar, but has one extra layer of non-open source 
> libraries that one need to install, and needs to be linked to.
The installer puts a few closed-source libraries in /usr/lib/ which is the same 
thing done by the Nvidia Driver.  I am still not seeing any difference between 
the two.



> On Feb 8, 2019, at 14:42, Carl Eugen Hoyos  wrote:
> How can a driver for a very optional hardware
Calling this optional depends on the computer’s job.  In some industries it’s 
an essential component — I could name dozens of commercial and free softwares 
which rely on it.  And remember, it’s quite possible to run a headless machine 
that uses the GPU only for compute operations.
> that nearly no user possesses
Blackmagic has sold hundreds of thousands of Decklink devices, and the number 
of people who own a piece of hardware is irrelevant here.
> and for which you have to download a
> driver via a complicated procedure be called a system library?
You have to accept the confusing EULA, but the process is exactly the same for 
Nvidia, minus entering your name.  To obtain Nvidia drivers you must accept the 
EULA on their website.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

2019-02-08 Thread Gyan



On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:

2019-02-08 6:08 GMT+01:00, Gyan :


On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:

.
No strong opinion here, I hadn't realized that -crf 0 only works with
newer versions.

Can you explain why crf alone has no effect and needs -b:v 0?
Isn't this a bug both with libvpx and libaom?


With crf present but VBV params absent, VPX operates using a constrained
Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
has a non-zero default -b of 200 kbps, this produces undesirable
effects. If set to 0, VPX switches to constant quality.

Yes.
This looks like a bug to me.
If there's a bug, it's in libav, in that, we can't signal when a value 
is assigned by the user or via user-initiated logic, versus being 
assigned as a default fallback. So it's a design conflict, and the 
workaround has been long documented.


Maybe just before the next major bump, a new field should be introduced 
in AVOptions which registers if the field was populated at the behest of 
the user.

I do see this block though,

  if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
  enccfg.rc_min_quantizer =
  enccfg.rc_max_quantizer = 0;
  } else {
  if (avctx->qmin >= 0)
  enccfg.rc_min_quantizer = avctx->qmin;
  if (avctx->qmax >= 0)
  enccfg.rc_max_quantizer = avctx->qmax;
  }


Looks like the quantizer range is disabled only by using the deprecated
option, or has this changed?

Is your question "Isn't 'lossless 1' necessary for lossless encoding"?
Yes. A quick glance at vpx HEAD indicates it is, although -qmin & -qmax 
0 should also work.



Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
0  vs only -lossless 1, with the latter producing a slightly larger
file, and its result showing a slightly larger SSIM score. Although
neither produces a SSIM of 1, like libx264. Not truly lossless?

Please provide your input sample.
I can reproduce the difference in result with 
fate-suite/h264-conformance/src19td.IBP.264


although the `-lossless 1` encoding does return as lossless in SSIM.

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