Re: [FFmpeg-devel] [PATCH] d3d12va_encode_hevc: use base to init VPS/SPS/PPS
>From: ffmpeg-devel On Behalf Of Tong >Wu >To: ffmpeg-devel@ffmpeg.org >Subject: [FFmpeg-devel] [PATCH] d3d12va_encode_hevc: use base to init >VPS/SPS/PPS > >Patch attached. > >Tong Ping. Will apply if there's no more comment on this patch Thanks, Tong ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avcodec/escape130: move get_buffer down
This way the (slow) allocation of an image is done after various additional checks Fixes: Timeout Fixes: 379418967/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ESCAPE130_fuzzer-6507383574036480 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/escape130.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/escape130.c b/libavcodec/escape130.c index 3b0460fd79a..4482a0e0704 100644 --- a/libavcodec/escape130.c +++ b/libavcodec/escape130.c @@ -212,9 +212,6 @@ static int escape130_decode_frame(AVCodecContext *avctx, AVFrame *pic, return AVERROR_INVALIDDATA; } -if ((ret = ff_get_buffer(avctx, pic, 0)) < 0) -return ret; - if ((ret = init_get_bits8(&gb, avpkt->data, avpkt->size)) < 0) return ret; skip_bits_long(&gb, 16 * 8); @@ -310,6 +307,9 @@ static int escape130_decode_frame(AVCodecContext *avctx, AVFrame *pic, skip--; } +if ((ret = ff_get_buffer(avctx, pic, 0)) < 0) +return ret; + new_y = s->new_y; new_cb = s->new_u; new_cr = s->new_v; -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] avformat/mov: free stream_info when the surrounding array is freed
Fixes: memleak
Fixes:
378408474/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5699368121860096
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 24feadb95b3..40535ec21d9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -10953,6 +10953,9 @@ static int mov_read_packet(AVFormatContext *s, AVPacket
*pkt)
// Discard current fragment index
if (mov->frag_index.allocated_size > 0) {
+for(int i = 0; i < mov->frag_index.nb_items; i++) {
+av_freep(&mov->frag_index.item[i].stream_info);
+}
av_freep(&mov->frag_index.item);
mov->frag_index.nb_items = 0;
mov->frag_index.allocated_size = 0;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] avcodec/rv60dec: Check NEXT/LAST availability
Fixes: NULL ptr use
Fixes:
378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rv60dec.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
index 4cc71dcd6ee..528f91acf05 100644
--- a/libavcodec/rv60dec.c
+++ b/libavcodec/rv60dec.c
@@ -1745,15 +1745,24 @@ static int decode_cu_r(RV60Context * s, AVFrame *
frame, ThreadContext * thread,
bx = mv_x << 2;
by = mv_y << 2;
+if (!(mv.mvref&2)) {
+if (!s->last_frame[LAST_PIC]->data[0]) {
+av_log(s->avctx, AV_LOG_ERROR, "missing reference
frame\n");
+return AVERROR_INVALIDDATA;
+}
+}
+if (mv.mvref & 6) {
+if (!s->last_frame[NEXT_PIC]->data[0]) {
+av_log(s->avctx, AV_LOG_ERROR, "missing reference
frame\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
switch (mv.mvref) {
case MVREF_REF0:
mc(s, frame->data, frame->linesize, s->last_frame[LAST_PIC],
bx, by, bw, bh, mv.f_mv, 0);
break;
case MVREF_REF1:
-if (!s->last_frame[NEXT_PIC]->data[0]) {
-av_log(s->avctx, AV_LOG_ERROR, "missing reference
frame\n");
-return AVERROR_INVALIDDATA;
-}
mc(s, frame->data, frame->linesize, s->last_frame[NEXT_PIC],
bx, by, bw, bh, mv.f_mv, 0);
break;
case MVREF_BREF:
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] avcodec/rv60dec: Use get_bits_long()
Fixes:
378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
Fixes: assertion failure
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rv60dec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
index 449650223d8..4cc71dcd6ee 100644
--- a/libavcodec/rv60dec.c
+++ b/libavcodec/rv60dec.c
@@ -395,10 +395,13 @@ static int read_slice_sizes(RV60Context *s, GetBitContext
*gb)
for (int i = 0; i < s->cu_height; i++)
s->slice[i].sign = get_bits1(gb);
-s->slice[0].size = last_size = sum = get_bits(gb, nbits);
+s->slice[0].size = last_size = sum = get_bits_long(gb, nbits);
+
+if (sum < 0)
+return AVERROR_INVALIDDATA;
for (int i = 1; i < s->cu_height; i++) {
-int diff = get_bits(gb, nbits);
+int diff = get_bits_long(gb, nbits);
if (s->slice[i].sign)
last_size += diff;
else
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/6] tools/target_dec_fuzzer: Adjust Threshold for indeo5
Fixes:
379768251/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO5_fuzzer-5981329084186624
Fixes: Timeout
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 432e9488168..48fa0e93a1d 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -255,6 +255,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_HQ_HQA: maxpixels /= 128; break;
case AV_CODEC_ID_IFF_ILBM:maxpixels /= 4096; break;
case AV_CODEC_ID_INDEO4: maxpixels /= 128; break;
+case AV_CODEC_ID_INDEO5: maxpixels /= 1024; break;
case AV_CODEC_ID_INTERPLAY_ACM: maxsamples /= 16384; break;
case AV_CODEC_ID_JPEG2000:maxpixels /= 16384; break;
case AV_CODEC_ID_LAGARITH:maxpixels /= 1024; break;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] tools/target_dec_fuzzer: Adjust threshold for MVC1
Fixes: Timeout
Fixes:
378231213/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MVC1_fuzzer-6640960500465664
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 48fa0e93a1d..1f01819eb84 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -271,6 +271,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_MSZH:maxpixels /= 128; break;
case AV_CODEC_ID_MTS2:maxpixels /= 4096; break;
case AV_CODEC_ID_MV30:maxpixels /= 128; break;
+case AV_CODEC_ID_MVC1:maxpixels /= 1024; break;
case AV_CODEC_ID_MVC2:maxpixels /= 128; break;
case AV_CODEC_ID_MVHA:maxpixels /= 16384; break;
case AV_CODEC_ID_MVDV:maxpixels /= 1024; break;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/6] avcodec/rv60dec: Use get_bits_long()
On Sun, Dec 08, 2024 at 04:57:00AM +0100, Michael Niedermayer wrote:
> Fixes:
> 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
> Fixes: assertion failure
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/rv60dec.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
> index 449650223d8..4cc71dcd6ee 100644
> --- a/libavcodec/rv60dec.c
> +++ b/libavcodec/rv60dec.c
> @@ -395,10 +395,13 @@ static int read_slice_sizes(RV60Context *s,
> GetBitContext *gb)
> for (int i = 0; i < s->cu_height; i++)
> s->slice[i].sign = get_bits1(gb);
>
> -s->slice[0].size = last_size = sum = get_bits(gb, nbits);
> +s->slice[0].size = last_size = sum = get_bits_long(gb, nbits);
> +
> +if (sum < 0)
> +return AVERROR_INVALIDDATA;
>
> for (int i = 1; i < s->cu_height; i++) {
> -int diff = get_bits(gb, nbits);
> +int diff = get_bits_long(gb, nbits);
> if (s->slice[i].sign)
> last_size += diff;
> else
please apply
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/6] avcodec/rv60dec: Check NEXT/LAST availability
On Sun, Dec 08, 2024 at 04:57:01AM +0100, Michael Niedermayer wrote:
> Fixes: NULL ptr use
> Fixes:
> 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/rv60dec.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
> index 4cc71dcd6ee..528f91acf05 100644
> --- a/libavcodec/rv60dec.c
> +++ b/libavcodec/rv60dec.c
> @@ -1745,15 +1745,24 @@ static int decode_cu_r(RV60Context * s, AVFrame *
> frame, ThreadContext * thread,
> bx = mv_x << 2;
> by = mv_y << 2;
>
> +if (!(mv.mvref&2)) {
hi michael. please insert some space around the & symbol
> +if (!s->last_frame[LAST_PIC]->data[0]) {
> +av_log(s->avctx, AV_LOG_ERROR, "missing reference
> frame\n");
> +return AVERROR_INVALIDDATA;
> +}
> +}
> +if (mv.mvref & 6) {
> +if (!s->last_frame[NEXT_PIC]->data[0]) {
> +av_log(s->avctx, AV_LOG_ERROR, "missing reference
> frame\n");
> +return AVERROR_INVALIDDATA;
> +}
> +}
> +
> switch (mv.mvref) {
> case MVREF_REF0:
> mc(s, frame->data, frame->linesize, s->last_frame[LAST_PIC],
> bx, by, bw, bh, mv.f_mv, 0);
> break;
> case MVREF_REF1:
> -if (!s->last_frame[NEXT_PIC]->data[0]) {
> -av_log(s->avctx, AV_LOG_ERROR, "missing reference
> frame\n");
> -return AVERROR_INVALIDDATA;
> -}
> mc(s, frame->data, frame->linesize, s->last_frame[NEXT_PIC],
> bx, by, bw, bh, mv.f_mv, 0);
> break;
> case MVREF_BREF:
suggest also setting enum MVREF_NONE = 0 higher up in the file, so it is clear
to readers these enums are ordered deliberately.
enum MVRefEnum {
MVREF_NONE = 0
MVREF_REF0,
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC election
On 06/12/2024 02:01, Lynne via ffmpeg-devel wrote: On 28/11/2024 23:29, Anton Khirnov wrote: Hi all, the current Technical Committee (TC) was elected on 2023-12-05 and its mandate lasts for one year, so we should hold a new election soon. If there are no unforeseen circumstances, I would like to start the vote on Monday 2024-12-09. As a reminder, the TC is in charge of resolving technical disputes. If you would like to be a TC member, please say so in a reply to this email. Cheers, Since there haven't been 5 candidates yet, I volunteer. Was not planning on running this year, I'm much more interested in actually working. ___ 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". Since there are more than 4 candidates now, my role is done, count me out. OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/png{dec, enc}: update mDCV and cLLI chunk capitalization
Hi Leo!
On 2024-12-01 09:20 -0500, Leo Izen wrote:
> The PNGv3 Specification Draft [1] has changed the capitalization
> of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates
> FFmpeg to work with the new chunk names while retaining decode-side
> compatibility with files created using the old names.
>
> [1]: https://w3c.github.io/png/
>
> Signed-off-by: Leo Izen
> ---
> libavcodec/pngdec.c | 12 +++-
> libavcodec/pngenc.c | 4 ++--
> tests/ref/fate/png-mdcv | 2 +-
> 3 files changed, 10 insertions(+), 8 deletions(-)
LGTM.
Your changes are sensible and complete as far as I could check.
Only problem I could think of is being to fast, as it isn't
in the latest published version of the W3C yet.
If I understood chunk naming conventions correctly they marked
those 2 chunks unsafe to copy, which will probably stay that
way. So I think the patch can be pushed.
Best regards,
Alexander
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index c5b32c166d..f8cb61775e 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -757,7 +757,7 @@ static int populate_avctx_color_fields(AVCodecContext
> *avctx, AVFrame *frame)
> if (clli) {
> /*
> * 0.0001 divisor value
> - * see: https://www.w3.org/TR/png-3/#cLLi-chunk
> + * see: https://www.w3.org/TR/png-3/#cLLI-chunk
> */
> clli->MaxCLL = s->clli_max / 1;
> clli->MaxFALL = s->clli_avg / 1;
> @@ -1566,18 +1566,20 @@ static int decode_frame_common(AVCodecContext *avctx,
> PNGDecContext *s,
>
> break;
> }
> -case MKTAG('c', 'L', 'L', 'i'):
> +case MKTAG('c', 'L', 'L', 'i'): /* legacy spelling, for backwards
> compat */
> +case MKTAG('c', 'L', 'L', 'I'):
> if (bytestream2_get_bytes_left(&gb_chunk) != 8) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid cLLi chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> +av_log(avctx, AV_LOG_WARNING, "Invalid cLLI chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> break;
> }
> s->have_clli = 1;
> s->clli_max = bytestream2_get_be32u(&gb_chunk);
> s->clli_avg = bytestream2_get_be32u(&gb_chunk);
> break;
> -case MKTAG('m', 'D', 'C', 'v'):
> +case MKTAG('m', 'D', 'C', 'v'): /* legacy spelling, for backward
> compat */
> +case MKTAG('m', 'D', 'C', 'V'):
> if (bytestream2_get_bytes_left(&gb_chunk) != 24) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid mDCv chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> +av_log(avctx, AV_LOG_WARNING, "Invalid mDCV chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> break;
> }
> s->have_mdcv = 1;
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index cb79c04e11..37e8d5bfcf 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -445,7 +445,7 @@ static int encode_headers(AVCodecContext *avctx, const
> AVFrame *pict)
> AVContentLightMetadata *clli = (AVContentLightMetadata *)
> side_data->data;
> AV_WB32(s->buf, clli->MaxCLL * 1);
> AV_WB32(s->buf + 4, clli->MaxFALL * 1);
> -png_write_chunk(&s->bytestream, MKTAG('c', 'L', 'L', 'i'), s->buf,
> 8);
> +png_write_chunk(&s->bytestream, MKTAG('c', 'L', 'L', 'I'), s->buf,
> 8);
> }
>
> side_data = av_frame_get_side_data(pict,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> @@ -460,7 +460,7 @@ static int encode_headers(AVCodecContext *avctx, const
> AVFrame *pict)
> AV_WB16(s->buf + 14, PNG_Q2D(mdcv->white_point[1], 5));
> AV_WB32(s->buf + 16, PNG_Q2D(mdcv->max_luminance, 1));
> AV_WB32(s->buf + 20, PNG_Q2D(mdcv->min_luminance, 1));
> -png_write_chunk(&s->bytestream, MKTAG('m', 'D', 'C', 'v'),
> s->buf, 24);
> +png_write_chunk(&s->bytestream, MKTAG('m', 'D', 'C', 'V'),
> s->buf, 24);
> }
> }
>
> diff --git a/tests/ref/fate/png-mdcv b/tests/ref/fate/png-mdcv
> index c524a94ded..4328c56349 100644
> --- a/tests/ref/fate/png-mdcv
> +++ b/tests/ref/fate/png-mdcv
> @@ -1,4 +1,4 @@
> -fc68fe6c8c72343b96d2695f6913995b *tests/data/fate/png-mdcv.image2pipe
> +b1837f5557ad969a3f9763840480d5c0 *tests/data/fate/png-mdcv.image2pipe
> 439248 tests/data/fate/png-mdcv.image2pipe
> #tb 0: 1/25
> #media_type 0: video
> --
___
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: CC election
Hi all, we only have 4 volunteers for the CC so far, so need at least one more person. Ideally several, since elections are better when they are competitive. -- Anton Khirnov ___ 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] [FFmpeg-cvslog] avfilter/vf_scale: switch to new swscale API
On Fri, 06 Dec 2024 20:57:54 +0100 Michael Niedermayer wrote: > Hi > > On Fri, Dec 06, 2024 at 02:40:06PM +0100, Niklas Haas wrote: > > On Fri, 06 Dec 2024 14:31:43 +0100 Michael Niedermayer > > wrote: > > > Hi > > > > > > On Mon, Nov 25, 2024 at 10:11:49AM +, Niklas Haas wrote: > > > > ffmpeg | branch: master | Niklas Haas | Fri Jun 28 > > > > 21:42:23 2024 +0200| [04ce01df0bb2d66e143bcfcea439afc2a1b8d96e] | > > > > committer: Niklas Haas > > > > > > > > avfilter/vf_scale: switch to new swscale API > > > > > > > > Most logic from this filter has been co-opted into swscale itself, > > > > allowing the resulting filter to be substantially simpler as it no > > > > longer has to worry about context initialization, interlacing, etc. > > > > > > > > Sponsored-by: Sovereign Tech Fund > > > > Signed-off-by: Niklas Haas > > > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=04ce01df0bb2d66e143bcfcea439afc2a1b8d96e > > > > --- > > > > > > > > libavfilter/vf_scale.c | 351 > > > > +++-- > > > > 1 file changed, 77 insertions(+), 274 deletions(-) > > > > > > It seems this broke: > > > > > > ./ffmpeg -i mm-short.mpg -vcodec prores -vframes 3 -bitexact -an > > > prores.mkv > > > ./ffplay prores.mkv > > > > > > [swscaler @ 0x7f76380068c0] Unsupported input (Operation not supported): > > > fmt:yuv422p10le csp:gbr prim:reserved trc:reserved -> fmt:yuv420p > > > csp:bt709 prim:reserved trc:reserved > > > > What is the meaning of AVCOL_*_RESERVED and why should we accept it here? > > > > If you look at e.g. H.273, it clearly reserves these values for future use, > > and so IMHO treatind them as invalid inputs is not entirely incorrect. > > > > Could we fix the prores decoder to instead output UNSPECIFIED? > > the decoder should probably output the value stored in the file. > > I have to say its a little odd a file generated by ffmpeg contains a > reserved value but how do i know without a prores spec ... > > Now even if theres an argument for the prores decoder not to output that > value here. Another decoder and other file could still have exactly that > reserved value. And in that case that decoder should output that Should we: 1) Treat RESERVED as UNSPECIFIED 2) Accept RESERVED only when no tranformation is needed (i.e. keep the input as RESERVED, fail if the user requests a conversion to a specific csp) 3) Preserve the current behavior of rejecting RESERVED outright ? What makes this a bit annoying is that we typically reject RESERVED inside the lavfi filter chain; and I was certainly hoping to add e.g. transfer function support to the filter negotiation code at some point. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Good people do not need laws to tell them to act responsibly, while bad > people will find a way around the laws. -- Plato > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC election
Hi all, we have 6 volunteers for the TC, so I think the vote can start on Monday as previously announced. If someone else still wants to volunteer, please do so ASAP. -- Anton Khirnov ___ 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: CC election
I am hereby volunteering for CC. I believe this community is deeply sick and has been for a very long time. I also believe an active CC can make important steps towards fixing that. If elected, I will advocate for the following: 1) Swift and determined action against uncivil behaviour, no matter who it comes from. 2) CC should look at patterns of behaviour rather than strictly focus on individual infractions. 3) Enforcement should be consistent and publicly announced. -- Anton Khirnov ___ 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/png{dec, enc}: update mDCV and cLLI chunk capitalization
On 12/1/24 9:20 AM, Leo Izen wrote: The PNGv3 Specification Draft [1] has changed the capitalization of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates FFmpeg to work with the new chunk names while retaining decode-side compatibility with files created using the old names. [1]: https://w3c.github.io/png/ Signed-off-by: Leo Izen Will merge soon if there's no issues. - Leo Izen (Traneptora) ___ 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] Decoding performance -f rawvideo pipe:1 vs BMP images output
On 12/6/24 1:30 PM, Clément Péron wrote: Hi, On Fri, 6 Dec 2024 at 18:55, Clément Péron wrote: Hi, I am trying to convert a RTSP stream to a series of frames that I send to a stdout PIPE with a low latency . I first tried this command. In general, user issues are for the ffmpeg-user mailing list, rather than ffmpeg-devel. However, you did bring up an issue with the codebase after further investigation. What happens if you use -thread_queue_size 0 before the output? - Leo Izen (Traneptora) ___ 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] avfilter/af_ashowinfo: fix scaling factor of replaygain peak values
On 12/6/24 3:23 PM, Kacper Michajłow wrote: Commit 8542f9c4f17125d483c40c0c5723842f1c982f81 changed replaygain peak values to use 100k instead of UINT32_MAX as peak, with possibility of overflow. af_ashowinfo was never updated to reflect this, so we update it now. Fixes: 8542f9c4f17125d483c40c0c5723842f1c982f81 Signed-off-by: Kacper Michajłow --- libavfilter/af_ashowinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/af_ashowinfo.c b/libavfilter/af_ashowinfo.c index b83847b866..de94d4c7c2 100644 --- a/libavfilter/af_ashowinfo.c +++ b/libavfilter/af_ashowinfo.c @@ -120,7 +120,7 @@ static void print_peak(AVFilterContext *ctx, const char *str, uint32_t peak) if (!peak) av_log(ctx, AV_LOG_INFO, "unknown"); else -av_log(ctx, AV_LOG_INFO, "%f", (float)peak / UINT32_MAX); +av_log(ctx, AV_LOG_INFO, "%f", peak / 10.0f); av_log(ctx, AV_LOG_INFO, ", "); } LGTM, will apply. - Leo Izen (Traneptora) ___ 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] avformat/iff: SndAnim decoding
Fixes ticket #5553.
---
libavformat/iff.c | 302 ++
1 file changed, 201 insertions(+), 101 deletions(-)
diff --git a/libavformat/iff.c b/libavformat/iff.c
index 7601baa629..9ab1252e67 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -111,6 +111,8 @@ typedef struct IffDemuxContext {
int is_64bit; ///< chunk size is 64-bit
int64_t body_pos;
int64_t body_end;
+int64_t sbdy_pos;
+int64_t resume_pos;
uint32_t body_size;
svx8_compression_type svx8_compression;
unsigned maud_bits;
@@ -122,7 +124,9 @@ typedef struct IffDemuxContext {
unsigned transparency; ///< transparency color index in palette
unsigned masking; ///< masking method used
uint8_t tvdc[32]; ///< TVDC lookup table
-int64_t pts;
+uint32_t form_tag;
+int audio_stream_index;
+int video_stream_index;
} IffDemuxContext;
/* Metadata string read */
@@ -385,7 +389,7 @@ static int read_dst_frame(AVFormatContext *s, AVPacket *pkt)
if (data_size & 1)
avio_skip(pb, 1);
pkt->flags |= AV_PKT_FLAG_KEY;
-pkt->stream_index = 0;
+pkt->stream_index = iff->audio_stream_index;
pkt->duration = s->streams[0]->codecpar->sample_rate / 75;
pkt->pos = chunk_pos;
@@ -416,11 +420,23 @@ static const uint8_t deep_bgra[] = {0, 0, 0, 4, 0, 3, 0,
8, 0, 2, 0, 8, 0, 1, 0
static const uint8_t deep_argb[] = {0, 0, 0, 4, 0,17, 0, 8, 0, 1, 0, 8, 0, 2,
0, 8};
static const uint8_t deep_abgr[] = {0, 0, 0, 4, 0,17, 0, 8, 0, 3, 0, 8, 0, 2,
0, 8};
+static AVStream * new_stream(AVFormatContext *s, AVStream **st_ptr, int
*index_ptr, enum AVMediaType codec_type)
+{
+if (!*st_ptr) {
+*st_ptr = avformat_new_stream(s, NULL);
+if (!*st_ptr)
+return NULL;
+(*st_ptr)->codecpar->codec_type = codec_type;
+(*index_ptr) = (*st_ptr)->index;
+ }
+ return *st_ptr;
+}
+
static int iff_read_header(AVFormatContext *s)
{
IffDemuxContext *iff = s->priv_data;
AVIOContext *pb = s->pb;
-AVStream *st;
+AVStream *sta = NULL, *stv = NULL;
uint8_t *buf;
uint32_t chunk_id;
uint64_t data_size;
@@ -430,16 +446,12 @@ static int iff_read_header(AVFormatContext *s)
uint8_t fmt[16];
int fmt_size;
-st = avformat_new_stream(s, NULL);
-if (!st)
-return AVERROR(ENOMEM);
-
-st->codecpar->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_MONO;
+iff->audio_stream_index = -1;
+iff->video_stream_index = -1;
iff->is_64bit = avio_rl32(pb) == ID_FRM8;
avio_skip(pb, iff->is_64bit ? 8 : 4);
-// codec_tag used by ByteRun1 decoder to distinguish progressive (PBM) and
interlaced (ILBM) content
-st->codecpar->codec_tag = avio_rl32(pb);
-if (st->codecpar->codec_tag == ID_ANIM) {
+iff->form_tag = avio_rl32(pb);
+if (iff->form_tag == ID_ANIM) {
avio_skip(pb, 12);
}
iff->bitmap_compression = -1;
@@ -461,23 +473,24 @@ static int iff_read_header(AVFormatContext *s)
switch(chunk_id) {
case ID_VHDR:
-st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-
if (data_size < 14)
return AVERROR_INVALIDDATA;
+if (!new_stream(s, &sta, &iff->audio_stream_index,
AVMEDIA_TYPE_AUDIO))
+return AVERROR(ENOMEM);
avio_skip(pb, 12);
-st->codecpar->sample_rate = avio_rb16(pb);
+sta->codecpar->sample_rate = avio_rb16(pb);
if (data_size >= 16) {
avio_skip(pb, 1);
iff->svx8_compression = avio_r8(pb);
}
+sta->codecpar->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_MONO;
break;
case ID_MHDR:
-st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-
if (data_size < 32)
return AVERROR_INVALIDDATA;
+if (!new_stream(s, &sta, &iff->audio_stream_index,
AVMEDIA_TYPE_AUDIO))
+return AVERROR(ENOMEM);
avio_skip(pb, 4);
iff->maud_bits = avio_rb16(pb);
avio_skip(pb, 2);
@@ -486,14 +499,14 @@ static int iff_read_header(AVFormatContext *s)
if (!den)
return AVERROR_INVALIDDATA;
avio_skip(pb, 2);
-st->codecpar->sample_rate = num / den;
-st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
-st->codecpar->ch_layout.nb_channels = avio_rb16(pb);
+sta->codecpar->sample_rate = num / den;
+sta->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC;
+sta->codecpar->ch_layout.nb_channels = avio_rb16(pb);
iff->maud_compression = avio_rb16(pb);
-if (st->codecpar->ch_layout.nb_channels == 1)
-st->codecpar->ch_layout =
(AVChannelLayout)AV_CHANNEL_LAYOUT_MONO;
-else
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election
On Thu, 28 Nov 2024 15:32:52 +0100, Anton Khirnov wrote: > If you would > like to be a CC member, please say so in a reply to this email. > > Cheers, I volunteer for the CC. My goal is to moderate and reject all personal discussion on the mailinglist. Before it reaches the list. But also to encourage developers to remove personal discussion and resend their development mails free of negativity. -compn ___ 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 11/16] swscale/csputils: add internal colorspace math helpers
On Fri, 06 Dec 2024 10:16:23 -0500 Leo Izen wrote:
>
>
> On 12/6/24 9:32 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Logic is, for the most part, a straight port of similar logic in
> > liplacebo's colorspace.c, with some general edits and refactors.
> > ---
> > libswscale/Makefile | 1 +
> > libswscale/csputils.c | 412 ++
> > libswscale/csputils.h | 111
> > 3 files changed, 524 insertions(+)
> > create mode 100644 libswscale/csputils.c
> > create mode 100644 libswscale/csputils.h
> >
> > diff --git a/libswscale/Makefile b/libswscale/Makefile
> > index 81f32f4dd7..08036634b7 100644
> > --- a/libswscale/Makefile
> > +++ b/libswscale/Makefile
> > @@ -6,6 +6,7 @@ HEADERS = swscale.h
> > \
> > version_major.h \
> >
> > OBJS = alphablend.o \
> > + csputils.o \
> > hscale.o \
> > hscale_fast_bilinear.o \
> > gamma.o \
> > diff --git a/libswscale/csputils.c b/libswscale/csputils.c
> > new file mode 100644
> > index 00..479caff5dd
> > --- /dev/null
> > +++ b/libswscale/csputils.c
> > @@ -0,0 +1,412 @@
> > +/*
> > + * Copyright (C) 2024 Niklas Haas
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +#include "libavutil/csp.h"
> > +
> > +#include "csputils.h"
> > +#include "utils.h"
> > +
> > +void ff_sws_matrix3x3_mul(SwsMatrix3x3 *a, const SwsMatrix3x3 *b)
> > +{
> > +float a00 = a->m[0][0], a01 = a->m[0][1], a02 = a->m[0][2],
> > + a10 = a->m[1][0], a11 = a->m[1][1], a12 = a->m[1][2],
> > + a20 = a->m[2][0], a21 = a->m[2][1], a22 = a->m[2][2];
> > +
> > +for (int i = 0; i < 3; i++) {
> > +a->m[0][i] = a00 * b->m[0][i] + a01 * b->m[1][i] + a02 *
> > b->m[2][i];
> > +a->m[1][i] = a10 * b->m[0][i] + a11 * b->m[1][i] + a12 *
> > b->m[2][i];
> > +a->m[2][i] = a20 * b->m[0][i] + a21 * b->m[1][i] + a22 *
> > b->m[2][i];
> > +}
> > +}
> > +
> > +void ff_sws_matrix3x3_rmul(const SwsMatrix3x3 *a, SwsMatrix3x3 *b)
> > +{
> > +float b00 = b->m[0][0], b01 = b->m[0][1], b02 = b->m[0][2],
> > + b10 = b->m[1][0], b11 = b->m[1][1], b12 = b->m[1][2],
> > + b20 = b->m[2][0], b21 = b->m[2][1], b22 = b->m[2][2];
> > +
> > +for (int i = 0; i < 3; i++) {
> > +b->m[i][0] = a->m[i][0] * b00 + a->m[i][1] * b10 + a->m[i][2] *
> > b20;
> > +b->m[i][1] = a->m[i][0] * b01 + a->m[i][1] * b11 + a->m[i][2] *
> > b21;
> > +b->m[i][2] = a->m[i][0] * b02 + a->m[i][1] * b12 + a->m[i][2] *
> > b22;
> > +}
> > +}
> > +
> > +void ff_sws_matrix3x3_invert(SwsMatrix3x3 *mat)
> > +{
> > +double m00 = mat->m[0][0], m01 = mat->m[0][1], m02 = mat->m[0][2],
> > + m10 = mat->m[1][0], m11 = mat->m[1][1], m12 = mat->m[1][2],
> > + m20 = mat->m[2][0], m21 = mat->m[2][1], m22 = mat->m[2][2];
> > +
> > +// calculate the adjoint
> > +double a00 = (m11 * m22 - m21 * m12);
> > +double a01 = -(m01 * m22 - m21 * m02);
> > +double a02 = (m01 * m12 - m11 * m02);
> > +double a10 = -(m10 * m22 - m20 * m12);
> > +double a11 = (m00 * m22 - m20 * m02);
> > +double a12 = -(m00 * m12 - m10 * m02);
> > +double a20 = (m10 * m21 - m20 * m11);
> > +double a21 = -(m00 * m21 - m20 * m01);
> > +double a22 = (m00 * m11 - m10 * m01);
> > +
> > +// calculate the determinant (as inverse == 1/det * adjoint,
> > +// adjoint * m == identity * det, so this calculates the det)
> > +double det = m00 * a00 + m10 * a01 + m20 * a02;
> > +det = 1.0 / det;
> > +
> > +mat->m[0][0] = det * a00;
> > +mat->m[0][1] = det * a01;
> > +mat->m[0][2] = det * a02;
> > +mat->m[1][0] = det * a10;
> > +mat->m[1][1] = det * a11;
> > +mat->m[1][2] = det * a12;
> > +mat->m[2][0] = det * a20;
> > +mat->m[2][1] = det * a21;
> > +mat->m[2][2] = det * a22;
> > +}
> > +
> > +void ff_sws_mat
Re: [FFmpeg-devel] [PATCH v2 10/16] avfilter/vf_scale: strip metadata when changing colorspace
On Fri, 06 Dec 2024 10:17:48 -0500 Leo Izen wrote:
>
>
> On 12/6/24 9:32 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This is no longer relevant after a change in color space.
> > ---
> > libavfilter/vf_scale.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index e33617468a..a56d452c6c 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -868,6 +868,18 @@ scale:
> > if (scale->out_transfer != AVCOL_TRC_UNSPECIFIED)
> > out->color_trc = scale->out_transfer;
> >
> > +if (in->color_primaries != out->color_primaries ||
> > +in->color_trc != out->color_trc)
> > +{
> > +av_frame_remove_side_data(out,
> > AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_PLUS);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_VIVID);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_ICC_PROFILE);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_METADATA);
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_RPU_BUFFER);
> > +}
> > +
> > av_reduce(&out->sample_aspect_ratio.num,
> > &out->sample_aspect_ratio.den,
> > (int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
> > (int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
>
> I think Mastering Display Metadata may still be relevant after a change
> in TRC but not primaries (e.g. after linearization), since it only
> references the gamut of the mastering display.
That is true; but I think I'd rather handle this as a separate patch
that re-attaches a modified / inferred set of MDM reflecting the new state
after tone/gamut mapping.
We need to strip the original and attach a modified copy in either case, and
the status quo after this patch seems no less wrong than not stripping this
metadata. (Otherwise, the behavior you get is something very strange like
HDR-in-SDR curves and other things that one should not get by default)
>
> - Leo Izen (Traneptora)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 10/16] avfilter/vf_scale: strip metadata when changing colorspace
On Sat, 07 Dec 2024 22:47:57 +0100 Niklas Haas wrote:
> On Fri, 06 Dec 2024 10:17:48 -0500 Leo Izen wrote:
> >
> >
> > On 12/6/24 9:32 AM, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > This is no longer relevant after a change in color space.
> > > ---
> > > libavfilter/vf_scale.c | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > > index e33617468a..a56d452c6c 100644
> > > --- a/libavfilter/vf_scale.c
> > > +++ b/libavfilter/vf_scale.c
> > > @@ -868,6 +868,18 @@ scale:
> > > if (scale->out_transfer != AVCOL_TRC_UNSPECIFIED)
> > > out->color_trc = scale->out_transfer;
> > >
> > > +if (in->color_primaries != out->color_primaries ||
> > > +in->color_trc != out->color_trc)
> > > +{
> > > +av_frame_remove_side_data(out,
> > > AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> > > +av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_PLUS);
> > > +av_frame_remove_side_data(out, AV_FRAME_DATA_DYNAMIC_HDR_VIVID);
> > > +av_frame_remove_side_data(out,
> > > AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> > > +av_frame_remove_side_data(out, AV_FRAME_DATA_ICC_PROFILE);
> > > +av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_METADATA);
> > > +av_frame_remove_side_data(out, AV_FRAME_DATA_DOVI_RPU_BUFFER);
> > > +}
> > > +
> > > av_reduce(&out->sample_aspect_ratio.num,
> > > &out->sample_aspect_ratio.den,
> > > (int64_t)in->sample_aspect_ratio.num * outlink->h *
> > > link->w,
> > > (int64_t)in->sample_aspect_ratio.den * outlink->w *
> > > link->h,
> >
> > I think Mastering Display Metadata may still be relevant after a change
> > in TRC but not primaries (e.g. after linearization), since it only
> > references the gamut of the mastering display.
>
> That is true; but I think I'd rather handle this as a separate patch
> that re-attaches a modified / inferred set of MDM reflecting the new state
> after tone/gamut mapping.
In particular, we also need a way for the user to specify what primaries and
HDR signal range they want on the output, and whether or not they want any
inverse tone mapping / gamut expansion.
I will add an API like this to vf_scale in a later series; for now I want the
basic functionality to be in place and working.
>
> We need to strip the original and attach a modified copy in either case, and
> the status quo after this patch seems no less wrong than not stripping this
> metadata. (Otherwise, the behavior you get is something very strange like
> HDR-in-SDR curves and other things that one should not get by default)
>
> >
> > - Leo Izen (Traneptora)
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC election
On 2024-11-28 15:29 +0100, Anton Khirnov wrote: > > the current Technical Committee (TC) was elected on 2023-12-05 and its > mandate lasts for one year, so we should hold a new election soon. If > there are no unforeseen circumstances, I would like to start the vote on > Monday 2024-12-09. > > As a reminder, the TC is in charge of resolving technical disputes. If > you would like to be a TC member, please say so in a reply to this > email. I volunteer to be a TC member. Some random facts in random order to spice this up a little: * I have been around for more than 20 years * I love reading source code * I have a nag at studying languages be it natural ones or programming languages * My day job is not related to FFmpeg or audio/video projects Best regards, Alexander ___ 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 PATCH] tests/color_utils: Reduce precision requirement to resolve test failure
Why 5215ec677c5510dcffc5c91003be145315df82fa isn’t on the mailing list?
I send the patch and cc to Haas at the first place.
> On Dec 6, 2024, at 11:23, Zhao Zhili
> wrote:
>
> From: Zhao Zhili
>
> ---
> libavutil/tests/color_utils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/tests/color_utils.c b/libavutil/tests/color_utils.c
> index 27ba8b529e..b8200e91fa 100644
> --- a/libavutil/tests/color_utils.c
> +++ b/libavutil/tests/color_utils.c
> @@ -70,7 +70,7 @@ int main(int argc, char *argv[])
> printf("trc=%s calling func(%f) expected=%f roundtrip=%f\n",
> name, test_data[i], result, roundtrip);
>
> -if (result > 0.0 && fabs(roundtrip - test_data[i]) > 1e-8) {
> +if (result > 0.0 && fabs(roundtrip - test_data[i]) > 1e-7) {
> printf(" FAIL\n");
> return 1;
> }
> --
> 2.46.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] [FFmpeg-cvslog] avfilter/vf_scale: switch to new swscale API
On Sat, Dec 07, 2024 at 07:10:49PM +0100, Niklas Haas wrote: > On Fri, 06 Dec 2024 20:57:54 +0100 Michael Niedermayer > wrote: > > Hi > > > > On Fri, Dec 06, 2024 at 02:40:06PM +0100, Niklas Haas wrote: > > > On Fri, 06 Dec 2024 14:31:43 +0100 Michael Niedermayer > > > wrote: > > > > Hi > > > > > > > > On Mon, Nov 25, 2024 at 10:11:49AM +, Niklas Haas wrote: > > > > > ffmpeg | branch: master | Niklas Haas | Fri Jun 28 > > > > > 21:42:23 2024 +0200| [04ce01df0bb2d66e143bcfcea439afc2a1b8d96e] | > > > > > committer: Niklas Haas > > > > > > > > > > avfilter/vf_scale: switch to new swscale API > > > > > > > > > > Most logic from this filter has been co-opted into swscale itself, > > > > > allowing the resulting filter to be substantially simpler as it no > > > > > longer has to worry about context initialization, interlacing, etc. > > > > > > > > > > Sponsored-by: Sovereign Tech Fund > > > > > Signed-off-by: Niklas Haas > > > > > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=04ce01df0bb2d66e143bcfcea439afc2a1b8d96e > > > > > --- > > > > > > > > > > libavfilter/vf_scale.c | 351 > > > > > +++-- > > > > > 1 file changed, 77 insertions(+), 274 deletions(-) > > > > > > > > It seems this broke: > > > > > > > > ./ffmpeg -i mm-short.mpg -vcodec prores -vframes 3 -bitexact -an > > > > prores.mkv > > > > ./ffplay prores.mkv > > > > > > > > [swscaler @ 0x7f76380068c0] Unsupported input (Operation not > > > > supported): fmt:yuv422p10le csp:gbr prim:reserved trc:reserved -> > > > > fmt:yuv420p csp:bt709 prim:reserved trc:reserved > > > > > > What is the meaning of AVCOL_*_RESERVED and why should we accept it here? > > > > > > If you look at e.g. H.273, it clearly reserves these values for future > > > use, > > > and so IMHO treatind them as invalid inputs is not entirely incorrect. > > > > > > Could we fix the prores decoder to instead output UNSPECIFIED? > > > > the decoder should probably output the value stored in the file. > > > > I have to say its a little odd a file generated by ffmpeg contains a > > reserved value but how do i know without a prores spec ... > > > > Now even if theres an argument for the prores decoder not to output that > > value here. Another decoder and other file could still have exactly that > > reserved value. And in that case that decoder should output that > > Should we: > > 1) Treat RESERVED as UNSPECIFIED yes, and maybe warn if a transform needs this value There also could be some code between the decoder and the filter that replaces reserved. It kind of doesnt really make a difference where we deal with this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavc/vvc: Use a bitfield to store MIP information
Applied.
Thank you, Frank
On Wed, Dec 4, 2024 at 4:57 AM Frank Plowman wrote:
> Reduces memory consumption by ~4MB for 1080p video with a maximum delay
> of 16 frames by packing various information related to MIP:
> * intra_mip_flag, 1 bit
> * intra_mip_transposed_flag, 1 bit
> * intra_mip_mode, 4 bits
> Into a single byte.
>
> Co-authored-by: Nuo Mi
> Signed-off-by: Frank Plowman
> ---
> Changes since v1 (posted as attachment in other thread).
> * Renamed (de)?structure_mip_info to (un)?pack_mip_info
> * Remove coerce_to_bool argument added to get_inc. Instead, define a
> variant of get_inc, get_mip_inc, particular to the MIP flag which
> performs the necessary transformations.
>
> I did also try implementing this patch as I mentioned I might on the
> other thread: by adding a function pointer argument to get_inc and
> get_left_top which can be used to transform values read from tables
> before they are used. I realised while doing so, however, that there is
> really no need for such complexity for get_left_top as it returns left
> and top separately, hence the caller can simply transform them itself.
> Then, get_inc is very simple and only called in two places, and so it is
> not fitting to employ such heavy-duty abstractions only for that
> function.
>
> ---
> libavcodec/vvc/cabac.c | 10 +-
> libavcodec/vvc/ctu.c| 12 +---
> libavcodec/vvc/dec.c| 2 --
> libavcodec/vvc/dec.h| 4 +---
> libavcodec/vvc/dsp.c| 9 +
> libavcodec/vvc/intra_template.c | 5 +++--
> 6 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/vvc/cabac.c b/libavcodec/vvc/cabac.c
> index 0d45eec751..5510144893 100644
> --- a/libavcodec/vvc/cabac.c
> +++ b/libavcodec/vvc/cabac.c
> @@ -1257,11 +1257,19 @@ int ff_vvc_pred_mode_ibc_flag(VVCLocalContext *lc,
> const int is_chroma)
> return GET_CABAC(PRED_MODE_IBC_FLAG + inc);
> }
>
> +static av_always_inline
> +uint8_t get_mip_inc(VVCLocalContext *lc, const uint8_t *ctx)
> +{
> +uint8_t left = 0, top = 0;
> +get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
> +return (left & 1) + (top & 1);
> +}
> +
> int ff_vvc_intra_mip_flag(VVCLocalContext *lc, const uint8_t
> *intra_mip_flag)
> {
> const int w = lc->cu->cb_width;
> const int h = lc->cu->cb_height;
> -const int inc = (w > h * 2 || h > w * 2) ? 3 : get_inc(lc,
> intra_mip_flag);
> +const int inc = (w > h * 2 || h > w * 2) ? 3 : get_mip_inc(lc,
> intra_mip_flag);
> return GET_CABAC(INTRA_MIP_FLAG + inc);
> }
>
> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> index 505099bc76..382fa582f4 100644
> --- a/libavcodec/vvc/ctu.c
> +++ b/libavcodec/vvc/ctu.c
> @@ -946,6 +946,12 @@ static void
> derive_chroma_intra_pred_mode(VVCLocalContext *lc,
> }
> }
>
> +static av_always_inline uint8_t pack_mip_info(int intra_mip_flag,
> +int intra_mip_transposed_flag, int intra_mip_mode)
> +{
> +return (intra_mip_mode << 2) | (intra_mip_transposed_flag << 1) |
> intra_mip_flag;
> +}
> +
> static void intra_luma_pred_modes(VVCLocalContext *lc)
> {
> VVCFrameContext *fc = lc->fc;
> @@ -974,9 +980,9 @@ static void intra_luma_pred_modes(VVCLocalContext *lc)
> int x = y_cb * pps->min_cb_width + x_cb;
> for (int y = 0; y < (cb_height>>log2_min_cb_size); y++) {
> int width = cb_width>>log2_min_cb_size;
> -memset(&fc->tab.imf[x], cu->intra_mip_flag, width);
> -memset(&fc->tab.imtf[x], intra_mip_transposed_flag,
> width);
> -memset(&fc->tab.imm[x], intra_mip_mode, width);
> +const uint8_t mip_info = pack_mip_info(cu->intra_mip_flag,
> +intra_mip_transposed_flag, intra_mip_mode);
> +memset(&fc->tab.imf[x], mip_info, width);
> x += pps->min_cb_width;
> }
> cu->intra_pred_mode_y = intra_mip_mode;
> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> index 50be9f9922..fef7339294 100644
> --- a/libavcodec/vvc/dec.c
> +++ b/libavcodec/vvc/dec.c
> @@ -128,7 +128,6 @@ static void min_cb_tl_init(TabList *l, VVCFrameContext
> *fc)
> tl_init(l, 1, changed);
>
> TL_ADD(imf, pic_size_in_min_cb);
> -TL_ADD(imm, pic_size_in_min_cb);
>
> for (int i = LUMA; i <= CHROMA; i++)
> TL_ADD(cb_width[i], pic_size_in_min_cb); //is_a0_available
> requires this
> @@ -143,7 +142,6 @@ static void min_cb_nz_tl_init(TabList *l,
> VVCFrameContext *fc)
> tl_init(l, 0, changed);
>
> TL_ADD(skip, pic_size_in_min_cb);
> -TL_ADD(imtf, pic_size_in_min_cb);
> TL_ADD(ipm, pic_size_in_min_cb);
>
> for (int i = LUMA; i <= CHROMA; i++) {
> diff --git a/libavcodec/vvc/dec.h b/libavcodec/vvc/dec.h
> index f7cd5b678c..0f8f1f721d 100644
> --- a/libavcodec/vvc/dec.h
> +++ b/libavcodec/vvc/dec.h
> @@ -161,9 +161,7 @@ typedef struct VVCFra
Re: [FFmpeg-devel] [PATCH 3/6] lavc/vvc: Store MIP information over entire CU area
On 07/12/2024 02:22, Nuo Mi wrote:
> On Wed, Dec 4, 2024 at 2:09 AM Frank Plowman wrote:
>
>> Hi,
>>
>> Thanks for your review.
>>
>> On 03/12/2024 10:04, Nuo Mi wrote:
>>> Hi Frank,
>>> Thank you for the patch
>>>
>>> On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman
>> wrote:
>>>
On 30/11/2024 06:46, Nuo Mi wrote:
> On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman
wrote:
>
>> Previously, the code only stored the MIP mode and transpose flag in
>> the
>> relevant tables at the top-left corner of the CU. This information
>> ends
>> up being retrieved in ff_vvc_intra_pred_* not based on the CU position
>> but instead the transform unit position (specifically, using the x0
>> and
>> y0 from get_luma_predict_unit). There might be multiple transform
>> units
>> in a CU, hence the top-left corner of the transform unit might not
>> coincide with the top-left corner of the CU. Consequently, we need to
>> store the MIP information at all positions in the CU, not only its
>> top-left corner, as we already do for the MIP flag.
>>
>> Signed-off-by: Frank Plowman
>> ---
>> libavcodec/vvc/ctu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
>> index 1e06119cfd..0030938cf5 100644
>> --- a/libavcodec/vvc/ctu.c
>> +++ b/libavcodec/vvc/ctu.c
>> @@ -975,8 +975,8 @@ static void intra_luma_pred_modes(VVCLocalContext
*lc)
>> for (int y = 0; y < (cb_height>>log2_min_cb_size); y++) {
>> int width = cb_width>>log2_min_cb_size;
>> memset(&fc->tab.imf[x], cu->intra_mip_flag, width);
>> -fc->tab.imtf[x] = intra_mip_transposed_flag;
>> -fc->tab.imm[x] = intra_mip_mode;
>> +memset(&fc->tab.imtf[x], intra_mip_transposed_flag,
>> width);
>> +memset(&fc->tab.imm[x], intra_mip_mode, width);
>
> intra_mip_mode is 4 bits, 2 flags are 2 bits. maybe we can use a
>> uint8_t
> for 3 fields,
> We only need 1 memset and save 2/3 memory.
I've implemented this (patch attached, to be applied atop the set), but
it's not as straightforward as it may seem. In particular, because the
tables are read directly from when determining which CABAC context to
use for these flags, we have to add quite a lot of extra code in cabac.c
to support this special case where the MIP information is a bit field.
In my implementation, this was done by adding this coerce_to_bool
parameter to get_inc and get_top. This does actually save a moderate
amount of memory though, ~1MB for 4K and ~256kB for 1080p.
>>> A coding block can be as small as 4x4, so for a 1080p frame, the memory
>>> required is approximately 2*1920*1080/(4*4) ~= 256 kB.
>>> However, with a maximum delay of 16 frames, the total memory usage will
>> be
>>> 256kB * 16=4 MB.
>>>
>>> In your patch, coerce_to_bool is set to 1 only when we are in
>>> ff_vvc_intra_mip_flag.
>>> How about defining get_mip_inc like this? This way, we can avoid changing
>>> get_inc
>>>
>>> static av_always_inline
>>> uint8_t get_mip_inc (VVCLocalContext *lc, const uint8_t *ctx)
>>> {
>>> uint8_t left = 0, top = 0;
>>> get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
>>> return !!left + !!top;
>>> }
>>
>> What about instead taking a function pointer as an argument to
>> get_inc/get_left_top which can be used to modify the value read from the
>> table before using it, or NULL to apply no such modification?
>
> Function pointers have a cost
>
Provided the caller and callee are defined in the same translation unit
and the caller is inlined, as would have been the case here, the
indirect call can be optimised away and the call inlined. GCC calls
this optimisation indirect-inlining.
In any case, I ended up not taking this approach for slightly different
reasons and implemented your first suggestion instead. It should be on
the ML as v2 now.
Cheers,
Frank
___
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/6] lavc/vvc: Store MIP information over entire CU area
On Sat, Dec 7, 2024 at 5:54 PM Frank Plowman wrote:
> On 07/12/2024 02:22, Nuo Mi wrote:
> > On Wed, Dec 4, 2024 at 2:09 AM Frank Plowman
> wrote:
> >
> >> Hi,
> >>
> >> Thanks for your review.
> >>
> >> On 03/12/2024 10:04, Nuo Mi wrote:
> >>> Hi Frank,
> >>> Thank you for the patch
> >>>
> >>> On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman
> >> wrote:
> >>>
> On 30/11/2024 06:46, Nuo Mi wrote:
> > On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman >
> wrote:
> >
> >> Previously, the code only stored the MIP mode and transpose flag in
> >> the
> >> relevant tables at the top-left corner of the CU. This information
> >> ends
> >> up being retrieved in ff_vvc_intra_pred_* not based on the CU
> position
> >> but instead the transform unit position (specifically, using the x0
> >> and
> >> y0 from get_luma_predict_unit). There might be multiple transform
> >> units
> >> in a CU, hence the top-left corner of the transform unit might not
> >> coincide with the top-left corner of the CU. Consequently, we need
> to
> >> store the MIP information at all positions in the CU, not only its
> >> top-left corner, as we already do for the MIP flag.
> >>
> >> Signed-off-by: Frank Plowman
> >> ---
> >> libavcodec/vvc/ctu.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> >> index 1e06119cfd..0030938cf5 100644
> >> --- a/libavcodec/vvc/ctu.c
> >> +++ b/libavcodec/vvc/ctu.c
> >> @@ -975,8 +975,8 @@ static void
> intra_luma_pred_modes(VVCLocalContext
> *lc)
> >> for (int y = 0; y < (cb_height>>log2_min_cb_size);
> y++) {
> >> int width = cb_width>>log2_min_cb_size;
> >> memset(&fc->tab.imf[x], cu->intra_mip_flag,
> width);
> >> -fc->tab.imtf[x] = intra_mip_transposed_flag;
> >> -fc->tab.imm[x] = intra_mip_mode;
> >> +memset(&fc->tab.imtf[x], intra_mip_transposed_flag,
> >> width);
> >> +memset(&fc->tab.imm[x], intra_mip_mode, width);
> >
> > intra_mip_mode is 4 bits, 2 flags are 2 bits. maybe we can use a
> >> uint8_t
> > for 3 fields,
> > We only need 1 memset and save 2/3 memory.
>
> I've implemented this (patch attached, to be applied atop the set),
> but
> it's not as straightforward as it may seem. In particular, because
> the
> tables are read directly from when determining which CABAC context to
> use for these flags, we have to add quite a lot of extra code in
> cabac.c
> to support this special case where the MIP information is a bit field.
> In my implementation, this was done by adding this coerce_to_bool
> parameter to get_inc and get_top. This does actually save a moderate
> amount of memory though, ~1MB for 4K and ~256kB for 1080p.
>
> >>> A coding block can be as small as 4x4, so for a 1080p frame, the memory
> >>> required is approximately 2*1920*1080/(4*4) ~= 256 kB.
> >>> However, with a maximum delay of 16 frames, the total memory usage will
> >> be
> >>> 256kB * 16=4 MB.
> >>>
> >>> In your patch, coerce_to_bool is set to 1 only when we are in
> >>> ff_vvc_intra_mip_flag.
> >>> How about defining get_mip_inc like this? This way, we can avoid
> changing
> >>> get_inc
> >>>
> >>> static av_always_inline
> >>> uint8_t get_mip_inc (VVCLocalContext *lc, const uint8_t *ctx)
> >>> {
> >>> uint8_t left = 0, top = 0;
> >>> get_left_top(lc, &left, &top, lc->cu->x0, lc->cu->y0, ctx, ctx);
> >>> return !!left + !!top;
> >>> }
> >>
> >> What about instead taking a function pointer as an argument to
> >> get_inc/get_left_top which can be used to modify the value read from the
> >> table before using it, or NULL to apply no such modification?
> >
> > Function pointers have a cost
> >
>
> Provided the caller and callee are defined in the same translation unit
> and the caller is inlined, as would have been the case here, the
> indirect call can be optimised away and the call inlined. GCC calls
> this optimisation indirect-inlining.
>
👍
>
> In any case, I ended up not taking this approach for slightly different
> reasons and implemented your first suggestion instead. It should be on
> the ML as v2 now.
> Cheers,
> Frank
> ___
> 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".
>
We are using too much memory. Please do some profiling using Massif or
another tool if you're interested.
___
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 wit
