Re: [FFmpeg-devel] [PATCH] ffmpeg_mux_init: correct log suggestion
On 2024-09-17 05:45 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-09-17 13:15:45) The option is enc_time_base, not enc_timebase --- fftools/ffmpeg_mux_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c index 30d74d37bd..571c9808b9 100644 --- a/fftools/ffmpeg_mux_init.c +++ b/fftools/ffmpeg_mux_init.c @@ -1365,7 +1365,7 @@ static int ost_add(Muxer *mux, const OptionsContext *o, enum AVMediaType type, #if FFMPEG_OPT_ENC_TIME_BASE_NUM if (q.num < 0) av_log(ost, AV_LOG_WARNING, "-enc_time_base -1 is deprecated," - " use -enc_timebase demux\n"); + " use -enc_time_base demux\n"); ok Pushed as 0d5b68c27cc18095aeb61ffcb9684ca7f13cfb91 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ffmpeg_mux_init: correct log suggestion
The option is enc_time_base, not enc_timebase --- fftools/ffmpeg_mux_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c index 30d74d37bd..571c9808b9 100644 --- a/fftools/ffmpeg_mux_init.c +++ b/fftools/ffmpeg_mux_init.c @@ -1365,7 +1365,7 @@ static int ost_add(Muxer *mux, const OptionsContext *o, enum AVMediaType type, #if FFMPEG_OPT_ENC_TIME_BASE_NUM if (q.num < 0) av_log(ost, AV_LOG_WARNING, "-enc_time_base -1 is deprecated," - " use -enc_timebase demux\n"); + " use -enc_time_base demux\n"); #endif } -- 2.44.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] doc/filters: update uspp availability status
On 2024-09-05 01:29 am, Michael Niedermayer wrote: On Wed, Sep 04, 2024 at 01:33:50PM +0530, Gyan Doshi wrote: The filter was disabled in 95054bfa48 and re-enabled in 771c27119d --- doc/filters.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM Thanks. Pushed as 3d0d0f68d5c5f619ae019c6f37c2f06d9e8debfd Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/filters: update uspp availability status
On 2024-09-04 01:33 pm, Gyan Doshi wrote: The filter was disabled in 95054bfa48 and re-enabled in 771c27119d Will push tomorrow. Regards, Gyan --- doc/filters.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/filters.texi b/doc/filters.texi index 2eb4a380fb..b1ca9ad2f3 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -24463,7 +24463,7 @@ The way this differs from the behavior of spp is that uspp actually encodes & decodes each case with libavcodec Snow, whereas spp uses a simplified intra only 8x8 DCT similar to MJPEG. -This filter is only available in ffmpeg version 4.4 or earlier. +This filter is not available in ffmpeg versions between 5.0 and 6.0. The filter accepts the following options: ___ 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] doc/filters: update uspp availability status
The filter was disabled in 95054bfa48 and re-enabled in 771c27119d --- doc/filters.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/filters.texi b/doc/filters.texi index 2eb4a380fb..b1ca9ad2f3 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -24463,7 +24463,7 @@ The way this differs from the behavior of spp is that uspp actually encodes & decodes each case with libavcodec Snow, whereas spp uses a simplified intra only 8x8 DCT similar to MJPEG. -This filter is only available in ffmpeg version 4.4 or earlier. +This filter is not available in ffmpeg versions between 5.0 and 6.0. The filter accepts the following options: -- 2.44.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] avfilter/formats: correct error message
On 2024-08-31 04:29 pm, Gyan Doshi wrote: On 2024-08-28 03:52 pm, Gyan Doshi wrote: The check is for color space, not range. Will push tomorrow. Pushed as b5daaa1503fd149a8e6c4964266ceb93fd7d09cd Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/formats: correct error message
On 2024-08-28 03:52 pm, Gyan Doshi wrote:
The check is for color space, not range.
Will push tomorrow.
Regards,
Gyan
---
libavfilter/formats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index eabc3ec946..2b570b466e 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -977,7 +977,7 @@ int ff_formats_check_color_spaces(void *log, const
AVFilterFormats *fmts)
{
for (int i = 0; fmts && i < fmts->nb_formats; i++) {
if (fmts->formats[i] == AVCOL_SPC_RESERVED) {
-av_log(log, AV_LOG_ERROR, "Invalid color range\n");
+av_log(log, AV_LOG_ERROR, "Invalid color space\n");
return AVERROR(EINVAL);
}
}
___
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/formats: correct error message
The check is for color space, not range.
---
libavfilter/formats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index eabc3ec946..2b570b466e 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -977,7 +977,7 @@ int ff_formats_check_color_spaces(void *log, const
AVFilterFormats *fmts)
{
for (int i = 0; fmts && i < fmts->nb_formats; i++) {
if (fmts->formats[i] == AVCOL_SPC_RESERVED) {
-av_log(log, AV_LOG_ERROR, "Invalid color range\n");
+av_log(log, AV_LOG_ERROR, "Invalid color space\n");
return AVERROR(EINVAL);
}
}
--
2.44.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] avfilter/vf_quirc: add missing header to unbreak build
Patch withdrawn, superfluous since 1afe42852b. On 2024-08-19 08:33 pm, Gyan Doshi wrote: filters.h has been needed since 42cbf66fff for FilterLink. --- libavfilter/vf_quirc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_quirc.c b/libavfilter/vf_quirc.c index 760f5d97de..afd172fa34 100644 --- a/libavfilter/vf_quirc.c +++ b/libavfilter/vf_quirc.c @@ -27,6 +27,7 @@ #include "libavutil/imgutils.h" #include "libavutil/opt.h" #include "avfilter.h" +#include "filters.h" #include "formats.h" #include "video.h" #include ___ 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_quirc: add missing header to unbreak build
filters.h has been needed since 42cbf66fff for FilterLink. --- libavfilter/vf_quirc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_quirc.c b/libavfilter/vf_quirc.c index 760f5d97de..afd172fa34 100644 --- a/libavfilter/vf_quirc.c +++ b/libavfilter/vf_quirc.c @@ -27,6 +27,7 @@ #include "libavutil/imgutils.h" #include "libavutil/opt.h" #include "avfilter.h" +#include "filters.h" #include "formats.h" #include "video.h" #include -- 2.44.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] lavc/libx265: unbreak build for X265_BUILD >= 210
On 2024-08-14 10:01 am, Gyan Doshi wrote: On 2024-08-11 04:03 pm, Gyan Doshi wrote: x265 added support for alpha starting with build 210. While doing so, x265_encoder_encode() changed its fifth arg to an array of pointers to x265_picture. This broke building lavc/libx265.c This patch simply unbreaks the build and maintains existing single-layer non-alpha encoding support. Fixes #11130 Plan to push tomorrow. Building with x265 HEAD has been broken for over a week now. Pushed as 1f801dfdb5066aadf0ade9cb5e94d620f33eacdc Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] MAINTAINERS: some random updating
On 2024-08-15 04:07 am, Michael Niedermayer wrote: Adding level to some of my entries Adding level to some random entries of other people who i have seen actively maintaining their code removing some people who have not been active where others where active For most we will need to contact people and ask if they are still available as maintainers (but for cases where patches are ignored for many months even with pings sent to the maintainer entries should be set to unmaintained) Signed-off-by: Michael Niedermayer --- MAINTAINERS | 60 ++--- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a27116e9d15..94d9b04d249 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -23,10 +23,10 @@ ffmpeg: ffmpeg.c Michael Niedermayer, Anton Khirnov ffplay: - ffplay.c Marton Balint + ffplay.c [2] Marton Balint ffprobe: - ffprobe.c Stefano Sabatini + ffprobe.c [2] Stefano Sabatini Commandline utility code: cmdutils.c, cmdutils.hMichael Niedermayer @@ -53,11 +53,11 @@ Communication website Deby Barbara Lepage fate.ffmpeg.org Timothy Gu Trac bug trackerAlexander Strasser, Michael Niedermayer, Carl Eugen Hoyos -Patchwork Andriy Gelman +Patchwork [2] Andriy Gelman mailing lists Baptiste Coudurier Twitter Reynaldo H. Verdejo Pinochet Launchpad Timothy Gu -ffmpeg-security Andreas Cadhalpun, Carl Eugen Hoyos, Clément Bœsch, Michael Niedermayer, Reimar Doeffinger, rcombs, wm4 +ffmpeg-security [2] Michael Niedermayer, Reimar Doeffinger Does the status apply to just you or all listed? The notation is ambiguous. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/libx265: unbreak build for X265_BUILD >= 210
On 2024-08-11 04:03 pm, Gyan Doshi wrote:
x265 added support for alpha starting with build 210.
While doing so, x265_encoder_encode() changed its fifth arg to
an array of pointers to x265_picture. This broke building lavc/libx265.c
This patch simply unbreaks the build and maintains existing single-layer
non-alpha encoding support.
Fixes #11130
Plan to push tomorrow. Building with x265 HEAD has been broken for over
a week now.
Regards,
Gyan
---
libavcodec/libx265.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0dc7ab6eeb..3bc3b5a03e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -661,7 +661,13 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
{
libx265Context *ctx = avctx->priv_data;
x265_picture x265pic;
-x265_picture x265pic_out = { 0 };
+#if X265_BUILD >= 210
+x265_picture x265pic_layers_out[MAX_SCALABLE_LAYERS];
+x265_picture* x265pic_lyrptr_out[MAX_SCALABLE_LAYERS];
+#else
+x265_picture x265pic_solo_out = { 0 };
+#endif
+x265_picture* x265pic_out;
x265_nal *nal;
x265_sei *sei;
uint8_t *dst;
@@ -798,8 +804,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
#endif
}
+#if X265_BUILD >= 210
+for (i = 0; i < MAX_SCALABLE_LAYERS; i++)
+x265pic_lyrptr_out[i] = &x265pic_layers_out[i];
+
+ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
+ pic ? &x265pic : NULL, x265pic_lyrptr_out);
+#else
ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
- pic ? &x265pic : NULL, &x265pic_out);
+ pic ? &x265pic : NULL, &x265pic_solo_out);
+#endif
for (i = 0; i < sei->numPayloads; i++)
av_free(sei->payloads[i].payload);
@@ -829,10 +843,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
pkt->flags |= AV_PKT_FLAG_KEY;
}
-pkt->pts = x265pic_out.pts;
-pkt->dts = x265pic_out.dts;
+#if X265_BUILD >= 210
+x265pic_out = x265pic_lyrptr_out[0];
+#else
+x265pic_out = &x265pic_solo_out;
+#endif
+
+pkt->pts = x265pic_out->pts;
+pkt->dts = x265pic_out->dts;
-switch (x265pic_out.sliceType) {
+switch (x265pic_out->sliceType) {
case X265_TYPE_IDR:
case X265_TYPE_I:
pict_type = AV_PICTURE_TYPE_I;
@@ -850,16 +870,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
}
#if X265_BUILD >= 130
-if (x265pic_out.sliceType == X265_TYPE_B)
+if (x265pic_out->sliceType == X265_TYPE_B)
#else
-if (x265pic_out.frameData.sliceType == 'b')
+if (x265pic_out->frameData.sliceType == 'b')
#endif
pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
-ff_side_data_set_encoder_stats(pkt, x265pic_out.frameData.qp * FF_QP2LAMBDA, NULL, 0, pict_type);
+ff_side_data_set_encoder_stats(pkt, x265pic_out->frameData.qp *
FF_QP2LAMBDA, NULL, 0, pict_type);
-if (x265pic_out.userData) {
-int idx = (int)(intptr_t)x265pic_out.userData - 1;
+if (x265pic_out->userData) {
+int idx = (int)(intptr_t)x265pic_out->userData - 1;
ReorderedData *rd = &ctx->rd[idx];
pkt->duration = rd->duration;
___
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] lavc/libx265: unbreak build for X265_BUILD >= 210
x265 added support for alpha starting with build 210.
While doing so, x265_encoder_encode() changed its fifth arg to
an array of pointers to x265_picture. This broke building lavc/libx265.c
This patch simply unbreaks the build and maintains existing single-layer
non-alpha encoding support.
Fixes #11130
---
libavcodec/libx265.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0dc7ab6eeb..3bc3b5a03e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -661,7 +661,13 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
{
libx265Context *ctx = avctx->priv_data;
x265_picture x265pic;
-x265_picture x265pic_out = { 0 };
+#if X265_BUILD >= 210
+x265_picture x265pic_layers_out[MAX_SCALABLE_LAYERS];
+x265_picture* x265pic_lyrptr_out[MAX_SCALABLE_LAYERS];
+#else
+x265_picture x265pic_solo_out = { 0 };
+#endif
+x265_picture* x265pic_out;
x265_nal *nal;
x265_sei *sei;
uint8_t *dst;
@@ -798,8 +804,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
#endif
}
+#if X265_BUILD >= 210
+for (i = 0; i < MAX_SCALABLE_LAYERS; i++)
+x265pic_lyrptr_out[i] = &x265pic_layers_out[i];
+
+ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
+ pic ? &x265pic : NULL, x265pic_lyrptr_out);
+#else
ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
- pic ? &x265pic : NULL, &x265pic_out);
+ pic ? &x265pic : NULL, &x265pic_solo_out);
+#endif
for (i = 0; i < sei->numPayloads; i++)
av_free(sei->payloads[i].payload);
@@ -829,10 +843,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
pkt->flags |= AV_PKT_FLAG_KEY;
}
-pkt->pts = x265pic_out.pts;
-pkt->dts = x265pic_out.dts;
+#if X265_BUILD >= 210
+x265pic_out = x265pic_lyrptr_out[0];
+#else
+x265pic_out = &x265pic_solo_out;
+#endif
+
+pkt->pts = x265pic_out->pts;
+pkt->dts = x265pic_out->dts;
-switch (x265pic_out.sliceType) {
+switch (x265pic_out->sliceType) {
case X265_TYPE_IDR:
case X265_TYPE_I:
pict_type = AV_PICTURE_TYPE_I;
@@ -850,16 +870,16 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
}
#if X265_BUILD >= 130
-if (x265pic_out.sliceType == X265_TYPE_B)
+if (x265pic_out->sliceType == X265_TYPE_B)
#else
-if (x265pic_out.frameData.sliceType == 'b')
+if (x265pic_out->frameData.sliceType == 'b')
#endif
pkt->flags |= AV_PKT_FLAG_DISPOSABLE;
-ff_side_data_set_encoder_stats(pkt, x265pic_out.frameData.qp *
FF_QP2LAMBDA, NULL, 0, pict_type);
+ff_side_data_set_encoder_stats(pkt, x265pic_out->frameData.qp *
FF_QP2LAMBDA, NULL, 0, pict_type);
-if (x265pic_out.userData) {
-int idx = (int)(intptr_t)x265pic_out.userData - 1;
+if (x265pic_out->userData) {
+int idx = (int)(intptr_t)x265pic_out->userData - 1;
ReorderedData *rd = &ctx->rd[idx];
pkt->duration = rd->duration;
--
2.44.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] doc/filters/libvmaf_cuda: fix a typo about the order of label
On 2024-07-22 01:01 pm, Gyan Doshi wrote: On 2024-07-22 12:53 pm, Shin Han wrote: Hi We found a very simple typo in the libvmaf_cuda section of doc/filters where the order of the [dis] and [ref] labels is reversed. We believe fixing this typo would be benefical of those who are new to using ffmpeg and libvmaf_cuda. Will apply. Adjusted commit subject and pushed as 172da370e70a24c8528efead0b24053fc74e5648 Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/filters/libvmaf_cuda: fix a typo about the order of label
On 2024-07-22 12:53 pm, Shin Han wrote: Hi We found a very simple typo in the libvmaf_cuda section of doc/filters where the order of the [dis] and [ref] labels is reversed. We believe fixing this typo would be benefical of those who are new to using ffmpeg and libvmaf_cuda. Will apply. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
On 2024-07-16 09:40 am, Marth64 wrote: Gyan: The former is not an error. The user was asked and the application behaved as per their reply. Could it make sense to only return the AVERROR(EEXIST) if -nostdin is passed (otherwise current behavior)? Agreed. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
On 2024-07-15 06:26 pm, Dabrien 'Dabe' Murphy wrote:
---
fftools/ffmpeg_opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 2c201c74b2..dddf7c6475 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -604,13 +604,13 @@ int assert_file_overwrite(const char *filename)
signal(SIGINT, SIG_DFL);
if (!read_yesno()) {
av_log(NULL, AV_LOG_FATAL, "Not overwriting -
exiting\n");
- return AVERROR_EXIT;
+ return AVERROR(EEXIST);
}
term_init();
}
else {
av_log(NULL, AV_LOG_FATAL, "File '%s' already exists.
Exiting.\n", filename);
- return AVERROR_EXIT;
+ return AVERROR(EEXIST);
The former is not an error. The user was asked and the application
behaved as per their reply.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg: don't truncate getmaxrss value
On 2024-07-14 02:14 pm, Gyan Doshi wrote: On 2024-07-11 02:52 pm, Gyan Doshi wrote: Can lead to printing of nonsensical negative memory usage Plan to push in 24h. Pushed as 350146a1ea9d2d0220cc8d024125b77240e3e98d Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg: don't truncate getmaxrss value
On 2024-07-11 02:52 pm, Gyan Doshi wrote:
Can lead to printing of nonsensical negative memory usage
Plan to push in 24h.
Regards,
Gyan
---
fftools/ffmpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 00ab1cce51..3aa2e12780 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -309,8 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL
};
static void ffmpeg_cleanup(int ret)
{
if (do_benchmark) {
-int maxrss = getmaxrss() / 1024;
-av_log(NULL, AV_LOG_INFO, "bench: maxrss=%iKiB\n", maxrss);
+int64_t maxrss = getmaxrss() / 1024;
+av_log(NULL, AV_LOG_INFO, "bench: maxrss=%"PRId64"KiB\n", maxrss);
}
for (int i = 0; i < nb_filtergraphs; i++)
___
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] ffmpeg: don't truncate getmaxrss value
Can lead to printing of nonsensical negative memory usage
---
fftools/ffmpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 00ab1cce51..3aa2e12780 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -309,8 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL
};
static void ffmpeg_cleanup(int ret)
{
if (do_benchmark) {
-int maxrss = getmaxrss() / 1024;
-av_log(NULL, AV_LOG_INFO, "bench: maxrss=%iKiB\n", maxrss);
+int64_t maxrss = getmaxrss() / 1024;
+av_log(NULL, AV_LOG_INFO, "bench: maxrss=%"PRId64"KiB\n", maxrss);
}
for (int i = 0; i < nb_filtergraphs; i++)
--
2.44.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] doc/filter: fix grammar in tiltandshift filter
On 2024-07-04 04:14 am, Vittorio Giovara wrote: On Wed, Jul 3, 2024 at 9:29 PM Gyan Doshi wrote: On 2024-07-02 10:45 am, Gyan Doshi wrote: --- doc/filters.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 0ff7c142b6..c9c4f7cf6b 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -23546,13 +23546,13 @@ tile=3x2:nb_frames=5:padding=7:margin=2 @end itemize @section tiltandshift -Apply tilt-and-shift effet. +Apply tilt-and-shift effect. What happens when you invert time and space? Normally a video is composed of several frames that represent a different instant of time and shows a scene that evolves in the space captured by the -frame. This filter is the antipode of that concept, taking inspiration by +frame. This filter is the antipode of that concept, taking inspiration from tilt and shift photography. A filtered frame contains the whole timeline of events composing the sequence, @@ -23591,7 +23591,7 @@ How many columns should be inserted before end of filtering. @end table -Normally the filter shifts and tils from the very first frame, and stops when +Normally the filter shifts and tilts from the very first frame, and stops when the last one is received. However, before filtering starts, normal video may be preseved, so that the effect is slowly shifted in its place. Similarly, the last video frame may be reconstructed at the end. Alternatively it is @@ -23599,7 +23599,7 @@ possible to just start and end with black. @table @samp @item none -Filtering is starts immediately and ends when the last frame is received. +Filtering starts immediately and ends when the last frame is received. @item frame The first frames or the very last frame are kept intact during processing. Will push soon. looks good, thanks for fixing those Thanks. Pushed as 03175b587cdc445d6d0de87ada0af0e6692e3dea Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/filter: fix grammar in tiltandshift filter
On 2024-07-02 10:45 am, Gyan Doshi wrote: --- doc/filters.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 0ff7c142b6..c9c4f7cf6b 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -23546,13 +23546,13 @@ tile=3x2:nb_frames=5:padding=7:margin=2 @end itemize @section tiltandshift -Apply tilt-and-shift effet. +Apply tilt-and-shift effect. What happens when you invert time and space? Normally a video is composed of several frames that represent a different instant of time and shows a scene that evolves in the space captured by the -frame. This filter is the antipode of that concept, taking inspiration by +frame. This filter is the antipode of that concept, taking inspiration from tilt and shift photography. A filtered frame contains the whole timeline of events composing the sequence, @@ -23591,7 +23591,7 @@ How many columns should be inserted before end of filtering. @end table -Normally the filter shifts and tils from the very first frame, and stops when +Normally the filter shifts and tilts from the very first frame, and stops when the last one is received. However, before filtering starts, normal video may be preseved, so that the effect is slowly shifted in its place. Similarly, the last video frame may be reconstructed at the end. Alternatively it is @@ -23599,7 +23599,7 @@ possible to just start and end with black. @table @samp @item none -Filtering is starts immediately and ends when the last frame is received. +Filtering starts immediately and ends when the last frame is received. @item frame The first frames or the very last frame are kept intact during processing. Will push soon. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/filter: fix grammar in tiltandshift filter
--- doc/filters.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 0ff7c142b6..c9c4f7cf6b 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -23546,13 +23546,13 @@ tile=3x2:nb_frames=5:padding=7:margin=2 @end itemize @section tiltandshift -Apply tilt-and-shift effet. +Apply tilt-and-shift effect. What happens when you invert time and space? Normally a video is composed of several frames that represent a different instant of time and shows a scene that evolves in the space captured by the -frame. This filter is the antipode of that concept, taking inspiration by +frame. This filter is the antipode of that concept, taking inspiration from tilt and shift photography. A filtered frame contains the whole timeline of events composing the sequence, @@ -23591,7 +23591,7 @@ How many columns should be inserted before end of filtering. @end table -Normally the filter shifts and tils from the very first frame, and stops when +Normally the filter shifts and tilts from the very first frame, and stops when the last one is received. However, before filtering starts, normal video may be preseved, so that the effect is slowly shifted in its place. Similarly, the last video frame may be reconstructed at the end. Alternatively it is @@ -23599,7 +23599,7 @@ possible to just start and end with black. @table @samp @item none -Filtering is starts immediately and ends when the last frame is received. +Filtering starts immediately and ends when the last frame is received. @item frame The first frames or the very last frame are kept intact during processing. -- 2.44.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 2/2] configure: align conditional library deps assignments
On 2024-06-25 11:51 am, Gyan Doshi wrote: On 2024-06-21 04:18 pm, Gyan Doshi wrote: --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Plan to improve commit messages and push set in 24h. Pushed as 27284b780087f9217f628a440e977f207b8b2885 and 9a3bc59a383d10ba414aed1f7d4ce692693f4fdd Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] configure: align conditional library deps assignments
On 2024-06-21 04:18 pm, Gyan Doshi wrote: --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Plan to improve commit messages and push set in 24h. diff --git a/configure b/configure index 1e58c0dbac..db11a78c74 100755 --- a/configure +++ b/configure @@ -7764,14 +7764,14 @@ enabled elbg_filter && prepend avfilter_deps "avcodec" enabled find_rect_filter&& prepend avfilter_deps "avformat avcodec" enabled fsync_filter&& prepend avfilter_deps "avformat" enabled mcdeint_filter && prepend avfilter_deps "avcodec" -enabled movie_filter&& prepend avfilter_deps "avformat avcodec" +enabled movie_filter&& prepend avfilter_deps "avformat avcodec" enabled pan_filter && prepend avfilter_deps "swresample" enabled pp_filter && prepend avfilter_deps "postproc" enabled qrencode_filter && prepend avfilter_deps "swscale" enabled qrencodesrc_filter && prepend avfilter_deps "swscale" enabled removelogo_filter && prepend avfilter_deps "avformat avcodec swscale" enabled sab_filter && prepend avfilter_deps "swscale" -enabled scale_filter&& prepend avfilter_deps "swscale" +enabled scale_filter&& prepend avfilter_deps "swscale" enabled scale2ref_filter&& prepend avfilter_deps "swscale" enabled showcqt_filter && prepend avfilter_deps "avformat swscale" enabled signature_filter&& prepend avfilter_deps "avcodec avformat" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] configure: align conditional library deps assignments
--- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 1e58c0dbac..db11a78c74 100755 --- a/configure +++ b/configure @@ -7764,14 +7764,14 @@ enabled elbg_filter && prepend avfilter_deps "avcodec" enabled find_rect_filter&& prepend avfilter_deps "avformat avcodec" enabled fsync_filter&& prepend avfilter_deps "avformat" enabled mcdeint_filter && prepend avfilter_deps "avcodec" -enabled movie_filter&& prepend avfilter_deps "avformat avcodec" +enabled movie_filter&& prepend avfilter_deps "avformat avcodec" enabled pan_filter && prepend avfilter_deps "swresample" enabled pp_filter && prepend avfilter_deps "postproc" enabled qrencode_filter && prepend avfilter_deps "swscale" enabled qrencodesrc_filter && prepend avfilter_deps "swscale" enabled removelogo_filter && prepend avfilter_deps "avformat avcodec swscale" enabled sab_filter && prepend avfilter_deps "swscale" -enabled scale_filter&& prepend avfilter_deps "swscale" +enabled scale_filter&& prepend avfilter_deps "swscale" enabled scale2ref_filter&& prepend avfilter_deps "swscale" enabled showcqt_filter && prepend avfilter_deps "avformat swscale" enabled signature_filter&& prepend avfilter_deps "avcodec avformat" -- 2.44.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/2] configure: correct deps assigment for QR libs
--- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 3bca638459..1e58c0dbac 100755 --- a/configure +++ b/configure @@ -7767,8 +7767,8 @@ enabled mcdeint_filter && prepend avfilter_deps "avcodec" enabled movie_filter&& prepend avfilter_deps "avformat avcodec" enabled pan_filter && prepend avfilter_deps "swresample" enabled pp_filter && prepend avfilter_deps "postproc" -enabled qrencode_filter && prepend_avfilter_deps "swscale" -enabled qrencodesrc_filter && prepend_avfilter_deps "swscale" +enabled qrencode_filter && prepend avfilter_deps "swscale" +enabled qrencodesrc_filter && prepend avfilter_deps "swscale" enabled removelogo_filter && prepend avfilter_deps "avformat avcodec swscale" enabled sab_filter && prepend avfilter_deps "swscale" enabled scale_filter&& prepend avfilter_deps "swscale" -- 2.44.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 v2] movenc: Add an option for hiding fragments at the end
On 2024-06-19 06:04 pm, Martin Storsjö wrote: On Mon, 17 Jun 2024, Gyan Doshi via ffmpeg-devel wrote: Ultimately, as long as the doc is clear about what the use of this option is, and what to do next if the muxing does abort, it should not matter too much what the option is called. So, are you saying you'd accept the hybrid_fragmented name, as long as the docs explain this correctly? Yes, Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 2024-06-18 11:53 pm, Timo Rothenpieler wrote:
On 18.06.2024 18:56, Gyan Doshi wrote:
FWIW, I had to do the same for securetransport on a project a couple
of years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
You mean the FFmpeg implementation of rtmps?
Cause if so, I think that only makes use of nonblocking mode for
receiving, not sending.
So it wouldn't run into this if it was wrong.
IIRC, the setup/handshake phase would never complete.
Adding this fixed it
+ TLSShared *s = &c->tls_shared;
+ int set_flag_nonblock = 0;
+
+ if (h->flags & AVIO_FLAG_NONBLOCK && !(s->tcp->flags &
AVIO_FLAG_NONBLOCK)) {
+ s->tcp->flags |= AVIO_FLAG_NONBLOCK;
+ set_flag_nonblock = 1;
+ }
+
int read = ffurl_read(c->tls_shared.tcp, data, requested);
+
+ if (set_flag_nonblock)
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 2024-06-18 10:00 pm, Timo Rothenpieler wrote:
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0, NULL, 0, &c->ctxt_handle,
&outbuf_desc, &c->context_flags, &c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret ==
SEC_I_CONTEXT_EXPIRED) {
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer,
outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t
*buf, int len)
}
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+ } else if (ret == AVERROR(EAGAIN)) {
+ ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const
uint8_t *buf, int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer +
outbuf[2].cbBuffer;
+
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
- if (ret < 0 || ret != len) {
+ if (ret == AVERROR(EAGAIN)) {
+ goto done;
+ } else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to
socket failed\n");
goto done;
ping
I'm specifically unsure if implementing the sending-side like this is
valid and would appreciate review from someone familiar with the code
and schannel.
FWIW, I had to do the same for securetransport on a project a couple of
years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
On 2024-06-17 04:08 pm, Martin Storsjö wrote: On Sat, 15 Jun 2024, Gyan Doshi wrote: On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote: On 2024-06-14 13:23, Gyan Doshi wrote: On 2024-06-14 04:35 pm, Timo Rothenpieler wrote: On 14/06/2024 12:44, Martin Storsjö wrote: On Fri, 14 Jun 2024, Gyan Doshi wrote: On 2024-06-14 02:18 am, Martin Storsjö wrote: On Thu, 13 Jun 2024, Gyan Doshi wrote: On 2024-06-13 06:20 pm, Martin Storsjö wrote: I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Those are good suggestions as well - but I think I prefer "hybrid_fragmented" still. In theory, I guess one could implement resilient writing in a number of different ways, whereas the hybrid fragmented/non-fragmented only is one. So with a couple other voices agreeing with the name "hybrid_fragmented", I'll post a new patch with the option in that form - hopefully you don't object to it. The term hybrid is not applicable here. The fragmented state is transient during writing and contingent in the finished artifact depending on how the writing process concluded. Hybrid implies both modes available e.g.. a hybrid vehicle can use both types of energy sources. The artifact here will be one _or_ the other. Sure, the file itself is either or, but the process of writing will have utilized both. TBH, I don't see it as such a black-or-white thing. What do the others who have chimed in on the thread think, compared to calling it "recoverable" or "resilient_mode"? I don't have a super strong opinion on it, but out of the options provided, I'd prefer the hybrid_ one, since there's a good chance it'll become an established term now that OBS presents it quite publicly visible. The OBS dev intends to change the term: "Come up with a better name than "Hybrid MP4" that hopefully won't confuse users" https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 Regards, Gyan Now that it's merged and in the hands of users I don't have any intention of changing the name any more. We had some chats about about it, but nobody suggested anything that people agreed was better, so it stuck. While "resilient" certainly fits, it could equally apply to regular fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not mistaken). The important attribute with this approach is that it's resilient *and* compatible, and I'm still not sure how to get that across in name alone. How about `failsafe`? I don't see how that differs from "resilient", as a regular fragmented file also is failsafe (or resilient) in the same way - while the special thing here is that it's both fragmented and not. The expert user already knows to save a fragmented file if they want resilience. This option saves them a remux step if the original writing ends gracefully. For all other users, the value proposition _is_ the resilience. If the muxing ends normally, they just have a normal file. If it ends prematurely, they just want to be able to convert to a regular seekable MP4. The fact that it is saved in fragmented or any other mode is irrelevant - an academic detail at best. Ultimately, as long as the doc is clear about what the use of this option is, and what to do next if the muxing does abort, it should not matter too much what the option is called. But just like the faststart flag name identifies the purpose instead of being called something like moov_in_front, hopefully so will the name here. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote: On 2024-06-14 13:23, Gyan Doshi wrote: On 2024-06-14 04:35 pm, Timo Rothenpieler wrote: On 14/06/2024 12:44, Martin Storsjö wrote: On Fri, 14 Jun 2024, Gyan Doshi wrote: On 2024-06-14 02:18 am, Martin Storsjö wrote: On Thu, 13 Jun 2024, Gyan Doshi wrote: On 2024-06-13 06:20 pm, Martin Storsjö wrote: I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Those are good suggestions as well - but I think I prefer "hybrid_fragmented" still. In theory, I guess one could implement resilient writing in a number of different ways, whereas the hybrid fragmented/non-fragmented only is one. So with a couple other voices agreeing with the name "hybrid_fragmented", I'll post a new patch with the option in that form - hopefully you don't object to it. The term hybrid is not applicable here. The fragmented state is transient during writing and contingent in the finished artifact depending on how the writing process concluded. Hybrid implies both modes available e.g.. a hybrid vehicle can use both types of energy sources. The artifact here will be one _or_ the other. Sure, the file itself is either or, but the process of writing will have utilized both. TBH, I don't see it as such a black-or-white thing. What do the others who have chimed in on the thread think, compared to calling it "recoverable" or "resilient_mode"? I don't have a super strong opinion on it, but out of the options provided, I'd prefer the hybrid_ one, since there's a good chance it'll become an established term now that OBS presents it quite publicly visible. The OBS dev intends to change the term: "Come up with a better name than "Hybrid MP4" that hopefully won't confuse users" https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 Regards, Gyan Now that it's merged and in the hands of users I don't have any intention of changing the name any more. We had some chats about about it, but nobody suggested anything that people agreed was better, so it stuck. While "resilient" certainly fits, it could equally apply to regular fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not mistaken). The important attribute with this approach is that it's resilient *and* compatible, and I'm still not sure how to get that across in name alone. How about `failsafe`? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote: On 14/06/2024 12:44, Martin Storsjö wrote: On Fri, 14 Jun 2024, Gyan Doshi wrote: On 2024-06-14 02:18 am, Martin Storsjö wrote: On Thu, 13 Jun 2024, Gyan Doshi wrote: On 2024-06-13 06:20 pm, Martin Storsjö wrote: I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Those are good suggestions as well - but I think I prefer "hybrid_fragmented" still. In theory, I guess one could implement resilient writing in a number of different ways, whereas the hybrid fragmented/non-fragmented only is one. So with a couple other voices agreeing with the name "hybrid_fragmented", I'll post a new patch with the option in that form - hopefully you don't object to it. The term hybrid is not applicable here. The fragmented state is transient during writing and contingent in the finished artifact depending on how the writing process concluded. Hybrid implies both modes available e.g.. a hybrid vehicle can use both types of energy sources. The artifact here will be one _or_ the other. Sure, the file itself is either or, but the process of writing will have utilized both. TBH, I don't see it as such a black-or-white thing. What do the others who have chimed in on the thread think, compared to calling it "recoverable" or "resilient_mode"? I don't have a super strong opinion on it, but out of the options provided, I'd prefer the hybrid_ one, since there's a good chance it'll become an established term now that OBS presents it quite publicly visible. The OBS dev intends to change the term: "Come up with a better name than "Hybrid MP4" that hopefully won't confuse users" https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
On 2024-06-14 02:18 am, Martin Storsjö wrote: On Thu, 13 Jun 2024, Gyan Doshi wrote: On 2024-06-13 06:20 pm, Martin Storsjö wrote: On Wed, 5 Jun 2024, Martin Storsjö wrote: This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. --- v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes no sense without it). Updated the description of the flag to "Write a fragmented file that is converted to non-fragmented at the end". Kept the flag named "hide_fragments", but I'm also pondering if we maybe should go for a name like "hybrid_fragmented" or so, as a better description of _what_ it produces, as opposed to _how_ it does things. (One could also consider "hybrid_mp4", but even if mp4 is the main thing, the same also goes for mov and a bunch of other related formats.) I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Those are good suggestions as well - but I think I prefer "hybrid_fragmented" still. In theory, I guess one could implement resilient writing in a number of different ways, whereas the hybrid fragmented/non-fragmented only is one. So with a couple other voices agreeing with the name "hybrid_fragmented", I'll post a new patch with the option in that form - hopefully you don't object to it. The term hybrid is not applicable here. The fragmented state is transient during writing and contingent in the finished artifact depending on how the writing process concluded. Hybrid implies both modes available e.g.. a hybrid vehicle can use both types of energy sources. The artifact here will be one _or_ the other. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
On 2024-06-13 06:20 pm, Martin Storsjö wrote: On Wed, 5 Jun 2024, Martin Storsjö wrote: This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. --- v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes no sense without it). Updated the description of the flag to "Write a fragmented file that is converted to non-fragmented at the end". Kept the flag named "hide_fragments", but I'm also pondering if we maybe should go for a name like "hybrid_fragmented" or so, as a better description of _what_ it produces, as opposed to _how_ it does things. (One could also consider "hybrid_mp4", but even if mp4 is the main thing, the same also goes for mov and a bunch of other related formats.) I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/trim: flag trim filter as metadata only
On 2024-06-05 12:47 am, Stefano Sabatini wrote:
On date Tuesday 2024-06-04 23:41:05 +0530, Gyan Doshi wrote:
Similar to select filter for video - it can only pass through or drop frames
---
libavfilter/trim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/trim.c b/libavfilter/trim.c
index 4c1a2b4f48..4afc4c74bb 100644
--- a/libavfilter/trim.c
+++ b/libavfilter/trim.c
@@ -364,6 +364,7 @@ const AVFilter ff_vf_trim = {
.activate= activate,
.priv_size = sizeof(TrimContext),
.priv_class = &trim_class,
+.flags = AVFILTER_FLAG_METADATA_ONLY,
FILTER_INPUTS(trim_inputs),
FILTER_OUTPUTS(ff_video_default_filterpad),
};
--
2.44.0
Should be good.
Thanks. Pushed as d55f5cba7b1fd362beb3b0322c5674016a85e859
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/trim: flag trim filter as metadata only
Similar to select filter for video - it can only pass through or drop frames
---
libavfilter/trim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/trim.c b/libavfilter/trim.c
index 4c1a2b4f48..4afc4c74bb 100644
--- a/libavfilter/trim.c
+++ b/libavfilter/trim.c
@@ -364,6 +364,7 @@ const AVFilter ff_vf_trim = {
.activate= activate,
.priv_size = sizeof(TrimContext),
.priv_class = &trim_class,
+.flags = AVFILTER_FLAG_METADATA_ONLY,
FILTER_INPUTS(trim_inputs),
FILTER_OUTPUTS(ff_video_default_filterpad),
};
--
2.44.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] configure: correct libopenjpeg description
On 2024-05-31 09:07 pm, Pierre-Anthony Lemieux wrote: On Fri, May 31, 2024 at 8:32 AM Gyan Doshi wrote: Decoding is no longer possible as the decoder wrapper was removed in 60ccb3fe78 --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 96b181fd21..6c5b8aab9a 100755 --- a/configure +++ b/configure @@ -253,7 +253,7 @@ External library support: --enable-libopencore-amrwb enable AMR-WB decoding via libopencore-amrwb [no] --enable-libopencv enable video filtering via libopencv [no] --enable-libopenh264 enable H.264 encoding via OpenH264 [no] - --enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no] + --enable-libopenjpeg enable JPEG 2000 encoding via OpenJPEG [no] LGTM Thanks. Pushed as 2f184aa89be8b92846cbbec3407a88ec7862358b Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: correct libopenjpeg description
Decoding is no longer possible as the decoder wrapper was removed in 60ccb3fe78 --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 96b181fd21..6c5b8aab9a 100755 --- a/configure +++ b/configure @@ -253,7 +253,7 @@ External library support: --enable-libopencore-amrwb enable AMR-WB decoding via libopencore-amrwb [no] --enable-libopencv enable video filtering via libopencv [no] --enable-libopenh264 enable H.264 encoding via OpenH264 [no] - --enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no] + --enable-libopenjpeg enable JPEG 2000 encoding via OpenJPEG [no] --enable-libopenmpt enable decoding tracked files via libopenmpt [no] --enable-libopenvino enable OpenVINO as a DNN module backend for DNN based filters like dnn_processing [no] -- 2.44.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] avfilter/colorize: add speed option
On 2024-05-01 12:18 pm, Yannis Gerlach wrote:
The speed option allows to have a constant (per frame) change of hue.
This allows for an easy way of creating an color changing effect
without relying on somewhat complicated expressions.
Signed-off-by: Yannis Gerlach
---
libavfilter/vf_colorize.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_colorize.c b/libavfilter/vf_colorize.c
index e6c563e3e2..ad8577c8fd 100644
--- a/libavfilter/vf_colorize.c
+++ b/libavfilter/vf_colorize.c
@@ -29,6 +29,7 @@ typedef struct ColorizeContext {
float saturation;
float lightness;
float mix;
+ float speed;
int depth;
int c[3];
@@ -205,6 +206,13 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *frame)
ff_filter_execute(ctx, do_slice, frame, NULL,
FFMIN(s->planeheight[1],
ff_filter_get_nb_threads(ctx)));
+ s->hue += s->speed;
+ if (s->hue < 0.f) {
+ s->hue += 360.f;
+ } else if(s->hue > 360.f) {
+ s->hue -= 360.f;
+ }
+
return ff_filter_frame(ctx->outputs[0], frame);
}
@@ -263,10 +271,11 @@ static const AVFilterPad colorize_inputs[] = {
#define VF
AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
static const AVOption colorize_options[] = {
- { "hue", "set the hue", OFFSET(hue), AV_OPT_TYPE_FLOAT,
{.dbl=0}, 0, 360, VF },
- { "saturation", "set the saturation", OFFSET(saturation),
AV_OPT_TYPE_FLOAT, {.dbl=0.5},0, 1, VF },
- { "lightness", "set the lightness", OFFSET(lightness),
AV_OPT_TYPE_FLOAT, {.dbl=0.5},0, 1, VF },
- { "mix", "set the mix of source lightness", OFFSET(mix),
AV_OPT_TYPE_FLOAT, {.dbl=1}, 0, 1, VF },
+ { "hue", "set the hue", OFFSET(hue), AV_OPT_TYPE_FLOAT,
{.dbl=0}, 0, 360, VF },
+ { "saturation", "set the saturation", OFFSET(saturation),
AV_OPT_TYPE_FLOAT, {.dbl=0.5}, 0, 1, VF },
+ { "lightness", "set the lightness", OFFSET(lightness),
AV_OPT_TYPE_FLOAT, {.dbl=0.5}, 0, 1, VF },
+ { "mix", "set the mix of source lightness", OFFSET(mix),
AV_OPT_TYPE_FLOAT, {.dbl=1}, 0, 1, VF },
The cosmetic changes should be in a separate patch.
Regards,
Gyan
+ { "speed", "set the change of hue per frame", OFFSET(speed),
AV_OPT_TYPE_FLOAT, {.dbl=0}, -180, 180, VF },
{ NULL }
};
-- 2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/5] replace scale2ref by scale=rw:rh
On 2024-04-24 04:21 pm, Niklas Haas wrote: As discussed in my previous series for fixing scale2ref[1], this filter is fundamentally broken, and the only real fix would be to switch to activate(), or ideally FFFrameSync. [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-March/323382.html The main thing making this difficult is the fact that scale2ref also wants to output ref frames to its secondary output, which FFFrameSync does not support, and which is ultimately at least part of the root cause of trac #10795. Since this is in principle completely unnecessary (users can just 'split' the ref input and have it be consumed by vf_scale), and to make the design of this filter a bit more robust and maintainable, switch to an approach where vf_scale itself gains the ability to reference a secondary input stream, using the "ref_*" series of variables. This makes the current [i][ri]scale2ref[o][ro] equivalent to the only slightly more verbose [ri]split[t][ro]; [i][t]scale=rw:rh[o]. (And conversely, it is no longer necessary to use nullsink to consume an unused [ro]) In principle, a good idea, but how does this impact memory use and speed in the not-so-uncommon scenario where multiple overlay targets are scaled 2 ref and then overlaid e.g. in current flow: [a][base]scale2ref[a][ref]; [b][ref]scale2ref[b][ref[; [c][ref]scale2ref[c][ref[; [d][ref]scale2ref[d][ref[; [ref][a]overlay[ref]; [ref][b]overlay[ref]; [ref][c]overlay[ref]; [ref][d]overlay[ref]; in new flow: [base]split=5[base][refa][refb][refc][refd]; [a][refa]scale[a]; [b][refb]scale[b]; [c][refc]scale[c]; [d][refd]scale[d]; [base][a]overlay[outa]; [outa][b]overlay[outb]; [outb][c]overlay[outc]; [outc][d]overlay[out]; Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/ivfenc: remove unused var
On 2024-04-17 05:25 pm, James Almer wrote:
On 4/17/2024 8:31 AM, Gyan Doshi wrote:
sum_delta_pts is unused since 3b358f151d
---
libavformat/ivfenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 09782eecd6..9feaea3516 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -24,7 +24,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
- uint64_t last_pts, sum_delta_pts, last_pkt_duration;
+ uint64_t last_pts, last_pkt_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -80,8 +80,6 @@ static int ivf_write_packet(AVFormatContext *s,
AVPacket *pkt)
avio_wl32(pb, pkt->size);
avio_wl64(pb, pkt->pts);
avio_write(pb, pkt->data, pkt->size);
- if (ctx->frame_cnt)
- ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
ctx->last_pkt_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
Ok.
Thanks. Pushed as 38c322681e9715b288172eaed1e90205aa46e969
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/ivfenc: remove unused var
sum_delta_pts is unused since 3b358f151d
---
libavformat/ivfenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 09782eecd6..9feaea3516 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -24,7 +24,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
-uint64_t last_pts, sum_delta_pts, last_pkt_duration;
+uint64_t last_pts, last_pkt_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -80,8 +80,6 @@ static int ivf_write_packet(AVFormatContext *s, AVPacket *pkt)
avio_wl32(pb, pkt->size);
avio_wl64(pb, pkt->pts);
avio_write(pb, pkt->data, pkt->size);
-if (ctx->frame_cnt)
-ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
ctx->last_pkt_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
--
2.44.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] Query from Reuters on XZ, open source, and Microsoft
On 2024-04-10 02:57 pm, Stefano Sabatini wrote: On date Tuesday 2024-04-09 10:36:05 +0200, Nicolas George wrote: [...] I am pointing that for the burden, I am not offering to do the same for free for the people who are so short-sighted they feel entitled to block software-defined radio, break real-time display devices, prevent me from adding the strings API necessary for proper built-in documentation and information exfiltration from devices, etc., and apparently can. The "people" is at the end the TC/CC (Technical/Community Committee), and we agreed to commit to what these organisms decide to resolve conflicts for controversial features. Only if they respond. My matter is pending with the TC for close to 2 months now. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
Ping x2. On 2024-04-02 10:55 am, Gyan Doshi wrote: Ping. As the TC rules matter has been concluded, this should go ahead. Regards, Gyan On 2024-02-17 05:15 pm, Gyan Doshi wrote: Issue: Patch: avcodec/s302m: enable non-PCM decoding URL: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ The issue needing resolution is whether the patch should be added to the existing s302m decoder or should that decoder be removed and all old and new patched features inlined into the mpeg-ts demuxer. Summary: SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST 337 enables this for non-PCM codecs. The payload has a custom layout so it can't be directly processed hence lavc/s302m decodes the packet data to yield LPCM media. But it can only deal at present with LPCM payloads, meaning that non-PCM payloads need to be exported to a raw bytestream format and then decoded in a 2nd step, which prohibits direct transcoding of live/streaming inputs. This patch corrects the identification process for non-PCM payloads, reformats the payload and then carries out in-place decoding by calling a nested decoder similar to the ftr or imm5 decoders in lavc. In the v1 patch review, Andreas, in response to the proposed doc entry describing the feature capability of multiple or differing payloads in a s302m stream, suggested[1] that s302m should be a bitstream filter instead, but I did not see that as an actionable suggestion as he immediately listed the bsf limitations preventing the possibility. I also had not seen an actual sample of s302m with multiple embedded streams. Kieran also observed[2] that he had not seen such a stream in the wild. So the added features of this patch, wherever they are ultimately located, shall not yield more than one media stream. Anton suggested[3] that the decoder should instead be a demuxer. I saw no other objections to the architecture of the patch. I posted the v2 patch, incorporating some changes suggested by Andreas, 4 days later. This had gone uncommented for over two weeks when I posted a notice stating an intention to push. Anton posted[4] a new objection that "If it dynamically generates nested decoders, then it's not a proper codec in our model". This new objection is not connected to multiple streams but only to a codec 'model' that I don't see described anywhere and which contradicts the implementations of multiple decoders with a nested decoder, including the ftr and imm5 decoders, which are most similar in design to the patched s302m decoder. Anton later on mentioned[5] that nested decoders are "a constant source of issues". However, I didn't find anything on trac reporting an issue with the nested decoders of ftr and imm5 nor anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit history either points to architectural bugs. These decoders have been around for 6 years among themselves. The testing of the patched s302m decoder over the past month by myself, an OTT provider and others shows no issues either. Finally, Anton speculates[6] that the burden of fixes will likely fall upon him. In none of his objections, till the time of writing, did I see specific concerns with the patch. There are some limitations in shifting this decoder wholesale to inside the MPEG-TS demuxer. A s302m stream may contain some non-media payload accompanying non-PCM media i.e. S-ADM metadata. At present, I have neither the samples nor the specification needed in order to locate and extract or parse this metadata. Formatting the payload data inside the demuxer will lead to irrevocable loss of such metadata if present. However, a decoder patch allows simultaneuous output of both a decoded stream alongside a copied stream. The end-user can then do with the raw data whatever they wish. Ultimately, s302m is specified an an elementary stream inside a MPEG-TS container. Its internal handling is better left to a dedicated module like a decoder. A bitstream filter might be a better fit if s302m streams with multiple media payloads ever start appearing - none have, so far - but for single media payloads, a decoder remains the best place. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html ___ 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 11/31] fftools/ffmpeg_filter: stop accessing encoder AVCodecContext
On 2024-04-05 10:20 pm, Dennis Mungai wrote: Does this imply that down the line, with this and additional patchsets, that FFmpeg can handle tasks such as stream copy and filtering in the same invocation? What do you mean? If you map a stream twice, you already can do that now. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
Ping. As the TC rules matter has been concluded, this should go ahead. Regards, Gyan On 2024-02-17 05:15 pm, Gyan Doshi wrote: Issue: Patch: avcodec/s302m: enable non-PCM decoding URL: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ The issue needing resolution is whether the patch should be added to the existing s302m decoder or should that decoder be removed and all old and new patched features inlined into the mpeg-ts demuxer. Summary: SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST 337 enables this for non-PCM codecs. The payload has a custom layout so it can't be directly processed hence lavc/s302m decodes the packet data to yield LPCM media. But it can only deal at present with LPCM payloads, meaning that non-PCM payloads need to be exported to a raw bytestream format and then decoded in a 2nd step, which prohibits direct transcoding of live/streaming inputs. This patch corrects the identification process for non-PCM payloads, reformats the payload and then carries out in-place decoding by calling a nested decoder similar to the ftr or imm5 decoders in lavc. In the v1 patch review, Andreas, in response to the proposed doc entry describing the feature capability of multiple or differing payloads in a s302m stream, suggested[1] that s302m should be a bitstream filter instead, but I did not see that as an actionable suggestion as he immediately listed the bsf limitations preventing the possibility. I also had not seen an actual sample of s302m with multiple embedded streams. Kieran also observed[2] that he had not seen such a stream in the wild. So the added features of this patch, wherever they are ultimately located, shall not yield more than one media stream. Anton suggested[3] that the decoder should instead be a demuxer. I saw no other objections to the architecture of the patch. I posted the v2 patch, incorporating some changes suggested by Andreas, 4 days later. This had gone uncommented for over two weeks when I posted a notice stating an intention to push. Anton posted[4] a new objection that "If it dynamically generates nested decoders, then it's not a proper codec in our model". This new objection is not connected to multiple streams but only to a codec 'model' that I don't see described anywhere and which contradicts the implementations of multiple decoders with a nested decoder, including the ftr and imm5 decoders, which are most similar in design to the patched s302m decoder. Anton later on mentioned[5] that nested decoders are "a constant source of issues". However, I didn't find anything on trac reporting an issue with the nested decoders of ftr and imm5 nor anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit history either points to architectural bugs. These decoders have been around for 6 years among themselves. The testing of the patched s302m decoder over the past month by myself, an OTT provider and others shows no issues either. Finally, Anton speculates[6] that the burden of fixes will likely fall upon him. In none of his objections, till the time of writing, did I see specific concerns with the patch. There are some limitations in shifting this decoder wholesale to inside the MPEG-TS demuxer. A s302m stream may contain some non-media payload accompanying non-PCM media i.e. S-ADM metadata. At present, I have neither the samples nor the specification needed in order to locate and extract or parse this metadata. Formatting the payload data inside the demuxer will lead to irrevocable loss of such metadata if present. However, a decoder patch allows simultaneuous output of both a decoded stream alongside a copied stream. The end-user can then do with the raw data whatever they wish. Ultimately, s302m is specified an an elementary stream inside a MPEG-TS container. Its internal handling is better left to a dedicated module like a decoder. A bitstream filter might be a better fit if s302m streams with multiple media payloads ever start appearing - none have, so far - but for single media payloads, a decoder remains the best place. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html ___ 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 mai
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On 2024-04-01 04:46 pm, Anton Khirnov wrote: Hi all, the vote has now ended with 23 votes cast, results are available at https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589 The winning option is 'Anton', i.e. my proposal. Voting data as reported by CIVS is attached to this email for future reference. How come there's an entry with all 7s? The choices were ranks, not weight markers. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/movenc: mark mov/mp4 as supporting VFR
On 2024-03-29 02:05 pm, Anton Khirnov wrote:
---
libavformat/movenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b97c479cc4..30cfbf6e74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -8230,11 +8230,11 @@ const FFOutputFormat ff_mov_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = (const AVCodecTag* const []){
ff_codec_movvideo_tags, ff_codec_movaudio_tags,
ff_codec_movsubtitle_tags, 0
},
@@ -8282,11 +8282,11 @@ const FFOutputFormat ff_mp4_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = mp4_codec_tags_list,
.check_bitstream = mov_check_bitstream,
.p.priv_class = &mov_isobmff_muxer_class,
LGTM. Should have been done a long time ago.
What about the other muxers in movenc?
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On 2024-03-25 03:11 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-03-22 14:05:05) Please do post the final text and options a day in advance. I have now created the poll, but not started it yet (the text and options can still be edited). It looks like this: The description, my option looks fine. What will be the evaluation method? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On 2024-03-22 06:22 pm, Anton Khirnov wrote: Michael, following up on the previous discussion in this thread - if you, personally, would like to vote for a different option than those suggested so far, please propose one. I am not going to add a large number of options that nobody actually wants to vote for, as it imposes a burden on the voters who have to carefully read and compare all the options. Beyond that, I am planning to start the vote on Monday 2024-03-25. Please do post the final text and options a day in advance. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/community: rule to avoid conflict of interest and prejudice in TC
Ping. Anton announced to have a vote on 4th Mar for changing the rule [1]. That's long past. It is holding up the consideration of the matter I raised [2] to the TC. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/322464.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321564.html On 2024-03-03 12:52 pm, Gyan Doshi wrote: --- doc/community.texi | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/community.texi b/doc/community.texi index 90d2b6f366..8d5722bd7f 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -82,7 +82,20 @@ The TC has 2 modes of operation: a RFC one and an internal one. If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself. -If the disagreement involves a member of the TC, that member should recuse themselves from the decision. +Any member of the TC who has + +@itemize @bullet +@item +had a major participation in the discussion or demonstrated a partisan disposition on a disputed matter at any public venue, or +@item +a material interest in the resolution of the dispute, either directly or via current or anticipated employment or consideration +@end itemize + +should be recused from participation in the TC activities related to the concerned matter. +This recusal may be effected either directly by the TC member, or failing which, by a vote of the +Community Committee (CC) - the TC member must not participate in any such vote. Failure by the TC member +to reveal any such involvement as described above, if judged intentional and material by the CC, shall +result in exclusion of said member from all FFmpeg governance bodies for a period of no less than two years. The decision to use a RFC process or an internal discussion is a discretionary decision of the TC. ___ 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] fate/lavf-container: correct operator; unbreak build
On 2024-03-18 04:11 pm, Liu Steven wrote: On Mar 18, 2024, at 18:11, Gyan Doshi wrote: --- tests/fate/lavf-container.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak index b18ed2362b..7a925117c3 100644 --- a/tests/fate/lavf-container.mak +++ b/tests/fate/lavf-container.mak @@ -80,7 +80,7 @@ FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MOV_DEMUXER LATM_MUXER) + FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MP3_DEMUXERMP3_MUXER) += mp3 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MOV_DEMUXER MOV_MUXER ARESAMPLE_FILTER) += qtrle_mace6.mov FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXER AVI_MUXER ARESAMPLE_FILTER) += cram.avi -FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXERFLV_MUXER) + = hevc.flv +FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXERFLV_MUXER) += hevc.flv Good catch. I'll push this now. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate/lavf-container: correct operator; unbreak build
--- tests/fate/lavf-container.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak index b18ed2362b..7a925117c3 100644 --- a/tests/fate/lavf-container.mak +++ b/tests/fate/lavf-container.mak @@ -80,7 +80,7 @@ FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MOV_DEMUXER LATM_MUXER) + FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MP3_DEMUXERMP3_MUXER) += mp3 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MOV_DEMUXER MOV_MUXER ARESAMPLE_FILTER) += qtrle_mace6.mov FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXER AVI_MUXER ARESAMPLE_FILTER) += cram.avi -FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXERFLV_MUXER) + = hevc.flv +FATE_LAVF_CONTAINER_FATE-$(call ALLYES, AVI_DEMUXERFLV_MUXER) += hevc.flv FATE_LAVF_CONTAINER_FATE = $(FATE_LAVF_CONTAINER_FATE-yes:%=fate-lavf-fate-%) -- 2.44.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] avformat/mpegtsenc: correct bitstream check
On 2024-03-16 02:02 pm, Marton Balint wrote: On Sat, 16 Mar 2024, Gyan Doshi wrote: 8559cce3c3 made the bitstream check generic using a LUT. However, one of the comparisons which involves a bitwise AND and equality check is faulty due to operator precedence. First reported and analysed at https://github.com/streamlink/streamlink/issues/5876 Fixes #10908 --- libavformat/mpegtsenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c index 06e88e9879..b8efc535a7 100644 --- a/libavformat/mpegtsenc.c +++ b/libavformat/mpegtsenc.c @@ -2319,7 +2319,7 @@ static int mpegts_check_bitstream(AVFormatContext *s, AVStream *st, pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 && (AV_RB24(pkt->data) != 0x01 || (st->codecpar->extradata_size > 0 && - (st->codecpar->extradata[0] & e->mask == e->value + ((st->codecpar->extradata[0] & e->mask) == e->value return ff_stream_add_bitstream_filter(st, e->bsf_name, NULL); } return 1; -- LGTM, thanks. Thanks. Pushed as f5441e441f9b0d235e49bdccc69e141ccd92e854 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mpegtsenc: correct bitstream check
8559cce3c3 made the bitstream check generic using a LUT. However, one of the comparisons which involves a bitwise AND and equality check is faulty due to operator precedence. First reported and analysed at https://github.com/streamlink/streamlink/issues/5876 Fixes #10908 --- libavformat/mpegtsenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c index 06e88e9879..b8efc535a7 100644 --- a/libavformat/mpegtsenc.c +++ b/libavformat/mpegtsenc.c @@ -2319,7 +2319,7 @@ static int mpegts_check_bitstream(AVFormatContext *s, AVStream *st, pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 && (AV_RB24(pkt->data) != 0x01 || (st->codecpar->extradata_size > 0 && -(st->codecpar->extradata[0] & e->mask == e->value +((st->codecpar->extradata[0] & e->mask) == e->value return ff_stream_add_bitstream_filter(st, e->bsf_name, NULL); } return 1; -- 2.44.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] [FFmpeg-cvslog] fftools/ffmpeg: add loopback decoding
On 2024-03-14 03:46 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-03-13 08:49:52) Are there any limitations to loopback decoding e.g. would a vpx w/alpha encode be decoded back to a alpha pix fmt? I don't know how vpx alpha works, was it a separate stream in the demuxer or something like that? The encoder attaches the coded alpha as side data to the packet. Only a couple of containers support this SD. The demuxer, in turn, attaches the alpha as SD upon export. Loopback decoders work exactly like normal decoders, except their packets arrive from an encoder instead of a demuxer. In terms of syntax, do all LB streams have to be specified in the first output? Does that output muxer have to be null, or can those packets be routed to both output and LB? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale2ref: switch to FFFrameSync
On 2024-03-13 05:54 pm, Niklas Haas wrote: From: Niklas Haas This filter's existing design has a number of issues: - There is no guarantee whatsoever about the order in which frames are pushed onto the main and ref link, due to this being entirely dependent on the order in which downstream filters decide to request frames from their various inputs. As such, there is absolutely no synchronization for ref streams with dynamically changing resolutions (see e.g. fate/h264/reinit-*). The only raison d'etre for scale2ref was to have some way to access another stream's parameters. Dynamic streams weren't really the focus. - For some (likely historical) reason, this filter outputs its ref stream as a second ref output, which is in principle completely unnecessary (complex filter graph users can just duplicate the input pin), but in practice only required to allow this filter to "eventually" see changes to the ref stream (see first point). In particular, this means that if the user uses the "wrong" pin, this filter may break completely. This change is fine but you should note in the manual docs that this change has occurred (and when) as existing scripts will fail due to the surplus output pad. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: mark scale2ref as supporting dynamic sizes
On 2024-03-13 05:54 pm, Niklas Haas wrote:
From: Niklas Haas
Analogous to the "scale" filter, which this is practically identical
with.
---
libavfilter/avfilter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 831871de90b..dcad4d55292 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1027,7 +1027,8 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
strcmp(link->dst->filter->name, "format") &&
strcmp(link->dst->filter->name, "idet") &&
strcmp(link->dst->filter->name, "null") &&
-strcmp(link->dst->filter->name, "scale")) {
+strcmp(link->dst->filter->name, "scale") &&
+strcmp(link->dst->filter->name, "scale2ref")) {
av_assert1(frame->format == link->format);
av_assert1(frame->width == link->w);
av_assert1(frame->height== link->h);
LGTM.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: add loopback decoding
On 2024-03-13 12:57 pm, Anton Khirnov wrote: ffmpeg | branch: master | Anton Khirnov | Mon Feb 19 10:27:44 2024 +0100| [a9193f7b7d65aafa326e25571c6672636a8ee3d2] | committer: Anton Khirnov fftools/ffmpeg: add loopback decoding ... +E.g. the following example: + +@example +ffmpeg -i INPUT\ + -map 0:v:0 -c:v libx264 -crf 45 -f null -\ + -dec 0:0 -filter_complex '[0:v][dec:0]hstack[stack]' \ + -map '[stack]' -c:v ffv1 OUTPUT Can you add an example showing the assignment of a specific decoder along with a lavc generic + private option to a loopbacked stream? Are there any limitations to loopback decoding e.g. would a vpx w/alpha encode be decoded back to a alpha pix fmt? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: add threads dep for vulkan
On 2024-03-12 09:15 pm, Lynne wrote: Mar 12, 2024, 05:16 by ffm...@gyani.pro: Fixes #10900 --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 05f8283af9..e0b5bcf589 100755 --- a/configure +++ b/configure @@ -3076,6 +3076,7 @@ nvdec_deps="ffnvcodec" vaapi_x11_deps="xlib_x11" videotoolbox_hwaccel_deps="videotoolbox pthreads" videotoolbox_hwaccel_extralibs="-framework QuartzCore" +vulkan_deps="threads" vulkan_deps_any="libdl LoadLibrary" av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1" lgtm Thanks. Pushed as 9e8be937fc4933ade00a18578f8c1420006d4291 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/muxers: add ffmetadata
On 2024-03-12 04:25 pm, Stefano Sabatini wrote:
---
doc/metadata.texi | 1 +
doc/muxers.texi | 16
2 files changed, 17 insertions(+)
diff --git a/doc/metadata.texi b/doc/metadata.texi
index be91059a98..e081da7735 100644
--- a/doc/metadata.texi
+++ b/doc/metadata.texi
@@ -1,3 +1,4 @@
+@anchor{metadata}
@chapter Metadata
@c man begin METADATA
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a697e4b153..0aaef2b520 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1429,6 +1429,22 @@ Use @command{ffmpeg} to convert the input:
ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r 29.97 -ac 2 -ar 48000 -y
out.dv
@end example
+@section ffmetadata
+FFmpeg metadata muxer.
+
+This muxer writes the streams metadata in the @samp{ffmetadata}
+format.
+
+See @ref{metadata,,the Metadata chapter,ffmpeg-formats} for
+information about the format.
+
+@subsection Example
+Copy an input file and insert metadata information from an
@file{metadata.ffmeta} file in
+@samp{ffmetadata} format:
+@example
+ffmpeg -i INPUT -i metadata.ffmeta -map_metadata 1 -codec copy OUTPUT
+@end example
+
The above example is for the demuxer only. Better to include an initial
step showing export.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] configure: add threads dep for vulkan
Fixes #10900 --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 05f8283af9..e0b5bcf589 100755 --- a/configure +++ b/configure @@ -3076,6 +3076,7 @@ nvdec_deps="ffnvcodec" vaapi_x11_deps="xlib_x11" videotoolbox_hwaccel_deps="videotoolbox pthreads" videotoolbox_hwaccel_extralibs="-framework QuartzCore" +vulkan_deps="threads" vulkan_deps_any="libdl LoadLibrary" av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1" -- 2.44.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] avfilter: update filter timeline state only on main link
On 2024-03-06 11:02 am, Gyan Doshi wrote: On 2024-03-01 07:41 pm, Gyan Doshi wrote: At present, consume_update evaluates timeline state on all links for a multi-input filter. This can lead to the filter being incorrectly en/dis-abled when evaluation on a frame on a secondary link leads to a different result than the frame on the current main link next in line for processing. Ping. Plan to apply in 72h, barring objections. Pushed as 3d1860ec8db7f9785bf1338e826138c0218dfb59 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: update filter timeline state only on main link
On 2024-03-01 07:41 pm, Gyan Doshi wrote: At present, consume_update evaluates timeline state on all links for a multi-input filter. This can lead to the filter being incorrectly en/dis-abled when evaluation on a frame on a secondary link leads to a different result than the frame on the current main link next in line for processing. Ping. Plan to apply in 72h, barring objections. Regards, Gyan --- libavfilter/avfilter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index daa7c3672a..d7ea993508 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfilter.c @@ -1430,7 +1430,8 @@ static void consume_update(FilterLinkInternal *li, const AVFrame *frame) AVFilterLink *const link = &li->l; update_link_current_pts(li, frame->pts); ff_inlink_process_commands(link, frame); -link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, frame); +if (link == link->dst->inputs[0]) +link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, frame); link->frame_count_out++; link->sample_count_out += frame->nb_samples; } ___ 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
On 2024-03-03 07:04 am, Michael Niedermayer wrote: On Sat, Mar 02, 2024 at 11:07:40AM +0530, Gyan Doshi wrote: On 2024-03-01 11:03 pm, Anton Khirnov wrote: * Any member of the TC who had a strong opinion on the question raised before it was raised should recuse themselves. In particular, must recuse themselves any member of the TC who: - participated in the discussion (on the ML, on IRC or elsewhere) in a specific direction (minor comments and questions being acceptable); - has a personal interest in the outcome; - is, was recently or soon will be employed by an entity having a personal interest in the outcome or has any kind of hierarchical relationship with such entity. Failure to do so would result, upon discovery, into the exclusion of all FFmpeg governance bodies, including the general assembly, for a duration of no less than five years. Additionally, any member of the general assembly can recuse any member of the TC without having to provide a reason. I propose a narrower version for this last point as currently it has a mix of unenforceable, broad and harsh elements. * Any member of the TC who has - had a major participation in the discussion or demonstrated a partisan disposition on the concerned issue at any public venue, or - a financial interest in the outcome, either directly or via current or anticipated employment or consideration is subject to recusal from participation in the TC activities related to the issue under consideration. This recusal may be effected either directly by the TC member, or by a vote of the Community Committee (CC) - the TC member must not participate in any such vote. Failure by the TC member to reveal any such involvement as described above, if judged intentional and material by the CC, shall result in exclusion of said member from all FFmpeg governance bodies for a period of no less than two years. Please provide this as a patch so potential voters can see exactly what before and after text there is Sent as 'doc/community: rule to avoid conflict of interest and prejudice in TC'. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/community: rule to avoid conflict of interest and prejudice in TC
--- doc/community.texi | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/community.texi b/doc/community.texi index 90d2b6f366..8d5722bd7f 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -82,7 +82,20 @@ The TC has 2 modes of operation: a RFC one and an internal one. If the TC thinks it needs the input from the larger community, the TC can call for a RFC. Else, it can decide by itself. -If the disagreement involves a member of the TC, that member should recuse themselves from the decision. +Any member of the TC who has + +@itemize @bullet +@item +had a major participation in the discussion or demonstrated a partisan disposition on a disputed matter at any public venue, or +@item +a material interest in the resolution of the dispute, either directly or via current or anticipated employment or consideration +@end itemize + +should be recused from participation in the TC activities related to the concerned matter. +This recusal may be effected either directly by the TC member, or failing which, by a vote of the +Community Committee (CC) - the TC member must not participate in any such vote. Failure by the TC member +to reveal any such involvement as described above, if judged intentional and material by the CC, shall +result in exclusion of said member from all FFmpeg governance bodies for a period of no less than two years. The decision to use a RFC process or an internal discussion is a discretionary decision of the TC. -- 2.44.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] [RFC] clarifying the TC conflict of interest rule
On 2024-03-01 11:03 pm, Anton Khirnov wrote: * Any member of the TC who had a strong opinion on the question raised before it was raised should recuse themselves. In particular, must recuse themselves any member of the TC who: - participated in the discussion (on the ML, on IRC or elsewhere) in a specific direction (minor comments and questions being acceptable); - has a personal interest in the outcome; - is, was recently or soon will be employed by an entity having a personal interest in the outcome or has any kind of hierarchical relationship with such entity. Failure to do so would result, upon discovery, into the exclusion of all FFmpeg governance bodies, including the general assembly, for a duration of no less than five years. Additionally, any member of the general assembly can recuse any member of the TC without having to provide a reason. I propose a narrower version for this last point as currently it has a mix of unenforceable, broad and harsh elements. * Any member of the TC who has - had a major participation in the discussion or demonstrated a partisan disposition on the concerned issue at any public venue, or - a financial interest in the outcome, either directly or via current or anticipated employment or consideration is subject to recusal from participation in the TC activities related to the issue under consideration. This recusal may be effected either directly by the TC member, or by a vote of the Community Committee (CC) - the TC member must not participate in any such vote. Failure by the TC member to reveal any such involvement as described above, if judged intentional and material by the CC, shall result in exclusion of said member from all FFmpeg governance bodies for a period of no less than two years. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter: update filter timeline state only on main link
At present, consume_update evaluates timeline state on all links for a multi-input filter. This can lead to the filter being incorrectly en/dis-abled when evaluation on a frame on a secondary link leads to a different result than the frame on the current main link next in line for processing. --- libavfilter/avfilter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index daa7c3672a..d7ea993508 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfilter.c @@ -1430,7 +1430,8 @@ static void consume_update(FilterLinkInternal *li, const AVFrame *frame) AVFilterLink *const link = &li->l; update_link_current_pts(li, frame->pts); ff_inlink_process_commands(link, frame); -link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, frame); +if (link == link->dst->inputs[0]) +link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, frame); link->frame_count_out++; link->sample_count_out += frame->nb_samples; } -- 2.44.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] configure: select iamfenc as movenc dep
Unbreaks movenc compilation in minimal configuration. --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 197f762b58..2d0e6a444a 100755 --- a/configure +++ b/configure @@ -3554,7 +3554,7 @@ mlp_demuxer_select="mlp_parser" mmf_muxer_select="riffenc" mov_demuxer_select="iso_media riffdec iamfdec" mov_demuxer_suggest="zlib" -mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf aac_adtstoasc_bsf ac3_parser" +mov_muxer_select="iso_media riffenc rtpenc_chain vp9_superframe_bsf aac_adtstoasc_bsf ac3_parser iamfenc" mp3_demuxer_select="mpegaudio_parser" mp3_muxer_select="mpegaudioheader" mp4_muxer_select="mov_muxer" -- 2.39.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] [RFC] clarifying the TC conflict of interest rule
On 2024-02-23 01:26 pm, Nicolas George wrote: Anton Khirnov (12024-02-22): In my updated proposal, based on comments by Niklas and Rémi, I'm leaving it up to the TC member in question, based on the assumption that TC members are honest. A "stronger" version could conceivably leave it to CC to decide ambiguous cases. Feel free to propose such a version if you prefer it. Your version does nothing to address the issue of the current situation, where the contributor who has to raise an issue in front of the TC does not trust one member of the TC to be unbiased on this issue. Just to be clear, that's not my basis. I said, "As a TC member who is part of the disagreement, I believe your participation is recused." based on the existing rule, "If the disagreement involves a member of the TC, that member should recuse themselves from the decision" Disagreement implies the existence of opposing sides, so discussion members from both sides are barred from the TC proceedings. The wiggle room in interpretation is over whether 'involves' captures all participants, including minor ones, or just the principal interlocutors. Note that the rule says nothing about patch authorship or asymmetry in its application. Anton's original disagreement, as I understand it, is about the propriety of the rule i.e. he believes that pre-existing public opposition (or agreement) on the issue should not bar a TC member. That's a disagreement with the rule, not with its interpretation. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On 2024-02-20 04:39 pm, Anton Khirnov wrote: As for determining conflict of interest in case of dishonest TC members, I don't think there is a general solution for it. This is not about dishonesty. Imagine a TC member genuinely does not self-assess or agree to a conflict of interest, does that mean they can vote regardless of what the other members think? In other words, by whom and how is a claim of conflict adjudicated? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
On 2024-02-20 02:20 pm, Anton Khirnov wrote: So IMO the only case that needs to be excluded is 6) - an actual conflict of interest. I therefore propose the following wording changes: --- a/doc/community.texi +++ b/doc/community.texi -If the disagreement involves a member of the TC, that member should recuse themselves from the decision. + Each TC member must vote on such decision according to what is, in their + view, best for the project. If a TC member is affected by a conflict of + interest with regards to the case, they must announce it and recuse + themselves from the TC discussion and vote. A conflict of interest is + presumed to occur when a TC member has a personal interest (e.g. + financial) in a specific outcome of the case. 1) besides financial interest, what are some other types of 'personal interest in a specific outcome of the case'? 2) the proposed wording says, 'they must announce it and recuse themselves'. That makes it seem that if a member does not self-attest or admit to a conflict of interest, then they cannot be stopped from voting. To frame it as a question, what are the independent ways ( i.e. not including the said member) of making a conflict of interest determination? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-19 08:00 pm, Vittorio Giovara wrote: On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote: The TC is invoked when there's an intractable dispute. So the dispute precedes the TC activity hence the parties to the dispute are the main opposing participants at the venue of the dispute wherever that is, and the rules applies to all main parties. Imagine there's a new feature to be added which doesn't exist in the codebase in any form so there's no status quo. Member A submits a patch using design pattern X. Member B objects and wants design pattern Y. Now let's say if only A was on the TC, then as per the arguments of some here, A should recuse themselves but if only B was on the TC, B gets to vote. That asymmetry is not supported in the wording nor would it be fair. The asymmetry is that the TC should be protecting the good of the project and the community interests, while the member of the community proposing the patch is protecting their own interest. Both the proposer and disputer of a patch may have a vested interest in steering decisions one way or the other, or both may believe they're furthering the good of the project. There is no asymmetry inherent in the roles of the participants. There shouldn't be in the rules either. The rule you keep bringing forth is stated to avoid a conflict of interest where the member of the TC is also the author of the patch, but was never meant to exclude one party from voting in the TC. We've already had the proposer of the rule participate in this thread and I cited discussion from the time of drafting of the rule that it is meant to apply to both sides. Treating the rule as applying to only the author is the aberrant interpretation. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-19 03:16 am, Vittorio Giovara wrote: On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote: On 2024-02-18 11:33 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-18 05:06:30) b) what "maximalist" interpretation? A non-maximalist interpretation would be that a TC member is only excluded from voting when they authored the patch that is being disputed. If the promulgators meant to only prevent proposers of the disputed change to not take part, then the verbiage would be different. In looking up how this clause came to be present, I came across the following messages: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273443.html (Nicolas George originally proposes this clause - wording is more restrictive) https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274822.html (this one is interesting, you objected to the clause but on the grounds that it was all-encompassing i.e. anyone commenting on the dispute was potentially subjected to recusal and referred to some 'model' discussion, so your describing my reading as maximalist is weird since that is how you read it - you just happen to object to this rule) https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274826.html (Ronald clarifies that "involved" should be constrained to just be one of the two parties -- of which you happen to be one) There's the matter of what the rule currently is, distinct from what it should be. What it ideally should be is that the decision should be taken by a fresh set of eyes consisting of those who haven't become or are seen to be publicly invested in the outcome. So the TC should have a set of alternates - those who can make up the quorum and constitute an odd number of voters when some from the first 5 are recused. I'd like to offer a lighter interpretation of the rule, the mailing list is the common playing ground, where discussions and disagreements can be had. In case of a technical "maximalist" disagreement, then either party can invoke the TC to judge on the matter. If anyone in the TC is involved in the patch, as if it's an author or significantly contributed to it, then they should step away from voting. In other words the "level of involvement" rule takes place at the TC level, not at the ffmpeg-devel discussion. The TC is invoked when there's an intractable dispute. So the dispute precedes the TC activity hence the parties to the dispute are the main opposing participants at the venue of the dispute wherever that is, and the rules applies to all main parties. Imagine there's a new feature to be added which doesn't exist in the codebase in any form so there's no status quo. Member A submits a patch using design pattern X. Member B objects and wants design pattern Y. Now let's say if only A was on the TC, then as per the arguments of some here, A should recuse themselves but if only B was on the TC, B gets to vote. That asymmetry is not supported in the wording nor would it be fair. Also consider that even in a vote recusal, the member's arguments will still be read and by all likelihood taken into consideration by the TC, so yours seems to be a literal interpretation of the rule, instead of the spirit of the rule, which in my opinion matters more. Of course. There's no mind-reading or mind-control machine here. Humans aren't automatons either. The judges on any Supreme Court are older human beings with all the deep convictions that one acquires during a long lifetime but that's the best we can do. The rules are meant to be the most that is practically feasible within mutually observable reality, not ideally efficient within an omniscient universe. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-18 11:33 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-18 05:06:30) b) what "maximalist" interpretation? A non-maximalist interpretation would be that a TC member is only excluded from voting when they authored the patch that is being disputed. If the promulgators meant to only prevent proposers of the disputed change to not take part, then the verbiage would be different. In looking up how this clause came to be present, I came across the following messages: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273443.html (Nicolas George originally proposes this clause - wording is more restrictive) https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274822.html (this one is interesting, you objected to the clause but on the grounds that it was all-encompassing i.e. anyone commenting on the dispute was potentially subjected to recusal and referred to some 'model' discussion, so your describing my reading as maximalist is weird since that is how you read it - you just happen to object to this rule) https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274826.html (Ronald clarifies that "involved" should be constrained to just be one of the two parties -- of which you happen to be one) There's the matter of what the rule currently is, distinct from what it should be. What it ideally should be is that the decision should be taken by a fresh set of eyes consisting of those who haven't become or are seen to be publicly invested in the outcome. So the TC should have a set of alternates - those who can make up the quorum and constitute an odd number of voters when some from the first 5 are recused. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-18 01:25 am, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-17 13:37:38) On 2024-02-17 05:52 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-17 12:46:27) As a TC member who is part of the disagreement, I believe your participation is recused. No, I do not think "TC members who commented on a patch lose their right to vote" is a reasonable interpretation of that rule. I refer to "If the disagreement involves a member of the TC, that member should recuse themselves from the decision" at https://ffmpeg.org/community.html#Announcement You clearly are one of the parties to the disagreement, and "recuse themselves from the decision" is self-explanatory. Such a maximalist interpretation makes no sense - why should my opinion become invalid because I commented on a patch, but not if I kept it to myself and let someone else object to your patch? a) I didn't make that rule, just pointed it out b) what "maximalist" interpretation? - I think the current patch is fine, you don't. That's a disagreement and you're involved in it, so the rule tells you to not be a judge. This is not a complex body of law or obscure legalese , just a trivial application of the rule composed in school-level English. c) your opinion hasn't been made invalid - it just can't be a weighted vote in the TC decision. And it's not merely because you 'commented' - see (b). Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
On 2024-02-17 07:12 pm, Niklas Haas wrote: On Sat, 17 Feb 2024 18:45:57 +0530 Gyan Doshi wrote: Whilst s302m multiple substreams I haven't seen, Dolby E streams internally contain multiple programs, often 5.1 and a 2.0 downmix. That is downstream of the Dolby-E decoder and user will have to use a filter like channelsplit to bifurcate those channels irrespective of where the s302m code resides. Is there metadata in Dolby E that tells you which channels belong together (and what attributes they might have)? Is it always 5.1+2.0, or could you have e.g. four different 2.0 programs encoded into a single S302M/AES3 stream? Yes, the metadata is program configuration, with 8 max channels and 8 max programs, so 8 mono programs at most. But my samples are all 5.1+2 or 7.1 or 4.0. These will all result in a single decoded stream from the dolby_e decoder. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg TC input needed
On 2024-02-17 05:31 pm, Kieran Kunhya wrote: On Sat, 17 Feb 2024, 11:46 Gyan Doshi, wrote: Issue: Patch: avcodec/s302m: enable non-PCM decoding URL: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ The issue needing resolution is whether the patch should be added to the existing s302m decoder or should that decoder be removed and all old and new patched features inlined into the mpeg-ts demuxer. Additional comments: Dolby E can exist in any PCM container (wav, MP4). S302M just happens to be a tricky one. Whilst s302m multiple substreams I haven't seen, Dolby E streams internally contain multiple programs, often 5.1 and a 2.0 downmix. That is downstream of the Dolby-E decoder and user will have to use a filter like channelsplit to bifurcate those channels irrespective of where the s302m code resides. There is a 3x3 matrix of flavours between coded Dolby E and the carriage PCM (16-bit, 20-bit, 24-bit). Have you seen a larger non-PCM word size inside a smaller AES3 word? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-17 05:52 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-17 12:46:27) As a TC member who is part of the disagreement, I believe your participation is recused. No, I do not think "TC members who commented on a patch lose their right to vote" is a reasonable interpretation of that rule. I refer to "If the disagreement involves a member of the TC, that member should recuse themselves from the decision" at https://ffmpeg.org/community.html#Announcement You clearly are one of the parties to the disagreement, and "recuse themselves from the decision" is self-explanatory. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-16 02:33 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-15 17:47:49) This patch facilitates a certain productive use of ffmpeg with respect to processing of live inputs that wasn't possible earlier, and which currently is being used successfully by multiple people over the past few weeks. It applies a processing model already implemented in multiple other decoders for a number of years. I haven't seen many reports of issues with them. And surely something being 'a constant source of issues' would be a lot more than 'subtly broken' as you describe them. This reads very much like "I can't be bothered to do it properly and would rather someone else fix it in the future". Given past experience, that someone is highly likely to be me, and fixing past architectural decisions requires a lot more effort than doing things properly in the first place.. You're the only one who has objected on architectural grounds and Not true, Andreas has objected as well. If you are blocking this patch, do acknowledge here within 24 hours and we can send this to the TC else I'll push it after that period. I must say I rather dislike this "my way or the highway" attitude. So yes, I am objecting to the patch in its current form. Thanks for the clear signal. I've presented my case to the TC on the ML. As a TC member who is part of the disagreement, I believe your participation is recused. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] FFmpeg TC input needed
Issue: Patch: avcodec/s302m: enable non-PCM decoding URL: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/ The issue needing resolution is whether the patch should be added to the existing s302m decoder or should that decoder be removed and all old and new patched features inlined into the mpeg-ts demuxer. Summary: SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST 337 enables this for non-PCM codecs. The payload has a custom layout so it can't be directly processed hence lavc/s302m decodes the packet data to yield LPCM media. But it can only deal at present with LPCM payloads, meaning that non-PCM payloads need to be exported to a raw bytestream format and then decoded in a 2nd step, which prohibits direct transcoding of live/streaming inputs. This patch corrects the identification process for non-PCM payloads, reformats the payload and then carries out in-place decoding by calling a nested decoder similar to the ftr or imm5 decoders in lavc. In the v1 patch review, Andreas, in response to the proposed doc entry describing the feature capability of multiple or differing payloads in a s302m stream, suggested[1] that s302m should be a bitstream filter instead, but I did not see that as an actionable suggestion as he immediately listed the bsf limitations preventing the possibility. I also had not seen an actual sample of s302m with multiple embedded streams. Kieran also observed[2] that he had not seen such a stream in the wild. So the added features of this patch, wherever they are ultimately located, shall not yield more than one media stream. Anton suggested[3] that the decoder should instead be a demuxer. I saw no other objections to the architecture of the patch. I posted the v2 patch, incorporating some changes suggested by Andreas, 4 days later. This had gone uncommented for over two weeks when I posted a notice stating an intention to push. Anton posted[4] a new objection that "If it dynamically generates nested decoders, then it's not a proper codec in our model". This new objection is not connected to multiple streams but only to a codec 'model' that I don't see described anywhere and which contradicts the implementations of multiple decoders with a nested decoder, including the ftr and imm5 decoders, which are most similar in design to the patched s302m decoder. Anton later on mentioned[5] that nested decoders are "a constant source of issues". However, I didn't find anything on trac reporting an issue with the nested decoders of ftr and imm5 nor anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit history either points to architectural bugs. These decoders have been around for 6 years among themselves. The testing of the patched s302m decoder over the past month by myself, an OTT provider and others shows no issues either. Finally, Anton speculates[6] that the burden of fixes will likely fall upon him. In none of his objections, till the time of writing, did I see specific concerns with the patch. There are some limitations in shifting this decoder wholesale to inside the MPEG-TS demuxer. A s302m stream may contain some non-media payload accompanying non-PCM media i.e. S-ADM metadata. At present, I have neither the samples nor the specification needed in order to locate and extract or parse this metadata. Formatting the payload data inside the demuxer will lead to irrevocable loss of such metadata if present. However, a decoder patch allows simultaneuous output of both a decoded stream alongside a copied stream. The end-user can then do with the raw data whatever they wish. Ultimately, s302m is specified an an elementary stream inside a MPEG-TS container. Its internal handling is better left to a dedicated module like a decoder. A bitstream filter might be a better fit if s302m streams with multiple media payloads ever start appearing - none have, so far - but for single media payloads, a decoder remains the best place. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html ___ 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/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-16 07:25 pm, Andreas Rheinhardt wrote: Gyan Doshi: On 2024-02-15 04:17 pm, Anton Khirnov wrote: Hi, sorry for the delay, I've been busy fixing things for the release Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) On 2024-01-28 04:24 pm, Anton Khirnov wrote: a) it would mean essentially inlining this decoder in the demuxer. Why is that a problem? This decoder seems like it shouldn't be a decoder. I agree with Andreas that this seems like it's a demuxer pretending to be a decoder. This module transforms the entire raw payload data to generate its output, even if the syntax is simple which essentially makes it a de-coder. The de-multiplexer aspect of multiple streams is an academic possibility allowed by the standard but not seen in any sample which makes me suspect it's used for carriage between broadcast facilities rather than something ever sent to an OTT provider, let alone an end user. If it dynamically generates nested decoders, then it's not a proper codec in our model. It should be either a part of the demuxer, or a bitstream filter (possibly inserted automatically by the demuxer). s302m is a hybrid creature and does not slot cleanly into any role. So there is no theoretically proper place for this component - any choice is a least-out-of-place accommodation. But it is much more out of place inside a demuxer. Analyzing packet payload and then manipulating that entire payload is much closer to a decoding role than data chunk extraction for packetization. And the stream extracted from the container is meant to be SMPTE ST 302 not PCM* or Dolby-E/AC-3..etc, which will both misrepresent what the container carries and possibly discard S-ADM metadata, if present, in the packet. With passthrough demuxing, a stream can be mapped for both decoding and streamcopying. This is not true: It can not be streamcopied into formats expecting ordinary PCM or Dolby-e/AC-3. Which is why exporting the data without the unnecessary packetization is preferable. With this decoder patch, the packet exported from the demuxer remains s302m. That may contain either PCM or non-PCM payload[+ ADM metadata]. A streamcopied output into TS or raw data allows the user to parse out the ADM on their own. I don't have the standard or samples for ADM so I can't extract it with either a decoder or demuxer patch. If they want the non-PCM coded stream then they select the pre-existing method of non_pcm_mode copy in the decoder and a suitable pcm_* encoder to extract the coded stream, else set the non pcm mode to decode to obtain playable LPCM AVFrames. With a demuxer patch, the packet extracted from the demuxer is either PCM* or some non-PCM codec. The ADM portion if present is lost since there is no parser for it. And if we add an option for passthrough demuxing and leave the s302m decoder as it is, then we're back with the status quo of a 2-step transcoding pipeline. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-16 01:56 am, Kieran Kunhya wrote: On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote: On 2024-02-15 09:40 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-15 13:31:59) On 2024-02-15 04:17 pm, Anton Khirnov wrote: Hi, sorry for the delay, I've been busy fixing things for the release Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) On 2024-01-28 04:24 pm, Anton Khirnov wrote: a) it would mean essentially inlining this decoder in the demuxer. Why is that a problem? This decoder seems like it shouldn't be a decoder. I agree with Andreas that this seems like it's a demuxer pretending to be a decoder. This module transforms the entire raw payload data to generate its output, even if the syntax is simple which essentially makes it a de-coder. The de-multiplexer aspect of multiple streams is an academic possibility allowed by the standard but not seen in any sample which makes me suspect it's used for carriage between broadcast facilities rather than something ever sent to an OTT provider, let alone an end user. If it dynamically generates nested decoders, then it's not a proper codec in our model. It should be either a part of the demuxer, or a bitstream filter (possibly inserted automatically by the demuxer). s302m is a hybrid creature and does not slot cleanly into any role. So there is no theoretically proper place for this component - any choice is a least-out-of-place accommodation. But it is much more out of place inside a demuxer. Analyzing packet payload and then manipulating that entire payload is much closer to a decoding role than data chunk extraction for packetization. I don't see why specifically this property should be the one distinguishing demuxers from decoders, it sounds pretty arbitrary to me. Many demuxers apply transformations of far higher complexity to the bytestream before exporting it, e.g. in matroska the packet data may be compressed, laced, etc. And the stream extracted from the container is meant to be SMPTE ST 302 not PCM* or Dolby-E/AC-3..etc, "meant to be"? By whom? The point of libavformat is to abstract away the differences between containers as much as is reasonably feasible, and export the data in the format most useful to the caller for decoding or other processing. which will both misrepresent what the container carries Why should the caller care? and possibly discard S-ADM metadata, if present, in the packet. Why could that not be exported as side data? A bsf in principle would work but in practice, can't as Andreas clarified that bsfs can't set or alter codec_id after init. And resetting the codec id requires packet inspection. There are two possibilities then - either extend the BSF API to support multiple output streams, or implement it inside libavformat as a post-demuxer hook called in the same place as parsing. Nested decoders are used without issue in components like imm5 or ftr (upto 64 nested decoders!) among others. There's no breaking of new ground here. Nested decoders are certainly not "without issue" - they are a constant source of issues, since implementing nesting properly is very tricky. I am fairly sure most nested decoders we have are subtly broken in various ways. This patch facilitates a certain productive use of ffmpeg with respect to processing of live inputs that wasn't possible earlier, and which currently is being used successfully by multiple people over the past few weeks. It applies a processing model already implemented in multiple other decoders for a number of years. I haven't seen many reports of issues with them. And surely something being 'a constant source of issues' would be a lot more than 'subtly broken' as you describe them.You're the only one who has objected on architectural grounds and this looks to be a fundamental disagreement. If you are blocking this patch, do acknowledge here within 24 hours and we can send this to the TC else I'll push it after that period. Dolby E can exist in other containers apart from S302M. Raising the TC is premature. This patch only concerns s302m and sets up a framework for non-PCM decode. Dolby-E is incidental. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-15 09:40 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-02-15 13:31:59) On 2024-02-15 04:17 pm, Anton Khirnov wrote: Hi, sorry for the delay, I've been busy fixing things for the release Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) On 2024-01-28 04:24 pm, Anton Khirnov wrote: a) it would mean essentially inlining this decoder in the demuxer. Why is that a problem? This decoder seems like it shouldn't be a decoder. I agree with Andreas that this seems like it's a demuxer pretending to be a decoder. This module transforms the entire raw payload data to generate its output, even if the syntax is simple which essentially makes it a de-coder. The de-multiplexer aspect of multiple streams is an academic possibility allowed by the standard but not seen in any sample which makes me suspect it's used for carriage between broadcast facilities rather than something ever sent to an OTT provider, let alone an end user. If it dynamically generates nested decoders, then it's not a proper codec in our model. It should be either a part of the demuxer, or a bitstream filter (possibly inserted automatically by the demuxer). s302m is a hybrid creature and does not slot cleanly into any role. So there is no theoretically proper place for this component - any choice is a least-out-of-place accommodation. But it is much more out of place inside a demuxer. Analyzing packet payload and then manipulating that entire payload is much closer to a decoding role than data chunk extraction for packetization. I don't see why specifically this property should be the one distinguishing demuxers from decoders, it sounds pretty arbitrary to me. Many demuxers apply transformations of far higher complexity to the bytestream before exporting it, e.g. in matroska the packet data may be compressed, laced, etc. And the stream extracted from the container is meant to be SMPTE ST 302 not PCM* or Dolby-E/AC-3..etc, "meant to be"? By whom? The point of libavformat is to abstract away the differences between containers as much as is reasonably feasible, and export the data in the format most useful to the caller for decoding or other processing. which will both misrepresent what the container carries Why should the caller care? and possibly discard S-ADM metadata, if present, in the packet. Why could that not be exported as side data? A bsf in principle would work but in practice, can't as Andreas clarified that bsfs can't set or alter codec_id after init. And resetting the codec id requires packet inspection. There are two possibilities then - either extend the BSF API to support multiple output streams, or implement it inside libavformat as a post-demuxer hook called in the same place as parsing. Nested decoders are used without issue in components like imm5 or ftr (upto 64 nested decoders!) among others. There's no breaking of new ground here. Nested decoders are certainly not "without issue" - they are a constant source of issues, since implementing nesting properly is very tricky. I am fairly sure most nested decoders we have are subtly broken in various ways. This patch facilitates a certain productive use of ffmpeg with respect to processing of live inputs that wasn't possible earlier, and which currently is being used successfully by multiple people over the past few weeks. It applies a processing model already implemented in multiple other decoders for a number of years. I haven't seen many reports of issues with them. And surely something being 'a constant source of issues' would be a lot more than 'subtly broken' as you describe them.You're the only one who has objected on architectural grounds and this looks to be a fundamental disagreement. If you are blocking this patch, do acknowledge here within 24 hours and we can send this to the TC else I'll push it after that period. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-02-15 04:17 pm, Anton Khirnov wrote: Hi, sorry for the delay, I've been busy fixing things for the release Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33) On 2024-01-28 04:24 pm, Anton Khirnov wrote: a) it would mean essentially inlining this decoder in the demuxer. Why is that a problem? This decoder seems like it shouldn't be a decoder. I agree with Andreas that this seems like it's a demuxer pretending to be a decoder. This module transforms the entire raw payload data to generate its output, even if the syntax is simple which essentially makes it a de-coder. The de-multiplexer aspect of multiple streams is an academic possibility allowed by the standard but not seen in any sample which makes me suspect it's used for carriage between broadcast facilities rather than something ever sent to an OTT provider, let alone an end user. If it dynamically generates nested decoders, then it's not a proper codec in our model. It should be either a part of the demuxer, or a bitstream filter (possibly inserted automatically by the demuxer). s302m is a hybrid creature and does not slot cleanly into any role. So there is no theoretically proper place for this component - any choice is a least-out-of-place accommodation. But it is much more out of place inside a demuxer. Analyzing packet payload and then manipulating that entire payload is much closer to a decoding role than data chunk extraction for packetization. And the stream extracted from the container is meant to be SMPTE ST 302 not PCM* or Dolby-E/AC-3..etc, which will both misrepresent what the container carries and possibly discard S-ADM metadata, if present, in the packet. With passthrough demuxing, a stream can be mapped for both decoding and streamcopying. A bsf in principle would work but in practice, can't as Andreas clarified that bsfs can't set or alter codec_id after init. And resetting the codec id requires packet inspection. Nested decoders are used without issue in components like imm5 or ftr (upto 64 nested decoders!) among others. There's no breaking of new ground here. If you feel strongly about this, please refer this to the TC. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-01-27 04:08 pm, Gyan Doshi wrote:
Set up framework for non-PCM decoding in-place and
add support for Dolby-E decoding.
Useful for direct transcoding of non-PCM audio in live inputs.
Plan to push in 3 days, barring objections.
Regards,
Gyan
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m.c | 596 +
3 files changed, 530 insertions(+), 107 deletions(-)
v2:
switch to pointer for non-pcm sync search
use intreadwrite macro for writing frame data
remove unneeded free of non-pcm dec opts
diff --git a/configure b/configure
index 21663000f8..4d7cd83247 100755
--- a/configure
+++ b/configure
@@ -2980,6 +2980,7 @@ rv20_decoder_select="h263_decoder"
rv20_encoder_select="h263_encoder"
rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
+s302m_decoder_select="dolby_e_decoder"
screenpresso_decoder_deps="zlib"
shorten_decoder_select="bswapdsp"
sipr_decoder_select="lsp"
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 293c82c2ba..9f85c876bf 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build
with
An FFmpeg native decoder for Opus exists, so users can decode Opus
without this library.
+@section s302m
+
+SMPTE ST 302 decoder.
+
+SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport
+Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a
+bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
+They can also contain non-PCM codec streams such as AC-3 or Dolby-E.
+
+Decoding non-PCM streams directly requires that the necessary stream decoder be
+present in the build. At present, only Dolby-E decoding is supported.
+
+@subsection Options
+
+The following options are supported by the s302m decoder.
+
+@table @option
+@item non_pcm_mode @var{mode}
+Specify how to process non-PCM streams
+
+@table @samp
+@item copy
+Treat data as if it were LPCM.
+@item drop
+Discard the stream.
+@item decode_copy
+Decode if possible eise treat the same as @code{copy}.
+@item decode_drop
+Decode if possible eise treat the same as @code{drop}.
+@end table
+
+The default value is @code{decode_drop}. This option does not affect the
processing of
+LPCM streams.
+
+@item non_pcm_options @var{options}
+Set options for non-PCM decoder using a list of key=value pairs separated by
":".
+Consult the docs for the non-PCM decoder for its options.
+
+@end table
+
@c man end AUDIO DECODERS
@chapter Subtitles Decoders
diff --git a/libavcodec/s302m.c b/libavcodec/s302m.c
index f1b41608f3..d890b6f117 100644
--- a/libavcodec/s302m.c
+++ b/libavcodec/s302m.c
@@ -24,21 +24,264 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "libavutil/log.h"
+#include "libavutil/dict.h"
#include "libavutil/reverse.h"
#include "avcodec.h"
#include "codec_internal.h"
+#include "get_bits.h"
#include "decode.h"
#define AES3_HEADER_LEN 4
+#define NONPCMSYNC_16MARKER 0x4E1F0F8720
+#define NONPCMSYNC_20MARKER 0x4E1F60F872A0
+#define NONPCMSYNC_24MARKER 0x7E1F690F872A50
+
+#define NONPCMSYNC_16_IN_20MARKER 0x04E1F00F8720
+#define NONPCMSYNC_20_IN_24MARKER 0x04E1F600F872A0
+
+#define IS_NONPCMSYNC_16(state) ((state & 0x00) ==
NONPCMSYNC_16MARKER)
+#define IS_NONPCMSYNC_20(state) ((state & 0xF0F0) ==
NONPCMSYNC_20MARKER)
+#define IS_NONPCMSYNC_24(state) ((state & 0xFF0FF0) ==
NONPCMSYNC_24MARKER)
+
+#define IS_NONPCMSYNC_16_IN_20(state) ((state & 0x0000) ==
NONPCMSYNC_16_IN_20MARKER)
+#define IS_NONPCMSYNC_20_IN_24(state) ((state & 0x0F00F0) ==
NONPCMSYNC_20_IN_24MARKER)
+
+#define IS_NONPCMSYNC(bit,state) ( ((bit == 16) && IS_NONPCMSYNC_16(state))
|| \
+((bit == 20) && (IS_NONPCMSYNC_20(state)
|| IS_NONPCMSYNC_16_IN_20(state))) || \
+((bit == 24) && (IS_NONPCMSYNC_24(state)
|| IS_NONPCMSYNC_20_IN_24(state))) \
+ )
+
+enum non_pcm_modes {
+NON_PCM_COPY,
+NON_PCM_DROP,
+NON_PCM_DEC_ELSE_COPY,
+NON_PCM_DEC_ELSE_DROP,
+};
+
typedef struct S302Context {
AVClass *class;
+
+int avctx_props_set;
+
+int channels;
+int bits;
+
int non_pcm_mode;
+int non_pcm_data_type;
+int non_pcm_bits;
+int non_pcm_dec;
+
+AVCodecContext *non_pcm_ctx;
+AVDictionary *non_pcm_opts;
+AVPacket *packet;
+AVFrame *frame;
} S302Context;
+static av_cold int s302m_init(AVCodecContext *avctx)
+{
+S302Context *s = a
Re: [FFmpeg-devel] [PATCH] avformat/wavenc: use strtoull for UMID conversion
On 2024-02-02 03:34 pm, Gyan Doshi wrote: On 2024-01-29 10:30 am, Gyan Doshi wrote: Existing use of strtoll can lead to ERANGE errors leading to incorrect storage of UMID. Plan to push tomorrow. Pushed as 7375a6ca7b4a4b223a71f85a772c64a34e60eabe Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/wavenc: use strtoull for UMID conversion
On 2024-01-29 10:30 am, Gyan Doshi wrote:
Existing use of strtoll can lead to ERANGE errors leading to incorrect
storage of UMID.
Plan to push tomorrow.
Regards,
Gyan
---
libavformat/wavenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 82acb9ef0f..a41f40b449 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -129,7 +129,7 @@ static void bwf_write_bext_chunk(AVFormatContext *s)
for (i = 0; i < len/16; i++) {
memcpy(umidpart_str, tmp_tag->value + 2 + (i*16), 16);
-umidpart = strtoll(umidpart_str, NULL, 16);
+umidpart = strtoull(umidpart_str, NULL, 16);
avio_wb64(s->pb, umidpart);
}
ffio_fill(s->pb, 0, 64 - i*8);
___
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/buffersrc: limit link variance logs below debug loglevel
On 2024-01-31 09:49 am, Gyan Doshi wrote: On 2024-01-26 07:39 pm, Gyan Doshi wrote: The video param change check will print loglines below debug level for each frame which is different from the inlink parameters. This can spam the console. It is now printed at warning level once for each param change else it is kept at debug level. Partially addresses #10823 Plan to push tomorrow. Pushed as 94422871fce3b90bebc95f5cae939fbbc4e33224 Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: limit link variance logs below debug loglevel
On 2024-01-26 07:39 pm, Gyan Doshi wrote:
The video param change check will print loglines below debug level
for each frame which is different from the inlink parameters. This
can spam the console. It is now printed at warning level once for
each param change else it is kept at debug level.
Partially addresses #10823
Plan to push tomorrow.
Regards,
Gyan
---
libavfilter/buffersrc.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index afe69433b2..6e450ff6b7 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -49,10 +49,10 @@ typedef struct BufferSourceContext {
unsigned nb_failed_requests;
/* video only */
-int w, h;
-enum AVPixelFormat pix_fmt;
-enum AVColorSpace color_space;
-enum AVColorRange color_range;
+int w, h, prev_w, prev_h;
+enum AVPixelFormat pix_fmt, prev_pix_fmt;
+enum AVColorSpace color_space, prev_color_space;
+enum AVColorRange color_range, prev_color_range;
AVRationalpixel_aspect;
AVBufferRef *hw_frames_ctx;
@@ -66,16 +66,30 @@ typedef struct BufferSourceContext {
int eof;
int64_t last_pts;
+int link_delta, prev_delta;
} BufferSourceContext;
#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, csp, range, pts)\
-if (c->w != width || c->h != height || c->pix_fmt != format ||\
-c->color_space != csp || c->color_range != range) {\
-av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d csp: %s range:
%s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time: %s\n",\
+c->link_delta = c->w != width || c->h != height || c->pix_fmt != format ||\
+c->color_space != csp || c->color_range != range;\
+c->prev_delta = c->prev_w != width || c->prev_h != height ||
c->prev_pix_fmt != format ||\
+c->prev_color_space != csp || c->prev_color_range !=
range;\
+if (c->link_delta) {\
+int loglevel = c->prev_delta ? AV_LOG_WARNING : AV_LOG_DEBUG;\
+av_log(s, loglevel, "Changing video frame properties on the fly is not
supported by all filters.\n");\
+av_log(s, loglevel, "filter context - w: %d h: %d fmt: %d csp: %s range:
%s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time: %s\n",\
c->w, c->h, c->pix_fmt, av_color_space_name(c->color_space),
av_color_range_name(c->color_range),\
width, height, format, av_color_space_name(csp),
av_color_range_name(range),\
av_ts2timestr(pts, &s->outputs[0]->time_base));\
-av_log(s, AV_LOG_WARNING, "Changing video frame properties on the fly is
not supported by all filters.\n");\
+}\
+if (c->prev_delta) {\
+if (!c->link_delta)\
+av_log(s, AV_LOG_VERBOSE, "video frame properties congruent with link at
pts_time: %s\n", av_ts2timestr(pts, &s->outputs[0]->time_base));\
+c->prev_w = width;\
+c->prev_h = height;\
+c->prev_pix_fmt = format;\
+c->prev_color_space = csp;\
+c->prev_color_range = range;\
}
#define CHECK_AUDIO_PARAM_CHANGE(s, c, srate, layout, format, pts)\
@@ -111,12 +125,12 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
switch (ctx->filter->outputs[0].type) {
case AVMEDIA_TYPE_VIDEO:
if (param->format != AV_PIX_FMT_NONE) {
-s->pix_fmt = param->format;
+s->pix_fmt = s->prev_pix_fmt = param->format;
}
if (param->width > 0)
-s->w = param->width;
+s->w = s->prev_w = param->width;
if (param->height > 0)
-s->h = param->height;
+s->h = s->prev_h = param->height;
if (param->sample_aspect_ratio.num > 0 && param->sample_aspect_ratio.den
> 0)
s->pixel_aspect = param->sample_aspect_ratio;
if (param->frame_rate.num > 0 && param->frame_rate.den > 0)
@@ -128,9 +142,9 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
return AVERROR(ENOMEM);
}
if (param->color_space != AVCOL_SPC_UNSPECIFIED)
-s->color_space = param->color_space;
+s->color_space = s->prev_color_space = param->color_space;
if (param->color_range != AVCOL_RANGE_UNSPECIFIED)
-s->color_range = param->color_range;
+s->color_range = s->prev_color_range = param->color_range;
break;
case AVMEDIA_TYPE_AUDIO:
if (param->format != AV_SAMPLE_FMT_NONE) {
___
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/2] avcodec/s302m: enable non-PCM decoding
On 2024-01-29 02:57 pm, Nicolas Gaullier wrote:
On 2024-01-28 04:24 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-01-26 05:23:50)
On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM decoding in-place and add support
for Dolby-E decoding.
Useful for direct transcoding of non-PCM audio in live inputs.
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m.c | 609 +
3 files changed, 543 insertions(+), 107 deletions(-)
diff --git a/configure b/configure index c8ae0a061d..8db3fa3f4b
100755
--- a/configure
+++ b/configure
@@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder"
rv20_encoder_select="h263_encoder"
rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
+s302m_decoder_select="dolby_e_decoder"
screenpresso_decoder_deps="zlib"
shorten_decoder_select="bswapdsp"
sipr_decoder_select="lsp"
diff --git a/doc/decoders.texi b/doc/decoders.texi index
293c82c2ba..9f85c876bf 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -347,6 +347,46 @@ configuration. You need to explicitly
configure the build with
An FFmpeg native decoder for Opus exists, so users can decode Opus
without this library.
+@section s302m
+
+SMPTE ST 302 decoder.
+
+SMPTE ST 302 is a method for storing AES3 data format within an
+MPEG
Transport
+Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8
channels with a
+bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
+They can also contain non-PCM codec streams such as AC-3 or Dolby-E.
+
This sounds like we should add bitstream filters to extract the
proper underlying streams instead.
(I see only two problems with this approach: The BSF API needs to
set the CodecID of the output during init, but at this point no
packet has reached the BSF to determine it. And changing codec IDs
mid-stream is also not supported.)
In theory, this decoder shouldn't exist, as it is just a carrier,
whether of LPCM or non-PCM.
FFmpeg architecture also imposes a fundamental limitation in that
one s302m stream may carry multiple payload streams and we support
only one decoding context per input stream
Then why does the demuxer not separate the data into multiple streams?
I didn't add demuxing support for this codec in MPEGTS, but I can
venture
a) it would mean essentially inlining this decoder in the demuxer.
Why is that a problem? This decoder seems like it shouldn't be a
decoder.
I agree with Andreas that this seems like it's a demuxer pretending to
be a decoder.
This module transforms the entire raw payload data to generate its output, even if
the syntax is simple which essentially makes it a de-coder. The de-multiplexer
aspect of multiple streams is an academic possibility allowed by the >standard
but not seen in any sample which makes me suspect it's used for carriage between
broadcast facilities rather than something ever sent to an OTT provider, let alone
an end user.
Regards,
Gyan
AFAIK, DolbyE may be found on satellite feeds, for carriage between broadcast facilities, and thus it makes them
accessible so they may be grabbed by "end users". Otherwise, it is "broadcast professional end
users", which are users too. AFAIK, its most common form is 20Bits and you simply "cannot" have a single
stream in a 20Bit carrier; but indeed, most of the time only the first stream ("program") is used and the
second is a downmix; but not always. For example, you can have a first program which is standard 5.1 and a second
program with Audio Description.
In the samples I have, including yours, the outermost layer is AES3
which contains one inner stream Dolby-E, which in turn contains 8
channels constituting multiple programs. Those are programs downstream
of the dolby_e decoder. That's not what we are talking about. The
discussion here is about multiple payload streams within the AES3 layer
- streams stored in subframe mode e.g. a Dolby-E and AC-3 or LPCM in
alternate subframes/frames. I've no such samples of that sort.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/wavenc: use strtoull for UMID conversion
Existing use of strtoll can lead to ERANGE errors leading to incorrect
storage of UMID.
---
libavformat/wavenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 82acb9ef0f..a41f40b449 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -129,7 +129,7 @@ static void bwf_write_bext_chunk(AVFormatContext *s)
for (i = 0; i < len/16; i++) {
memcpy(umidpart_str, tmp_tag->value + 2 + (i*16), 16);
-umidpart = strtoll(umidpart_str, NULL, 16);
+umidpart = strtoull(umidpart_str, NULL, 16);
avio_wb64(s->pb, umidpart);
}
ffio_fill(s->pb, 0, 64 - i*8);
--
2.39.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/2] avcodec/s302m: enable non-PCM decoding
On 2024-01-28 04:24 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2024-01-26 05:23:50) On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote: Gyan Doshi: On 2024-01-25 10:29 am, Andreas Rheinhardt wrote: Gyan Doshi: Set up framework for non-PCM decoding in-place and add support for Dolby-E decoding. Useful for direct transcoding of non-PCM audio in live inputs. --- configure | 1 + doc/decoders.texi | 40 +++ libavcodec/s302m.c | 609 + 3 files changed, 543 insertions(+), 107 deletions(-) diff --git a/configure b/configure index c8ae0a061d..8db3fa3f4b 100755 --- a/configure +++ b/configure @@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder" rv20_encoder_select="h263_encoder" rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" +s302m_decoder_select="dolby_e_decoder" screenpresso_decoder_deps="zlib" shorten_decoder_select="bswapdsp" sipr_decoder_select="lsp" diff --git a/doc/decoders.texi b/doc/decoders.texi index 293c82c2ba..9f85c876bf 100644 --- a/doc/decoders.texi +++ b/doc/decoders.texi @@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build with An FFmpeg native decoder for Opus exists, so users can decode Opus without this library. +@section s302m + +SMPTE ST 302 decoder. + +SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport +Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a +bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz. +They can also contain non-PCM codec streams such as AC-3 or Dolby-E. + This sounds like we should add bitstream filters to extract the proper underlying streams instead. (I see only two problems with this approach: The BSF API needs to set the CodecID of the output during init, but at this point no packet has reached the BSF to determine it. And changing codec IDs mid-stream is also not supported.) In theory, this decoder shouldn't exist, as it is just a carrier, whether of LPCM or non-PCM. FFmpeg architecture also imposes a fundamental limitation in that one s302m stream may carry multiple payload streams and we support only one decoding context per input stream Then why does the demuxer not separate the data into multiple streams? I didn't add demuxing support for this codec in MPEGTS, but I can venture a) it would mean essentially inlining this decoder in the demuxer. Why is that a problem? This decoder seems like it shouldn't be a decoder. I agree with Andreas that this seems like it's a demuxer pretending to be a decoder. This module transforms the entire raw payload data to generate its output, even if the syntax is simple which essentially makes it a de-coder. The de-multiplexer aspect of multiple streams is an academic possibility allowed by the standard but not seen in any sample which makes me suspect it's used for carriage between broadcast facilities rather than something ever sent to an OTT provider, let alone an end user. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] fate: add tests for dolby_e decoding in s302m
Three tests, one each for 1) 16-bit Dolby-E words in 20-bits AES3 words 2) 20-bit Dolby-E words in 20-bits AES3 words 3) 20-bit Dolby-E words in 24-bits AES3 words --- tests/fate/acodec.mak | 15 ++ tests/ref/acodec/s302m-20-dolbye-16 | 221 tests/ref/acodec/s302m-20-dolbye-20 | 127 tests/ref/acodec/s302m-24-dolbye-20 | 170 + 4 files changed, 533 insertions(+) create mode 100644 tests/ref/acodec/s302m-20-dolbye-16 create mode 100644 tests/ref/acodec/s302m-20-dolbye-20 create mode 100644 tests/ref/acodec/s302m-24-dolbye-20 diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak index 7b09e3bd63..60d3b8515b 100644 --- a/tests/fate/acodec.mak +++ b/tests/fate/acodec.mak @@ -165,6 +165,21 @@ fate-acodec-s302m: CODEC = s302m fate-acodec-s302m: ENCOPTS = -af aresample=48000:tsf=s16p -strict -2 fate-acodec-s302m: DECOPTS = -af aresample=44100:tsf=s16p +FATE_ACODEC-$(call FRAMECRC, MPEGTS, S302M DOLBY_E) += fate-acodec-s302m-20-dolbye-16 +fate-acodec-s302m-20-dolbye-16: CMD = framecrc -auto_conversion_filters \ + -non_pcm_mode decode_copy -i $(TARGET_SAMPLES)/s302m/s302_20bits_DolbyE_16bits.ts \ + -vn -c:a pcm_s16le + +FATE_ACODEC-$(call FRAMECRC, MPEGTS, S302M DOLBY_E) += fate-acodec-s302m-20-dolbye-20 +fate-acodec-s302m-20-dolbye-20: CMD = framecrc -auto_conversion_filters \ + -non_pcm_mode decode_copy -i $(TARGET_SAMPLES)/s302m/s302_20bits_DolbyE_20bits.ts \ + -vn -c:a pcm_s16le + +FATE_ACODEC-$(call FRAMECRC, MPEGTS, S302M DOLBY_E) += fate-acodec-s302m-24-dolbye-20 +fate-acodec-s302m-24-dolbye-20: CMD = framecrc -auto_conversion_filters \ + -non_pcm_mode decode_copy -i $(TARGET_SAMPLES)/s302m/s302_24bits_DolbyE_20bits.ts \ + -vn -c:a pcm_s16le + FATE_ACODEC-$(call ENCDEC, WAVPACK, WV, ARESAMPLE_FILTER) += fate-acodec-wavpack fate-acodec-wavpack: FMT = wv fate-acodec-wavpack: CODEC = wavpack -compression_level 1 diff --git a/tests/ref/acodec/s302m-20-dolbye-16 b/tests/ref/acodec/s302m-20-dolbye-16 new file mode 100644 index 00..e0c7b9e13b --- /dev/null +++ b/tests/ref/acodec/s302m-20-dolbye-16 @@ -0,0 +1,221 @@ +#tb 0: 1/44800 +#media_type 0: audio +#codec_id 0: pcm_s16le +#sample_rate 0: 44800 +#channel_layout_name 0: 5.1(side) +0, 0, 0, 1792,21504, 0x9136aa8a +0, 1792, 1792, 1792,21504, 0x6b8b42f0 +0, 3584, 3584, 1792,21504, 0xc73c0342 +0, 5376, 5376, 1792,21504, 0x9d777e2a +0, 7168, 7168, 1792,21504, 0x2ee86c97 +0, 8960, 8960, 1792,21504, 0xfdd41829 +0, 10752, 10752, 1792,21504, 0x58ea1b12 +0, 12544, 12544, 1792,21504, 0xa81a35f4 +0, 14336, 14336, 1792,21504, 0x2bd9bb62 +0, 16128, 16128, 1792,21504, 0x0648940e +0, 17920, 17920, 1792,21504, 0x377452f9 +0, 19712, 19712, 1792,21504, 0xf50f26b9 +0, 21504, 21504, 1792,21504, 0x935e7c69 +0, 23296, 23296, 1792,21504, 0x99363659 +0, 25088, 25088, 1792,21504, 0x78212dd2 +0, 26880, 26880, 1792,21504, 0x687f5776 +0, 28672, 28672, 1792,21504, 0xd6d3320c +0, 30464, 30464, 1792,21504, 0x96e1b731 +0, 32256, 32256, 1792,21504, 0xbb0b9cd9 +0, 34048, 34048, 1792,21504, 0x819db403 +0, 35840, 35840, 1792,21504, 0xa95c859a +0, 37632, 37632, 1792,21504, 0xd9cd11cc +0, 39424, 39424, 1792,21504, 0xe7a3abbf +0, 41216, 41216, 1792,21504, 0x975e4ddc +0, 43008, 43008, 1792,21504, 0x329af143 +0, 44800, 44800, 1792,21504, 0x9bb6281b +0, 46592, 46592, 1792,21504, 0x96cc0fa8 +0, 48384, 48384, 1792,21504, 0xaae03a7d +0, 50176, 50176, 1792,21504, 0x2a5d6225 +0, 51968, 51968, 1792,21504, 0xf7cc19f5 +0, 53760, 53760, 1792,21504, 0x89e85e67 +0, 2, 2, 1792,21504, 0x607ab65e +0, 57344, 57344, 1792,21504, 0x95c0ad8f +0, 59136, 59136, 1792,21504, 0x6b9e8b96 +0, 60928, 60928, 1792,21504, 0x7b83696c +0, 62720, 62720, 1792,21504, 0xac0b6fbf +0, 64512, 64512, 1792,21504, 0xfa249f22 +0, 66304, 66304, 1792,21504, 0x51acbb93 +0, 68096, 68096, 1792,21504, 0xd77b34be +0, 69888, 69888, 1792,21504, 0xd5494a86 +0, 71680, 71680, 1792,21504, 0xd83c3d91 +0, 73472, 73472, 1792,21504, 0xa476ccd8 +0, 75264, 75264, 1792,21504, 0x2aafc337 +0, 77056, 77056, 1792,21504, 0xeee70084 +0, 78848, 78848, 1792,21504, 0xd60a3c93 +0, 80640, 80640, 1792,21504, 0x43ac0f84 +0
[FFmpeg-devel] [PATCH v2 1/2] avcodec/s302m: enable non-PCM decoding
Set up framework for non-PCM decoding in-place and
add support for Dolby-E decoding.
Useful for direct transcoding of non-PCM audio in live inputs.
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m.c | 596 +
3 files changed, 530 insertions(+), 107 deletions(-)
v2:
switch to pointer for non-pcm sync search
use intreadwrite macro for writing frame data
remove unneeded free of non-pcm dec opts
diff --git a/configure b/configure
index 21663000f8..4d7cd83247 100755
--- a/configure
+++ b/configure
@@ -2980,6 +2980,7 @@ rv20_decoder_select="h263_decoder"
rv20_encoder_select="h263_encoder"
rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
+s302m_decoder_select="dolby_e_decoder"
screenpresso_decoder_deps="zlib"
shorten_decoder_select="bswapdsp"
sipr_decoder_select="lsp"
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 293c82c2ba..9f85c876bf 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build
with
An FFmpeg native decoder for Opus exists, so users can decode Opus
without this library.
+@section s302m
+
+SMPTE ST 302 decoder.
+
+SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport
+Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a
+bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
+They can also contain non-PCM codec streams such as AC-3 or Dolby-E.
+
+Decoding non-PCM streams directly requires that the necessary stream decoder be
+present in the build. At present, only Dolby-E decoding is supported.
+
+@subsection Options
+
+The following options are supported by the s302m decoder.
+
+@table @option
+@item non_pcm_mode @var{mode}
+Specify how to process non-PCM streams
+
+@table @samp
+@item copy
+Treat data as if it were LPCM.
+@item drop
+Discard the stream.
+@item decode_copy
+Decode if possible eise treat the same as @code{copy}.
+@item decode_drop
+Decode if possible eise treat the same as @code{drop}.
+@end table
+
+The default value is @code{decode_drop}. This option does not affect the
processing of
+LPCM streams.
+
+@item non_pcm_options @var{options}
+Set options for non-PCM decoder using a list of key=value pairs separated by
":".
+Consult the docs for the non-PCM decoder for its options.
+
+@end table
+
@c man end AUDIO DECODERS
@chapter Subtitles Decoders
diff --git a/libavcodec/s302m.c b/libavcodec/s302m.c
index f1b41608f3..d890b6f117 100644
--- a/libavcodec/s302m.c
+++ b/libavcodec/s302m.c
@@ -24,21 +24,264 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "libavutil/log.h"
+#include "libavutil/dict.h"
#include "libavutil/reverse.h"
#include "avcodec.h"
#include "codec_internal.h"
+#include "get_bits.h"
#include "decode.h"
#define AES3_HEADER_LEN 4
+#define NONPCMSYNC_16MARKER 0x4E1F0F8720
+#define NONPCMSYNC_20MARKER 0x4E1F60F872A0
+#define NONPCMSYNC_24MARKER 0x7E1F690F872A50
+
+#define NONPCMSYNC_16_IN_20MARKER 0x04E1F00F8720
+#define NONPCMSYNC_20_IN_24MARKER 0x04E1F600F872A0
+
+#define IS_NONPCMSYNC_16(state) ((state & 0x00) ==
NONPCMSYNC_16MARKER)
+#define IS_NONPCMSYNC_20(state) ((state & 0xF0F0) ==
NONPCMSYNC_20MARKER)
+#define IS_NONPCMSYNC_24(state) ((state & 0xFF0FF0) ==
NONPCMSYNC_24MARKER)
+
+#define IS_NONPCMSYNC_16_IN_20(state) ((state & 0x0000) ==
NONPCMSYNC_16_IN_20MARKER)
+#define IS_NONPCMSYNC_20_IN_24(state) ((state & 0x0F00F0) ==
NONPCMSYNC_20_IN_24MARKER)
+
+#define IS_NONPCMSYNC(bit,state) ( ((bit == 16) && IS_NONPCMSYNC_16(state))
|| \
+((bit == 20) && (IS_NONPCMSYNC_20(state)
|| IS_NONPCMSYNC_16_IN_20(state))) || \
+((bit == 24) && (IS_NONPCMSYNC_24(state)
|| IS_NONPCMSYNC_20_IN_24(state))) \
+ )
+
+enum non_pcm_modes {
+NON_PCM_COPY,
+NON_PCM_DROP,
+NON_PCM_DEC_ELSE_COPY,
+NON_PCM_DEC_ELSE_DROP,
+};
+
typedef struct S302Context {
AVClass *class;
+
+int avctx_props_set;
+
+int channels;
+int bits;
+
int non_pcm_mode;
+int non_pcm_data_type;
+int non_pcm_bits;
+int non_pcm_dec;
+
+AVCodecContext *non_pcm_ctx;
+AVDictionary *non_pcm_opts;
+AVPacket *packet;
+AVFrame *frame;
} S302Context;
+static av_cold int s302m_init(AVCodecContext *avctx)
+{
+S302Context *s = avctx->priv_data;
+
+s->non_pcm_data_type = -1;
+
+return 0;
+}
+
+static int s302m_non_pcm_inspect(AVCodecContext *avctx, const uint8_t *buf,
int buf_size,
+ int *offset, int *length)
+{
+S302Context *s = avctx->priv_data;
+const uint8_t *pos = buf;
+int ret, aes_frm_size, data_type, length_code = 0, pkt_left = buf_size;
+uint64_
[FFmpeg-devel] [PATCH] avfilter/buffersrc: limit link variance logs below debug loglevel
The video param change check will print loglines below debug level
for each frame which is different from the inlink parameters. This
can spam the console. It is now printed at warning level once for
each param change else it is kept at debug level.
Partially addresses #10823
---
libavfilter/buffersrc.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index afe69433b2..6e450ff6b7 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -49,10 +49,10 @@ typedef struct BufferSourceContext {
unsigned nb_failed_requests;
/* video only */
-int w, h;
-enum AVPixelFormat pix_fmt;
-enum AVColorSpace color_space;
-enum AVColorRange color_range;
+int w, h, prev_w, prev_h;
+enum AVPixelFormat pix_fmt, prev_pix_fmt;
+enum AVColorSpace color_space, prev_color_space;
+enum AVColorRange color_range, prev_color_range;
AVRationalpixel_aspect;
AVBufferRef *hw_frames_ctx;
@@ -66,16 +66,30 @@ typedef struct BufferSourceContext {
int eof;
int64_t last_pts;
+int link_delta, prev_delta;
} BufferSourceContext;
#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, csp, range, pts)\
-if (c->w != width || c->h != height || c->pix_fmt != format ||\
-c->color_space != csp || c->color_range != range) {\
-av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d csp: %s
range: %s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time:
%s\n",\
+c->link_delta = c->w != width || c->h != height || c->pix_fmt != format ||\
+c->color_space != csp || c->color_range != range;\
+c->prev_delta = c->prev_w != width || c->prev_h != height ||
c->prev_pix_fmt != format ||\
+c->prev_color_space != csp || c->prev_color_range !=
range;\
+if (c->link_delta) {\
+int loglevel = c->prev_delta ? AV_LOG_WARNING : AV_LOG_DEBUG;\
+av_log(s, loglevel, "Changing video frame properties on the fly is not
supported by all filters.\n");\
+av_log(s, loglevel, "filter context - w: %d h: %d fmt: %d csp: %s
range: %s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time:
%s\n",\
c->w, c->h, c->pix_fmt, av_color_space_name(c->color_space),
av_color_range_name(c->color_range),\
width, height, format, av_color_space_name(csp),
av_color_range_name(range),\
av_ts2timestr(pts, &s->outputs[0]->time_base));\
-av_log(s, AV_LOG_WARNING, "Changing video frame properties on the fly
is not supported by all filters.\n");\
+}\
+if (c->prev_delta) {\
+if (!c->link_delta)\
+av_log(s, AV_LOG_VERBOSE, "video frame properties congruent with
link at pts_time: %s\n", av_ts2timestr(pts, &s->outputs[0]->time_base));\
+c->prev_w = width;\
+c->prev_h = height;\
+c->prev_pix_fmt = format;\
+c->prev_color_space = csp;\
+c->prev_color_range = range;\
}
#define CHECK_AUDIO_PARAM_CHANGE(s, c, srate, layout, format, pts)\
@@ -111,12 +125,12 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
switch (ctx->filter->outputs[0].type) {
case AVMEDIA_TYPE_VIDEO:
if (param->format != AV_PIX_FMT_NONE) {
-s->pix_fmt = param->format;
+s->pix_fmt = s->prev_pix_fmt = param->format;
}
if (param->width > 0)
-s->w = param->width;
+s->w = s->prev_w = param->width;
if (param->height > 0)
-s->h = param->height;
+s->h = s->prev_h = param->height;
if (param->sample_aspect_ratio.num > 0 &&
param->sample_aspect_ratio.den > 0)
s->pixel_aspect = param->sample_aspect_ratio;
if (param->frame_rate.num > 0 && param->frame_rate.den > 0)
@@ -128,9 +142,9 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
return AVERROR(ENOMEM);
}
if (param->color_space != AVCOL_SPC_UNSPECIFIED)
-s->color_space = param->color_space;
+s->color_space = s->prev_color_space = param->color_space;
if (param->color_range != AVCOL_RANGE_UNSPECIFIED)
-s->color_range = param->color_range;
+s->color_range = s->prev_color_range = param->color_range;
break;
case AVMEDIA_TYPE_AUDIO:
if (param->format != AV_SAMPLE_FMT_NONE) {
--
2.39.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/2] avcodec/s302m: enable non-PCM decoding
On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote: Gyan Doshi: On 2024-01-25 10:29 am, Andreas Rheinhardt wrote: Gyan Doshi: Set up framework for non-PCM decoding in-place and add support for Dolby-E decoding. Useful for direct transcoding of non-PCM audio in live inputs. --- configure | 1 + doc/decoders.texi | 40 +++ libavcodec/s302m.c | 609 + 3 files changed, 543 insertions(+), 107 deletions(-) diff --git a/configure b/configure index c8ae0a061d..8db3fa3f4b 100755 --- a/configure +++ b/configure @@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder" rv20_encoder_select="h263_encoder" rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" +s302m_decoder_select="dolby_e_decoder" screenpresso_decoder_deps="zlib" shorten_decoder_select="bswapdsp" sipr_decoder_select="lsp" diff --git a/doc/decoders.texi b/doc/decoders.texi index 293c82c2ba..9f85c876bf 100644 --- a/doc/decoders.texi +++ b/doc/decoders.texi @@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build with An FFmpeg native decoder for Opus exists, so users can decode Opus without this library. +@section s302m + +SMPTE ST 302 decoder. + +SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport +Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a +bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz. +They can also contain non-PCM codec streams such as AC-3 or Dolby-E. + This sounds like we should add bitstream filters to extract the proper underlying streams instead. (I see only two problems with this approach: The BSF API needs to set the CodecID of the output during init, but at this point no packet has reached the BSF to determine it. And changing codec IDs mid-stream is also not supported.) In theory, this decoder shouldn't exist, as it is just a carrier, whether of LPCM or non-PCM. FFmpeg architecture also imposes a fundamental limitation in that one s302m stream may carry multiple payload streams and we support only one decoding context per input stream Then why does the demuxer not separate the data into multiple streams? I didn't add demuxing support for this codec in MPEGTS, but I can venture a) it would mean essentially inlining this decoder in the demuxer. b) it would lead to a mapping of 1 actual to N virtual streams. How would stream_ids be assigned? c) this codec specifies for multiple payloads but I haven't seen an actual sample + + ret = init_get_bits8(&gb, buf, buf_size); + if (ret < 0) + return ret; + + aes_frm_size = (s->bits + 4) * 2 / 8; + if (buf_size < aes_frm_size * 2) // not enough to contain data_type & length_code + return AVERROR_INVALIDDATA; + + state = get_bits64(&gb, aes_frm_size * 8); + + while (!IS_NONPCMSYNC(s->bits,state) && (get_bits_left(&gb) >= 8)) + state = (state << 8) | get_bits(&gb, 8); Reading byte-aligned data with a GetBit context is very suboptimal. What is the performance difference vs. uint8 pointers? Typically worse by a constant factor. But in this scenario (of a few dozen bytes per packet if dolby_e), how significant is it? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM decoding in-place and
add support for Dolby-E decoding.
Useful for direct transcoding of non-PCM audio in live inputs.
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m.c | 609 +
3 files changed, 543 insertions(+), 107 deletions(-)
diff --git a/configure b/configure
index c8ae0a061d..8db3fa3f4b 100755
--- a/configure
+++ b/configure
@@ -2979,6 +2979,7 @@ rv20_decoder_select="h263_decoder"
rv20_encoder_select="h263_encoder"
rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp"
+s302m_decoder_select="dolby_e_decoder"
screenpresso_decoder_deps="zlib"
shorten_decoder_select="bswapdsp"
sipr_decoder_select="lsp"
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 293c82c2ba..9f85c876bf 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -347,6 +347,46 @@ configuration. You need to explicitly configure the build
with
An FFmpeg native decoder for Opus exists, so users can decode Opus
without this library.
+@section s302m
+
+SMPTE ST 302 decoder.
+
+SMPTE ST 302 is a method for storing AES3 data format within an MPEG Transport
+Stream. AES3 streams can contain LPCM streams of 2, 4, 6 or 8 channels with a
+bit depth of 16, 20 or 24-bits at a sample rate of 48 kHz.
+They can also contain non-PCM codec streams such as AC-3 or Dolby-E.
+
This sounds like we should add bitstream filters to extract the proper
underlying streams instead.
(I see only two problems with this approach: The BSF API needs to set
the CodecID of the output during init, but at this point no packet has
reached the BSF to determine it. And changing codec IDs mid-stream is
also not supported.)
In theory, this decoder shouldn't exist, as it is just a carrier,
whether of LPCM or non-PCM.
FFmpeg architecture also imposes a fundamental limitation in that one
s302m stream may
carry multiple payload streams and we support only one decoding context
per input stream
neither can a bsf spawn streams (not sure). So proper, full support
seems not possible.
[...]
+
+ret = init_get_bits8(&gb, buf, buf_size);
+if (ret < 0)
+return ret;
+
+aes_frm_size = (s->bits + 4) * 2 / 8;
+if (buf_size < aes_frm_size * 2) // not enough to contain data_type &
length_code
+return AVERROR_INVALIDDATA;
+
+state = get_bits64(&gb, aes_frm_size * 8);
+
+while (!IS_NONPCMSYNC(s->bits,state) && (get_bits_left(&gb) >= 8))
+state = (state << 8) | get_bits(&gb, 8);
Reading byte-aligned data with a GetBit context is very suboptimal.
What is the performance difference vs. uint8 pointers?
Note that if stream is LPCM or non-decodable non-PCM, this isn't called
again. If it is Dolby-E, the data traversed can typically be measured in
the dozens of bytes. And further on, I do read and skip some
non-byte-aligned lengths.
[...]
+
+if (s->non_pcm_dec)
+for (int i = 0; i < 4; i++)
+*p++ = b[i];
+else {
+*f16++ = (b[0] << 8) |
+ (b[1] ) ;
AV_RB16(b)
Ok.
[...]
+
+for (int ch = 0; ch < s->frame->ch_layout.nb_channels; ch++)
+memcpy(frame->extended_data[ch], s->frame->extended_data[ch],
+ av_get_bytes_per_sample(s->non_pcm_ctx->sample_fmt) *
s->frame->nb_samples);
Would you please explain to me why this extra frame s->frame exists at
all? (Is it just the assert due to the missing FrameDecodeData? If so,
then this should be changed instead.)
Yes, that assert was triggered. I haven't looked into the ramifications
of altering decode_receive_frame_internal and it's out of scope for this
patch.
If you feel strongly about it, I invite you to change that code and I'll
update this patch accordingly.
[...]
+static av_cold int s302m_close(AVCodecContext *avctx)
+{
+S302Context *s = avctx->priv_data;
+
+avcodec_free_context(&s->non_pcm_ctx);
+av_packet_free(&s->packet);
+av_frame_free(&s->frame);
+av_dict_free(&s->non_pcm_opts);
non_pcm_opts is an av_opt-enabled field and is therefore freed generically.
Will remove.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
