Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

> On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel  
> wrote:
> 
> On 14/05/2024 17:09, Christian Bartnik wrote:
>> From: Thomas Siedel 
>> Add external decoder VVdeC for H266/VVC decoding.
>> Register new decoder libvvdec.
>> Add libvvdec to wrap the vvdec interface.
>> Enable decoder by adding --enable-libvvdec in configure step.
>> Co-authored-by: Christian Bartnik chris1031...@gmail.com
>> Signed-off-by: Christian Bartnik 
>> ---
>>  configure  |   5 +
>>  libavcodec/Makefile|   1 +
>>  libavcodec/allcodecs.c |   1 +
>>  libavcodec/libvvdec.c  | 617 +
>>  4 files changed, 624 insertions(+)
>>  create mode 100644 libavcodec/libvvdec.c
> 
> I would prefer to have this one skipped, as initially suggested.

Why? I tried to look back through the list but didn't see anything.

- Cosmin
___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

> On May 18, 2024, at 7:04 AM, Nuo Mi  wrote:
> 
> This happened many years ago. See the discussion here:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589
> Now that we have an internal vvc decoder, we can focus on improving it.
> As for the encoder, it is far more complex than the decoder. Reasonable to
> wrapper other libraries just like libx264 and libx265...

I'm all for improving the internal decoder, and I agree that the internal 
decoder should be preferred and be used by default, but it's not clear why that 
should preclude adding an external decoder as an option.

Sometimes bugs are found in the internal decoders or some functionality may be 
missing, and having the option to fallback to an external decoder as a 
workaround is very useful in practice.

For example there's a native AAC decoder in ffmpeg but it's still useful to 
have FDK-AAC available for decoding when running into edge cases on the native 
AAC decoder, or to decode USAC while the new decoder is under development, etc.

- Cosmin
___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont  wrote:

Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel 
mailto:ffmpeg-devel@ffmpeg.org> > a écrit :


On May 18, 2024, at 7:04 AM, Nuo Mi mailto:nuomi2...@gmail.com> > wrote:

This happened many years ago. See the discussion here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589
 
<https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589>
 
Now that we have an internal vvc decoder, we can focus on improving it.
As for the encoder, it is far more complex than the decoder. Reasonable to
wrapper other libraries just like libx264 and libx265...

I'm all for improving the internal decoder, and I agree that the internal 
decoder should be preferred and be used by default, but it's not clear why that 
should preclude adding an external decoder as an option.

Adding a disabled-by-default decoder is adding bloat, if there is not a 
specific known reason why that is needed.

This is especially true for video decoders, where the external decoders 
typically will have no or worse optimisations for DSP functions, no thread 
support (or not accessible via libavcodec), 

Is this an actual problem with vvdec? To me it seems like a reasonably 
optimized decoder with support for threading, etc.

and no integration with hwaccel.

The later point has become a problem even with dav1d...

hwaccel decoding seems somewhat orthogonal


Sometimes bugs are found in the internal decoders

Providing a non-default choice is a poor excuse for a bug. Most users won't 
know how to do that, 

need better documentation?

and many FFmpeg reverse dependencies don't even allow it.

not sure that designing for the lowest common denominator of reverse 
dependencies is the best way to do things, but at a minimum one can rebuild 
ffmpeg with only one decoder enabled to get around this


or some functionality may be missing, and having the option to fallback to an 
external decoder as a workaround is very useful in practice.

That I can agree, but what do you find missing in the VVC decoder compared to 
libvvcdec?
___

This I'm not sure, perhaps there is no feature gap? Does the internal VVC 
decoder supports all features of the Main10 profile?

- Cosmin
___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

Trying again with better formatting, hopefully

> On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont  wrote:
> 
> Hi,
> 
> Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel 
>  a écrit :
>> 
>> 
>>> On May 18, 2024, at 7:04 AM, Nuo Mi  wrote:
>>> 
>>> This happened many years ago. See the discussion here:
>>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589
>>> Now that we have an internal vvc decoder, we can focus on improving it.
>>> As for the encoder, it is far more complex than the decoder. Reasonable to
>>> wrapper other libraries just like libx264 and libx265...
>> 
>> I'm all for improving the internal decoder, and I agree that the internal 
>> decoder should be preferred and be used by default, but it's not clear why 
>> that should preclude adding an external decoder as an option.
> 
> Adding a disabled-by-default decoder is adding bloat, if there is not a 
> specific known reason why that is needed.
> 
> This is especially true for video decoders, where the external decoders 
> typically will have no or worse optimisations for DSP functions, no thread 
> support (or not accessible via libavcodec), and no integration with hwaccel.

Is this an actual problem with vvdec? To me it seems like a reasonably 
optimized decoder with support for threading, etc. hwaccel decoding seems 
somewhat orthogonal

> 
> The later point has become a problem even with dav1d...
> 
>> Sometimes bugs are found in the internal decoders
> 
> Providing a non-default choice is a poor excuse for a bug. Most users won't 
> know how to do that, and many FFmpeg reverse dependencies don't even allow it.

Need better documentation then? Not sure that designing for the lowest common 
denominator of reverse dependencies is the best way to do things, but at a 
minimum one can rebuild ffmpeg with only one decoder enabled to get around this.

> 
>> or some functionality may be missing, and having the option to fallback to 
>> an external decoder as a workaround is very useful in practice.
> 
> That I can agree, but what do you find missing in the VVC decoder compared to 
> libvvcdec?

This I'm not sure, perhaps there is no feature gap? Does the internal VVC 
decoder supports all features of the Main10 profile?

- Cosmin
___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

> On May 20, 2024, at 11:03 AM, Rémi Denis-Courmont  wrote:
> 
> Le maanantaina 20. toukokuuta 2024, 19.33.43 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
> 
>> hwaccel decoding seems somewhat orthogonal
> 
> How exactly will that work then? Either vvdec is the default, and hwaccel 
> won't work, or vvdec is not the default and it's essentially dead code.

The same way using FDK-AAC as a decoder works, if you want to use it as the 
*AAC decoder you have to specify the decoder with -c:a libfdk_aac before the 
input.-

> 
>>> Providing a non-default choice is a poor excuse for a bug. Most users
>>> won't know how to do that, and many FFmpeg reverse dependencies don't
>>> even allow it.
>> 
>> Need better documentation then?
> 
> Well, good luck with that. Documentation for working around as yet unknown 
> bugs sounds a bit difficult to write, and even then, requiring manual decoder 
> selection seems very user-hostile to me.

Where is the "requiring" part coming in? I'm saying that manual decoder 
selection is an option in the ffmpeg CLI, and can be used to select an 
alternate decoder if the default one is not sufficient for some reason. 

This is a thing I've had to do repeatedly over the past few years for FDK-AAC.

> 
>> Not sure that designing for the lowest common denominator of reverse
>> dependencies is the best way to do things, but at a minimum one can rebuild
>> ffmpeg with only one decoder enabled to get around this.
> 
> To the contrary, gstreamer, mpv, VLC et al. are better equipped to handle 
> this, starting with a proper plugin architecture.

Better equipped to handle what? For the usecase of transcoding it doesn't 
matter whether or not downstream player dependencies do or don't expose 
alternate decoders in libavcodec, to the extent they even use libavcodec for 
decoding.

So it seems weird to reject a patch to add a decoder option because it may or 
may not be useful to the downstream players.
 
- Cosmin
___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

> On May 20, 2024, at 12:01 PM, Rémi Denis-Courmont  wrote:
> 
> Le maanantaina 20. toukokuuta 2024, 21.39.18 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> The same way using FDK-AAC as a decoder works, if you want to use it as the
>> *AAC decoder you have to specify the decoder with -c:a libfdk_aac before
>> the input.-
> 
> AFAIK, we don't have hwaccel for audio codecs. That sentence makes zero sense.

This is unrelated to hwaccel, I'm illustrating how a non-default decoder is 
selected in practice. It just so happens I always need to do this for audio 
currently.

> 
> And again, you can't expect users to select decoders manually. If vvdec is 
> the 
> default, hwaccel won't work. If vvdec is not the default, then it's dead code.

Not sure why you keep returning to this false dichotomy. 

You absolutely can have a decoder that's not the default, there is a facility 
for selecting it, and I use this to select the non-default decoder despite you 
claiming that non-default decoders are dead code, or that manually selecting 
them isn't a thing that users do.

>> Where is the "requiring" part coming in? I'm saying that manual decoder
>> selection is an option in the ffmpeg CLI, and can be used to select an
>> alternate decoder if the default one is not sufficient for some reason. 
> 
> So most people use libavcodec through higher-level frameworks or 
> applications, 
> not the CLI tool, and that is especially true for playback. If that's the 
> super-niche use-case for vvdec, then I agree with Kieran that it's just bloat.

Yes, the use case would be to be an alternate decoder that's available to users 
that want to use it. If that's not your use case that's ok, don't build with 
--enable-libvvdec.



- Cosmin


___
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 v3 2/2] avcodec: add external dec libvvdec for H266/VVC

[Cosmin Stejerean via ffmpeg-devel]

> On May 20, 2024, at 1:05 PM, Rémi Denis-Courmont  wrote:
> 
> Le maanantaina 20. toukokuuta 2024, 22.33.45 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>>> And again, you can't expect users to select decoders manually. If vvdec is
>>> the 
>>> default, hwaccel won't work. If vvdec is not the default, then it's
>>> dead code.
>> 
>> Not sure why you keep returning to this false dichotomy. 
> 
> It is the default or it is not the default. This is a true dichotomy and it 
> is 
> very disingenous to claim otherwise, so I will leave it at that.

You stated it's either the default or dead code. This is the false dichotomy I 
was referring to. Seems disingenuous to claim otherwise.

- Cosmin



___
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] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

It looks like the el_bitdepth_minus8 value in the header can also encode
ext_mapping_idc in the upper 8 bits.

Samples having a non-zero ext_mapping_idc fail validation currently because the
value returned is out of range. This bypasses this by currently ignoring the
ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.

---
 libavcodec/dovi_rpudec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 7c7eda9d09..1b11ad3640 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -411,7 +411,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 
 if ((hdr->rpu_format & 0x700) == 0) {
 int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
-int el_bit_depth_minus8 = get_ue_golomb_31(gb);
+// this can encode a two byte value, with higher byte being 
ext_mapping_idc
+// use only the lower byte for el_bit_depth_minus8
+uint8_t el_bit_depth_minus8 = get_ue_golomb_long(gb) & 0xFF;
 int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
 VALIDATE(bl_bit_depth_minus8, 0, 8);
 VALIDATE(el_bit_depth_minus8, 0, 8);
-- 
2.42.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] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Co-authored-by: Amir Naghdinezhad 
Signed-off-by: Cosmin Stejerean 
---
 libavcodec/libsvtav1.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (svt_ret == EB_NoErrorEmptyQueue)
 return AVERROR(EAGAIN);
 
+#if SVT_AV1_CHECK_VERSION(2, 0, 0)
+if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
+ svt_enc->eos_flag = EOS_RECEIVED;
+ svt_av1_enc_release_out_buffer(&headerPtr);
+ return AVERROR_EOF;
+}
+#endif
+
 ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
 if (!ref) {
 av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
@@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
 pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
 
+#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
 if (headerPtr->flags & EB_BUFFERFLAG_EOS)
 svt_enc->eos_flag = EOS_RECEIVED;
+#endif
 
 ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0, 
pict_type);
 
-- 
2.42.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] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On May 20, 2024, at 6:17 PM, Cosmin Stejerean via ffmpeg-devel 
>  wrote:
> 
> From: Cosmin Stejerean 
> 
> Co-authored-by: Amir Naghdinezhad 
> Signed-off-by: Cosmin Stejerean 
> ---
> libavcodec/libsvtav1.c | 10 ++
> 1 file changed, 10 insertions(+)
> 

Disregard this one, it was previously applied. It was left over in my patches 
folder by mistake and git send-email picked it up again.

- Cosmin


___
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] avcodec/dovi - disable metadata compression by default

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

not all clients support metadata compression, make this an option and off by
default until we can verify output.

vdr_dm_metadata_changed = 0 case fails the DV verifier so force this to true
for now until we can determine the correct output format for this case.


---
 libavcodec/dovi_rpu.h| 5 +
 libavcodec/dovi_rpuenc.c | 8 ++--
 libavcodec/libaomenc.c   | 1 +
 libavcodec/libsvtav1.c   | 1 +
 libavcodec/libx265.c | 1 +
 5 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 8ce0c88e9d..fca30804ae 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -71,6 +71,11 @@ typedef struct DOVIContext {
 AVDOVIDmData *ext_blocks;
 int num_ext_blocks;
 
+/**
+ * Enable metadata compression in the output. Currently this is 
experimental.
+ */
+int enable_compression;
+
 /**
  * Private fields internal to dovi_rpu.c
  */
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3c3e0f84c0..26ed25733a 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -512,8 +512,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 }
 }
 
-vdr_dm_metadata_changed = !s->color || memcmp(s->color, color, 
sizeof(*color));
-use_prev_vdr_rpu = !memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, 
sizeof(*mapping));
+// the output when vdr_dm_metadata_changed is 0 fails the DV verifier
+// force it to 1 until we can get some samples or documentation on correct 
syntax
+vdr_dm_metadata_changed = 1; // !s->color || memcmp(s->color, color, 
sizeof(*color));
+
+// not all clients support metadata compression
+use_prev_vdr_rpu = s->enable_compression && 
!memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, sizeof(*mapping));
 
 buffer_size = 12 /* vdr seq info */ + 5 /* CRC32 + terminator */;
 buffer_size += num_ext_blocks_v1 * 13;
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..c6104f5522 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1489,6 +1489,7 @@ static const AVOption options[] = {
 { "still-picture", "Encode in single frame mode (typically used for still 
AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, -1, 1, VE 
},
 { "dolbyvision", "Enable Dolby Vision RPU coding", 
OFFSET(dovi.enable), AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, 
.unit = "dovi" },
 {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
 { "enable-rect-partitions", "Enable rectangular partitions", 
OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-ab-partitions",   "Enable ab shape partitions",
OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2fef8c8971..86bb6686dd 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -733,6 +733,7 @@ static const AVOption options[] = {
 
 { "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
 {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
 
 {NULL},
 };
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index ac1dbc4f97..2a79a5e6da 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -953,6 +953,7 @@ static const AVOption options[] = {
 #if X265_BUILD >= 167
 { "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
 {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
 #endif
 { NULL }
 };
-- 
2.42.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] avcodec/dovi_rpudec - correctly read el_bit_depth_minus8 when ext_mapping_idc is non-zero

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 3:21 AM, Niklas Haas  wrote:
> 
> On Tue, 21 May 2024 01:17:32 +0000 Cosmin Stejerean via ffmpeg-devel 
>  wrote:
>> From: Cosmin Stejerean 
>> 
>> It looks like the el_bitdepth_minus8 value in the header can also encode
>> ext_mapping_idc in the upper 8 bits.
>> 
>> Samples having a non-zero ext_mapping_idc fail validation currently because 
>> the
>> value returned is out of range. This bypasses this by currently ignoring the
>> ext_mapping_idc and using only the lower 8 bits for el_bitdepth_minus8.
> 
> What is ext_mapping_idc? If it's signalled data that can't be
> reconstructed, we need to store it somewhere into AVDOVIMetadata and
> then re-synthesize it during encoding. Otherwise the RPU transcode will
> be lossy.

I'm not actually sure what it does, but from what I can tell on the current 
samples it doesn't matter if in the process of transcoding it ends up being set 
to 0. However it's not hard to save it and re-synthesize it so I can send a new 
patch that does that.

- Cosmin
___
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 v2] avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.

Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.

---
 libavcodec/dovi_rpudec.c | 7 ++-
 libavcodec/dovi_rpuenc.c | 4 +++-
 libavutil/dovi_meta.h| 2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 7c7eda9d09..af41ab5827 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -411,13 +411,18 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 
 if ((hdr->rpu_format & 0x700) == 0) {
 int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
-int el_bit_depth_minus8 = get_ue_golomb_31(gb);
+int el_bit_depth_minus8_and_ext_mapping_idc = 
get_ue_golomb_long(gb);
+int el_bit_depth_minus8 = el_bit_depth_minus8_and_ext_mapping_idc 
& 0xFF; // lowest 8 bits
+int ext_mapping_idc = (el_bit_depth_minus8_and_ext_mapping_idc & 
0xFF00) >> 8; // upper 8 bits
+
 int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
 VALIDATE(bl_bit_depth_minus8, 0, 8);
 VALIDATE(el_bit_depth_minus8, 0, 8);
 VALIDATE(vdr_bit_depth_minus8, 0, 8);
 hdr->bl_bit_depth = bl_bit_depth_minus8 + 8;
 hdr->el_bit_depth = el_bit_depth_minus8 + 8;
+hdr->ext_mapping_idc_0_4 = ext_mapping_idc & 0x1F; // lowest 5 
bits of ext_mapping_idc
+hdr->ext_mapping_idc_5_7 = (ext_mapping_idc & 0xE0) >> 5; // upper 
3 bits of ext_mapping_idc
 hdr->vdr_bit_depth = vdr_bit_depth_minus8 + 8;
 hdr->spatial_resampling_filter_flag = get_bits1(gb);
 skip_bits(gb, 3); /* reserved_zero_3bits */
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3c3e0f84c0..91c0a85050 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -444,6 +444,7 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 int vdr_dm_metadata_changed, vdr_rpu_id, use_prev_vdr_rpu, profile,
 buffer_size, rpu_size, pad, zero_run;
 int num_ext_blocks_v1, num_ext_blocks_v2;
+uint8_t ext_mapping_idc;
 uint32_t crc;
 uint8_t *dst;
 if (!metadata) {
@@ -551,7 +552,8 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 put_bits(pb, 1, hdr->bl_video_full_range_flag);
 if ((hdr->rpu_format & 0x700) == 0) {
 set_ue_golomb(pb, hdr->bl_bit_depth - 8);
-set_ue_golomb(pb, hdr->el_bit_depth - 8);
+ext_mapping_idc = (hdr->ext_mapping_idc_5_7 << 5) | 
hdr->ext_mapping_idc_0_4;
+set_ue_golomb(pb, (ext_mapping_idc << 8) | hdr->el_bit_depth - 8);
 set_ue_golomb(pb, hdr->vdr_bit_depth - 8);
 put_bits(pb, 1, hdr->spatial_resampling_filter_flag);
 put_bits(pb, 3, 0); /* reserved_zero_3bits */
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index e10332f8d7..d01bfe19fe 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -87,6 +87,8 @@ typedef struct AVDOVIRpuDataHeader {
 uint8_t bl_video_full_range_flag;
 uint8_t bl_bit_depth; /* [8, 16] */
 uint8_t el_bit_depth; /* [8, 16] */
+uint8_t ext_mapping_idc_0_4; /* extended base layer inverse mapping 
indicator */
+uint8_t ext_mapping_idc_5_7; /* reserved */
 uint8_t vdr_bit_depth; /* [8, 16] */
 uint8_t spatial_resampling_filter_flag;
 uint8_t el_spatial_resampling_filter_flag;
-- 
2.42.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 01/13] avformat/flvenc: Implement support for multi-track video

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 11:48 AM, Dennis Sädtler via ffmpeg-devel 
>  wrote:
> 
>> From: Dennis Sädtler via ffmpeg-devel 
> 
> I wonder what happened here, did I make a mistake when submitting the
> original patch to the ML so the actual commit author name/email got
> lost?
> 
> Should be the same as the signed-off section based on the repo I
> submitted it from:
> https://github.com/derrod/ffmpeg/commit/25f1700cffa00fcd04bcc27efce077a93e7f5142
> 

The problem is the mailing list rewrites the message (to for example add the 
footer at the bottom). It cannot do that and keep the from email address if you 
have email security configured properly for the domain (as it would get 
rejected). 

So the mailing list changes the from to " via ffmpeg-devel 
". Furthermore git send-email won't include "From:" in 
the patch body if the commit authorship matches the from email address on git 
send-email. 

However I've found a workaround. By setting my git send-email from to just 
"cos...@cosmin.at " rather than "Cosmin Stejerean 
mailto:cos...@cosmin.at>>" then the emails that go out will 
have the "From: " as the first line of the body, so the patches apply properly. 
You can see my most recent patch for example.

You can add an entry to .mailmap to handle any previous commits that have been 
pushed using the "via ffmpeg-devel" rewrite, see my entry for example.


- Cosmin




___
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 01/13] avformat/flvenc: Implement support for multi-track video

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel 
>  wrote:
> 
> 
> However I've found a workaround. By setting my git send-email from to just 
> "cos...@cosmin.at <mailto:cos...@cosmin.at>" rather than "Cosmin Stejerean 
> mailto:cos...@cosmin.at>>" then the emails that go out 
> will have the "From: " as the first line of the body, so the patches apply 
> properly. You can see my most recent patch for example.
> 

The email client is trying to be too helpful here adding extra formatting to 
the message body. The .gitconfig should look something like this, using your 
email address without <> and without the name.

from = cos...@cosmin.at

That works in my testing.

- Cosmin



___
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 01/13] avformat/flvenc: Implement support for multi-track video

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel 
>  wrote:
> 
> 
> However I've found a workaround. By setting my git send-email from to just 
> "cos...@cosmin.at <mailto:cos...@cosmin.at>" rather than "Cosmin Stejerean 
> mailto:cos...@cosmin.at>>" then the emails that go out 
> will have the "From: " as the first line of the body, so the patches apply 
> properly. You can see my most recent patch for example.
> 

The email client is trying to be too helpful here adding extra formatting to 
the message body. The .gitconfig should look something like this, using your 
email address without <> and without the name.

from = cos...@cosmin.at

That works in my testing.

- Cosmin



___
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] avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 9:19 PM, Andreas Rheinhardt 
>  wrote:
> 
> Cosmin Stejerean via ffmpeg-devel:
>> From: Cosmin Stejerean 
>> 
>> These two fields are coded together into a single 16 bit integer with upper 8
>> bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.
>> 
>> Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 
>> bits.
> 
> How do you know about these fields? You seem to know something that
> Niklas doesn't.

I can see them in the output of the DoVi verifier.

 RPU Header
...
  |  Sequence header
...
  |BL_video_full_range_flag  0
  |BL_bit_depth  10
  |EL_bit_depth  10
  |ext_mapping_idc[4:0]  1
  |ext_mapping_idc[7:5]  4
  |vdr_bit_depth 12
...

>> --- a/libavutil/dovi_meta.h
>> +++ b/libavutil/dovi_meta.h
>> @@ -87,6 +87,8 @@ typedef struct AVDOVIRpuDataHeader {
>> uint8_t bl_video_full_range_flag;
>> uint8_t bl_bit_depth; /* [8, 16] */
>> uint8_t el_bit_depth; /* [8, 16] */
>> +uint8_t ext_mapping_idc_0_4; /* extended base layer inverse mapping 
>> indicator */
>> +uint8_t ext_mapping_idc_5_7; /* reserved */
> 
> This is an ABI break. All new additions need to be put at the end.
> Furthermore this needs an entry in APIChanges and a lavu minor version
> bump. And it should be in a patch of its own.

Ok, sending v3.

- Cosmin
___
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 v3 1/2] lavu/dovi_meta - add fields for ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

---
 libavutil/dovi_meta.h | 2 ++
 libavutil/version.h   | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index e10332f8d7..e168075a24 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -91,6 +91,8 @@ typedef struct AVDOVIRpuDataHeader {
 uint8_t spatial_resampling_filter_flag;
 uint8_t el_spatial_resampling_filter_flag;
 uint8_t disable_residual_flag;
+uint8_t ext_mapping_idc_0_4; /* extended base layer inverse mapping 
indicator */
+uint8_t ext_mapping_idc_5_7; /* reserved */
 } AVDOVIRpuDataHeader;
 
 enum AVDOVIMappingMethod {
diff --git a/libavutil/version.h b/libavutil/version.h
index 3221c4c592..9c7146c228 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  59
-#define LIBAVUTIL_VERSION_MINOR  19
+#define LIBAVUTIL_VERSION_MINOR  20
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.42.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 v3 2/2] avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.

Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.
---
 libavcodec/dovi_rpudec.c | 7 ++-
 libavcodec/dovi_rpuenc.c | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 7c7eda9d09..af41ab5827 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -411,13 +411,18 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 
 if ((hdr->rpu_format & 0x700) == 0) {
 int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
-int el_bit_depth_minus8 = get_ue_golomb_31(gb);
+int el_bit_depth_minus8_and_ext_mapping_idc = 
get_ue_golomb_long(gb);
+int el_bit_depth_minus8 = el_bit_depth_minus8_and_ext_mapping_idc 
& 0xFF; // lowest 8 bits
+int ext_mapping_idc = (el_bit_depth_minus8_and_ext_mapping_idc & 
0xFF00) >> 8; // upper 8 bits
+
 int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
 VALIDATE(bl_bit_depth_minus8, 0, 8);
 VALIDATE(el_bit_depth_minus8, 0, 8);
 VALIDATE(vdr_bit_depth_minus8, 0, 8);
 hdr->bl_bit_depth = bl_bit_depth_minus8 + 8;
 hdr->el_bit_depth = el_bit_depth_minus8 + 8;
+hdr->ext_mapping_idc_0_4 = ext_mapping_idc & 0x1F; // lowest 5 
bits of ext_mapping_idc
+hdr->ext_mapping_idc_5_7 = (ext_mapping_idc & 0xE0) >> 5; // upper 
3 bits of ext_mapping_idc
 hdr->vdr_bit_depth = vdr_bit_depth_minus8 + 8;
 hdr->spatial_resampling_filter_flag = get_bits1(gb);
 skip_bits(gb, 3); /* reserved_zero_3bits */
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3c3e0f84c0..91c0a85050 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -444,6 +444,7 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 int vdr_dm_metadata_changed, vdr_rpu_id, use_prev_vdr_rpu, profile,
 buffer_size, rpu_size, pad, zero_run;
 int num_ext_blocks_v1, num_ext_blocks_v2;
+uint8_t ext_mapping_idc;
 uint32_t crc;
 uint8_t *dst;
 if (!metadata) {
@@ -551,7 +552,8 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 put_bits(pb, 1, hdr->bl_video_full_range_flag);
 if ((hdr->rpu_format & 0x700) == 0) {
 set_ue_golomb(pb, hdr->bl_bit_depth - 8);
-set_ue_golomb(pb, hdr->el_bit_depth - 8);
+ext_mapping_idc = (hdr->ext_mapping_idc_5_7 << 5) | 
hdr->ext_mapping_idc_0_4;
+set_ue_golomb(pb, (ext_mapping_idc << 8) | hdr->el_bit_depth - 8);
 set_ue_golomb(pb, hdr->vdr_bit_depth - 8);
 put_bits(pb, 1, hdr->spatial_resampling_filter_flag);
 put_bits(pb, 3, 0); /* reserved_zero_3bits */
-- 
2.42.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 v3 0/2] avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Some DolbyVision samples fail to parse currently due to mis-reading the
el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has
been extended in an as of yet undocumented way by adding ext_mapping_idc and
coding it together with el_bit_depth_minus8 together into a single 16 bit
integer with the upper 8 bits for ext_mapping_idc and the lower 8 bits for
el_bit_depth_minus8.

This can be observed in the output of the DoVi verifier, which shows how this
is laid out. This patchset adds the new fields to dovi_meta and implements the
code to parse and write this back out.

Compared to the previous version it moves the fields to the end for ABI
compatibility, bumps the minor version in lavu and splits this into a separate
commit.

Cosmin Stejerean (2):
  lavu/dovi_meta - add fields for ext_mapping_idc
  avcodec/dovi - correctly read el_bit_depth_minus8 and ext_mapping_idc

 libavcodec/dovi_rpudec.c | 7 ++-
 libavcodec/dovi_rpuenc.c | 4 +++-
 libavutil/dovi_meta.h| 2 ++
 libavutil/version.h  | 2 +-
 4 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.42.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] avcodec/dovi - disable metadata compression by default

[Cosmin Stejerean via ffmpeg-devel]

> On May 21, 2024, at 3:19 AM, Niklas Haas  wrote:
> 
> On Tue, 21 May 2024 04:03:43 +0000 Cosmin Stejerean via ffmpeg-devel 
>  wrote:
>> 
>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>> index dec74ebecd..c6104f5522 100644
>> --- a/libavcodec/libaomenc.c
>> +++ b/libavcodec/libaomenc.c
>> @@ -1489,6 +1489,7 @@ static const AVOption options[] = {
>> { "still-picture", "Encode in single frame mode (typically used for 
>> still AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, 
>> -1, 1, VE },
>> { "dolbyvision", "Enable Dolby Vision RPU coding", 
>> OFFSET(dovi.enable), AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, 
>> VE, .unit = "dovi" },
>> {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, 
>> .flags = VE, .unit = "dovi" },
>> +{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
>> OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
>> { "enable-rect-partitions", "Enable rectangular partitions", 
>> OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
>> OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> { "enable-ab-partitions",   "Enable ab shape partitions",
>> OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
>> index 2fef8c8971..86bb6686dd 100644
>> --- a/libavcodec/libsvtav1.c
>> +++ b/libavcodec/libsvtav1.c
>> @@ -733,6 +733,7 @@ static const AVOption options[] = {
>> 
>> { "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
>> AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
>> {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, 
>> .flags = VE, .unit = "dovi" },
>> +{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
>> OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
>> 
>> {NULL},
>> };
>> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
>> index ac1dbc4f97..2a79a5e6da 100644
>> --- a/libavcodec/libx265.c
>> +++ b/libavcodec/libx265.c
>> @@ -953,6 +953,7 @@ static const AVOption options[] = {
>> #if X265_BUILD >= 167
>> { "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
>> AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
>> {   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, 
>> .flags = VE, .unit = "dovi" },
>> +{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
>> OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
>> #endif
> 
> Setting up an extra AVClass here seems more hassle than it's worth, but
> maybe we could at least hide these options behind a preprocessor
> definition so that multiple files can reference them without blatantly
> duplicating code?
> 

Sending a revised v2 that moves these to a shared preprocessor definition.


- Cosmin
___
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 v2] avcodec/dovi - disable metadata compression by default

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

not all clients support metadata compression, output when 
vdr_dm_metadata_changed fails the DV verifier.
---
 libavcodec/dovi_rpu.h| 10 ++
 libavcodec/dovi_rpuenc.c |  8 ++--
 libavcodec/libaomenc.c   |  3 +--
 libavcodec/libsvtav1.c   |  3 +--
 libavcodec/libx265.c |  3 +--
 5 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 8ce0c88e9d..dee34165c9 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -28,6 +28,11 @@
 #include "libavutil/frame.h"
 #include "avcodec.h"
 
+#define DOVI_ENCODING_OPTS \
+{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" }, \
+{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" }, \
+{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
+
 #define DOVI_MAX_DM_ID 15
 typedef struct DOVIContext {
 void *logctx;
@@ -71,6 +76,11 @@ typedef struct DOVIContext {
 AVDOVIDmData *ext_blocks;
 int num_ext_blocks;
 
+/**
+ * Enable metadata compression in the output. Currently this is 
experimental.
+ */
+int enable_compression;
+
 /**
  * Private fields internal to dovi_rpu.c
  */
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3c3e0f84c0..26ed25733a 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -512,8 +512,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 }
 }
 
-vdr_dm_metadata_changed = !s->color || memcmp(s->color, color, 
sizeof(*color));
-use_prev_vdr_rpu = !memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, 
sizeof(*mapping));
+// the output when vdr_dm_metadata_changed is 0 fails the DV verifier
+// force it to 1 until we can get some samples or documentation on correct 
syntax
+vdr_dm_metadata_changed = 1; // !s->color || memcmp(s->color, color, 
sizeof(*color));
+
+// not all clients support metadata compression
+use_prev_vdr_rpu = s->enable_compression && 
!memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, sizeof(*mapping));
 
 buffer_size = 12 /* vdr seq info */ + 5 /* CRC32 + terminator */;
 buffer_size += num_ext_blocks_v1 * 13;
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..3837eaaec2 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1487,8 +1487,7 @@ static const AVOption options[] = {
 { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_SSIM}, 0, 0, VE, .unit = "tune"},
 FF_AV1_PROFILE_OPTS
 { "still-picture", "Encode in single frame mode (typically used for still 
AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, -1, 1, VE 
},
-{ "dolbyvision", "Enable Dolby Vision RPU coding", 
OFFSET(dovi.enable), AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, 
.unit = "dovi" },
-{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+DOVI_ENCODING_OPTS
 { "enable-rect-partitions", "Enable rectangular partitions", 
OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-ab-partitions",   "Enable ab shape partitions",
OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2fef8c8971..d747c31824 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -731,8 +731,7 @@ static const AVOption options[] = {
   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
 { "svtav1-params", "Set the SVT-AV1 configuration using a :-separated list 
of key=value parameters", OFFSET(svtav1_opts), AV_OPT_TYPE_DICT, { 0 }, 0, 0, 
VE },
 
-{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
-{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+DOVI_ENCODING_OPTS
 
 {NULL},
 };
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index ac1dbc4f97..30a0b3d205 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -951,8 +951,7 @@ static const AVOption options[] = {
 { "a53cc",   "Use A53 Closed Captions (if available)", 
 OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   { .i64 = 1 }, 0, 1, 
VE },
 { "x265-params", "set the x265 configuration using a :-separated list of 
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_DICT,   { 0 }, 0, 0, VE },
 #if X265_BUILD >= 167
-{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSE

[FFmpeg-devel] [PATCH v3 0/5] avcodec/dovi - disable metadata compression by default

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

not all clients support metadata compression, output when 
vdr_dm_metadata_changed fails the DV verifier.

Compared to v2 this makes the dovi field name a parameter of the
DOVI_ENCODING_OPTS macro as requested.  It also splits up the commits into
introducing the macro, guarding compression by it, and then leveraging it in
the encoder.

I split up each encoder into a separate patch since the original support was
added in separate patches but this could also be squashed when applying if
that's better.

Cosmin Stejerean (5):
  avcodec/dovi_rpu - add field to disable metadata compression
  avcodec/dovi_rpuenc - guard metadata compression by enable_compression
  avcodec/libaomenc - switch DolbyVision options to DOVI_ENCODING_OPTS
  avcodec/libsvtav1 - switch DolbyVision options to DOVI_ENCODING_OPTS
  avcodec/libx265 - switch DolbyVision options to DOVI_ENCODING_OPTS

 libavcodec/dovi_rpu.h| 10 ++
 libavcodec/dovi_rpuenc.c |  8 ++--
 libavcodec/libaomenc.c   |  3 +--
 libavcodec/libsvtav1.c   |  3 +--
 libavcodec/libx265.c |  3 +--
 5 files changed, 19 insertions(+), 8 deletions(-)

-- 
2.42.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 v3 1/5] avcodec/dovi_rpu - field and macro for metadata compression

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 


Add a field to enable or disable metadata compression since not all clients 
support this.

Introduce DOVI_ENCODING_OPTS macro to faciliate exposing this as an option to 
encoders.

---
 libavcodec/dovi_rpu.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 8ce0c88e9d..5406425c0d 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -28,6 +28,11 @@
 #include "libavutil/frame.h"
 #include "avcodec.h"
 
+#define DOVI_ENCODING_OPTS(dovi) \
+{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" }, \
+{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" }, \
+{ "dv_enable_compression", "Enable Dolby Vision metadata compression", 
OFFSET(dovi.enable_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, VE },
+
 #define DOVI_MAX_DM_ID 15
 typedef struct DOVIContext {
 void *logctx;
@@ -71,6 +76,11 @@ typedef struct DOVIContext {
 AVDOVIDmData *ext_blocks;
 int num_ext_blocks;
 
+/**
+ * Enable metadata compression in the output. Currently this is 
experimental.
+ */
+int enable_compression;
+
 /**
  * Private fields internal to dovi_rpu.c
  */
-- 
2.42.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 v3 2/5] avcodec/dovi_rpuenc - guard metadata compression

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Guard use_prev_vdr_rpu by the new enable_compression field since not all
clients support this.

Separately output when vdr_dm_metadata_changed == 0 fails the DV verifier so
turn that off unconditionally for now.


---
 libavcodec/dovi_rpuenc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3c3e0f84c0..26ed25733a 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -512,8 +512,12 @@ int ff_dovi_rpu_generate(DOVIContext *s, const 
AVDOVIMetadata *metadata,
 }
 }
 
-vdr_dm_metadata_changed = !s->color || memcmp(s->color, color, 
sizeof(*color));
-use_prev_vdr_rpu = !memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, 
sizeof(*mapping));
+// the output when vdr_dm_metadata_changed is 0 fails the DV verifier
+// force it to 1 until we can get some samples or documentation on correct 
syntax
+vdr_dm_metadata_changed = 1; // !s->color || memcmp(s->color, color, 
sizeof(*color));
+
+// not all clients support metadata compression
+use_prev_vdr_rpu = s->enable_compression && 
!memcmp(&s->vdr[vdr_rpu_id]->mapping, mapping, sizeof(*mapping));
 
 buffer_size = 12 /* vdr seq info */ + 5 /* CRC32 + terminator */;
 buffer_size += num_ext_blocks_v1 * 13;
-- 
2.42.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 v3 3/5] avcodec/libaomenc - switch to DOVI_ENCODING_OPTS

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

---
 libavcodec/libaomenc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index dec74ebecd..22429717e8 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1487,8 +1487,7 @@ static const AVOption options[] = {
 { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_SSIM}, 0, 0, VE, .unit = "tune"},
 FF_AV1_PROFILE_OPTS
 { "still-picture", "Encode in single frame mode (typically used for still 
AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, -1, 1, VE 
},
-{ "dolbyvision", "Enable Dolby Vision RPU coding", 
OFFSET(dovi.enable), AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, 
.unit = "dovi" },
-{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+DOVI_ENCODING_OPTS(dovi)
 { "enable-rect-partitions", "Enable rectangular partitions", 
OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-ab-partitions",   "Enable ab shape partitions",
OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
-- 
2.42.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 v3 5/5] avcodec/libx265 - switch to DOVI_ENCODING_OPTS

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

---
 libavcodec/libx265.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index ac1dbc4f97..70e447fc0e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -951,8 +951,7 @@ static const AVOption options[] = {
 { "a53cc",   "Use A53 Closed Captions (if available)", 
 OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   { .i64 = 1 }, 0, 1, 
VE },
 { "x265-params", "set the x265 configuration using a :-separated list of 
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_DICT,   { 0 }, 0, 0, VE },
 #if X265_BUILD >= 167
-{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
-{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+DOVI_ENCODING_OPTS(dovi)
 #endif
 { NULL }
 };
-- 
2.42.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 v3 4/5] avcodec/libsvtav1 - switch to DOVI_ENCODING_OPTS

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

---
 libavcodec/libsvtav1.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 2fef8c8971..4a8cab4eb9 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -731,8 +731,7 @@ static const AVOption options[] = {
   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
 { "svtav1-params", "Set the SVT-AV1 configuration using a :-separated list 
of key=value parameters", OFFSET(svtav1_opts), AV_OPT_TYPE_DICT, { 0 }, 0, 0, 
VE },
 
-{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
-{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+DOVI_ENCODING_OPTS(dovi)
 
 {NULL},
 };
-- 
2.42.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 v3 1/2] lavu/dovi_meta - add fields for ext_mapping_idc

[Cosmin Stejerean via ffmpeg-devel]

> On May 23, 2024, at 4:03 AM, Niklas Haas  wrote:
> 
> On Wed, 22 May 2024 15:50:43 +0000 Cosmin Stejerean via ffmpeg-devel 
>  wrote:
>> From: Cosmin Stejerean 
>> 
>> ---
>> libavutil/dovi_meta.h | 2 ++
>> libavutil/version.h   | 2 +-
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
>> index e10332f8d7..e168075a24 100644
>> --- a/libavutil/dovi_meta.h
>> +++ b/libavutil/dovi_meta.h
>> @@ -91,6 +91,8 @@ typedef struct AVDOVIRpuDataHeader {
>> uint8_t spatial_resampling_filter_flag;
>> uint8_t el_spatial_resampling_filter_flag;
>> uint8_t disable_residual_flag;
>> +uint8_t ext_mapping_idc_0_4; /* extended base layer inverse mapping 
>> indicator */
>> +uint8_t ext_mapping_idc_5_7; /* reserved */
>> } AVDOVIRpuDataHeader;
> 
> What value ranges have you seen for this indicator? Is it possible that
> some values would extend the RPU in other ways, adding more bits that we
> need to parse?

So far I've only seen two sets of values. 

The samples from the iPhone:

ext_mapping_idc[4:0] = 0
ext_mapping_idc[7:5] = 0

The samples from Xiaomi and Oppo:

ext_mapping_idc[4:0] = 1
ext_mapping_idc[7:5] = 4

I don't have any additional information on what the possible range of values 
could be so far.
As far as I can tell it has no impact on the size of the subsequent fields, at 
least for what I've encountered so far.


> 
> Maybe we should enforce this to be a well-known value just to be on the
> safe side, until we receive public documentation on its purpose.
> 

I think to avoid being brittle we should allow the entire range of values for 
now until we know better, and just ensure it roundtrips correctly (which I've 
verified by running the validator on the 10.4 output transcoded from 8.4 input).

Once we track down more info we can try to add more validation on top of it.

- Cosmin





___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 12:55 AM, Rémi Denis-Courmont  wrote:
> 
> IBC is probably not as (cost-)problematic as NAB, w.r.t. setting up the booth 
> or transportation

What was cost-problematic about NAB? As far as I know it cost ffmpeg $0. It 
would be hard for IBC to be less cost-problematic than that.


- Cosmin
___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 10:36 AM, Rémi Denis-Courmont  wrote:
> 
> Le 3 juin 2024 19:43:52 GMT+03:00, Cosmin Stejerean via ffmpeg-devel 
>  a écrit :
>> 
>> 
>>> On Jun 3, 2024, at 12:55 AM, Rémi Denis-Courmont  wrote:
>>> 
>>> IBC is probably not as (cost-)problematic as NAB, w.r.t. setting up the 
>>> booth or transportation
>> 
>> What was cost-problematic about NAB? As far as I know it cost ffmpeg $0.
>> It would be hard for IBC to be less cost-problematic than that.
> 
> Booth setup is notoriously expensive due to local regulations. This was 
> already mentioned on the list earlier, and no explanations were given how 
> this would be funded.

The basic booth package that was donated includes a simple booth with a table 
and two chairs. Thilo brought a banner and a table cloth. I donated a power 
strip and a case of water for the people at the booth. That was the extent of 
the booth setup, there were no costs.

> 
> Well in hindsight, based on what was reported by NAB attendees, I surmise 
> that the setup wasn't done nor funded at all and the booth was FFmpeg in name 
> only. (That sounds like embezzlement to me but that is not really our 
> problem, I guess.)


What do you mean by setup wasn't done or funded and the booth was FFmpeg in 
name only? An accusation of embezzlement sounds serious.


- Cosmin



___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 11:18 AM, Rémi Denis-Courmont  wrote:
> 
> Le maanantaina 3. kesäkuuta 2024, 20.48.08 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>>>> What was cost-problematic about NAB? As far as I know it cost ffmpeg $0.
>>>> It would be hard for IBC to be less cost-problematic than that.
>>> 
>>> 
>>> Booth setup is notoriously expensive due to local regulations. This was
>>> already mentioned on the list earlier, and no explanations were given how
>>> this would be funded.
>> 
>> The basic booth package that was donated includes a simple booth with a
>> table and two chairs. Thilo brought a banner and a table cloth. I donated a
>> power strip and a case of water for the people at the booth. That was the
>> extent of the booth setup, there were no costs.
> 
> This is news. Why was that plan not communicated when the question was raised 
> on this mailing list after the announcement of the NAB sponsorship?

I believe Thilo responded that there were no costs to ffmpeg back then.

> 
>>> Well in hindsight, based on what was reported by NAB attendees, I surmise
>>> that the setup wasn't done nor funded at all and the booth was FFmpeg in
>>> name only. (That sounds like embezzlement to me but that is not really
>>> our problem, I guess.)
>> 
>> What do you mean by setup wasn't done or funded and the booth was FFmpeg in
>> name only?
> 
> GPAC self reported on using the FFmpeg booth at NAB:
> https://x.com/JanetGrecoBP/status/1773342135514779700
> 
> Devin even reported on this very list that there were *only* GPAC people:
> https://ffmpeg.org//pipermail/ffmpeg-devel/2024-April/325765.html
> 
> If there were at least three of you, then why did you not reply to Devin back 
> then and why did you not arrange to keep at least one person on the booth 
> while the other went eating?

Thilo called Devin to discuss this later that day, I addressed it on IRC and I 
think it was addressed on the mailing list as well. 

Not sure why you keep beating this dead horse. Yes, there were limited times 
when none of the ffmpeg people happened to be at the booth, and it just so 
happened that was the only time Devin had to stop by.

The vast majority of the time there was at least one of Thilo and Ramiro at the 
booth and I helped to fill in when I could. To claim "it was an FFmpeg booth in 
name only" is an insult to the time that Thilo and Ramiro put into this. 

This is was a volunteer effort, you're welcome to volunteer for the IBC booth 
to increase the probability of there being an FFmpeg developer present at the 
booth at all times.


> 
>> An accusation of embezzlement sounds serious.
> 
> If as she herself alleged, Mrs Janet Greco used the FFmpeg booth for her or 
> her employer's commercial interest, then that is embezzlement by the 
> dictionary definition: the IBC booth funding that Thilo secured from the 
> anonymous sponsor for FFmpeg would instead have been used by those third 
> parties.

It was not "instead used by those parties". They shared space at the booth, a 
relatively common practice at NAB. 

For what it's worth I was also not aware that GPAC would be sharing space with 
ffmpeg at NAB, but it's orthogonal to whether there are any booth setup costs. 

GPAC's contribution was to also bring a banner to hang next to the ffmpeg one.

> 
> IANAL, so I won't comment if this meets the legal definition.

Then you might want to avoid throwing such accusations around.

- Cosmin
___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 12:26 PM, Rémi Denis-Courmont  wrote:
> 
> Le maanantaina 3. kesäkuuta 2024, 21.58.48 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> Not sure why you keep beating this dead horse.
> 
> Err, I think that it is obvious why:
> 
> 1) The questions were not answered back then. Calling the people asking 
> questions troll is not answering, it's insulting.
> 
> 2) IBC came up today, in much the same way as NAB did.

The costs or lack thereof came up today. Making accusations that it was FFmpeg 
in name only did not come up until you brought it up, and seems completely 
uncalled for.

> 
>> This is was a volunteer effort, you're welcome to volunteer for the IBC
>> booth to increase the probability of there being an FFmpeg developer
>> present at the booth at all times.
> 
> I don't know about that. I mean, I did obtain an FFmpeg booth at SCaLE. A 
> boot 
> that Thilo unilaterally canceled because He could not attend. You know, 
> instead of asking for volunteers. And when I brought that out here, I was 
> called a troll.
> 

I have no idea what happened with SCaLE. However if you put something together 
in future years I might be able to volunteer, it's a relatively short drive for 
me from Vegas.

The situation with Thilo cancelling the booth sounds like a miscommunication, 
you may want to discuss this directly with Thilo?

In any case, don't let that prevent you from volunteering at IBC if that's 
something you're interested in.

> And the CC apparently find that both the cancellation and insults were, at 
> least except for the one member that resigned.
> 
>>>> An accusation of embezzlement sounds serious.
>>> 
>>> 
>>> If as she herself alleged, Mrs Janet Greco used the FFmpeg booth for her
>>> or her employer's commercial interest, then that is embezzlement by the
>>> dictionary definition: the IBC booth funding that Thilo secured from the
>>> anonymous sponsor for FFmpeg would instead have been used by those third
>>> parties.
> 
>> It was not "instead used by those parties". They shared space at the booth,
>> a relatively common practice at NAB.
> 
> You are splitting hairs. They were using a booth designated FFmpeg and paid 
> for as sponsorship to a non-profit for their own commercial interest. This is 
> legally and fiscally sketchy. And presumably the "relatively common practice 
> at 
> NAB" is for multiple companies to share booths, or for the company to pay for 
> a booth and host a non-profit, not the other way around.
> 
> 

GPAC is a popular open source media project, and the banner at the booth was 
for GPAC. To me it was very much two open source media projects sharing a booth 
rather than some random commercial company.

Motion Spell is to GPAC roughly what FFLabs is to FFmpeg, only with a lot less 
drama around it, and some additional tools in the toolbox like providing a 
commercial license.

While I found it surprising to share a booth with them, since "their own 
commercial interest" is to get companies to fund their open source project, 
much like we're all trying to get funding for FFmpeg, it didn't seem 
particularly problematic.

That said I'm all for not doing this again in the future, but again it's 
orthogonal to the costs for an FFmpeg booth at either NAB or IBC. 

- Cosmin
___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 3:58 PM, Vittorio Giovara  
> wrote:
> 
> On Mon, Jun 3, 2024 at 10:57 PM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
>> 
>> 
>>> On Jun 3, 2024, at 12:26 PM, Rémi Denis-Courmont 
>> wrote:
>>> 
>>> Le maanantaina 3. kesäkuuta 2024, 21.58.48 EEST Cosmin Stejerean via
>> ffmpeg-
>>> devel a écrit :
>>>> Not sure why you keep beating this dead horse.
>>> 
>>> Err, I think that it is obvious why:
>>> 
>>> 1) The questions were not answered back then. Calling the people asking
>>> questions troll is not answering, it's insulting.
>>> 
>>> 2) IBC came up today, in much the same way as NAB did.
>> 
>> The costs or lack thereof came up today. Making accusations that it was
>> FFmpeg in name only did not come up until you brought it up, and seems
>> completely uncalled for.
>> 
> 
> Reposting my question/comment here since Thilo hasn't had a chance to
> respond, but shouldn't these kinds of requests go through the GA? If
> anybody can do whatever they want with the ffmpeg name, then what's the
> point of voting and following the established process?
> 

Probably? I'm not actually sure what the process is for getting an FFmpeg booth 
at a conference. Is there a documented process somewhere for how this should be 
done? If not this might be a good opportunity to create one.

It might also make for a good topic of discussion at VDD. For how much drama 
there was about NAB on the list I was surprised there was zero discussion about 
it at FOSDEM.

> I think this is the underlying problem with booth management, everybody
> acts like they own the place, and nothing changes from one event to
> another, instead of taking notes to improve the situation. For example :
> thilo or you sending a note to the GA "hey i got sponsorship for
> IBC/NAB/whatever, I plan to represent ffmpeg, and have a b c as objectives.
> Is that cool with you all? If yes, can we host GPAC and other multimedia
> foss projects?" would have avoided a lot of drama.

No disagreements from me, I do think that might have avoided a lot of drama.

Regarding the "or you" part, I wasn't involved in securing sponsorship for NAB 
or IBC. I did volunteer to help with NAB because I happen to live in Vegas and 
I enjoy spending time with other ffmpeg developers. I'm happy to help at NAB 
next year as well should it happen again.

I have no plans to attend IBC and no involvement with the FFmpeg booth at IBC. 
I am merely trying to correct the perception that NAB was cost-problematic, 
since no money was paid by the project for NAB.



- Cosmin
___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 11:53 PM, Vittorio Giovara  
> wrote:
> 
> On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
>>> Reposting my question/comment here since Thilo hasn't had a chance to
>>> respond, but shouldn't these kinds of requests go through the GA? If
>>> anybody can do whatever they want with the ffmpeg name, then what's the
>>> point of voting and following the established process?
>> 
>> Probably? I'm not actually sure what the process is for getting an FFmpeg
>> booth at a conference. Is there a documented process somewhere for how this
>> should be done? If not this might be a good opportunity to create one.
>> 
> 
> Agreed, do you have a draft you could share as a base of discussion? Once
> defined, we could have the GA vote on it
> 

If you really want to work on a proposal I'm happy to collaborate with you 
offline to draft something and then propose it to the GA.

> 
>> It might also make for a good topic of discussion at VDD. For how much
>> drama there was about NAB on the list I was surprised there was zero
>> discussion about it at FOSDEM.
>> 
> 
> There were probably more important topics to discuss and the lingering hope
> that the problematic points would have been handled better than by calling
> people trolls
> 

Perhaps. Shall we set something up at VDD? I think in person discussion can go 
a long way to avoid the kind of miscommunication that can happen over email.

> 
> I don't think anybody is suggesting that booths are cost-problematic, but
> rather they are lacking in process (one shouldn't allowed use ffmpeg name
> "just because") and in scope (aka "the why" and what kind of results are
> expected by investing time in said booth)

My part of this thread started by responding to "IBC is probably not as 
(cost-)problematic as NAB, w.r.t. setting up the booth or transportation".

- Cosmin
___
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/dovi_rpudec: replace brittle struct copying code

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 5, 2024, at 5:23 AM, Niklas Haas  wrote:
> 
> On Wed, 05 Jun 2024 12:07:08 +0200 Andreas Rheinhardt 
>  wrote:
>> Niklas Haas:
>>> From: Niklas Haas 
>>> 
>>> This code was unnecessarily trying to be robust against downgrades of
>>> libavutil (relative to the version libavcodec was compiled against), but
>>> in the process, ended up with very brittle code that is easy to
>>> accidentally forget to update when adding new fields.
>>> 
>>> Instead, do the obvious thing and just directly copy the parts of the
>>> struct known at compile time. Since it is not generally supported to
>>> link against a version of libavutil older than the version libavcodec
>>> was compiled against, the struct shrinking externally is not a case we
>>> need to be worrying about.
>> 
>> The exact opposite is true: The code is trying to be robust against
>> upgrades of libavutil. The reason for this is potential trailing padding
>> in the structures that are copied here. It may be used for actual stuff
>> in a future libavutil and the approach you use here allows the compiler
>> to clobber it.
>> 
>> (How would this code be robust against downgrades of libavutil at all?
>> There is no check here that sizeof of the side data is big enough to
>> contain everything we expect it to contain.)
> 
> I should clearly not write code immediately after waking up.
> 
> Yes, true, the only thing this logic is trying to accomplish is being
> robust against the struct gaining extra padding in the future.
> 
> That said, I still think the code as written is brittle and I'm not sure
> it's providing anything useful. What is the likelihood of this struct
> being extended in a way that does not affect the encoder, vs. the
> likelihood of this struct being extended but somebody forgetting to bump
> the equivalent "last field" entry in this file?
> 
> Anecdotally, the latter has already happened once.

+1, having already tripped on this on my patch to add ext_mapping_idc* fields I 
can confirm that it's easy to trip on this, easy to miss unless you carefully 
inspect the RPU afterwards,  and then hard to spot where the problem is without 
having to trace through the code and catch this copy. 

The new approach seems much better in practice.

- Cosmin
___
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 v3 0/5] avcodec/dovi - disable metadata compression by default

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 19, 2024, at 3:21 AM, Niklas Haas  wrote:
> 
> On Thu, 23 May 2024 19:50:23 +0000 Cosmin Stejerean via ffmpeg-devel 
>  wrote:
>> From: Cosmin Stejerean 
>> 
>> not all clients support metadata compression, output when 
>> vdr_dm_metadata_changed fails the DV verifier.
>> 
>> Compared to v2 this makes the dovi field name a parameter of the
>> DOVI_ENCODING_OPTS macro as requested.  It also splits up the commits into
>> introducing the macro, guarding compression by it, and then leveraging it in
>> the encoder.
>> 
>> I split up each encoder into a separate patch since the original support was
>> added in separate patches but this could also be squashed when applying if
>> that's better.
>> 
>> Cosmin Stejerean (5):
>>  avcodec/dovi_rpu - add field to disable metadata compression
>>  avcodec/dovi_rpuenc - guard metadata compression by enable_compression
>>  avcodec/libaomenc - switch DolbyVision options to DOVI_ENCODING_OPTS
>>  avcodec/libsvtav1 - switch DolbyVision options to DOVI_ENCODING_OPTS
>>  avcodec/libx265 - switch DolbyVision options to DOVI_ENCODING_OPTS
>> 
>> libavcodec/dovi_rpu.h| 10 ++
>> libavcodec/dovi_rpuenc.c |  8 ++--
>> libavcodec/libaomenc.c   |  3 +--
>> libavcodec/libsvtav1.c   |  3 +--
>> libavcodec/libx265.c |  3 +--
>> 5 files changed, 19 insertions(+), 8 deletions(-)
>> 
>> -- 
>> 2.42.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".
> 
> I suppose this series is redundant now with the compression changes from
> my BSF patchset?
> 
> Unless we want to preserve the macro for purely stylistic reasons, but
> we can probably stomach the duplication of only a single option field.
> 

Agreed, I think we can abandon this patchset in favor of the BSF one. 

- Cosmin


___
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] avcodec/dovi_rpudec: fix reading el_bit_depth_minus8

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

now that we are reading ext_mapping_idc as the upper 8 bits of
el_bit_depth_minus8 we need to use get_ue_golomb_long rather than
get_ue_golomb_31 for reading it

---
 libavcodec/dovi_rpudec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index 8cafdcf5e6..c025800206 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -420,7 +420,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 
 if ((hdr->rpu_format & 0x700) == 0) {
 int bl_bit_depth_minus8 = get_ue_golomb_31(gb);
-int el_bit_depth_minus8 = get_ue_golomb_31(gb);
+int el_bit_depth_minus8 = get_ue_golomb_long(gb);
 int vdr_bit_depth_minus8 = get_ue_golomb_31(gb);
 int reserved_zero_3bits;
 /* ext_mapping_idc is in the upper 8 bits of el_bit_depth_minus8 */
-- 
2.42.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] SWS cleanup / SPI Funding Suggestion

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 13, 2023, at 4:00 PM, Vittorio Giovara  
> wrote:
> 
> TBF this is in part why i was suggesting a new library - I feel like sws is
> affected by bad brading because of these caching issues and imprecise
> conversion, and a new clean api in a new library would make a lot of sense
> in my opinion.

I think the branding issue would solve itself in short order if the actual 
implementation of swscale started to be good. My concern with adding a new 
library is that we'd end up in a situation where we have both swscale and a new 
library side by side for some extended period of time. 

By comparison adding cleaner APIs to swscale and then slowly strangling the old 
APIs (along the lines of Niklas' proposal) would allow for a more gradual 
transition that has a higher likelihood of success compared to a full rewrite 
IMO.

- Cosmin
___
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] avfilter/vf_scale: fix interlaced chroma for other formats

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 13, 2023, at 4:00 PM, Niklas Haas  wrote:
> 
> That said, if the status quo for the past decades is to for vf_scale
> treat unspecified chroma loc as center-aligned, I am no longer sure if
> suddenly changing this behavior is a good idea.

I'd say that the current default (jpeg chroma loc for untagged) is more likely 
to be wrong than right in practice. It is definitely a change but while we're 
fixing lots of color related issues the next major release this might be a good 
time to draw a line in the sand and fix the defaults going forward to be the 
typical case (while perhaps trying to minimize the instances that hit this 
default path and warning loudly when it does).

That said this seems like the kind of change that should be in a 7.0 release 
rather than a 6.1 release if a 6.1 is going to happen.

- Cosmin
___
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] SWS cleanup / SPI Funding Suggestion

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 17, 2023, at 7:36 AM, Michael Niedermayer  
> wrote:
> 
> On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote:
>> 
>> It would be useful at this point to define the process to accept the
>> proposal and potential candidates. We have a technical committee which
>> might take the lead on that and probably have the last word on it,
>> since "approved by the community" is a bit vague and there is the risk
>> that there will be never an approval "from the community" because of
>> diverging views, or that we get stuck at the design level.
> 
> I think there are several shades of this
> 
> The community might simply have a consensus that X should be funded.
> We achieved this both for traval and hw in all or nearly all cases.
> And quite plausibly we will achieve this too for other cases
> 
> Hypothetically the community might have a consensus some work should
> be funded but not agree on technical details.
> Here honestly i think the developer doing the work should be the main
> decission maker. She is the one doing the work, knowing the code best.
> And most likely its one of the FFmpeg team doing the work.

I think this makes sense for cases where there is easily reachable consensus. 
What happens when we can't easily reach consensus? For example it doesn't seem 
like we have consensus on funding improvements to swscale (compared to 
integrating a 3rd party library). Does that mean that work cannot get funded 
through SPI? 

This is where I think using the TC to make a decision where the community at 
large cannot reach consensus might be useful. It doesn't need to decide the 
fine technical points of how the work is done, but it can provide a useful 
mechanism to disagree and commit about whether the work should be done at all 
and provide the broad strokes (like improve swscale vs write a brand new 
library vs integrate some third party one).

- Cosmin



___
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] trac spam

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 20, 2023, at 10:53 AM, Michael Koch  
> wrote:
> 
>> should i add /pipermail/ffmpeg-trac to robots.txt ?
> is there anyone who googles in these ffmpeg trac archives ?
> 
> I don't.

I'd imagine anyone wanting to search would search trac itself rather than the 
mailing list archive. If it has to stay publicly searchable though, is there a 
way to add rel="nofollow" to the links when they appear in the trac archive? 
That should remove the appeal of this vector for stuffing links in to the trac 
archive. 

- Cosmin
___
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] [ANNOUNCE] upcoming GA vote

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 25, 2023, at 10:39 AM, Rémi Denis-Courmont  wrote:
> 
> Objectively, it really does not matter insofar as we are dealing solely with 
> non-GA members such as I. But if I were to play devil's advocate, you may be 
> serving on a plate a pretext for some future dissatisfied voters to call the 
> voting process invalid later, or worse, maybe even allege xenophobic 
> discrimination (this does *not* represent my opinion and is *not* meant to 
> constitute an actual serious accusation). Either way it might be a problem in 
> the particular context of this project, especially in light of the abundance 
> of formality from Anton's original post.

I don't think the intent is to leave this broken. This first test is intended 
to confirm the email deliverability though so perhaps we can focus on that for 
now. Then we can circle back on fixing the server side voting software to deal 
with different locales. 

- Cosmin


___
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] [ANNOUNCE] upcoming GA vote

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel 
>  wrote:
> 
>> I'll try to post a patch today either inverting their order (which
>> hopefully outputs my community member e-mail), or - since this e-mail
>> is never supposed to apply to any committer cases - removing it.
> 
> Andreas might be in the same boat. If necessary, we could have a seperate 
> .mailmap_voting file only used in the GA script. Patches welcome, I guess.

I think the script works correctly. According to the mailmap documentation the 
order is supposed to be 

 

I'd expect the first email in the mailmap to be the proper email to send things 
like GA votes to, whereas the second one can be one of potentially multiple 
other emails that commits could be under. So multiple second emails would be 
used to aggregate commits to a single proper email address to be used for GA 
purposes.

- Cosmin
___
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] [ANNOUNCE] upcoming GA vote

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel 
>  wrote:
> 
>> I'll try to post a patch today either inverting their order (which
>> hopefully outputs my community member e-mail), or - since this e-mail
>> is never supposed to apply to any committer cases - removing it.
> 
> Andreas might be in the same boat. If necessary, we could have a seperate 
> .mailmap_voting file only used in the GA script. Patches welcome, I guess.

I think the script works correctly. According to the mailmap documentation the 
order is supposed to be 

 

I'd expect the first email in the mailmap to be the proper email to send things 
like GA votes to, whereas the second one can be one of potentially multiple 
other emails that commits could be under. So multiple second emails would be 
used to aggregate commits to a single proper email address to be used for GA 
purposes.

- Cosmin
___
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] [RFC] financial sustainability Plan A (SPI)

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 27, 2023, at 9:14 AM, Rémi Denis-Courmont  wrote:
> 
>> Consider FFlabs, you can look at who is being paid by FFlabs, its being
>> mentioned in various places.
>> Then look at what these people do, so you know what they are paid for.
> 
> I don't know if FFlabs publishes the payments it makes to its consultants, so 
> I can't answer your question. But it sounds odd, as I would expect that that 
> would violate privacy laws. All FFlabs seems to publish is who their 
> consultants are, not what they work on or for.

With a list of FFLabs consultants the "what they work on" can be extracted from 
the git log or mailing list patches. Not who is paying for the work or how much 
is being paid, but certainly the what can be inferred with a reasonable degree 
of accuracy.

- Cosmin
___
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] [RFC] financial sustainability Plan A (SPI)

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 27, 2023, at 12:00 PM, Rémi Denis-Courmont  wrote:
> 
> Le perjantaina 27. lokakuuta 2023, 21.52.51 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> With a list of FFLabs consultants the "what they work on" can be extracted
>> from the git log or mailing list patches. Not who is paying for the work or
>> how much is being paid, but certainly the what can be inferred with a
>> reasonable degree of accuracy.
> 
> In other words, we know neither what the statement of work is, nor how much 
> FFlabs is paid for or passes on to the consultants. We just guess that maybe 
> what the people listed as consultants are paid to do what they do.
> 
> Then that is nowhere near the level of labour-intensive (for the GA) and 
> privacy-intrusive (for the consultants) that SPI funding would involve, more 
> or less making my point.

Sure, work done via FFLabs has more privacy than work funded with non-profit 
SPI donations. It's not clear what the problem is though, nobody is forced to 
accept work via the SPI route, presumably folks can continue to work via FFLabs 
or via other commercial contracts exclusively if they so prefer. Having more 
transparency for work funded from donations seems like a good thing.

- Cosmin
___
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] web: move 5.0 to olddownloads

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 20, 2023, at 9:01 AM, Michael Niedermayer  
> wrote:
> 
> our downstream list shows no maintained users of that release
> https://trac.ffmpeg.org/wiki/Downstreams

I was trying to track down the status of OpenMandriva Lx 3 because it's listed 
as a downstream for ffmpeg 4.0. While doing this I noticed that Lx 3 is EOL as 
of 2019-07-16. The current active version of OpenMandriva is Lx 4.3, and it 
seems to be packaging ffmpeg 5.0 based on 
https://openmandriva.pkgs.org/4.3/openmandriva-main-release-x86_64/ffmpeg-5.0-1-omv4050.x86_64.rpm.html

I'm not directly familiar with OpenMandriva I was just chasing up the 4.0 
relationship. I updated the wiki based on this information but it would be good 
for someone familiar with OpenMandriva to confirm. Based on that it might make 
sense to keep 5.0 and consider moving 4.0 to old downloads.


- Cosmin
___
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 0/1] tools/general_assembly.pl - print names with emails

[Cosmin Stejerean via ffmpeg-devel]

Per http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316480.html
a list of emails should not be published as the GA membership. To
facilitate publishing the GA list this updates the GA script to also
print names along with the emails in the format

```
Name 
```

Cosmin Stejerean (1):
  update GA script to print names in addition to emails since emails
should not be shared on the list, this makes it easier to publish
the current GA membership

 tools/general_assembly.pl | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
2.31.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 1/1] tools/general_assembly.pl - print names with emails

[Cosmin Stejerean via ffmpeg-devel]

Update GA script to print names in addition to emails since emails
should not be shared in all contexts, this makes it easier to publish
the current GA membership.

Signed-off-by: Cosmin Stejerean 
---
 tools/general_assembly.pl | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index 898a6262ef..aa467ba34a 100644
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
@@ -7,6 +7,8 @@ use POSIX qw(strftime);
 use Encode qw(decode);
 use Data::Dumper;
 
+binmode(STDOUT, ":utf8");
+
 sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
 
 my @shortlog = split /\n/, decode('UTF-8', `git log --pretty=format:"%aN 
<%aE>" --since="last 36 months" | sort | uniq -c | sort -r`, Encode::FB_CROAK);
@@ -35,6 +37,7 @@ foreach my $line (@shortlog) {
 }
 
 printf("# %s %s", strftime("%Y-%m-%d", localtime), decode('UTF-8', `git 
rev-parse HEAD`, Encode::FB_CROAK));
-foreach my $email (sort values %assembly) {
-printf("%s\n", $email);
+foreach my $name (sort keys %assembly) {
+my $email = $assembly{$name};
+printf("%s <%s>\n", $name, $email);
 }
-- 
2.31.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 1/1] tools/general_assembly.pl - print names with emails

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 3, 2023, at 11:40 AM, Nicolas George  wrote:
> 
> This is also changing the sort order. It might be acceptable but it
> might also not be.

It is and I probably should have called that out in the description. If the 
goal is to publish mostly names and not emails in various places like this list 
then it seems sorting by name would be more natural. But I'm happy to to update 
the patch with whatever sort order we want to use.

- Cosmin
___
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 1/1] tools/general_assembly.pl - print names with emails

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 5, 2023, at 5:41 AM, Thilo Borgmann via ffmpeg-devel 
>  wrote:
> 
> The script should output two files then, so that no manual editing is 
> required.
> The voting system expects a file with mail addresses one per line and the ML 
> then shall be given the very same list but with only the names.

The editing in this case is fairly straight forward to extract the emails 
between the <>, but if we need a convenient "emails only" output option for the 
voting system I could also add some switches to the script to print only names, 
only emails or name and email for example. Outputting to a file (or more than 
one file) rather than to stdout is certainly an option as well but feels like a 
bigger change compared to some flags to control formatting. 

- Cosmin
___
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 v2 0/1] tools/general_assembly.pl - add options to print names, emails or both

[Cosmin Stejerean via ffmpeg-devel]

Per http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316480.html
a list of emails should not be published as the GA membership. To
facilitate publishing the GA list this updates the GA script with
options to print only names, only emails (for voting) or both.

Changes since v1:
- added --emails to print only emails with compatibility with voting software
- added --names to make it easy to get a list of only names for publishing
- added help message to show usage

Cosmin Stejerean (1):
  tools/general_assembly.pl - add options to print names, emails or both

 tools/general_assembly.pl | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

-- 
2.42.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 v2 1/1] tools/general_assembly.pl - add options to print names, emails or both

[Cosmin Stejerean via ffmpeg-devel]

Signed-off-by: Cosmin Stejerean 
---
 tools/general_assembly.pl | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index 898a6262ef..8204d89794 100644
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
@@ -6,9 +6,41 @@ use strict;
 use POSIX qw(strftime);
 use Encode qw(decode);
 use Data::Dumper;
+use Getopt::Long;
+
+binmode(STDOUT, ":utf8");
 
 sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
 
+sub print_help {
+print "Usage: $0 [options]\n";
+print "Options:\n";
+print "  --names  Print only the names\n";
+print "  --emails Print only the email addresses\n";
+print "  --full   Print both names and email addresses 
(default)\n";
+print "  -h, --help   Show this help message\n";
+exit;
+}
+
+my $print_full = 1;
+my $print_names = 0;
+my $print_emails = 0;
+my $help = 0;
+
+GetOptions(
+"full" => \$print_full,
+"names" => \$print_names,
+"emails" => \$print_emails,
+"help" => \$help,
+"h" => \$help,
+);
+
+print_help() if $help;
+
+if ($print_names || $print_emails) {
+$print_full = 0;
+}
+
 my @shortlog = split /\n/, decode('UTF-8', `git log --pretty=format:"%aN 
<%aE>" --since="last 36 months" | sort | uniq -c | sort -r`, Encode::FB_CROAK);
 my %assembly = ();
 
@@ -35,6 +67,13 @@ foreach my $line (@shortlog) {
 }
 
 printf("# %s %s", strftime("%Y-%m-%d", localtime), decode('UTF-8', `git 
rev-parse HEAD`, Encode::FB_CROAK));
-foreach my $email (sort values %assembly) {
-printf("%s\n", $email);
+foreach my $name (sort keys %assembly) {
+my $email = $assembly{$name};
+if ($print_full) {
+printf("%s <%s>\n", $name, $email);
+} elsif ($print_names) {
+printf("%s\n", $name);
+} elsif ($print_emails) {
+printf("%s\n", $email);
+}
 }
-- 
2.42.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] [ANNOUNCE] upcoming vote: extra members for GA

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 9, 2023, at 9:53 AM, Rémi Denis-Courmont  wrote:
> 
> The point is that, whether or not they are on the mailing list, people should 
> not be volunteered to the GA by others, but on their own volition. The 
> circumstances are different for those on the mailing list and those not, but 
> the end result is the same: don't nominate people like that. It's rude.

I don't think nominating others for the GA is rude, assuming they accept the 
nomination. I do agree they shouldn't be automatically be put on the GA because 
of a nomination they did not accept, but it seems reasonable to ask them if 
they want to accept the nomination. I do think that being subscribed to the 
mailing list should be a prerequisite however.

- Cosmin
___
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 v5 4/7] libavcodec/webp: add support for animated WebP decoding

[Cosmin Stejerean via ffmpeg-devel]

On Nov 20, 2023, at 5:14 PM, James Almer  wrote:

On 11/20/2023 4:22 PM, Thilo Borgmann via ffmpeg-devel wrote:
+    if (*got_frame) {
+    if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION)) {
+    // no animation, output the decoded frame
+    av_frame_move_ref(p, s->frame);
+    ret = ff_attach_decode_data(p);
+    if (ret < 0)
+    return ret;

If this frame's buffers were allocated with ff_get_buffer() (or its threaded 
version), then a call to ff_attach_decode_data() is not necessary.

The frame returned by avcodec_receive_frame doesn’t have private_ref set on it, 
and eventually this null private_ref would get propagated to the other frame 
objects (even if allocated with ff_get_buffer) by av_frame_copy_props, and 
later on this would fail the assert that frames returned by codecs with 
AV_CODEC_CAP_DR1 have private_ref set on them.

However this patch is dealing with it in the wrong place, moving 
ff_attach_decode_data to right after avcodec_receive_frame would both make this 
more clear and fix the assert issues (currently there’s an unnecessary call to 
ff_attach_decode_data on an already allocated frame in a code path that doesn’t 
go through vp8_lossy_decode_frame).

I verified that with that change on top of the current patch set it would run 
the webp fate tests cleanly. I’m not sure if this is the best way to properly 
reference a frame that came from avcodec_receive_frame inside of another codec. 
But it does seem to work and a cursory search didn’t reveal a better API for 
this.


- Cosmin
___
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] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

Fixes #10688

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..bce11c39f7 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
 }
 
 yadif->csp = av_pix_fmt_desc_get(link->format);
+
+if (yadif->csp->nb_components > 1) {
+int w_chroma, h_chroma;
+h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
+w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
+
+if (w_chroma < 3 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns 
or 4 lines is not supported\n");
+return AVERROR(EINVAL);
+}
+}
+
 yadif->filter = filter;
 ff_bwdif_init_filter_line(&s->dsp, yadif->csp->comp[0].depth);
 
-- 
2.39.2 (Apple Git-143)

___
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] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 28, 2023, at 5:30 AM, Thomas Mundt  wrote:
> 
> Hi Cosmin,
> 
> Cosmin Stejerean via ffmpeg-devel  schrieb am Sa.,
> 25. Nov. 2023, 21:39:
> 
>> Fixes #10688
>> 
>> Signed-off-by: Cosmin Stejerean 
>> ---
>> libavfilter/vf_bwdif.c | 12 
>> 1 file changed, 12 insertions(+)
>> 
>> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
>> index 137cd5ef13..bce11c39f7 100644
>> --- a/libavfilter/vf_bwdif.c
>> +++ b/libavfilter/vf_bwdif.c
>> @@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
>> }
>> 
>> yadif->csp = av_pix_fmt_desc_get(link->format);
>> +
>> +if (yadif->csp->nb_components > 1) {
>> +int w_chroma, h_chroma;
>> +h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
>> +w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
>> +
>> +if (w_chroma < 3 || h_chroma < 4) {
>> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
>> columns or 4 lines is not supported\n");
>> +return AVERROR(EINVAL);
>> +}
>> +}
>> +
>> 
> 
> Thanks for your quick patch.
> Could you please make the size check for all components and remove the old
> one to avoid having two size checks in a row?
> 

Certainly, will send a v2 shortly.

- Cosmin
___
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] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 29, 2023, at 11:36 AM, Dennis Mungai  wrote:
> 
> On Wed, 29 Nov 2023 at 22:26, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
>> 
>> 
>>> On Nov 28, 2023, at 5:30 AM, Thomas Mundt  wrote:
>>> 
>>> Hi Cosmin,
>>> 
>>> Cosmin Stejerean via ffmpeg-devel  schrieb am
>> Sa.,
>>> 25. Nov. 2023, 21:39:
>>> 
>>>> Fixes #10688
>>>> 
>>>> Signed-off-by: Cosmin Stejerean 
>>>> ---
>>>> libavfilter/vf_bwdif.c | 12 
>>>> 1 file changed, 12 insertions(+)
>>>> 
>>>> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
>>>> index 137cd5ef13..bce11c39f7 100644
>>>> --- a/libavfilter/vf_bwdif.c
>>>> +++ b/libavfilter/vf_bwdif.c
>>>> @@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
>>>>}
>>>> 
>>>>yadif->csp = av_pix_fmt_desc_get(link->format);
>>>> +
>>>> +if (yadif->csp->nb_components > 1) {
>>>> +int w_chroma, h_chroma;
>>>> +h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
>>>> +w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
>>>> +
>>>> +if (w_chroma < 3 || h_chroma < 4) {
>>>> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
>>>> columns or 4 lines is not supported\n");
>>>> +return AVERROR(EINVAL);
>>>> +}
>>>> +}
>>>> +
>>>> 
>>> 
>>> Thanks for your quick patch.
>>> Could you please make the size check for all components and remove the
>> old
>>> one to avoid having two size checks in a row?
>>> 
>> 
>> Certainly, will send a v2 shortly.
>> 
>> - Cosmin
>> 
>> 
> Does this change also need to be replicated to bwdif_cuda?
> 


Good callout, it's like the that both bwdif_cuda and bwdif_vulkan need similar 
updates as they both have checks for width and height and would likely 
encounter the same problem on the chroma planes. I'll include both of those in 
v2.

On a side note the minimum width and height requirements are a bit different 
between the three filters in terms of whether 3x4, 3x3 or 4x4 are the minimum 
required dimensions. I'm assuming this is intentional based on the underlying 
filters but just wanted to double check whether it might be worth unifying all 
of these to say min 4x4 for consistency.

- Cosmin






___
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] [ANNOUNCE] upcoming vote: TC/CC elections

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 29, 2023, at 3:14 PM, Michael Niedermayer  
> wrote:
> 
> If you give Jerry a weight of 10 and give Tom a weight of 9, that means
> you prefer Jerry over Tom because 10 > 9
> If you give Spike a weight of 20 that would mean you not only prefer Spike
> over Tom OR Jerry but also over Tom AND Jerry. Because 20 > 10 + 9
> 
> OTOH if you give Spike a weight of 18 that would mean you prefer Spike over
> Tom OR Jerry but you prefer Tom AND Jerry over Spike.
> Because: 9   < 10< 18 < 9 + 10
> Tom < Jerry < Spike  < Tom and Jerry

Is this last example the kind of preference that people are likely to want to 
express in practice? It seems much harder to reason about and much more likely 
to lead to mistakes. 

Given a list of say 7 candidates running for 5 positions that's 21 possible 
combinations and in theory weights would have to be assigned such that the sum 
for each one of those 21 combinations is correctly ranked by order of 
preference.

I think the simplicity of the simpler ranked choice voting might outweigh the 
benefit of expressing complex preferences with the sum of weights.

- Cosmin
___
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 v2 0/3] consider chroma subsampling for bwdif (including CUDA and Vulkan)

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

This fixes the issue reported in #10688. In v2 the checks for chroma
plane are combined together and the fixes are extended to cover the
Vulkan and CUDA implementations of bwdif.

I have not had a chance to replicate the issue on CUDA or Vulkan but
based on the dimension checks in those filters I believe they would
have the same out of bounds issue.

I kept the changes in separate patches since I've only properly tested
the first one. I'll work on testing the CUDA and Vulkan
implementations as well but meanwhile wanted to get some feedback on
the overall approach.

Cosmin Stejerean (3):
  avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum
dimensions
  avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing
minimum dimensions
  avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing
minimum dimensions

 libavfilter/vf_bwdif.c| 13 ++---
 libavfilter/vf_bwdif_cuda.c   | 13 ++---
 libavfilter/vf_bwdif_vulkan.c | 14 ++
 3 files changed, 30 insertions(+), 10 deletions(-)

-- 
2.42.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 v2 2/3] avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif_cuda.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index a5ecfbadb6..7d9bf861b7 100644
--- a/libavfilter/vf_bwdif_cuda.c
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -296,13 +296,20 @@ static int config_output(AVFilterLink *link)
 link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
 (AVRational){2, 1});
 
-if (link->w < 3 || link->h < 3) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is 
not supported\n");
+const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(output_frames->sw_format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 3 || w_chroma < 3 || h < 3 || h_chroma < 3) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 
lines is not supported\n");
 ret = AVERROR(EINVAL);
 goto exit;
 }
 
-y->csp = av_pix_fmt_desc_get(output_frames->sw_format);
+y->csp = desc;
 y->filter = filter;
 
 ret = CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
-- 
2.42.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 v2 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Fixes #10688

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..80aa85a48b 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -191,12 +191,19 @@ static int config_props(AVFilterLink *link)
 return ret;
 }
 
-if (link->w < 3 || link->h < 4) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4 lines is 
not supported\n");
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 3 || w_chroma < 3 || h < 4 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 4 
lines is not supported\n");
 return AVERROR(EINVAL);
 }
 
-yadif->csp = av_pix_fmt_desc_get(link->format);
+yadif->csp = desc;
 yadif->filter = filter;
 ff_bwdif_init_filter_line(&s->dsp, yadif->csp->comp[0].depth);
 
-- 
2.42.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 v2 3/3] avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif_vulkan.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_bwdif_vulkan.c b/libavfilter/vf_bwdif_vulkan.c
index 690a89c4ba..6a886d11ac 100644
--- a/libavfilter/vf_bwdif_vulkan.c
+++ b/libavfilter/vf_bwdif_vulkan.c
@@ -362,13 +362,19 @@ static int bwdif_vulkan_config_output(AVFilterLink 
*outlink)
 outlink->frame_rate = av_mul_q(avctx->inputs[0]->frame_rate,
(AVRational){2, 1});
 
-if (outlink->w < 4 || outlink->h < 4) {
-av_log(avctx, AV_LOG_ERROR, "Video of less than 4 columns or lines is 
not "
-   "supported\n");
+const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(vkctx->frames->sw_format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 4 || w_chroma < 4 || h < 4 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 4 columns or 
lines is not supported\n");
 return AVERROR(EINVAL);
 }
 
-y->csp = av_pix_fmt_desc_get(vkctx->frames->sw_format);
+y->csp = desc;
 y->filter = bwdif_vulkan_filter_frame;
 
 return init_filter(avctx);
-- 
2.42.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] [ANNOUNCE] upcoming vote: TC/CC elections

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 29, 2023, at 5:42 PM, Ronald S. Bultje  wrote:
> 
> Does ranked voting allow expressing equal weight to multiple candidates?
> For example, I prefer Jerry and Tom equally, but I prefer either one over
> Spike.

In theory that could depend on the implementation of ranked voting, it could 
require strict ordering or allow expressing equal rank. I did a quick test vote 
on the public CIVS instance using "proportional representation" and "rank of 
their favorite choice" mode and it appears to allow assigning equal rank to 
multiple candidates.

- Cosmin


___
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] [POC][PATCHSET] Add qrencodesrc source

[Cosmin Stejerean via ffmpeg-devel]

> On Nov 30, 2023, at 03:07, Tomas Härdin  wrote:
> 
> tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
>> This is meant to introduce functionality to handle QR codes.
> 
> Why?
> 

The why seems to be answered below the section you quoted in the original email

> QR codes are robust to lossy coding, therefore it should be possible to use 
> them to compare a generated video with a reference one (in case
they cannot be compared frame-by-frame).

- Cosmin
___
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/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

On Nov 30, 2023, at 04:37, Thomas Mundt  wrote:


Am Do., 30. Nov. 2023 um 01:23 Uhr schrieb Cosmin Stejerean via ffmpeg-devel 
mailto:ffmpeg-devel@ffmpeg.org> >:
From: Cosmin Stejerean mailto:cos...@cosmin.at> >

Fixes #10688

Signed-off-by: Cosmin Stejerean mailto:cos...@cosmin.at> >
---
 libavfilter/vf_bwdif.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..80aa85a48b 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -191,12 +191,19 @@ static int config_props(AVFilterLink *link)
         return ret;
     }

-    if (link->w < 3 || link->h < 4) {
-        av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4 lines is 
not supported\n");
+    const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
+
+    int h = link->h;
+    int w = link->w;
+    int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+    int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+    if (w < 3 || w_chroma < 3 || h < 4 || h_chroma < 4) {
+        av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 4 
lines is not supported\n");
         return AVERROR(EINVAL);
     }

-    yadif->csp = av_pix_fmt_desc_get(link->format);
+    yadif->csp = desc;
     yadif->filter = filter;
     ff_bwdif_init_filter_line(&s->dsp, yadif->csp->comp[0].depth);

I think mixed declarations are not allowed.
Also log2_chroma_w/h should never be negative, so why not just do:

if (AV_CEIL_RSHIFT(link->w,  yadif->csp->log2_chroma_w) < 3 ||
    AV_CEIL_RSHIFT(link->h,  yadif->csp->log2_chroma_h) < 4)


Thank you for the prompt feedback, makes a lot of sense to me, will update in 
v3. 

- Cosmin
___
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] lavc: remove the QOA decoder

[Cosmin Stejerean via ffmpeg-devel]

> On Dec 2, 2023, at 7:53 AM, Anton Khirnov  wrote:
> 
> Its author not only failed to add any tests, as is required by the
> development rules, but continues to actively refuse to do so.
> 
> Untested decoders are worse than useless, so remove it.

While I agree that decoders (among other things) need tests this seems like an 
unfortunate outcome from an end user perspective. There are QOA samples at 
https://qoaformat.org/samples/ and presumably someone else could add some tests 
for it if the author can't be bothered. Can we hold off on this for a couple of 
days? If nobody else can add a test I can try to do so but I'll need a couple 
of days to figure it out.

- Cosmin


___
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 v3 0/3] consider chroma subsampling for bwdif (including CUDA and Vulkan)

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

This fixes the issue reported in #10688. In v3 only the chroma planes
are checked based on feedback for v2, since the chroma planes are
going to have the minimum dimension.

Cosmin Stejerean (3):
  avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum
dimensions
  avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing
minimum dimensions
  avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing
minimum dimensions

 libavfilter/vf_bwdif.c| 13 ++---
 libavfilter/vf_bwdif_cuda.c   | 13 ++---
 libavfilter/vf_bwdif_vulkan.c | 14 ++
 3 files changed, 30 insertions(+), 10 deletions(-)

-- 
2.42.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 v3 2/3] avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif_cuda.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index a5ecfbadb6..418f15f989 100644
--- a/libavfilter/vf_bwdif_cuda.c
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -296,15 +296,16 @@ static int config_output(AVFilterLink *link)
 link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
 (AVRational){2, 1});
 
-if (link->w < 3 || link->h < 3) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is 
not supported\n");
-ret = AVERROR(EINVAL);
-goto exit;
-}
 
 y->csp = av_pix_fmt_desc_get(output_frames->sw_format);
 y->filter = filter;
 
+if (AV_CEIL_RSHIFT(link->w, y->csp->log2_chroma_w) < 3 || 
AV_CEIL_RSHIFT(link->h, y->csp->log2_chroma_h) < 3) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 
lines is not supported\n");
+ret = AVERROR(EINVAL);
+goto exit;
+}
+
 ret = CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
 if (ret < 0)
 goto exit;
-- 
2.42.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 v3 3/3] avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif_vulkan.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_bwdif_vulkan.c b/libavfilter/vf_bwdif_vulkan.c
index 690a89c4ba..c51df9aa26 100644
--- a/libavfilter/vf_bwdif_vulkan.c
+++ b/libavfilter/vf_bwdif_vulkan.c
@@ -362,15 +362,14 @@ static int bwdif_vulkan_config_output(AVFilterLink 
*outlink)
 outlink->frame_rate = av_mul_q(avctx->inputs[0]->frame_rate,
(AVRational){2, 1});
 
-if (outlink->w < 4 || outlink->h < 4) {
-av_log(avctx, AV_LOG_ERROR, "Video of less than 4 columns or lines is 
not "
-   "supported\n");
-return AVERROR(EINVAL);
-}
-
 y->csp = av_pix_fmt_desc_get(vkctx->frames->sw_format);
 y->filter = bwdif_vulkan_filter_frame;
 
+if (AV_CEIL_RSHIFT(outlink->w, y->csp->log2_chroma_w) < 4 || 
AV_CEIL_RSHIFT(outlink->h, y->csp->log2_chroma_h) < 4) {
+av_log(avctx, AV_LOG_ERROR, "Video with planes less than 4 columns or 
lines is not supported\n");
+return AVERROR(EINVAL);
+}
+
 return init_filter(avctx);
 }
 
-- 
2.42.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 v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Fixes #10688

Signed-off-by: Cosmin Stejerean 
---
 libavfilter/vf_bwdif.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..353cd0b61a 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -191,13 +191,14 @@ static int config_props(AVFilterLink *link)
 return ret;
 }
 
-if (link->w < 3 || link->h < 4) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4 lines is 
not supported\n");
+yadif->csp = av_pix_fmt_desc_get(link->format);
+yadif->filter = filter;
+
+if (AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w) < 3 || 
AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h) < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 4 
lines is not supported\n");
 return AVERROR(EINVAL);
 }
 
-yadif->csp = av_pix_fmt_desc_get(link->format);
-yadif->filter = filter;
 ff_bwdif_init_filter_line(&s->dsp, yadif->csp->comp[0].depth);
 
 return 0;
-- 
2.42.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] fate: Add tests for QOA decoder

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

---
 tests/Makefile |   1 +
 tests/fate/qoa.mak |  12 
 tests/ref/fate/qoa-152 |  13 
 tests/ref/fate/qoa-278 | 135 +
 tests/ref/fate/qoa-303 |  35 +++
 5 files changed, 196 insertions(+)
 create mode 100644 tests/fate/qoa.mak
 create mode 100644 tests/ref/fate/qoa-152
 create mode 100644 tests/ref/fate/qoa-278
 create mode 100644 tests/ref/fate/qoa-303

diff --git a/tests/Makefile b/tests/Makefile
index f03cf20d8e..444c09b3de 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -226,6 +226,7 @@ include $(SRC_PATH)/tests/fate/pixfmt.mak
 include $(SRC_PATH)/tests/fate/pixlet.mak
 include $(SRC_PATH)/tests/fate/probe.mak
 include $(SRC_PATH)/tests/fate/prores.mak
+include $(SRC_PATH)/tests/fate/qoa.mak
 include $(SRC_PATH)/tests/fate/qt.mak
 include $(SRC_PATH)/tests/fate/qtrle.mak
 include $(SRC_PATH)/tests/fate/real.mak
diff --git a/tests/fate/qoa.mak b/tests/fate/qoa.mak
new file mode 100644
index 00..2e20ee5ee1
--- /dev/null
+++ b/tests/fate/qoa.mak
@@ -0,0 +1,12 @@
+FATE_QOA-$(call DEMDEC, QOA, QOA) += fate-qoa-152
+fate-qoa-152: CMD = framecrc -i $(TARGET_SAMPLES)/qoa/coin_48_1_152.qoa
+
+FATE_QOA-$(call DEMDEC, QOA, QOA) += fate-qoa-278
+fate-qoa-278: CMD = framecrc -i $(TARGET_SAMPLES)/qoa/vibra_44_2_278.qoa
+
+FATE_QOA-$(call DEMDEC, QOA, QOA) += fate-qoa-303
+fate-qoa-303: CMD = framecrc -i $(TARGET_SAMPLES)/qoa/banjo_48_2_303.qoa
+
+fate-qoa: fate-qoa-152 fate-qoa-278 fate-qoa-303
+
+FATE_SAMPLES_AUDIO += $(FATE_QOA-yes)
diff --git a/tests/ref/fate/qoa-152 b/tests/ref/fate/qoa-152
new file mode 100644
index 00..62fb6ecdf3
--- /dev/null
+++ b/tests/ref/fate/qoa-152
@@ -0,0 +1,13 @@
+#tb 0: 1/48000
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 48000
+#channel_layout_name 0: mono
+0,  0,  0, 5120,10240, 0xa687046e
+0,   5120,   5120, 5120,10240, 0xa75bd341
+0,  10240,  10240, 5120,10240, 0x6a59cebe
+0,  15360,  15360, 5120,10240, 0x04771262
+0,  20480,  20480, 5120,10240, 0x3cefe573
+0,  25600,  25600, 5120,10240, 0xba329e6b
+0,  30720,  30720, 5120,10240, 0x6fabfff0
+0,  35840,  35840, 3591, 7182, 0x3fb1ae86
diff --git a/tests/ref/fate/qoa-278 b/tests/ref/fate/qoa-278
new file mode 100644
index 00..63f4f4abae
--- /dev/null
+++ b/tests/ref/fate/qoa-278
@@ -0,0 +1,135 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout_name 0: stereo
+0,  0,  0, 5120,20480, 0xc51f1bf2
+0,   5120,   5120, 5120,20480, 0xcace16a8
+0,  10240,  10240, 5120,20480, 0x39311aac
+0,  15360,  15360, 5120,20480, 0xce741aaa
+0,  20480,  20480, 5120,20480, 0xbe47c7c2
+0,  25600,  25600, 5120,20480, 0xcc7790fa
+0,  30720,  30720, 5120,20480, 0x4be97965
+0,  35840,  35840, 5120,20480, 0x7bfe4b0e
+0,  40960,  40960, 5120,20480, 0xf99889c4
+0,  46080,  46080, 5120,20480, 0x66092d82
+0,  51200,  51200, 5120,20480, 0x34b5d044
+0,  56320,  56320, 5120,20480, 0xba76964e
+0,  61440,  61440, 5120,20480, 0x82f88eb2
+0,  66560,  66560, 5120,20480, 0xb5b9c3f3
+0,  71680,  71680, 5120,20480, 0x24e87a1d
+0,  76800,  76800, 5120,20480, 0xfa1743f2
+0,  81920,  81920, 5120,20480, 0x0d9a42ff
+0,  87040,  87040, 5120,20480, 0x43494a02
+0,  92160,  92160, 5120,20480, 0x4cfeb13e
+0,  97280,  97280, 5120,20480, 0xc7aace4d
+0, 102400, 102400, 5120,20480, 0xc435715d
+0, 107520, 107520, 5120,20480, 0x4321403b
+0, 112640, 112640, 5120,20480, 0xaea959b8
+0, 117760, 117760, 5120,20480, 0x796c9b96
+0, 122880, 122880, 5120,20480, 0x3a036bf1
+0, 128000, 128000, 5120,20480, 0xd5cb30d6
+0, 133120, 133120, 5120,20480, 0x8921cd54
+0, 138240, 138240, 5120,20480, 0x2c3ddc88
+0, 143360, 143360, 5120,20480, 0x17b6d52f
+0, 148480, 148480, 5120,20480, 0x8f6cb3fa
+0, 153600, 153600, 5120,20480, 0xd8428d98
+0, 158720, 158720, 5120,20480, 0xc295b551
+0, 163840, 163840, 5120,20480, 0x5fcb3d7a
+0, 168960, 168960, 5120,20480, 0xe31f5663
+0, 174080, 174080, 5120,20480, 0x9ef8364a
+0, 179200, 179200, 5120,20480, 0x8a256b59
+0, 184320, 184320, 5120,20480, 0xcde4dc9a
+0, 189440, 189440, 5120,20480, 0xf6f8259b
+0, 194560, 194560, 5120,20480, 0x8c61f88c
+0, 199680, 199680, 5120,20480, 0x89888a7e
+0, 204800, 204800, 5120,

Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions

[Cosmin Stejerean via ffmpeg-devel]

> On Dec 6, 2023, at 02:44, Philip Langdale via ffmpeg-devel 
>  wrote:
> 
> On Sat, 2 Dec 2023 23:02:36 +0100
> Thomas Mundt  wrote:
> 
>> 
>> LGTM, thanks.
>> 
> 
> I am going to squash the three commits and push. There's no real need
> to put each filter in a separate diff when the logical change is
> identical in all three.
> 

Squashing sounds good to me.

- Cosmin
___
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 v3] ffmpeg CLI multithreading

[Cosmin Stejerean via ffmpeg-devel]

> On Dec 6, 2023, at 11:36 AM, Anton Khirnov  wrote:
> 
>> In some cases the performance penalty because of threading is quite 
>> significant:
>> 
>> Example command line:
>> 
>> ffmpeg -f lavfi -i sine -af volume=6dB -f null none
>> 
>> After latest threading changes: speed=810x
>> Before latest threading changes: speed=1.13e+03x
>> With 6.0 branch: speed=1.43e+03x
>> With 5.1 branch: speed=2.92e+03x
>> 
>> This is a significant decline from 5.1, getting slower with each 
>> release... Is there anything that can be done about this?
> 
> Would guess this is caused by overhead from tons of tiny frames. So
> 1) generate larger frames

Larger frames would definitely help. With the command as is I get 4.75e+03x on 
6.0 and 2.81e+03x on latest mutli-threading branch. 
However when adding asetnsamples this improves considerably. For example using 
asetnsamples=2048 as follows runs at 5.6e+03x on the multi-threading branch

./ffmpeg -f lavfi -i sine,asetnsamples=2048 -af volume=6dB -f null none

and it can be further improved by increasing the asetnsamples values to 4096 
for example (9.18e+03x).

There is still a penalty as you could do asetnsamples without multi-threading 
and get even higher performance,
but given the general benefits of multi-threading and the fact that it's 
possible to increase the performance of this 
usecase arbitrarily by using larger and larger frames I think that's an 
acceptable tradeoff for this use case.


- Cosmin





___
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 v7 3/7] avcodec/webp_parser: parse each frame into one packet

[Cosmin Stejerean via ffmpeg-devel]

> On Dec 7, 2023, at 9:42 AM, Andreas Rheinhardt 
>  wrote:
> 
> According to
> https://developers.google.com/speed/webp/docs/riff_container#extended_file_format
> metadata chunks are stored after the image data; if you split the data
> into packets, then the metadata while only become available for the very
> last frame, although it pertains to all of them. This makes your
> approach unworkable.
> 
> Additionally, the WebP muxer expects animations to be contained in a
> single packet, hence the warnings from Michael.

What would be a better approach here, keeping all the animations in a single 
packet and decoding multiple frames from it, by essentially moving this logic 
to split them from the parser to the decoder?

- Cosmin
___
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] lavc/libopenh264: Drop openh264 runtime version checks

[Cosmin Stejerean via ffmpeg-devel]

> On Dec 8, 2023, at 11:07 AM, Kalev Lember  wrote:
> 
> On Fri, Dec 8, 2023 at 4:59 PM James Almer  wrote:
> 
>> Does the configure check ensure a new enough openh264 version is the
>> minimum supported?
>> 
> 
> Hm, I'd say that configure minimum version check is mostly orthogonal to
> the patch here.
> 
> This patch just removes a check that made it error out if the build time
> and runtime versions didn't perfectly match (as in, 1.0.0 at build time and
> 1.0.1 at run time would have resulted in erroring out). Basically just
> makes it behave like with all other libraries :)

As of what version of openh264 though is it safe to assume that ABI won't 
change without soname changes? Since years ago ABI changes without soname 
changes were present there's likely to be some minimum version above which 
runtime version checks are not needed.

- Cosmin
___
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] Added alpha layer support for smartblur

[Cosmin Stejerean via ffmpeg-devel]

> On Mar 25, 2024, at 1:49 AM, Andrea Mastroberti via ffmpeg-devel 
>  wrote:
> 
> Signed-off-by: Andrea Mastroberti <10736...@polimi.it>
> ---
> doc/filters.texi   | 20 -
> libavfilter/version.h  |  2 +-
> libavfilter/vf_smartblur.c | 44 ++
> 3 files changed, 55 insertions(+), 11 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 913365671d..30b3627724 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -22688,9 +22688,27 @@ whether a pixel should be blurred or not. The option 
> value must be an
> integer in the range [-30,30]. A value of 0 will filter all the image,
> a value included in [0,30] will filter flat areas and a value included
> in [-30,0] will filter edges. Default value is @option{luma_threshold}.
> +
> +@item alpha_radius, ar
> +Set the alpha radius. The option value must be a float number in
> +the range [0.1,5.0] that specifies the variance of the gaussian filter
> +used to blur the image (slower if larger). Default value is 1.0.


Default value should be @option{luma_radius}.

> +
> +@item alpha_strength, as
> +Set the alpha strength. The option value must be a float number
> +in the range [-1.0,1.0] that configures the blurring. A value included
> +in [0.0,1.0] will blur the image whereas a value included in
> +[-1.0,0.0] will sharpen the image. Default value is 1.0.

Default value should be @option{luma_strength}.

> +
> +@item alpha_threshold, at
> +Set the alpha threshold used as a coefficient to determine
> +whether a pixel should be blurred or not. The option value must be an
> +integer in the range [-30,30]. A value of 0 will filter all the image,
> +a value included in [0,30] will filter flat areas and a value included
> +in [-30,0] will filter edges. Default value is 0.

Default value should be @option{luma_threshold}.

> @end table
> -If a chroma option is not explicitly set, the corresponding luma value
> +If a chroma or alpha option is not explicitly set, the corresponding luma 
> value
> is set.
>  @section sobel
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index d5a6bc143a..f01b3f8e91 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -32,7 +32,7 @@
> #include "version_major.h"
>  #define LIBAVFILTER_VERSION_MINOR   0
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>   #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> diff --git a/libavfilter/vf_smartblur.c b/libavfilter/vf_smartblur.c
> index ae0ec05b2d..bc377d0b92 100644
> --- a/libavfilter/vf_smartblur.c
> +++ b/libavfilter/vf_smartblur.c
> @@ -54,6 +54,7 @@ typedef struct SmartblurContext {
> const AVClass *class;
> FilterParam  luma;
> FilterParam  chroma;
> +FilterParam  alpha;
> int  hsub;
> int  vsub;
> unsigned int sws_flags;
> @@ -77,6 +78,13 @@ static const AVOption smartblur_options[] = {
> { "chroma_threshold", "set chroma threshold", OFFSET(chroma.threshold), 
> AV_OPT_TYPE_INT,   {.i64=THRESHOLD_MIN-1}, THRESHOLD_MIN-1, THRESHOLD_MAX, 
> .flags=FLAGS },
> { "ct",   "set chroma threshold", OFFSET(chroma.threshold), 
> AV_OPT_TYPE_INT,   {.i64=THRESHOLD_MIN-1}, THRESHOLD_MIN-1, THRESHOLD_MAX, 
> .flags=FLAGS },

Probably add a line break in here for visual separation as there is between 
chroma and luma parameters.

> +{ "alpha_radius","set alpha radius",OFFSET(alpha.radius),
> AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
> +{ "ar" ,"set alpha radius",OFFSET(alpha.radius), 
> AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },

The default value for both of those should be RADIUS_MIN-1 not 1.0, and the 
minimum value  RADIUS_MIN-1.

> +{ "alpha_strength",  "set alpha strength",  OFFSET(alpha.strength),  
> AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN, STRENGTH_MAX, .flags=FLAGS },
> +{ "as", "set alpha strength",  OFFSET(alpha.strength), 
> AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN, STRENGTH_MAX, .flags=FLAGS },


The default value should be STRENGTH_MIN-1, likewise for the minimum value.

> +{ "alpha_threshold", "set alpha threshold", OFFSET(alpha.threshold), 
> AV_OPT_TYPE_INT,   {.i64=0}, THRESHOLD_MIN, THRESHOLD_MAX, .flags=FLAGS },
> +{ "at", "set alpha threshold", OFFSET(alpha.threshold), 
> AV_OPT_TYPE_INT,   {.i64=0}, THRESHOLD_MIN, THRESHOLD_MAX, .flags=FLAGS },

The default value should be THRESHOLD_MIN-1, likewise for the minimum value.

> +
> { NULL }
> };
> @@ -86,7 +94,7 @@ static av_cold int init(AVFilterContext *ctx)
> {
> SmartblurContext *s = ctx->priv;
> -/* make chroma default to luma values, if not explicitly set */
> +/* make chroma and alpha default to luma values, if not explicitly set */


Rather than change this comment I think you can add a similar comment above the 
alpha defaulting belo

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Cosmin Stejerean via ffmpeg-devel]

> On May 2, 2024, at 9:35 AM, Zhao Zhili  wrote:
> 
> I know a developer which have contributed to FFmpeg and stop doing so after
> losing his git-send-email environment.

I'm not surprised, getting git-send-email to work can be fairly daunting.

First you have to know enough about secure SMTP to know the difference 
between ports 465 and 587 and properly configuring SMTP encryption in 
git config (quick, which one is "tls" and which one is "ssl").

Then you may need to know enough about Perl to install some modules from 
CPAN, for example I always need to install Net::SMTP::SSL on a new machine.

Lastly you need to figure out how to integrate git with keychain on your 
particular platform to avoid having your email password in a plaintext file.

- Cosmin
___
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] [RFC] 5 year plan & Inovation

[Cosmin Stejerean via ffmpeg-devel]

> On May 3, 2024, at 6:54 AM, Ronald S. Bultje  wrote:
> 
> On Fri, May 3, 2024 at 7:33 AM Rémi Denis-Courmont  wrote:
> 
>> 
>> There is no technical plan how that would actually work in practice, and I
>> don't think it is even feasible. Not to speak of a realistic plan who would
>> actually implement it and in what time frame.
>> 
> 
> To clarify: I myself much prefer gitlab's workflow and would use that if it
> was available. I think providing a CLI-based workflow (which Anton and some
> others have requested) is feasible and fair. If an email variant thereof
> can be made and someone wants to fund it, I think that's reasonable. But it
> shouldn't block allowing more people to convert to a gitlab-style workflow,
> which I consider far superior over what we have now. End of clarification.

I think it's useful to separate out CLI-based workflow from email based 
workflow. 

For example with GitHub you can use the gh command line tool 
(https://github.com/cli/cli)  to do almost everything from the CLI. See 
outstanding 
pull requests, create a new pull request, check out a pull request, leave 
comments, 
approve, reject, etc. The only thing the official CLI tool itself doesn't offer 
is ability 
to add in-line comments.

If one really wants to avoid the browser for leaving in-line comments there are 
solutions integrated with popular editors to do this directly from the editor.

For those that like Neovim a full featured editor plugin like octo.nvim 
(https://github.com/pwntester/octo.nvim?tab=readme-ov-file#-pr-reviews)
can be used to do everything including code reviews with inline comments.

Similar solutions exist for Emacs. And the API is there to make something more 
customized if desired. For example a tool like "re" can open up $EDITOR and 
allow adding inline comments (https://github.com/jordanlewis/re).

This is for Github but Gitlab is popular enough that I'd expect the same to 
exist
there or at a minimum to be possible to bridge the gap (in general the github 
tooling
is more mature).

What doesn't exist (yet) is a way to keep people on the exact email based 
workflow 
we currently have, and have bi-directional sync with something like github or 
gitlab.
Such a thing could probably be built, but it might be worth first trying to see 
if those
that insist on sticking with the CLI can use one of the existing CLI based 
workflows.

- Cosmin





___
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] [RFC] clarifying the TC conflict of interest rule

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 20, 2024, at 12:41 PM, Michael Niedermayer  
> wrote:
> 
> On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-02-20 15:01:11)
>>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>>> [...]
 their preferred wording, and then we can have the GA vote on it.
>>> 
>>> Before this GA vote, we need another extra member discussion/vote.
>>> Because the last GA reset droped several developers from the GA
>> 
>> I see neither why would we "need" such a vote, or why should it be
>> related to this one.
> 
> Because thats what was done in the past.
> The extra member vote was done between a GA reset and the following votes
> like the CC/TC votes
> The exception was the STF vote because there just was not enough time
> 
> We should do this consistently, and
> given that we reset the GA every 6 months, thats the natural rate
> at which to do a extra member vote (unless there is no other vote then
> the extra member vote can be skiped as it would make no difference)

It's not clear from https://www.ffmpeg.org/community.html that the extra 
members should be refreshed every time the GA is updated or that a vote should 
get held up if that hasn't happened yet. 

> Additional members are added to the General Assembly through a vote after 
> proposal by a member of the General Assembly. They are part of the GA for two 
> years, after which they need a confirmation by the GA.

It looks like a request to add extra members to the GA should be done 
explicitly by someone requesting a vote on it, which can be done at any time. 
Waiting until something else comes up for a vote seems suboptimal because it 
then delays that first decision by at least a couple of weeks (given the rules 
for voting).

- Cosmin








___
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] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

From: Cosmin Stejerean 

Co-authored-by: Amir Naghdinezhad 
Signed-off-by: Cosmin Stejerean 
---
 libavcodec/libsvtav1.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -539,6 +539,14 @@ static int eb_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (svt_ret == EB_NoErrorEmptyQueue)
 return AVERROR(EAGAIN);
 
+#if SVT_AV1_CHECK_VERSION(2, 0, 0)
+if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
+ svt_enc->eos_flag = EOS_RECEIVED;
+ svt_av1_enc_release_out_buffer(&headerPtr);
+ return AVERROR_EOF;
+}
+#endif
+
 ref = get_output_ref(avctx, svt_enc, headerPtr->n_filled_len);
 if (!ref) {
 av_log(avctx, AV_LOG_ERROR, "Failed to allocate output packet.\n");
@@ -573,8 +581,10 @@ static int eb_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (headerPtr->pic_type == EB_AV1_NON_REF_PICTURE)
 pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
 
+#if !(SVT_AV1_CHECK_VERSION(2, 0, 0))
 if (headerPtr->flags & EB_BUFFERFLAG_EOS)
 svt_enc->eos_flag = EOS_RECEIVED;
+#endif
 
 ff_side_data_set_encoder_stats(pkt, headerPtr->qp * FF_QP2LAMBDA, NULL, 0, 
pict_type);
 
-- 
2.42.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] avcodec/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 27, 2024, at 1:19 PM, James Almer  wrote:
> 
> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head 
> commit. Is this in preparation for an upcoming release?

Yes, this is in preparation for release 2.0 which is targeted for next week. 
https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the status, 
and this API change is one of the outstanding items.

- Cosmin
___
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/libsvtav1: send the EOS signal without a one frame delay to allow for the library to operate in a low-delay mode

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 27, 2024, at 1:49 PM, James Almer  wrote:
> 
>>> SVT-AV1 1.8.0 has this value set to 1.8.0, same as in the current git head 
>>> commit. Is this in preparation for an upcoming release?
>> Yes, this is in preparation for release 2.0 which is targeted for next week. 
>> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2155 is tracking the 
>> status, and this API change is one of the outstanding items.
> 
> Without this patch, the command "ffmpeg -lavfi testsrc,format=yuv420p 
> -vframes 101 -c:v libsvtav1 -loglevel debug -f null -" gives this:
> 
>> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17890 
>> bytes);
>> Total: 101 packets (17890 bytes) muxed
>> frame=  101 fps=0.0 q=31.0 Lsize=N/A time=00:00:04.00 bitrate=N/A
> 
> Whereas with it applied, i get:
> 
>> Output stream #0:0 (video): 101 frames encoded; 100 packets muxed (17885 
>> bytes);
>> Total: 100 packets (17885 bytes) muxed
>> frame=  100 fps=0.0 q=35.0 Lsize=N/A time=00:00:03.96 bitrate=N/A
> 
> If i pass it a single frame, i get no output at all. So the last frame is 
> being lost.

This change depends on the API change on the SVT-AV1 side, which is in in 
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2189

This will get merged in shortly as part of the 2.0 release. If I build this 
patch against the low-delay-api-change branch (from PR 2189) then I get 

> Output stream #0:0 (video): 101 frames encoded; 101 packets muxed (17970 
> bytes);
> Total: 101 packets (17970 bytes) muxed


- Cosmin
___
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] [ infra] Does main server hang?

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 29, 2024, at 7:27 AM, Zhao Zhili  wrote:
> 
> Hi, I can't pull from main developer git server. Patchwork is slow to loading.
> I have tried two ISP. Anything happened?

Not sure if it's related but trac has also been very unreliable for me, with 
frequent "Service Unavailable" errors from Apache. 

- Cosmin
___
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] libavfi/dnn: add LibTorch as one of DNN backend

[Cosmin Stejerean via ffmpeg-devel]

> On Feb 20, 2024, at 7:07 PM, wenbin.chen-at-intel@ffmpeg.org wrote:
> 
> From: Wenbin Chen 
> 
> PyTorch is an open source machine learning framework that accelerates
> the path from research prototyping to production deployment. Official
> website: https://pytorch.org/. We call the C++ library of PyTorch as
> LibTorch, the same below.
> 
> To build FFmpeg with LibTorch, please take following steps as reference:
> 1. download LibTorch C++ library in https://pytorch.org/get-started/locally/,
> please select C++/Java for language, and other options as your need.

I tested this locally with the current release (2.2.1) and this should clarify 
that the cxx11 ABI version needs to be downloaded 
(libtorch-cxx11-abi-shared-with-deps-*.zip) otherwise it fails to link with 
undefined reference to various c10 components.


> 
> @@ -6886,6 +6888,7 @@ enabled libtensorflow && require libtensorflow 
> tensorflow/c/c_api.h TF_Versi
> enabled libtesseract  && require_pkg_config libtesseract tesseract 
> tesseract/capi.h TessBaseAPICreate
> enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> enabled libtls&& require_pkg_config libtls libtls tls.h 
> tls_configure
> +enabled libtorch  && check_cxxflags -std=c++14 && require_cpp 
> libtorch torch/torch.h "torch::Tensor" -ltorch -lc10 -ltorch_cpu -lstdc++ 
> -lpthread

This needs to be c++17 at least for the most recent (2.2.1) release. It fails 
to compile with c++14.

- Cosmin


___
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] [RFC] clarifying the TC conflict of interest rule

[Cosmin Stejerean via ffmpeg-devel]

> On Mar 2, 2024, at 11:01 AM, Ronald S. Bultje  wrote:
> 
> This recusal may be effected either directly by
>>   the TC member, or by a vote of the Community Committee (CC)
>> 
> 
> The CC is for enforcement of behavioural guidelines (CoC), not for
> technical matters, so this strikes me as a bit of a stretch of the CC
> mandate.

I don't think in this case the CC would be enforcing a technical matter, but 
rather enforcing the recusal in the case of a conflict of interest when the TC 
member in question fails to recuse themselves. This does seem appropriate for 
the CC as the question is one of behavior rather than technical merit.

- Cosmin
___
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 2/3] avfilter: add an LCEVC decoding filter

[Cosmin Stejerean via ffmpeg-devel]

On Mar 19, 2024, at 10:21 AM, Kieran Kunhya  wrote:

On Tue, 19 Mar 2024 at 15:27, James Almer mailto:jamr...@gmail.com> > wrote:

On 3/19/2024 12:20 PM, Kieran Kunhya wrote:From 
https://github.com/v-novaltd/LCEVCdec
" This software is protected by copyrights and other intellectual
property
rights and no license is granted to any such rights. If you would like to
obtain a license to compile, distribute, or make any other use of this
software, please contact V-Nova Limited i...@v-nova.com."

So you want to include a library that requires ffmpeg users to obtain a
licence to compile?

Would adding it to the nonfree list be enough? But it's true that most

users would not be aware of the aforementioned limitations.


This is a slippery slope to adding whatever binary blob. As the decoder is
de-facto a binary blob.


Yeah, source available but with a prohibition on compilation might as well be a 
binary blob. Even to be on non-free I'd expect something along the lines of the 
FDK-AAC license at a minimum.

- Cosmin
___
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 4/4] avcodec/libx265: encode dovi RPUs

[Cosmin Stejerean via ffmpeg-devel]

> On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis  
> wrote:
> 
> The reason I never implemented this back when I adde RPU side data is that
> there is a strong chance of generating broken files.
> 
> That's because if we do anything to the video with swscale, etc., we're
> now encoding RPUs that aren't meant to be applied to that converted video.
> 
> For example, this could end up propagating RPUs when the user is tonemapping.

Would it be possible to only propagate RPUs if the color params are not 
changing? If there's any change from say PQ to HLG or HLG to PQ or tonemapping 
then we wouldn't want to propagate RPUs. If the color params are not changing 
then propagating RPUs by default seems sensible, and perhaps a filter can be 
added to explicitly clear RPUs if they should not be propagated.

- Cosmin
___
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/2] avcodec: add ambient viewing environment packet side data.

[Cosmin Stejerean via ffmpeg-devel]

> On Aug 17, 2023, at 11:36 PM, Damiano Galassi  wrote:
> 
> Ping
> 

I believe this is still waiting for a FATE test to be added.

- Cosmin

___
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] VDD conference invitation - Dublin 22-24 Sept 2023

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 8, 2023, at 6:09 AM, Michael Niedermayer  
> wrote:
> 
> modern video encoders where no longer added to ffmpeg

Writing a good modern video encoder is a massive undertaking, and i think it's 
likely that encoders are going to be mostly integrated via libraries. 

Along those lines though, one pattern that's becoming more popular particularly 
recently integrated encoder libraries is to move options into an opaque 
key-value string that's passed to the encoder library. For example 
svtav1-params. This makes sense because the parameters are frequently changing 
with new versions and it's hard to keep that in sync. However it gives up the 
self-documentation when running ffmpeg -h encoder=libsvtav1 for example.

It would be nice if there were some facilities for encoders to expose their 
parameters to ffmpeg including min/max or value list, the default value and a 
description such that running -h can show a useful help message. This would 
also allow ffmpeg to validate the parameters and possibly expose the options as 
proper -flags rather than requiring jamming them through a string blob.

- Cosmin



___
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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 24, 2023, at 5:45 PM, Michael Niedermayer  
> wrote:
> 
> On Sun, Sep 24, 2023 at 04:10:00PM +0100, Ronald S. Bultje wrote:
>> 
>> 
>> I believe the GA should have sole control and ownership over the domain and
>> trademark. I suggested to kindly ask Fabrice to transfer ownership and/or
>> legal control permanently to a non-profit controlled by and composed of
>> only our GA. I believe this can be amicably worked out.  If you believe
>> Fabrice should continue to have *some* (although not *sole*) say over
>> FFmpeg and ffmpeg.org, then we could propose for him to be a GA member,
>> too. I think that makes a lot of sense - he historically has a ton more
>> work in FFmpeg than me.
> 
> I disagree
> * Who is and is not a member of the GA is in flux, there can be disputes
>  even on GA membership.
> * You cannot have something owned by a group like that. There needs to be
>  an individual like a treassurer who has the actual key.
>  So you again trust one person, this is not different from what it is
>  now.
> 
> Also democracies can make really bad decissions. Which iam sure you have
> never seen occur ;)
> 
> And last but not least, this is attackable even unintentionally
> you just need for a single moment a majority in the GA that is
> bad. This is not hard to reach, a group can easily pose as enough
> active developers to achieve 51% and if the domain then really is
> legally controlled by the GA. yeah goodby domain
> this is not a scenario possible with fabrice having theretical veto
> power.
> So Yes, i strongly favor fabrice keeping this veto power.

These are legitimate concerns that exist in every member driven non-profit. 
There are common tools though to deal with this. I'm not proposing anything 
specific for ffmpeg, I don't get a vote here, but I'm just going to list some 
suggestions:

- a board, elected by the GA with staggered board seats such that 1/N come up 
for a vote every year
- rules around how or when something can be put to a vote by the GA
- bylaws requiring a supermajority of the vote such as 2/3 or 3/4 for certain 
decisions that shouldn't be left to simple majority
- new members of the GA needing to be voted in by existing members in addition 
to requiring certain criteria for eligibility such as number of commits 

Perhaps some of these things have been considered in the past.  The more 
important point is that these are common concerns with common tools to deal 
with them. I don't believe concerns about a name takeover should require an 
ad-hoc governance model when more common and arguably more equitable governance 
models exist. 

- Cosmin
___
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] SDR choices

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 26, 2023, at 11:14 AM, Anton Khirnov  wrote:
> 
> From my perspective, the objections to SDR have been largely
> technical,

>From my perspective the objections against the current SDR implementation 
>could be grouped into roughly 3 categories:

A) support for taking input from an SDR device doesn't belong in ffmpeg at all 
in any form, it's way too big and there are other projects out there for SDR 
there that one ought to use instead, and trying to do it in ffmpeg in any form 
would bloat the codebase and make a mess no matter which option is chosen

B) support for SDR is fine to have in ffmpeg, but it should be done via an 
external library that does not live in the ffmpeg source tree, and ffmpeg could 
be optionally compiled with a --enable-libsdr or some such

C) support for SDR is fine to have as long as it's in a separate module like a 
libavradio with a clean API rather than trying to beat it into libavdevice, the 
current implementation is too invasive

All 3 are united in objecting to the current implementation, which I'd 
summarize as SDR using libavdevice (let's call it option D). This makes it seem 
like there's a united front against SDR, but I think there's significant 
disagreement even among the people objecting to the current implementation as 
to which one of these 3 ought to be the right outcome for SDR. The discussion 
tends to go in circles. Discussions about C-vs-D tend to run into objections 
from B, trying to discuss the relative merits of B-vs-C runs into objections 
from A and so on.

This might be a good use of the TC (after a new GA and new TC is formed to 
avoid arguments about the validity of the decision). The TC could then settle 
on the direction for SDR in the project:

A. no SDR in ffmpeg at all
B. SDR via external library
C. SDR via a new libavradio library
D. SDR via libavdevice

For what it's worth as a user of ffmpeg I hope the outcome is not A, I believe 
having support for RTL-SDR in ffmpeg would be neat and I'd love to use it (at 
home, at work I'd compile ffmpeg with SDR disabled). I'm not qualified to 
comment on whether B,C or D are better ways to achieve it.

- Cosmin












___
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] aacdec: padding skip improvements

[Cosmin Stejerean via ffmpeg-devel]

> On Oct 4, 2023, at 7:37 PM, Lynne  wrote:
> 
> 2048 is just more widely encountered. I'm posting these patches
> to get an opinion:
>  - do we cut nothing at all (currently)
>  - do we cut 1024 (required by the standard/algorithm, and currently what our 
> AAC ENcoder outputs)
>  - do we cut 2048 (what is most widely expected)
> 
> My preference would be 1024. Note: this is only for raw AAC
> streams outside of a container. Streams inside of a container are currently
> correctly cut, with this value being overridden.

I think it would be good by default to have the ffmpeg encoder and decoder 
roundtrip correctly, and then leverage an option to specify a different padding 
if a different encoder was used. I think the important property is that if we 
take a PCM input, encode it to raw AAC with ffmpeg and then decode it to PCM 
output that we have the same number of PCM samples and they're all properly 
aligned. 

Since we can't correctly handle unknown encoders (that might be using 2048 or 
2112 priming samples) for the option to override the priming samples should be 
used in that case (which could also be set to 0 if someone really wants 
potentially distorted output before the decoder was properly primed).

- Cosmin
___
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 1/5] avutil/dovi_meta: add dv_md_compression to cfg record

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 1:23 PM, Niklas Haas  wrote:
> 
> From: Niklas Haas 
> 
> This field is used to signal the compression method in use.
> ---
> doc/APIchanges| 3 +++
> libavutil/dovi_meta.h | 9 +
> libavutil/version.h   | 2 +-
> 3 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 5751216b24..80ab3012c3 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
> 
> API changes, most recent first:
> 
> +2024-07-16 - xx - lavu 59.29.100 - dovi_meta.h
> +  Add AVDOVIDecoderConfigurationRecord.dv_md_compression.
> +
> 2024-07-xx - xx - lavf 61 - avformat.h
>   Deprecate avformat_transfer_internal_stream_timing_info()
>   and av_stream_get_codec_timebase() without replacement.
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index e168075a24..c942d0e133 100644
> --- a/libavutil/dovi_meta.h
> +++ b/libavutil/dovi_meta.h
> @@ -46,6 +46,7 @@
>  * uint8_t  el_present_flag
>  * uint8_t  bl_present_flag
>  * uint8_t  dv_bl_signal_compatibility_id
> + * uint8_t  dv_md_compression, the compression method in use
>  * @endcode
>  *
>  * @note The struct must be allocated with av_dovi_alloc() and
> @@ -60,8 +61,16 @@ typedef struct AVDOVIDecoderConfigurationRecord {
> uint8_t el_present_flag;
> uint8_t bl_present_flag;
> uint8_t dv_bl_signal_compatibility_id;
> +uint8_t dv_md_compression;
> } AVDOVIDecoderConfigurationRecord;
> 
> +enum AVDOVICompression {
> +AV_DOVI_COMPRESSION_NONE = 0,
> +AV_DOVI_COMPRESSION_LIMITED  = 1,
> +AV_DOVI_COMPRESSION_RESERVED = 2,
> +AV_DOVI_COMPRESSION_EXTENDED = 3,
> +};
> +
> 

Looks good to me.

- Cosmin


___
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 5/5] fftools/ffprobe: implement dv_md_compression

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 1:23 PM, Niklas Haas  wrote:
> 
> From: Niklas Haas 
> 
> ---
> fftools/ffprobe.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0b7d4ce0d7..265718467f 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2611,6 +2611,7 @@ static void print_pkt_side_data(WriterContext *w,
> print_int("el_present_flag", dovi->el_present_flag);
> print_int("bl_present_flag", dovi->bl_present_flag);
> print_int("dv_bl_signal_compatibility_id", 
> dovi->dv_bl_signal_compatibility_id);
> +print_int("dv_md_compression", dovi->dv_md_compression);
> } else if (sd->type == AV_PKT_DATA_AUDIO_SERVICE_TYPE) {
> enum AVAudioServiceType *t = (enum AVAudioServiceType *)sd->data;
> print_int("service_type", *t);
> -- 
> 2.45.2
> 
> 

LGTM


___
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 2/5] avformat/dovi_isom: implement dv_md_compression

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 1:23 PM, Niklas Haas  wrote:
> 
> From: Niklas Haas 
> 
> ---
> libavformat/dovi_isom.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
> index d49aa5a75f..269374cff9 100644
> --- a/libavformat/dovi_isom.c
> +++ b/libavformat/dovi_isom.c
> @@ -57,11 +57,14 @@ int ff_isom_parse_dvcc_dvvc(void *logctx, AVStream *st,
> 
> // Has enough remaining data
> if (size >= 5) {
> -dovi->dv_bl_signal_compatibility_id = ((*buf_ptr++) >> 4) & 0x0f; // 
> 4 bits
> +uint8_t buf = *buf_ptr++;
> +dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4 bits
> +dovi->dv_md_compression = (buf >> 2) & 0x03; // 2 bits

This seems fine based on what this code is currently doing, but I'm curious, 
should this be moved to something like get_bits at some point?

> } else {
> // 0 stands for None
> // Dolby Vision V1.2.93 profiles and levels
> dovi->dv_bl_signal_compatibility_id = 0;
> +dovi->dv_md_compression = AV_DOVI_COMPRESSION_NONE;
> }
> 
> if (!av_packet_side_data_add(&st->codecpar->coded_side_data, 
> &st->codecpar->nb_coded_side_data,
> @@ -71,13 +74,14 @@ int ff_isom_parse_dvcc_dvvc(void *logctx, AVStream *st,
> }
> 
> av_log(logctx, AV_LOG_TRACE, "DOVI in dvcC/dvvC/dvwC box, version: %d.%d, 
> profile: %d, level: %d, "
> -   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
> +   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d, 
> compression: %d\n",
>dovi->dv_version_major, dovi->dv_version_minor,
>dovi->dv_profile, dovi->dv_level,
>dovi->rpu_present_flag,
>dovi->el_present_flag,
>dovi->bl_present_flag,
> -   dovi->dv_bl_signal_compatibility_id);
> +   dovi->dv_bl_signal_compatibility_id,
> +   dovi->dv_md_compression);
> 
> return 0;
> }
> @@ -97,8 +101,9 @@ void ff_isom_put_dvcc_dvvc(void *logctx, uint8_t 
> out[ISOM_DVCC_DVVC_SIZE],
> put_bits(&pb, 1, !!dovi->el_present_flag);
> put_bits(&pb, 1, !!dovi->bl_present_flag);
> put_bits(&pb, 4, dovi->dv_bl_signal_compatibility_id & 0x0f);
> +put_bits(&pb, 2, dovi->dv_md_compression & 0x03);
> 
> -put_bits(&pb, 28, 0); /* reserved */
> +put_bits(&pb, 26, 0); /* reserved */
> put_bits32(&pb, 0); /* reserved */
> put_bits32(&pb, 0); /* reserved */
> put_bits32(&pb, 0); /* reserved */
> @@ -108,12 +113,14 @@ void ff_isom_put_dvcc_dvvc(void *logctx, uint8_t 
> out[ISOM_DVCC_DVVC_SIZE],
> 
> av_log(logctx, AV_LOG_DEBUG,
>"DOVI in %s box, version: %d.%d, profile: %d, level: %d, "
> -   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
> +   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d, "
> +   "compression: %d\n",

would it be more user friendly to log the display value like limited, none, 
extended rather than numeric value here?

>dovi->dv_profile > 10 ? "dvwC" : (dovi->dv_profile > 7 ? "dvvC" : 
> "dvcC"),
>dovi->dv_version_major, dovi->dv_version_minor,
>dovi->dv_profile, dovi->dv_level,
>dovi->rpu_present_flag,
>dovi->el_present_flag,
>dovi->bl_present_flag,
> -   dovi->dv_bl_signal_compatibility_id);
> +   dovi->dv_bl_signal_compatibility_id,
> +   dovi->dv_md_compression);
> }
> -- 
> 

Overall LGTM.

- Cosmin


___
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/5] avformat/mpegts: implement dv_md_compression

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 1:23 PM, Niklas Haas  wrote:
> 
> From: Niklas Haas 
> 
> ---
> libavformat/mpegts.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index c66a1ea6ed..6b02187eb1 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2213,10 +2213,12 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
> if (desc_end - *pp >= 1) {  // 8 bits
> buf = get8(pp, desc_end);
> dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4 
> bits
> +dovi->dv_md_compression = (buf >> 2) & 0x03; // 2 bits
> } else {
> // 0 stands for None
> // Dolby Vision V1.2.93 profiles and levels
> dovi->dv_bl_signal_compatibility_id = 0;
> +dovi->dv_md_compression = AV_DOVI_COMPRESSION_NONE;
> }
> 
> if (!av_packet_side_data_add(&st->codecpar->coded_side_data,
> @@ -2228,14 +2230,16 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
> AVStream *st, int stream_type
> }
> 
> av_log(fc, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d, 
> level: %d, "
> -   "rpu flag: %d, el flag: %d, bl flag: %d, dependency_pid: 
> %d, compatibility id: %d\n",
> +   "rpu flag: %d, el flag: %d, bl flag: %d, dependency_pid: 
> %d, "
> +   "compatibility id: %d, compression: %d\n",
>dovi->dv_version_major, dovi->dv_version_minor,
>dovi->dv_profile, dovi->dv_level,
>dovi->rpu_present_flag,
>dovi->el_present_flag,
>dovi->bl_present_flag,
>dependency_pid,
> -   dovi->dv_bl_signal_compatibility_id);
> +   dovi->dv_bl_signal_compatibility_id,
> +   dovi->dv_md_compression);
> }
> break;
> default:
> 

LGTM, although like the previous patch I'm curious if the logging should be 
using display names instead of integer values for compression.

- Cosmin


___
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 4/5] avformat/dump: implement dv_md_compression

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 1:23 PM, Niklas Haas  wrote:
> 
> From: Niklas Haas 
> 
> ---
> libavformat/dump.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 78b2481d90..5e1f367742 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -416,13 +416,15 @@ static void dump_dovi_conf(void *ctx, const 
> AVPacketSideData *sd,
> (const AVDOVIDecoderConfigurationRecord *)sd->data;
> 
> av_log(ctx, log_level, "version: %d.%d, profile: %d, level: %d, "
> -   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d",
> +   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d, "
> +   "compression: %d",
>dovi->dv_version_major, dovi->dv_version_minor,
>dovi->dv_profile, dovi->dv_level,
>dovi->rpu_present_flag,
>dovi->el_present_flag,
>dovi->bl_present_flag,
> -   dovi->dv_bl_signal_compatibility_id);
> +   dovi->dv_bl_signal_compatibility_id,
> +   dovi->dv_md_compression);
> }
> 
> static void dump_s12m_timecode(void *ctx, const AVStream *st, const 
> AVPacketSideData *sd,
> 

LGTM

- Cosmin
___
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] Add Mediacodec audio decoders support

[Cosmin Stejerean via ffmpeg-devel]

> On Jul 16, 2024, at 4:58 PM, Zhao Zhili  wrote:
> 
> 
> 
>> On Jul 16, 2024, at 21:20, Matthieu Bouron  wrote:
>> 
>> On Wed, Jul 10, 2024 at 6:31 PM Matthieu Bouron
>>  wrote:
>>> 
>>> On Wed, Jul 10, 2024 at 4:04 PM Zhao Zhili  wrote:
 
 
> On Jun 12, 2024, at 21:42, Matthieu Bouron  
> wrote:
> 
> Hello,
> 
> This patchset adds Mediacodec audio decoders support. Currently, only 
> AAC, AMR,
> MP3, FLAC, VORBIS and OPUS are supported.
> 
> This is mainly useful to avoid shipping Android builds of FFmpeg that are
> subjects to licensing/patents (due to AAC and AMR).
 
 I’m not keen on put OS audio decoder/encoder wrapper into FFmpeg. They 
 don’t bring
 new features, they don’t improve performance. I know these type of wrapper 
 exist in current
 project, but I’m not sure if it’s a good idea to add more.
>>> 
>>> I agree that on the technical side it doesn't bring new features nor
>>> performance improvements. It's all about avoiding licensing/patents
>>> issues with AAC and AMR here.
>>> In this specific case we already have the wrapper infrastructure, the
>>> audio part only needs small adjustments to work.
>>> Moreover, if that helps, I can reduce the scope of the patch to AAC
>>> and AMR only and get rid of mp3/flac/vorbis/opus support. What do you
>>> think ?
>> 
>> Ping.
>> 
>> IMHO, this benefits users wanting to ship an Android app that relies
>> on FFmpeg upstream in countries that are subject to AAC/AMR licensing.
>> While I agree that it's not great from a purely technical pov since we
>> already have better native decoders, it will allow the use of FFmpeg
>> in such situation without the need to use or create another FFmpeg
>> fork dedicated to Android. Plus, as I said above, we already have the
>> wrapper and the additional code to make it work for audio is
>> relatively small and scoped. Restricting the wrapper to AAC/AMR seems
>> like a good compromise to me.
> 
> Sounds reasonable, but I’d like to get more opinions. cc TC.

To add another data point, the platform decoders might also be more secure due 
to sandboxing. I believe as of Android Q the software decoders provided by 
MediaCodec have been moved to run within a constrained sandbox.

- Cosmin


___
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".