[FFmpeg-devel] [PATCH] fftools/ffmpeg: prefer real errors over EOF in err_merge()
Fixes an issue in 6.1 when reading a corrupted file with -xerror would
exit with success. This specific issue is not present in master, but
this should generally be a more robust behaviour.
Reported-by: Andrej Peterka
---
fftools/ffmpeg_utils.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_utils.h b/fftools/ffmpeg_utils.h
index bd225abc38..7939e44cdc 100644
--- a/fftools/ffmpeg_utils.h
+++ b/fftools/ffmpeg_utils.h
@@ -35,11 +35,12 @@ typedef struct Timestamp {
/**
* Merge two return codes - return one of the error codes if at least one of
* them was negative, 0 otherwise.
- * Currently just picks the first one, eventually we might want to do something
- * more sophisticated, like sorting them by priority.
*/
static inline int err_merge(int err0, int err1)
{
+// prefer "real" errors over EOF
+if ((err0 >= 0 || err0 == AVERROR_EOF) && err1 < 0)
+return err1;
return (err0 < 0) ? err0 : FFMIN(err1, 0);
}
--
2.43.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] fate/ffmpeg: Avoid dependency on samples
Creating vsynth_lena.yuv needs the FATE suite, yet several tests in ffmpeg.mak without a dependency on samples used it as input file. Fix this by using vsynth1.yuv (which does not have such a dependency) instead. Also use vsynth1.yuv in fate-shortest to avoid the samples dependency in this test, too. Fixes ticket #10947. Signed-off-by: Andreas Rheinhardt --- tests/fate/ffmpeg.mak | 30 +++ tests/ref/fate/ffmpeg-filter-in-eof | 100 +++ tests/ref/fate/ffmpeg-loopback-decoding | 104 tests/ref/fate/force_key_frames | 8 +- tests/ref/fate/shortest | 100 +++ 5 files changed, 171 insertions(+), 171 deletions(-) diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 49dbba4a6b..dc102750a0 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -16,10 +16,10 @@ fate-ffmpeg-filter_colorkey: CMD = framecrc -auto_conversion_filters -idct simpl FATE_FFMPEG-$(call FILTERFRAMECRC, COLOR) += fate-ffmpeg-lavfi fate-ffmpeg-lavfi: CMD = framecrc -lavfi color=d=1:r=5 -fflags +bitexact -FATE_SAMPLES_FFMPEG-$(call ENCDEC2, MPEG4, RAWVIDEO, AVI, RAWVIDEO_DEMUXER FRAMECRC_MUXER) += fate-force_key_frames -fate-force_key_frames: tests/data/vsynth_lena.yuv +FATE_FFMPEG-$(call ENCDEC2, MPEG4, RAWVIDEO, AVI, RAWVIDEO_DEMUXER FRAMECRC_MUXER) += fate-force_key_frames +fate-force_key_frames: tests/data/vsynth1.yuv fate-force_key_frames: CMD = enc_dec \ - "rawvideo -s 352x288 -pix_fmt yuv420p" tests/data/vsynth_lena.yuv \ + "rawvideo -s 352x288 -pix_fmt yuv420p" tests/data/vsynth1.yuv\ avi "-c mpeg4 -g 240 -qscale 10 -force_key_frames 0.5,0:00:01.5" \ framecrc "" "-skip_frame nokey" @@ -89,12 +89,12 @@ fate-unknown_layout-ac3: CMD = md5 -auto_conversion_filters \ -guess_layout_max 0 -f s32le -ac 1 -ar 44100 -i $(TARGET_PATH)/$(AREF) \ -f ac3 -flags +bitexact -c ac3_fixed -FATE_SAMPLES_FFMPEG-$(call FILTERDEMDEC, AMIX ARESAMPLE SINE, RAWVIDEO, \ +FATE_FFMPEG-$(call FILTERDEMDEC, AMIX ARESAMPLE SINE, RAWVIDEO, \ PCM_S16LE RAWVIDEO, LAVFI_INDEV \ MPEG4_ENCODER AC3_FIXED_ENCODER) \ += fate-shortest -fate-shortest: tests/data/vsynth_lena.yuv -fate-shortest: CMD = framecrc -auto_conversion_filters -f lavfi -i "sine=3000:d=10" -f lavfi -i "sine=1000:d=1" -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -idct simple -f rawvideo -s 352x288 -pix_fmt yuv420p -i $(TARGET_PATH)/tests/data/vsynth_lena.yuv -filter_complex "[0:a:0][1:a:0]amix=inputs=2[audio]" -map 2:v:0 -map "[audio]" -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -idct simple -dct fastint -qscale 10 -threads 1 -c:v mpeg4 -c:a ac3_fixed -shortest +fate-shortest: tests/data/vsynth1.yuv +fate-shortest: CMD = framecrc -auto_conversion_filters -f lavfi -i "sine=3000:d=10" -f lavfi -i "sine=1000:d=1" -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -idct simple -f rawvideo -s 352x288 -pix_fmt yuv420p -i $(TARGET_PATH)/tests/data/vsynth1.yuv -filter_complex "[0:a:0][1:a:0]amix=inputs=2[audio]" -map 2:v:0 -map "[audio]" -sws_flags +accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -idct simple -dct fastint -qscale 10 -threads 1 -c:v mpeg4 -c:a ac3_fixed -shortest # test interleaving video with a sparse subtitle stream FATE_SAMPLES_FFMPEG-$(call ALLYES, COLOR_FILTER, VOBSUB_DEMUXER, MATROSKA_DEMUXER,, \ @@ -242,24 +242,24 @@ FATE_SAMPLES_FFMPEG-$(call FRAMECRC, MOV, , SETTS_BSF) += fate-ffmpeg-bsf-input # Test behaviour when a complex filtergraph returns EOF on one of its inputs, # but other inputs are still active. # cf. #10803 -fate-ffmpeg-filter-in-eof: tests/data/vsynth_lena.yuv -fate-ffmpeg-filter-in-eof: CMD = framecrc \ --f rawvideo -s 352x288 -pix_fmt yuv420p -t 1 -i $(TARGET_PATH)/tests/data/vsynth_lena.yuv \ --f rawvideo -s 352x288 -pix_fmt yuv420p -t 1 -i $(TARGET_PATH)/tests/data/vsynth_lena.yuv \ +fate-ffmpeg-filter-in-eof: tests/data/vsynth1.yuv +fate-ffmpeg-filter-in-eof: CMD = framecrc \ +-f rawvideo -s 352x288 -pix_fmt yuv420p -t 1 -i $(TARGET_PATH)/tests/data/vsynth1.yuv \ +-f rawvideo -s 352x288 -pix_fmt yuv420p -t 1 -i $(TARGET_PATH)/tests/data/vsynth1.yuv \ -filter_complex "[0][1]concat" -c:v rawvideo FATE_FFMPEG-$(call FRAMECRC, RAWVIDEO, RAWVIDEO, CONCAT_FILTER) += fate-ffmpeg-filter-in-eof # Test termination on streamcopy with -t as an output option. -fate-ffmpeg-streamcopy-t: tests/data/vsynth_lena.yuv +fate-ffmpeg-streamcopy-t: tests/data/vsynth1.yuv fate-ffmpeg-streamcopy-t: CMP = null -fate-ffmpeg-streamcopy-t: CMD = ffmpeg \ --stream_loop -1 -f rawvideo -s 352x288 -pix_fmt yuv420p -i
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: mention how to pass options to loopback decoders
Quoting Stefano Sabatini (2024-03-19 15:58:03)
> On date Thursday 2024-03-14 11:12:31 +0100, Anton Khirnov wrote:
> > ---
> > doc/ffmpeg.texi | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index a38ef834e1..801c083705 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -229,12 +229,16 @@ successive integers starting at zero. These indices
> > should then be used to refer
> > to loopback decoders in complex filtergraph link labels, as described in
> > the
> > documentation for @option{-filter_complex}.
> >
>
> > +Decoding AVOptions can be passed to loopback decoders by placing them
> > before
>
> AVOptions => options (rationale: we have only a few references to
> AVOptions and no direct ones in ffmpeg.texi, and there is no need to
> assume arbitrary AV/FF jargon).
This is how these options are described by ffmpeg -h full.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: mention how to pass options to loopback decoders
On date Thursday 2024-03-14 11:12:31 +0100, Anton Khirnov wrote:
> ---
> doc/ffmpeg.texi | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index a38ef834e1..801c083705 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -229,12 +229,16 @@ successive integers starting at zero. These indices
> should then be used to refer
> to loopback decoders in complex filtergraph link labels, as described in the
> documentation for @option{-filter_complex}.
>
> +Decoding AVOptions can be passed to loopback decoders by placing them before
AVOptions => options (rationale: we have only a few references to
AVOptions and no direct ones in ffmpeg.texi, and there is no need to
assume arbitrary AV/FF jargon).
> +@code{-dec}, analogously to input/output options.
> +
> 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]' \
> + -threads 3 -dec 0:0 \
> + -filter_complex '[0:v][dec:0]hstack[stack]' \
>-map '[stack]' -c:v ffv1 OUTPUT
> @end example
>
> @@ -244,11 +248,13 @@ reads an input video and
> (line 2) encodes it with @code{libx264} at low quality;
>
> @item
> -(line 3) decodes this encoded stream and places it side by side with the
> -original input video;
> +(line 3) decodes this encoded stream using 3 threads;
>
> @item
> -(line 4) combined video is then losslessly encoded and written into
> +(line 4) places decoded video side by side with the original input video;
> +
> +@item
> +(line 5) combined video is then losslessly encoded and written into
> @file{OUTPUT}.
LGTM otherwise, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ffmpeg: mention how to pass options to loopback decoders
---
doc/ffmpeg.texi | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a38ef834e1..801c083705 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -229,12 +229,16 @@ successive integers starting at zero. These indices
should then be used to refer
to loopback decoders in complex filtergraph link labels, as described in the
documentation for @option{-filter_complex}.
+Decoding AVOptions can be passed to loopback decoders by placing them before
+@code{-dec}, analogously to input/output options.
+
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]' \
+ -threads 3 -dec 0:0 \
+ -filter_complex '[0:v][dec:0]hstack[stack]' \
-map '[stack]' -c:v ffv1 OUTPUT
@end example
@@ -244,11 +248,13 @@ reads an input video and
(line 2) encodes it with @code{libx264} at low quality;
@item
-(line 3) decodes this encoded stream and places it side by side with the
-original input video;
+(line 3) decodes this encoded stream using 3 threads;
@item
-(line 4) combined video is then losslessly encoded and written into
+(line 4) places decoded video side by side with the original input video;
+
+@item
+(line 5) combined video is then losslessly encoded and written into
@file{OUTPUT}.
@end itemize
--
2.43.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] fate/ffmpeg: add a test for loopback decoding
Signed-off-by: James Almer --- tests/fate/ffmpeg.mak | 7 +++ tests/ref/fate/ffmpeg-loopback-decoding | 57 + 2 files changed, 64 insertions(+) create mode 100644 tests/ref/fate/ffmpeg-loopback-decoding diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 669c878c7f..aab9d103e1 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -254,3 +254,10 @@ fate-ffmpeg-streamcopy-t: CMD = ffmpeg -stream_loop -1 -f rawvideo -s 352x288 -pix_fmt yuv420p -i $(TARGET_PATH)/tests/data/vsynth_lena.yuv \ -c copy -f null -t 1 - FATE_FFMPEG-$(call REMUX, RAWVIDEO) += fate-ffmpeg-streamcopy-t + +# Test loopback decoding and passing the output to a complex graph. +fate-ffmpeg-loopback-decoding: tests/data/vsynth_lena.yuv +fate-ffmpeg-loopback-decoding: CMD = transcode \ +"rawvideo -s 352x288 -pix_fmt yuv420p" $(TARGET_PATH)/tests/data/vsynth_lena.yuv nut \ +"-map 0:v:0 -c:v mpeg2video -f null - -dec 0:0 -filter_complex '[0:v][dec:0]hstack[stack]' -map '[stack]' -c:v ffv1" "" +FATE_FFMPEG-$(call ENCDEC2, MPEG2VIDEO, FFV1, NUT, HSTACK_FILTER PIPE_PROTOCOL FRAMECRC_MUXER) += fate-ffmpeg-loopback-decoding diff --git a/tests/ref/fate/ffmpeg-loopback-decoding b/tests/ref/fate/ffmpeg-loopback-decoding new file mode 100644 index 00..e535b9060f --- /dev/null +++ b/tests/ref/fate/ffmpeg-loopback-decoding @@ -0,0 +1,57 @@ +faefe475118cacc36dff3cab59baa6cf *tests/data/fate/ffmpeg-loopback-decoding.nut +6478832 tests/data/fate/ffmpeg-loopback-decoding.nut +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 704x288 +#sar 0: 0/1 +0, 0, 0,1, 304128, 0xe07dafdd +0, 1, 1,1, 304128, 0xc5734e5d +0, 2, 2,1, 304128, 0x855acdcc +0, 3, 3,1, 304128, 0x4ad94309 +0, 4, 4,1, 304128, 0x174ebea3 +0, 5, 5,1, 304128, 0xdb416da6 +0, 6, 6,1, 304128, 0x72442b79 +0, 7, 7,1, 304128, 0x00ddf9ed +0, 8, 8,1, 304128, 0xe7e7a773 +0, 9, 9,1, 304128, 0x7df26501 +0, 10, 10,1, 304128, 0x4f5a3eb3 +0, 11, 11,1, 304128, 0x1ad35b6c +0, 12, 12,1, 304128, 0xec8e6f56 +0, 13, 13,1, 304128, 0xb237e0ef +0, 14, 14,1, 304128, 0x55b26ce2 +0, 15, 15,1, 304128, 0x22920436 +0, 16, 16,1, 304128, 0x54eea0c0 +0, 17, 17,1, 304128, 0x17113686 +0, 18, 18,1, 304128, 0xeb9ae1af +0, 19, 19,1, 304128, 0x1ba09d4c +0, 20, 20,1, 304128, 0x0100748f +0, 21, 21,1, 304128, 0xcc914570 +0, 22, 22,1, 304128, 0x9bc21952 +0, 23, 23,1, 304128, 0xc118d0af +0, 24, 24,1, 304128, 0x7e4b2df0 +0, 25, 25,1, 304128, 0x1078bff2 +0, 26, 26,1, 304128, 0xeedbeda1 +0, 27, 27,1, 304128, 0x35ac0a1b +0, 28, 28,1, 304128, 0x3644fb76 +0, 29, 29,1, 304128, 0x5efa175c +0, 30, 30,1, 304128, 0x72c14f39 +0, 31, 31,1, 304128, 0xd7c46bb0 +0, 32, 32,1, 304128, 0x20f368ab +0, 33, 33,1, 304128, 0x9bea7ced +0, 34, 34,1, 304128, 0xf1b66b94 +0, 35, 35,1, 304128, 0x3e5e6815 +0, 36, 36,1, 304128, 0x6c2d5e3a +0, 37, 37,1, 304128, 0x763046b0 +0, 38, 38,1, 304128, 0x05f71f4c +0, 39, 39,1, 304128, 0x3db72dff +0, 40, 40,1, 304128, 0x86e34c11 +0, 41, 41,1, 304128, 0x09334889 +0, 42, 42,1, 304128, 0xc8566851 +0, 43, 43,1, 304128, 0x4a7ec9da +0, 44, 44,1, 304128, 0x609a176b +0, 45, 45,1, 304128, 0x98deede0 +0, 46, 46,1, 304128, 0x59ee66a3 +0, 47, 47,1, 304128, 0x0fc5c8c2 +0, 48, 48,1, 304128, 0x0371d7b0 +0, 49, 49,1, 304128, 0xd81c18cf -- 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 v2] ffmpeg: set extra_hw_frames to account for frames held in queues
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
fixed-size pool of frames (common in some hardware APIs where the output
frames must be stored as an array texture) this could lead to the pool
being exhausted and the decoder getting stuck. Fix this by telling the
decoder to allocate additional frames according to the queue size.
---
fftools/ffmpeg_dec.c | 13 +
fftools/ffmpeg_sched.c | 16 +++-
fftools/ffmpeg_sched.h | 12
3 files changed, 40 insertions(+), 1 deletion(-)
On 25/02/2024 16:02, Marton Balint wrote:
On Sun, 25 Feb 2024, Mark Thompson wrote:
On 25/02/2024 15:01, Marton Balint wrote:
On Sun, 25 Feb 2024, Mark Thompson wrote:
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
fixed-size pool of frames (common in some hardware APIs where the output
frames must be stored as an array texture) this could lead to the pool
being exhausted and the decoder getting stuck. Fix this by telling the
decoder to allocate additional frames according to the queue size.
[...]
diff --git a/fftools/ffmpeg_sched.h b/fftools/ffmpeg_sched.h
index 95f9c1d4db..315053ae42 100644
--- a/fftools/ffmpeg_sched.h
+++ b/fftools/ffmpeg_sched.h
@@ -233,6 +233,13 @@ int sch_add_filtergraph(Scheduler *sch, unsigned
nb_inputs, unsigned nb_outputs,
*/
int sch_add_mux(Scheduler *sch, SchThreadFunc func, int (*init)(void *),
void *ctx, int sdp_auto, unsigned thread_queue_size);
+
+/**
+ * Default size of a thread queue, used if thread_queue_size is not set
on a
+ * call to sch_add_mux().
Not precisely, as this thread queue size is used for both frame queues and
packet queues.
Yes, it applies to both - hence the description I added not mentioning frames
or packets.
For some reason I assumed the description implies it is only used in
sched_add_mux().
Ah, I didn't think of reading it like that. Hopefully clearer in this version.
Historically the thread_queue_size option was introduced for packet queues
for demuxed packets, and recently on the output for muxing packets.
If we want to make the frame queue size adjustable as well, I think it
should be a separate option and maybe a separate constant should be added
for its default value.
This part is not changing anything about the queue sizes, it is just moving the
existing magic number hidden in queue_alloc() to a named constant.
I don't have any motivation to make the frame queue size adjustable; I added
the assert so that if someone wants to do that in future they know that they
need to take additional action to avoid breaking some decoders again.
+ */
+#define DEFAULT_THREAD_QUEUE_SIZE 8
Would you prefer that I make distinct DEFAULT_FRAME_THREAD_QUEUE_SIZE and
DEFAULT_PACKET_THREAD_QUEUE_SIZE (both 8?) and replace the magic number in
queue_alloc() with a selection between them based on the type? I have no
strong opinion on that, so I don't mind doing it if you would prefer it.
I think its worth doing.
Sure, here you go.
Thanks,
- Mark
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 8c92b27cc1..0a6c3f46f1 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -1146,6 +1146,19 @@ int dec_open(Decoder **pdec, Scheduler *sch,
goto fail;
}
+if (dp->dec_ctx->hw_device_ctx) {
+// Update decoder extra_hw_frames option to account for the
+// frames held in queues inside the ffmpeg utility. This is
+// called after avcodec_open2() because the user-set value of
+// extra_hw_frames becomes valid in there, and we need to add
+// this on top of it.
+int extra_frames = DEFAULT_FRAME_THREAD_QUEUE_SIZE;
+if (dp->dec_ctx->extra_hw_frames >= 0)
+dp->dec_ctx->extra_hw_frames += extra_frames;
+else
+dp->dec_ctx->extra_hw_frames = extra_frames;
+}
+
ret = check_avoptions(*dec_opts);
if (ret < 0)
goto fail;
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 1144fce958..ce10de682c 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sched.c
@@ -361,7 +361,21 @@ static int queue_alloc(ThreadQueue **ptq, unsigned
nb_streams, unsigned queue_si
ThreadQueue *tq;
ObjPool *op;
-queue_size = queue_size > 0 ? queue_size : 8;
+if (queue_size <= 0) {
+if (type == QUEUE_FRAMES)
+queue_size = DEFAULT_FRAME_THREAD_QUEUE_SIZE;
+else
+queue_size = DEFAULT_PACKET_THREAD_QUEUE_SIZE;
+}
+
+if (type == QUEUE_FRAMES) {
+// This queue length is used in the decoder code to ensure that
+// there are enough entries in fixed-size
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: remove options deprecated before 6.0
Quoting Andreas Rheinhardt (2024-02-21 17:59:16) > Anton Khirnov: > > --- > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > > index 3f21815ba2..669c878c7f 100644 > > --- a/tests/fate/ffmpeg.mak > > +++ b/tests/fate/ffmpeg.mak > > @@ -1,28 +1,3 @@ > > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, > > WAV, MD5_PROTOCOL) += fate-mapchan-6ch-extract-2 > > -fate-mapchan-6ch-extract-2: tests/data/asynth-22050-6.wav > > -fate-mapchan-6ch-extract-2: CMD = ffmpeg -i > > $(TARGET_PATH)/tests/data/asynth-22050-6.wav -map_channel 0.0.0 -fflags > > +bitexact -f wav md5: -map_channel 0.0.1 -fflags +bitexact -f wav md5: > > - > > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN ARESAMPLE, WAV, PCM_S16LE, > > PCM_S16LE, WAV) += fate-mapchan-6ch-extract-2-downmix-mono > > -fate-mapchan-6ch-extract-2-downmix-mono: tests/data/asynth-22050-6.wav > > -fate-mapchan-6ch-extract-2-downmix-mono: CMD = md5 > > -auto_conversion_filters -i $(TARGET_PATH)/tests/data/asynth-22050-6.wav > > -map_channel 0.0.1 -map_channel 0.0.0 -ac 1 -fflags +bitexact -f wav > > - > > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, > > WAV) += fate-mapchan-silent-mono > > -fate-mapchan-silent-mono: tests/data/asynth-22050-1.wav > > -fate-mapchan-silent-mono: CMD = md5 -i > > $(TARGET_PATH)/tests/data/asynth-22050-1.wav -map_channel -1 -map_channel > > 0.0.0 -fflags +bitexact -f wav > > - > > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, > > WAV) += fate-mapchan-2ch-extract-ch0-ch2-trailing > > -fate-mapchan-2ch-extract-ch0-ch2-trailing: tests/data/asynth-44100-2.wav > > -fate-mapchan-2ch-extract-ch0-ch2-trailing: CMD = md5 -i > > $(TARGET_PATH)/tests/data/asynth-44100-2.wav -map_channel 0.0.0 > > -map_channel 0.0.2? -fflags +bitexact -f wav > > - > > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, > > WAV) += fate-mapchan-3ch-extract-ch0-ch2-trailing > > -fate-mapchan-3ch-extract-ch0-ch2-trailing: tests/data/asynth-44100-3.wav > > -fate-mapchan-3ch-extract-ch0-ch2-trailing: CMD = md5 -i > > $(TARGET_PATH)/tests/data/asynth-44100-3.wav -map_channel 0.0.0 > > -map_channel 0.0.2? -fflags +bitexact -f wav > > - > > -FATE_MAPCHAN = $(FATE_MAPCHAN-yes) > > - > > -FATE_FFMPEG += $(FATE_MAPCHAN) > > -fate-mapchan: $(FATE_MAPCHAN) > > - > > FATE_FFMPEG-$(call FILTERFRAMECRC, COLOR) += fate-ffmpeg-filter_complex > > fate-ffmpeg-filter_complex: CMD = framecrc -filter_complex color=d=1:r=5 > > -fflags +bitexact > > > > Will this reduce coverage in the pan filter? According to gcov, no. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: remove options deprecated before 6.0
Anton Khirnov: > --- > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index 3f21815ba2..669c878c7f 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -1,28 +1,3 @@ > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, WAV, > MD5_PROTOCOL) += fate-mapchan-6ch-extract-2 > -fate-mapchan-6ch-extract-2: tests/data/asynth-22050-6.wav > -fate-mapchan-6ch-extract-2: CMD = ffmpeg -i > $(TARGET_PATH)/tests/data/asynth-22050-6.wav -map_channel 0.0.0 -fflags > +bitexact -f wav md5: -map_channel 0.0.1 -fflags +bitexact -f wav md5: > - > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN ARESAMPLE, WAV, PCM_S16LE, > PCM_S16LE, WAV) += fate-mapchan-6ch-extract-2-downmix-mono > -fate-mapchan-6ch-extract-2-downmix-mono: tests/data/asynth-22050-6.wav > -fate-mapchan-6ch-extract-2-downmix-mono: CMD = md5 -auto_conversion_filters > -i $(TARGET_PATH)/tests/data/asynth-22050-6.wav -map_channel 0.0.1 > -map_channel 0.0.0 -ac 1 -fflags +bitexact -f wav > - > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, WAV) > += fate-mapchan-silent-mono > -fate-mapchan-silent-mono: tests/data/asynth-22050-1.wav > -fate-mapchan-silent-mono: CMD = md5 -i > $(TARGET_PATH)/tests/data/asynth-22050-1.wav -map_channel -1 -map_channel > 0.0.0 -fflags +bitexact -f wav > - > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, WAV) > += fate-mapchan-2ch-extract-ch0-ch2-trailing > -fate-mapchan-2ch-extract-ch0-ch2-trailing: tests/data/asynth-44100-2.wav > -fate-mapchan-2ch-extract-ch0-ch2-trailing: CMD = md5 -i > $(TARGET_PATH)/tests/data/asynth-44100-2.wav -map_channel 0.0.0 -map_channel > 0.0.2? -fflags +bitexact -f wav > - > -FATE_MAPCHAN-$(call FILTERDEMDECENCMUX, PAN, WAV, PCM_S16LE, PCM_S16LE, WAV) > += fate-mapchan-3ch-extract-ch0-ch2-trailing > -fate-mapchan-3ch-extract-ch0-ch2-trailing: tests/data/asynth-44100-3.wav > -fate-mapchan-3ch-extract-ch0-ch2-trailing: CMD = md5 -i > $(TARGET_PATH)/tests/data/asynth-44100-3.wav -map_channel 0.0.0 -map_channel > 0.0.2? -fflags +bitexact -f wav > - > -FATE_MAPCHAN = $(FATE_MAPCHAN-yes) > - > -FATE_FFMPEG += $(FATE_MAPCHAN) > -fate-mapchan: $(FATE_MAPCHAN) > - > FATE_FFMPEG-$(call FILTERFRAMECRC, COLOR) += fate-ffmpeg-filter_complex > fate-ffmpeg-filter_complex: CMD = framecrc -filter_complex color=d=1:r=5 > -fflags +bitexact > Will this reduce coverage in the pan filter? - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: remove options deprecated before 6.0
---
Changelog | 1 +
doc/ffmpeg.texi | 75 ---
fftools/ffmpeg.h | 31 --
fftools/ffmpeg_filter.c | 14 -
fftools/ffmpeg_mux.c | 5 --
fftools/ffmpeg_mux_init.c | 75 +--
fftools/ffmpeg_opt.c | 122 --
tests/fate/ffmpeg.mak | 25
8 files changed, 3 insertions(+), 345 deletions(-)
diff --git a/Changelog b/Changelog
index 610ee61dd6..ab95a4b730 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
- a C11-compliant compiler is now required; note that this requirement
will be bumped to C17 in the near future, so consider updating your
build environment if it lacks C17 support
+- removed deprecated ffmpeg CLI options -psnr and -map_channel
version 6.1:
- libaribcaption decoder
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 5a214dd139..bee3cd4c70 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1230,10 +1230,6 @@ list separated with slashes. Two first values are the
beginning and
end frame numbers, last one is quantizer to use if positive, or quality
factor if negative.
-@item -psnr
-Calculate PSNR of compressed frames. This option is deprecated, pass the
-PSNR flag to the encoder instead, using @code{-flags +psnr}.
-
@item -vstats
Dump video coding statistics to @file{vstats_HHMMSS.log}. See the
@ref{vstats_file_format,,vstats file format} section for the format
description.
@@ -1806,77 +1802,6 @@ such streams is attempted.
Allow input streams with unknown type to be copied instead of failing if
copying
such streams is attempted.
-@item -map_channel
[@var{input_file_id}.@var{stream_specifier}.@var{channel_id}|-1][?][:@var{output_file_id}.@var{stream_specifier}]
-This option is deprecated and will be removed. It can be replaced by the
-@var{pan} filter. In some cases it may be easier to use some combination of the
-@var{channelsplit}, @var{channelmap}, or @var{amerge} filters.
-
-Map an audio channel from a given input to an output. If
-@var{output_file_id}.@var{stream_specifier} is not set, the audio channel will
-be mapped on all the audio streams.
-
-Using "-1" instead of
-@var{input_file_id}.@var{stream_specifier}.@var{channel_id} will map a muted
-channel.
-
-A trailing @code{?} will allow the map_channel to be
-optional: if the map_channel matches no channel the map_channel will be
ignored instead
-of failing.
-
-For example, assuming @var{INPUT} is a stereo audio file, you can switch the
-two audio channels with the following command:
-@example
-ffmpeg -i INPUT -map_channel 0.0.1 -map_channel 0.0.0 OUTPUT
-@end example
-
-If you want to mute the first channel and keep the second:
-@example
-ffmpeg -i INPUT -map_channel -1 -map_channel 0.0.1 OUTPUT
-@end example
-
-The order of the "-map_channel" option specifies the order of the channels in
-the output stream. The output channel layout is guessed from the number of
-channels mapped (mono if one "-map_channel", stereo if two, etc.). Using "-ac"
-in combination of "-map_channel" makes the channel gain levels to be updated if
-input and output channel layouts don't match (for instance two "-map_channel"
-options and "-ac 6").
-
-You can also extract each channel of an input to specific outputs; the
following
-command extracts two channels of the @var{INPUT} audio stream (file 0, stream
0)
-to the respective @var{OUTPUT_CH0} and @var{OUTPUT_CH1} outputs:
-@example
-ffmpeg -i INPUT -map_channel 0.0.0 OUTPUT_CH0 -map_channel 0.0.1 OUTPUT_CH1
-@end example
-
-The following example splits the channels of a stereo input into two separate
-streams, which are put into the same output file:
-@example
-ffmpeg -i stereo.wav -map 0:0 -map 0:0 -map_channel 0.0.0:0.0 -map_channel
0.0.1:0.1 -y out.ogg
-@end example
-
-Note that currently each output stream can only contain channels from a single
-input stream; you can't for example use "-map_channel" to pick multiple input
-audio channels contained in different streams (from the same or different
files)
-and merge them into a single output stream. It is therefore not currently
-possible, for example, to turn two separate mono streams into a single stereo
-stream. However splitting a stereo stream into two single channel mono streams
-is possible.
-
-If you need this feature, a possible workaround is to use the @emph{amerge}
-filter. For example, if you need to merge a media (here @file{input.mkv}) with
2
-mono audio streams into one single stereo channel audio stream (and keep the
-video stream), you can use the following command:
-@example
-ffmpeg -i input.mkv -filter_complex "[0:1] [0:2] amerge" -c:a pcm_s16le -c:v
copy output.mkv
-@end example
-
-To map the first two audio channels from the first input, and using the
-trailing @code{?}, ignore the audio channel mapping if the first input is
-mono instead of stereo:
-@example
-ffmpeg -i INPUT -map_channel 0.0.0 -map_channel 0.0.1? OUTPUT
-@end example
-
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: use correct unit prefix symbol for binary scaled byte values
On date Monday 2024-01-29 15:54:27 +0800, 王昊然 wrote:
> Fix bug #10501
>
> Signed-off-by: WHR
> ---
> fftools/ffmpeg.c | 4 ++--
> fftools/ffmpeg_enc.c | 2 +-
> fftools/ffmpeg_mux.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 53df200d1ab..035210a8e90 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -329,7 +329,7 @@ static void ffmpeg_cleanup(int ret)
>
> if (do_benchmark) {
> int maxrss = getmaxrss() / 1024;
> -av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
> +av_log(NULL, AV_LOG_INFO, "bench: maxrss=%iKiB\n", maxrss);
> }
>
> for (i = 0; i < nb_filtergraphs; i++)
> @@ -570,7 +570,7 @@ static void print_report(int is_last_report, int64_t
> timer_start, int64_t cur_ti
> speed = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE
> / t : -1;
>
> if (total_size < 0) av_bprintf(, "size=N/A time=");
> -elseav_bprintf(, "size=%8.0fkB time=", total_size /
> 1024.0);
> +elseav_bprintf(, "size=%8.0fKiB time=", total_size /
> 1024.0);
> if (pts == AV_NOPTS_VALUE) {
> av_bprintf(, "N/A ");
> } else {
> diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
> index 2a7fba0c51f..bc0d3a334d7 100644
> --- a/fftools/ffmpeg_enc.c
> +++ b/fftools/ffmpeg_enc.c
> @@ -612,7 +612,7 @@ static int update_video_stats(OutputStream *ost, const
> AVPacket *pkt, int write_
>
> bitrate = (pkt->size * 8) / av_q2d(enc->time_base) / 1000.0;
> avg_bitrate = (double)(e->data_size * 8) / ti1 / 1000.0;
> -fprintf(vstats_file, "s_size= %8.0fkB time= %0.3f br= %7.1fkbits/s
> avg_br= %7.1fkbits/s ",
> +fprintf(vstats_file, "s_size= %8.0fKiB time= %0.3f br= %7.1fkbits/s
> avg_br= %7.1fkbits/s ",
> (double)e->data_size / 1024, ti1, bitrate, avg_bitrate);
> fprintf(vstats_file, "type= %c\n", av_get_picture_type_char(pict_type));
>
> diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> index ab86abee14f..ee708267c1e 100644
> --- a/fftools/ffmpeg_mux.c
> +++ b/fftools/ffmpeg_mux.c
> @@ -725,8 +725,8 @@ static void mux_final_stats(Muxer *mux)
> }
>
> av_log(of, AV_LOG_INFO,
> - "video:%1.0fkB audio:%1.0fkB subtitle:%1.0fkB other
> streams:%1.0fkB "
> - "global headers:%1.0fkB muxing overhead: %s\n",
> + "video:%1.0fKiB audio:%1.0fKiB subtitle:%1.0fKiB other
> streams:%1.0fKiB "
> + "global headers:%1.0fKiB muxing overhead: %s\n",
> video_size/ 1024.0,
> audio_size/ 1024.0,
> subtitle_size / 1024.0,
LGTM, I'll apply in a few days if I see no comments, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg: use correct unit prefix symbol for binary scaled byte values
Fix bug #10501
Signed-off-by: WHR
---
fftools/ffmpeg.c | 4 ++--
fftools/ffmpeg_enc.c | 2 +-
fftools/ffmpeg_mux.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 53df200d1ab..035210a8e90 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -329,7 +329,7 @@ static void ffmpeg_cleanup(int ret)
if (do_benchmark) {
int maxrss = getmaxrss() / 1024;
-av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
+av_log(NULL, AV_LOG_INFO, "bench: maxrss=%iKiB\n", maxrss);
}
for (i = 0; i < nb_filtergraphs; i++)
@@ -570,7 +570,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
speed = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE /
t : -1;
if (total_size < 0) av_bprintf(, "size=N/A time=");
-elseav_bprintf(, "size=%8.0fkB time=", total_size /
1024.0);
+elseav_bprintf(, "size=%8.0fKiB time=", total_size /
1024.0);
if (pts == AV_NOPTS_VALUE) {
av_bprintf(, "N/A ");
} else {
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 2a7fba0c51f..bc0d3a334d7 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -612,7 +612,7 @@ static int update_video_stats(OutputStream *ost, const
AVPacket *pkt, int write_
bitrate = (pkt->size * 8) / av_q2d(enc->time_base) / 1000.0;
avg_bitrate = (double)(e->data_size * 8) / ti1 / 1000.0;
-fprintf(vstats_file, "s_size= %8.0fkB time= %0.3f br= %7.1fkbits/s avg_br=
%7.1fkbits/s ",
+fprintf(vstats_file, "s_size= %8.0fKiB time= %0.3f br= %7.1fkbits/s
avg_br= %7.1fkbits/s ",
(double)e->data_size / 1024, ti1, bitrate, avg_bitrate);
fprintf(vstats_file, "type= %c\n", av_get_picture_type_char(pict_type));
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index ab86abee14f..ee708267c1e 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -725,8 +725,8 @@ static void mux_final_stats(Muxer *mux)
}
av_log(of, AV_LOG_INFO,
- "video:%1.0fkB audio:%1.0fkB subtitle:%1.0fkB other streams:%1.0fkB
"
- "global headers:%1.0fkB muxing overhead: %s\n",
+ "video:%1.0fKiB audio:%1.0fKiB subtitle:%1.0fKiB other
streams:%1.0fKiB "
+ "global headers:%1.0fKiB muxing overhead: %s\n",
video_size/ 1024.0,
audio_size/ 1024.0,
subtitle_size / 1024.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] fftools/ffmpeg: optimize inter-thread queue sizes
Quoting Andreas Rheinhardt (2024-01-24 20:35:48)
> > diff --git a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > b/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > index bc9b833799..3a3ec96637 100644
> > --- a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > +++ b/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat
> > @@ -33,8 +33,3 @@
> > {\an7}( inaudible radio chatter )
> > >> Safety remains our numb
> >
> > -9
> > -00:00:03,704 --> 00:00:04,004
> > -{\an7}( inaudible radio chatter )
> > ->> Safety remains our number one
> > -
>
> Why does the output of this test change?
Because the feature being tested is semi-broken - exact output depends on the
amount of buffering between the decoder and the muxer. We also get
rare random failures in this test in current master. So far nobody has
suggested a way of fixing it properly.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: optimize inter-thread queue sizes
Anton Khirnov:
> Use 8 packets/frames by default rather than 1, which seems to provide
> better throughput.
>
> Allow -thread_queue_size to set the muxer queue size manually again.
> ---
> fftools/ffmpeg_mux.h | 2 --
> fftools/ffmpeg_mux_init.c| 3 +--
> fftools/ffmpeg_opt.c | 2 +-
> fftools/ffmpeg_sched.c | 15 ++-
> fftools/ffmpeg_sched.h | 4 +++-
> tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat | 5 -
> 6 files changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
> index d0be8a51ea..e1b44142cf 100644
> --- a/fftools/ffmpeg_mux.h
> +++ b/fftools/ffmpeg_mux.h
> @@ -94,8 +94,6 @@ typedef struct Muxer {
>
> AVDictionary *opts;
>
> -int thread_queue_size;
> -
> /* filesize limit expressed in bytes */
> int64_t limit_filesize;
> atomic_int_least64_t last_filesize;
> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
> index 6b5e4f8b3c..8ada837555 100644
> --- a/fftools/ffmpeg_mux_init.c
> +++ b/fftools/ffmpeg_mux_init.c
> @@ -3047,7 +3047,6 @@ int of_open(const OptionsContext *o, const char
> *filename, Scheduler *sch)
> of->start_time = o->start_time;
> of->shortest = o->shortest;
>
> -mux->thread_queue_size = o->thread_queue_size > 0 ? o->thread_queue_size
> : 8;
> mux->limit_filesize= o->limit_filesize;
> av_dict_copy(>opts, o->g->format_opts, 0);
>
> @@ -3081,7 +3080,7 @@ int of_open(const OptionsContext *o, const char
> *filename, Scheduler *sch)
> }
>
> err = sch_add_mux(sch, muxer_thread, mux_check_init, mux,
> - !strcmp(oc->oformat->name, "rtp"));
> + !strcmp(oc->oformat->name, "rtp"),
> o->thread_queue_size);
> if (err < 0)
> return err;
> mux->sch = sch;
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 304c493dcf..7505b0cf90 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -144,7 +144,7 @@ static void init_options(OptionsContext *o)
> o->limit_filesize = INT64_MAX;
> o->chapters_input_file = INT_MAX;
> o->accurate_seek = 1;
> -o->thread_queue_size = -1;
> +o->thread_queue_size = 0;
> o->input_sync_ref = -1;
> o->find_stream_info = 1;
> o->shortest_buf_duration = 10.f;
> diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
> index 4fc5a33941..62a40c6057 100644
> --- a/fftools/ffmpeg_sched.c
> +++ b/fftools/ffmpeg_sched.c
> @@ -218,6 +218,7 @@ typedef struct SchMux {
> */
> atomic_int mux_started;
> ThreadQueue*queue;
> +unsignedqueue_size;
>
> AVPacket *sub_heartbeat_pkt;
> } SchMux;
> @@ -358,6 +359,8 @@ static int queue_alloc(ThreadQueue **ptq, unsigned
> nb_streams, unsigned queue_si
> ThreadQueue *tq;
> ObjPool *op;
>
> +queue_size = queue_size > 0 ? queue_size : 8;
> +
> op = (type == QUEUE_PACKETS) ? objpool_alloc_packets() :
> objpool_alloc_frames();
> if (!op)
> @@ -653,7 +656,7 @@ static const AVClass sch_mux_class = {
> };
>
> int sch_add_mux(Scheduler *sch, SchThreadFunc func, int (*init)(void *),
> -void *arg, int sdp_auto)
> +void *arg, int sdp_auto, unsigned thread_queue_size)
> {
> const unsigned idx = sch->nb_mux;
>
> @@ -667,6 +670,7 @@ int sch_add_mux(Scheduler *sch, SchThreadFunc func, int
> (*init)(void *),
> mux = >mux[idx];
> mux->class = _mux_class;
> mux->init = init;
> +mux->queue_size = thread_queue_size;
>
> task_init(sch, >task, SCH_NODE_TYPE_MUX, idx, func, arg);
>
> @@ -773,7 +777,7 @@ int sch_add_dec(Scheduler *sch, SchThreadFunc func, void
> *ctx,
> if (!dec->send_frame)
> return AVERROR(ENOMEM);
>
> -ret = queue_alloc(>queue, 1, 1, QUEUE_PACKETS);
> +ret = queue_alloc(>queue, 1, 0, QUEUE_PACKETS);
> if (ret < 0)
> return ret;
>
> @@ -813,7 +817,7 @@ int sch_add_enc(Scheduler *sch, SchThreadFunc func, void
> *ctx,
>
> task_init(sch, >task, SCH_NODE_TYPE_ENC, idx, func, ctx);
>
> -ret = queue_alloc(>queue, 1, 1, QUEUE_FRAMES);
> +ret = queue_alloc(>queue, 1, 0, QUEUE_FRAMES);
> if (ret < 0)
> return ret;
>
> @@ -861,7 +865,7 @@ int sch_add_filtergraph(Scheduler *sch, unsigned
> nb_inputs, unsigned nb_outputs,
> if (ret < 0)
> return ret;
>
> -ret = queue_alloc(>queue, fg->nb_inputs + 1, 1, QUEUE_FRAMES);
> +ret = queue_alloc(>queue, fg->nb_inputs + 1, 0, QUEUE_FRAMES);
> if (ret < 0)
> return ret;
>
> @@ -1313,7 +1317,8 @@ int sch_start(Scheduler *sch)
> }
> }
>
> -ret = queue_alloc(>queue, mux->nb_streams, 1, QUEUE_PACKETS);
> +ret =
[FFmpeg-devel] [PATCH] fftools/ffmpeg: optimize inter-thread queue sizes
Use 8 packets/frames by default rather than 1, which seems to provide
better throughput.
Allow -thread_queue_size to set the muxer queue size manually again.
---
fftools/ffmpeg_mux.h | 2 --
fftools/ffmpeg_mux_init.c| 3 +--
fftools/ffmpeg_opt.c | 2 +-
fftools/ffmpeg_sched.c | 15 ++-
fftools/ffmpeg_sched.h | 4 +++-
tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat | 5 -
6 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index d0be8a51ea..e1b44142cf 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -94,8 +94,6 @@ typedef struct Muxer {
AVDictionary *opts;
-int thread_queue_size;
-
/* filesize limit expressed in bytes */
int64_t limit_filesize;
atomic_int_least64_t last_filesize;
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 6b5e4f8b3c..8ada837555 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -3047,7 +3047,6 @@ int of_open(const OptionsContext *o, const char
*filename, Scheduler *sch)
of->start_time = o->start_time;
of->shortest = o->shortest;
-mux->thread_queue_size = o->thread_queue_size > 0 ? o->thread_queue_size :
8;
mux->limit_filesize= o->limit_filesize;
av_dict_copy(>opts, o->g->format_opts, 0);
@@ -3081,7 +3080,7 @@ int of_open(const OptionsContext *o, const char
*filename, Scheduler *sch)
}
err = sch_add_mux(sch, muxer_thread, mux_check_init, mux,
- !strcmp(oc->oformat->name, "rtp"));
+ !strcmp(oc->oformat->name, "rtp"), o->thread_queue_size);
if (err < 0)
return err;
mux->sch = sch;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 304c493dcf..7505b0cf90 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -144,7 +144,7 @@ static void init_options(OptionsContext *o)
o->limit_filesize = INT64_MAX;
o->chapters_input_file = INT_MAX;
o->accurate_seek = 1;
-o->thread_queue_size = -1;
+o->thread_queue_size = 0;
o->input_sync_ref = -1;
o->find_stream_info = 1;
o->shortest_buf_duration = 10.f;
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 4fc5a33941..62a40c6057 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sched.c
@@ -218,6 +218,7 @@ typedef struct SchMux {
*/
atomic_int mux_started;
ThreadQueue*queue;
+unsignedqueue_size;
AVPacket *sub_heartbeat_pkt;
} SchMux;
@@ -358,6 +359,8 @@ static int queue_alloc(ThreadQueue **ptq, unsigned
nb_streams, unsigned queue_si
ThreadQueue *tq;
ObjPool *op;
+queue_size = queue_size > 0 ? queue_size : 8;
+
op = (type == QUEUE_PACKETS) ? objpool_alloc_packets() :
objpool_alloc_frames();
if (!op)
@@ -653,7 +656,7 @@ static const AVClass sch_mux_class = {
};
int sch_add_mux(Scheduler *sch, SchThreadFunc func, int (*init)(void *),
-void *arg, int sdp_auto)
+void *arg, int sdp_auto, unsigned thread_queue_size)
{
const unsigned idx = sch->nb_mux;
@@ -667,6 +670,7 @@ int sch_add_mux(Scheduler *sch, SchThreadFunc func, int
(*init)(void *),
mux = >mux[idx];
mux->class = _mux_class;
mux->init = init;
+mux->queue_size = thread_queue_size;
task_init(sch, >task, SCH_NODE_TYPE_MUX, idx, func, arg);
@@ -773,7 +777,7 @@ int sch_add_dec(Scheduler *sch, SchThreadFunc func, void
*ctx,
if (!dec->send_frame)
return AVERROR(ENOMEM);
-ret = queue_alloc(>queue, 1, 1, QUEUE_PACKETS);
+ret = queue_alloc(>queue, 1, 0, QUEUE_PACKETS);
if (ret < 0)
return ret;
@@ -813,7 +817,7 @@ int sch_add_enc(Scheduler *sch, SchThreadFunc func, void
*ctx,
task_init(sch, >task, SCH_NODE_TYPE_ENC, idx, func, ctx);
-ret = queue_alloc(>queue, 1, 1, QUEUE_FRAMES);
+ret = queue_alloc(>queue, 1, 0, QUEUE_FRAMES);
if (ret < 0)
return ret;
@@ -861,7 +865,7 @@ int sch_add_filtergraph(Scheduler *sch, unsigned nb_inputs,
unsigned nb_outputs,
if (ret < 0)
return ret;
-ret = queue_alloc(>queue, fg->nb_inputs + 1, 1, QUEUE_FRAMES);
+ret = queue_alloc(>queue, fg->nb_inputs + 1, 0, QUEUE_FRAMES);
if (ret < 0)
return ret;
@@ -1313,7 +1317,8 @@ int sch_start(Scheduler *sch)
}
}
-ret = queue_alloc(>queue, mux->nb_streams, 1, QUEUE_PACKETS);
+ret = queue_alloc(>queue, mux->nb_streams, mux->queue_size,
+ QUEUE_PACKETS);
if (ret < 0)
return ret;
diff --git a/fftools/ffmpeg_sched.h b/fftools/ffmpeg_sched.h
index b167d8d158..d12affa69d 100644
--- a/fftools/ffmpeg_sched.h
+++
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Marth64 (2024-01-16 00:51:14) > Hello, I wanted to call out 2 issues that I think are bugs from this, and > that I was able to trace to the exact commit. > > *#1: Concat filter issues: *A user from IRC support reported it, and I was > able to successfully reproduce it. > When using concat filter on multiple inputs alongside -ss (same file or > different file), it doesn't work correctly: output EOF after the first > segment. > https://trac.ffmpeg.org/ticket/10803 Thanks for the report, sent patches that should fix this. > *#2 Wrong duration reported muxing graphical subtitles: *After > re-architecture, ffmpeg CLI is printing incorrect output time and/or N/A > after a job when muxing video with graphical subtitles (have reproduced > with DVD and DVB). Issue is exaggerated with subtitle streams that have > long gap like forced subs. > https://trac.ffmpeg.org/ticket/10792 Hopefully will get to this soonish. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hello, I wanted to call out 2 issues that I think are bugs from this, and that I was able to trace to the exact commit. *#1: Concat filter issues: *A user from IRC support reported it, and I was able to successfully reproduce it. When using concat filter on multiple inputs alongside -ss (same file or different file), it doesn't work correctly: output EOF after the first segment. https://trac.ffmpeg.org/ticket/10803 *#2 Wrong duration reported muxing graphical subtitles: *After re-architecture, ffmpeg CLI is printing incorrect output time and/or N/A after a job when muxing video with graphical subtitles (have reproduced with DVD and DVB). Issue is exaggerated with subtitle streams that have long gap like forced subs. https://trac.ffmpeg.org/ticket/10792 Thank you for your time and this improvement. Respectfully, On Mon, Dec 11, 2023 at 3:06 AM Anton Khirnov wrote: > both should now be fixed in my tree > > -- > Anton Khirnov > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@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/ffmpeg: add missing comma
Signed-off-by: Marth64 --- doc/ffmpeg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index 145cbb1032..bb57aeaef4 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -118,7 +118,7 @@ Encoded packets are then passed to the decoder (unless streamcopy is selected for the stream, see further for a description). The decoder produces uncompressed frames (raw video/PCM audio/...) which can be processed further by filtering (see next section). After filtering, the frames are passed to the -encoder, which encodes them and outputs encoded packets. Finally those are +encoder, which encodes them and outputs encoded packets. Finally, those are passed to the muxer, which writes the encoded packets to the output file. @section Filtering -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
both should now be fixed in my tree -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: fix -copy_ts typo, should be -copyts
On 2023-12-11 09:13 am, Marth64 wrote:
Signed-off-by: Marth64
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6bcedd76d5..36fdaef879 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1861,7 +1861,7 @@ of seconds.
The timestamp discontinuity correction enabled by this option is only
applied to input formats accepting timestamp discontinuity (for which
the @code{AVFMT_TS_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
-is automatically disabled when employing the @code{-copy_ts} option
+is automatically disabled when employing the @code{-copyts} option
(unless wrapping is detected).
If a timestamp discontinuity is detected whose absolute value is
Will apply.
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/ffmpeg: fix -copy_ts typo, should be -copyts
Signed-off-by: Marth64
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6bcedd76d5..36fdaef879 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1861,7 +1861,7 @@ of seconds.
The timestamp discontinuity correction enabled by this option is only
applied to input formats accepting timestamp discontinuity (for which
the @code{AVFMT_TS_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
-is automatically disabled when employing the @code{-copy_ts} option
+is automatically disabled when employing the @code{-copyts} option
(unless wrapping is detected).
If a timestamp discontinuity is detected whose absolute value is
--
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".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: AV_FMT_DISCONT typo should be AVFMT_TS_DISCONT
On date Saturday 2023-12-09 13:17:55 -0600, Marth64 wrote:
> ---
> doc/ffmpeg.texi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 145cbb1032..6bcedd76d5 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -1860,7 +1860,7 @@ of seconds.
>
> The timestamp discontinuity correction enabled by this option is only
> applied to input formats accepting timestamp discontinuity (for which
> -the @code{AV_FMT_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
> +the @code{AVFMT_TS_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
> is automatically disabled when employing the @code{-copy_ts} option
> (unless wrapping is detected).
>
> @@ -1877,7 +1877,7 @@ seconds.
>
> The timestamp correction enabled by this option is only applied to
> input formats not accepting timestamp discontinuity (for which the
> -@code{AV_FMT_DISCONT} flag is not enabled).
> +@code{AVFMT_TS_DISCONT} flag is not enabled).
Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ffmpeg: AV_FMT_DISCONT typo should be AVFMT_TS_DISCONT
---
doc/ffmpeg.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 145cbb1032..6bcedd76d5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1860,7 +1860,7 @@ of seconds.
The timestamp discontinuity correction enabled by this option is only
applied to input formats accepting timestamp discontinuity (for which
-the @code{AV_FMT_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
+the @code{AVFMT_TS_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
is automatically disabled when employing the @code{-copy_ts} option
(unless wrapping is detected).
@@ -1877,7 +1877,7 @@ seconds.
The timestamp correction enabled by this option is only applied to
input formats not accepting timestamp discontinuity (for which the
-@code{AV_FMT_DISCONT} flag is not enabled).
+@code{AVFMT_TS_DISCONT} flag is not enabled).
If a timestamp discontinuity is detected whose absolute value is
greater than @var{threshold}, ffmpeg will drop the PTS/DTS timestamp
--
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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push it in a few days. > > > > I have a case that becomes really non deterministic > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x52e2e323 > > CRC=0x747761ba > > CRC=0x747761ba > > CRC=0x52e2e323 > > CRC=0x9d872a4b > > CRC=0x5f5cacfd > > CRC=0xda55c458 > > CRC=0x2eccf1c8 > > CRC=0x747761ba > > CRC=0x1a4775bd > > > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > > > before: > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > Should now be fixed in my git tree. Another failure: ./ffmpeg -analyzeduration 1M -y -i mm-short.mpg -vcodec copy -vframes 3 tmp.avi [in#0/mpeg @ 0x55f7cf529a40] Unable to send demuxed packet to consumers: Invalid argument [in#0/mpeg @ 0x55f7cf529a40] Task finished with error code: -22 (Invalid argument) [in#0/mpeg @ 0x55f7cf529a40] Terminating thread with return code -22 (Invalid argument) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push it in a few days. > > > > I have a case that becomes really non deterministic > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x52e2e323 > > CRC=0x747761ba > > CRC=0x747761ba > > CRC=0x52e2e323 > > CRC=0x9d872a4b > > CRC=0x5f5cacfd > > CRC=0xda55c458 > > CRC=0x2eccf1c8 > > CRC=0x747761ba > > CRC=0x1a4775bd > > > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > > > before: > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > Should now be fixed in my git tree. Fresh stuck sample: ffmpeg -i tickets/2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 -level 0 file-2531.avi https://trac.ffmpeg.org/raw-attachment/ticket/2531/interlaced_top.wmv thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Michael Niedermayer (2023-12-06 21:21:55) > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > I have a case that becomes really non deterministic > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > -bitexact -t 1 -f crc - ; done > CRC=0x52e2e323 > CRC=0x747761ba > CRC=0x747761ba > CRC=0x52e2e323 > CRC=0x9d872a4b > CRC=0x5f5cacfd > CRC=0xda55c458 > CRC=0x2eccf1c8 > CRC=0x747761ba > CRC=0x1a4775bd > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > before: > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > -bitexact -t 1 -f crc - ; done > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 Should now be fixed in my git tree. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Cosmin Stejerean via ffmpeg-devel (2023-12-06 21:29:11) > There is still a penalty as you could do asetnsamples without multi-threading > and get even higher performance, > but given the general benefits of multi-threading and the fact that it's > possible to increase the performance of this > usecase arbitrarily by using larger and larger frames I think that's an > acceptable tradeoff for this use case. Exactly, I don't think you can reasonably expect a generic transcoder to be optimally performant in all cases. Every major change like this is a tradeoff and we have to pick those that are most broadly useful. A transcoding setup that encodes PCM and throws it away is not particularly useful, and the picture could change quite a lot once you add actual encoding. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote: > Lie. > A summary of your proposal or a link to your suggestion would be appreciated. Without reference we're all shouting in the void. > I guess now that your side holds most of the power the mask is off. > > This mail you just sent should be enough to get you kicked out three > times over. > I actually chuckled at this line :-D But that will not happen, will it? > > Congratulations, you are on track to become FFmpeg's de-facto dictator, > just like you were libav's de-facto dictator and ran it to the ground > with your blatant disregard for users and disrespect for fellow > developers. > I don't think improving the ffmpeg CLI tools shows any "disregard for users" and having code in parallel shows a lot of respect to fellow developers since it makes our life easier. You seem fixed on a crusade of keeping the status quo, but the consensus you speak of is instead to move forward. Yes some very minor use cases might break or see degraded performance, but that's the point of a development branch - so that we can all improve the code before the next stable release > I hope Fabrice keeps control of the domain, so that we can revive FFmpeg > in a few years. > See? this is what i mean, you're still in 2011. It's time to move on Nicolas, for your own sake, and for respect to your fellow developers and the users you hold so dear -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Also, the numbers I'm seeing on my 16-core Ryzen 9 5950X are quite different: * 5.0, your command:speed=3.25e+03x * 5.0, filter_complex: speed=5.29e+03x * 5.1, your command:speed=3.2e+03x * 5.1, filter_complex: speed=5.2e+03x * 6.0, your command:speed=2.44e+03x * 6.0, filter_complex: speed=3.44e+03x * 6.1, your command:speed=1.31e+03x * 6.1, filter_complex: speed=4.06e+03x * threading, your command:speed=3e+03x * threading, filter_complex:speed=4.1e+03x So while there is a drop from 5.0 to post-threading, it is not as dramatic, and threading is actually faster than 6.1. And finally you can get at least an order of magnitude faster by using a larger frame size. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote: > >> In some cases the performance penalty because of threading is quite >> significant: >> >> Example command line: >> >> ffmpeg -f lavfi -i sine -af volume=6dB -f null none >> >> After latest threading changes: speed=810x >> Before latest threading changes: speed=1.13e+03x >> With 6.0 branch: speed=1.43e+03x >> With 5.1 branch: speed=2.92e+03x >> >> This is a significant decline from 5.1, getting slower with each >> release... Is there anything that can be done about this? > > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames Larger frames would definitely help. With the command as is I get 4.75e+03x on 6.0 and 2.81e+03x on latest mutli-threading branch. However when adding asetnsamples this improves considerably. For example using asetnsamples=2048 as follows runs at 5.6e+03x on the multi-threading branch ./ffmpeg -f lavfi -i sine,asetnsamples=2048 -af volume=6dB -f null none and it can be further improved by increasing the asetnsamples values to 4096 for example (9.18e+03x). There is still a penalty as you could do asetnsamples without multi-threading and get even higher performance, but given the general benefits of multi-threading and the fact that it's possible to increase the performance of this usecase arbitrarily by using larger and larger frames I think that's an acceptable tradeoff for this use case. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. I have a case that becomes really non deterministic for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x52e2e323 CRC=0x747761ba CRC=0x747761ba CRC=0x52e2e323 CRC=0x9d872a4b CRC=0x5f5cacfd CRC=0xda55c458 CRC=0x2eccf1c8 CRC=0x747761ba CRC=0x1a4775bd sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ before: for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames > 2) use -filter_complex with no inputs instead of -f lavfi to eliminate >all overhead from demuxing, decoding, and demux-decode/decode-filter >inter-thread communication Or maybe the threading code is just very inefficient because, just like the BufferRef code, it is riddled with unnecessary indirections and dynamic allocations. We will never know because your attitude made sure nobody competent looked at it. But that is not an issue, because you will ignore Marton's objection just like your ignored mine. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > As usual when someone disagrees with him, Nicolas converged to being > utterly unreasonable and deaf to all arguments. I see no point in Ad-hominem attack. > discussing this with him any further and intend to push the set > tomorrow, unless somebody else has substantial objections. > > I've considered asking for a TC vote, Stated intent to act without seeking consensus. > but as he is not suggesting any > viable alternative, Lie. I guess now that your side holds most of the power the mask is off. This mail you just sent should be enough to get you kicked out three times over. But that will not happen, will it? Congratulations, you are on track to become FFmpeg's de-facto dictator, just like you were libav's de-facto dictator and ran it to the ground with your blatant disregard for users and disrespect for fellow developers. I hope Fabrice keeps control of the domain, so that we can revive FFmpeg in a few years. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. > LGTM -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Marton Balint (2023-12-06 20:29:01) > > > On Wed, 6 Dec 2023, Anton Khirnov wrote: > > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > In some cases the performance penalty because of threading is quite > significant: > > Example command line: > > ffmpeg -f lavfi -i sine -af volume=6dB -f null none > > After latest threading changes: speed=810x > Before latest threading changes: speed=1.13e+03x > With 6.0 branch: speed=1.43e+03x > With 5.1 branch: speed=2.92e+03x > > This is a significant decline from 5.1, getting slower with each > release... Is there anything that can be done about this? Would guess this is caused by overhead from tons of tiny frames. So 1) generate larger frames 2) use -filter_complex with no inputs instead of -f lavfi to eliminate all overhead from demuxing, decoding, and demux-decode/decode-filter inter-thread communication -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, 6 Dec 2023, Anton Khirnov wrote: Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. In some cases the performance penalty because of threading is quite significant: Example command line: ffmpeg -f lavfi -i sine -af volume=6dB -f null none After latest threading changes: speed=810x Before latest threading changes: speed=1.13e+03x With 6.0 branch: speed=1.43e+03x With 5.1 branch: speed=2.92e+03x This is a significant decline from 5.1, getting slower with each release... Is there anything that can be done about this? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi all, As usual when someone disagrees with him, Nicolas converged to being utterly unreasonable and deaf to all arguments. I see no point in discussing this with him any further and intend to push the set tomorrow, unless somebody else has substantial objections. I've considered asking for a TC vote, but as he is not suggesting any viable alternative, there is really nothing to vote on. So the purpose of this email is just summarizing the dispute, so others can understand it more easily. The issue concerns sub2video code, which allows converting bitmap subtitles to video streams, mainly for hardsubbing purposes. As subtitles are typically sparse in time, the demuxer that produces the subtitle stream emits "heartbeat" frames that are sent to the filtering code just like real subtitle frames. The code in ffmpeg_filter.c then decides whether these heartbeat frames should be sent to the filtergraph or ignored. The problem is that this decision is currently made in a way that depends on what frames previously arrived on _other_ filtergraph inputs (e.g. on video frames in a graph with a subtitle and a video input). However, the inputs are not synchronized, and the interleaving of frames on different inputs is effectively arbitrary. E.g. it depends on the video decoder delay (and thus on the number of frame threads, when frame threading is used). The reason this arbitrariness has not become a major issue until now, is that it is deterministic for a given run on a given machine (sub2video FATE tests do not use a frame-threaded decoder, and so do not exhibit the problem). With ffmpeg CLI becoming fully parallel, the results become non-deterministic and change from run to run, which forces me to do something about this. My solution in patch 01/10 changes the filtering code to always send the heartbeat frames to the filtergraph. This not only makes the results deterministic, but also improves subtitle timing in FATE tests. Nicolas presented a testcase that consists of taking a video+subtitle streams from a single source, offsetting them against each other by a fixed delay, and overlaying subtitle onto video. After my patch, this results in the filtergraph buffering a number of heartbeat frames proportional to the offset, which causes higher memory consumption. However, * the testcase suffers from the above problem - its output can change significantly depending on the number of decoder frame threads; this is fixed by my patch; * the extra buffering added by the patch is similar to what would be added by the muxer interleaving queue, were the streams remuxed rather than overlaid; * the buffering can be avoided entirely by opening the input twice. I thus consider his argument (that the patch is "breaking" the testcase) invalid, as the testcase is * contrived; * already broken; * actually fixed by my patch. Nicolas has also NOT suggested any viable alternative approach. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > After weeks of discussion, you have NOT suggested any workable > alternative. Indeed. And the reason for that is that all the time I have available on this is spent debunking your libel about the current logic. > Producing unpredictable output generally means broken. > And "my feature produces random data, but needs very little memory for > it" is not a valid argument. In this particular case you are absolutely wrong, probably because of a lack of familiarity with the use of subtitles in the real world. See the explanations in the mail I just sent. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Nicolas George (2023-12-06 13:10:41) > I have offered Anton my help. After weeks of discussion, you have NOT suggested any workable alternative. The single suggestion I did see from you * was already implemented * did not address the issues at all > But first he needs to acknowledge there he is breaking something > instead of pretending it was already broken Producing unpredictable output generally means broken. And "my feature produces random data, but needs very little memory for it" is not a valid argument. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Zhao Zhili (12023-12-06): > For such large patch set, it’s almost impossible to not break any corner case. Yes, that is what review is for. > Considering the improvements the patch set brings into fftools, those corner > cases can be fixed after merge. That means never. No. > And any body can try to figure out a proper fix after merged, rather than > blocking > the patch set and let Anton work on it alone. I have offered Anton my help. But first he needs to acknowledge there he is breaking something instead of pretending it was already broken so that he can ignore the issue entirely and move on with the parts of the code that matter to himself. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
> On Dec 6, 2023, at 18:55, Nicolas George wrote: > > Anton Khirnov (12023-12-06): >> this should hopefully be the last version of this set. If nobody has new >> comments, I will push it in a few days. > > Absolutely not: you cannot push until consensus is reached, and > consensus is not reached since you are still breaking the sparseness of > sub2video frame. I will answer the last mail in the ongoing discussion > soon. For such large patch set, it’s almost impossible to not break any corner case. Considering the improvements the patch set brings into fftools, those corner cases can be fixed after merge. And any body can try to figure out a proper fix after merged, rather than blocking the patch set and let Anton work on it alone. I want to discuss how to deal with libavdevice/SDL2 issue after applying the patch set, not before. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. Absolutely not: you cannot push until consensus is reached, and consensus is not reached since you are still breaking the sparseness of sub2video frame. I will answer the last mail in the ongoing discussion soon. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. Cheers, -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] ffmpeg CLI multithreading
Hi, this is the updated version of the CLI multithreading set. All issues reported in the previous version should be fixed. The -fix_sub_duration_heartbeat option is enabled again, thanks to JEEB for testing. I've now merged the actual conversion patches into the last one, so every patch of the set should work in isolation. If you want to review conversions of individual components, see branch 'ffmpeg_threading' in git://git.khirnov.net/libav Cheers, -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: do not fail on AVERROR(EAGAIN) from choose_output()
This is not an error condition, but would be treated like one if the
program terminates on the next transcode loop iteration because of a
signal or keyboard input.
Fixes #10504
Tested-by: https://github.com/0Ky
---
fftools/ffmpeg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f1c5f40caf..fd2ce1c2d0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1196,6 +1196,7 @@ static int transcode(int *err_rate_exceeded)
if (ret == AVERROR(EAGAIN)) {
reset_eagain();
av_usleep(1);
+ret = 0;
continue;
} else if (ret < 0) {
av_log(NULL, AV_LOG_VERBOSE, "No more output streams to write to,
finishing.\n");
--
2.40.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] fftools/ffmpeg: fix negative timestamps at the beginning of the encoding
On Tue, 4 Jul 2023, Marton Balint wrote:
Also fix a couple of possible overflows while at it.
Fixes the negative initial timestamps in ticket #10358.
Will apply.
Regards,
Marton
Signed-off-by: Marton Balint
---
fftools/ffmpeg.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 435e12a37b..71d4067a6c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -497,11 +497,12 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
int vid;
double bitrate;
double speed;
-int64_t pts = INT64_MIN + 1;
+int64_t pts = AV_NOPTS_VALUE;
static int64_t last_time = -1;
static int first_report = 1;
uint64_t nb_frames_dup = 0, nb_frames_drop = 0;
-int hours, mins, secs, us;
+int mins, secs, us;
+int64_t hours;
const char *hours_sign;
int ret;
float t;
@@ -553,7 +554,8 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
}
/* compute min output value */
if (ost->last_mux_dts != AV_NOPTS_VALUE) {
-pts = FFMAX(pts, ost->last_mux_dts);
+if (pts == AV_NOPTS_VALUE || ost->last_mux_dts > pts)
+pts = ost->last_mux_dts;
if (copy_ts) {
if (copy_ts_first_pts == AV_NOPTS_VALUE && pts > 1)
copy_ts_first_pts = pts;
@@ -566,23 +568,21 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
nb_frames_drop += ost->last_dropped;
}
-secs = FFABS(pts) / AV_TIME_BASE;
-us = FFABS(pts) % AV_TIME_BASE;
-mins = secs / 60;
-secs %= 60;
-hours = mins / 60;
-mins %= 60;
+us= FFABS64U(pts) % AV_TIME_BASE;
+secs = FFABS64U(pts) / AV_TIME_BASE % 60;
+mins = FFABS64U(pts) / AV_TIME_BASE / 60 % 60;
+hours = FFABS64U(pts) / AV_TIME_BASE / 3600;
hours_sign = (pts < 0) ? "-" : "";
-bitrate = pts && total_size >= 0 ? total_size * 8 / (pts / 1000.0) : -1;
-speed = t != 0.0 ? (double)pts / AV_TIME_BASE / t : -1;
+bitrate = pts != AV_NOPTS_VALUE && pts && total_size >= 0 ? total_size * 8
/ (pts / 1000.0) : -1;
+speed = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE /
t : -1;
if (total_size < 0) av_bprintf(, "size=N/A time=");
elseav_bprintf(, "size=%8.0fkB time=", total_size /
1024.0);
if (pts == AV_NOPTS_VALUE) {
av_bprintf(, "N/A ");
} else {
-av_bprintf(, "%s%02d:%02d:%02d.%02d ",
+av_bprintf(, "%s%02"PRId64":%02d:%02d.%02d ",
hours_sign, hours, mins, secs, (100 * us) / AV_TIME_BASE);
}
@@ -603,7 +603,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
} else {
av_bprintf(_script, "out_time_us=%"PRId64"\n", pts);
av_bprintf(_script, "out_time_ms=%"PRId64"\n", pts);
-av_bprintf(_script, "out_time=%s%02d:%02d:%02d.%06d\n",
+av_bprintf(_script, "out_time=%s%02"PRId64":%02d:%02d.%06d\n",
hours_sign, hours, mins, secs, us);
}
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: fix negative timestamps at the beginning of the encoding
Also fix a couple of possible overflows while at it.
Fixes the negative initial timestamps in ticket #10358.
Signed-off-by: Marton Balint
---
fftools/ffmpeg.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 435e12a37b..71d4067a6c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -497,11 +497,12 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
int vid;
double bitrate;
double speed;
-int64_t pts = INT64_MIN + 1;
+int64_t pts = AV_NOPTS_VALUE;
static int64_t last_time = -1;
static int first_report = 1;
uint64_t nb_frames_dup = 0, nb_frames_drop = 0;
-int hours, mins, secs, us;
+int mins, secs, us;
+int64_t hours;
const char *hours_sign;
int ret;
float t;
@@ -553,7 +554,8 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
}
/* compute min output value */
if (ost->last_mux_dts != AV_NOPTS_VALUE) {
-pts = FFMAX(pts, ost->last_mux_dts);
+if (pts == AV_NOPTS_VALUE || ost->last_mux_dts > pts)
+pts = ost->last_mux_dts;
if (copy_ts) {
if (copy_ts_first_pts == AV_NOPTS_VALUE && pts > 1)
copy_ts_first_pts = pts;
@@ -566,23 +568,21 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
nb_frames_drop += ost->last_dropped;
}
-secs = FFABS(pts) / AV_TIME_BASE;
-us = FFABS(pts) % AV_TIME_BASE;
-mins = secs / 60;
-secs %= 60;
-hours = mins / 60;
-mins %= 60;
+us= FFABS64U(pts) % AV_TIME_BASE;
+secs = FFABS64U(pts) / AV_TIME_BASE % 60;
+mins = FFABS64U(pts) / AV_TIME_BASE / 60 % 60;
+hours = FFABS64U(pts) / AV_TIME_BASE / 3600;
hours_sign = (pts < 0) ? "-" : "";
-bitrate = pts && total_size >= 0 ? total_size * 8 / (pts / 1000.0) : -1;
-speed = t != 0.0 ? (double)pts / AV_TIME_BASE / t : -1;
+bitrate = pts != AV_NOPTS_VALUE && pts && total_size >= 0 ? total_size * 8
/ (pts / 1000.0) : -1;
+speed = pts != AV_NOPTS_VALUE && t != 0.0 ? (double)pts / AV_TIME_BASE /
t : -1;
if (total_size < 0) av_bprintf(, "size=N/A time=");
elseav_bprintf(, "size=%8.0fkB time=", total_size /
1024.0);
if (pts == AV_NOPTS_VALUE) {
av_bprintf(, "N/A ");
} else {
-av_bprintf(, "%s%02d:%02d:%02d.%02d ",
+av_bprintf(, "%s%02"PRId64":%02d:%02d.%02d ",
hours_sign, hours, mins, secs, (100 * us) / AV_TIME_BASE);
}
@@ -603,7 +603,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
} else {
av_bprintf(_script, "out_time_us=%"PRId64"\n", pts);
av_bprintf(_script, "out_time_ms=%"PRId64"\n", pts);
-av_bprintf(_script, "out_time=%s%02d:%02d:%02d.%06d\n",
+av_bprintf(_script, "out_time=%s%02"PRId64":%02d:%02d.%06d\n",
hours_sign, hours, mins, secs, us);
}
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ffmpeg: improve -stats_*_fmt documentation
---
doc/ffmpeg.texi | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index c0fa90f381..6769f8d305 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -2145,8 +2145,8 @@ Input frame number. Index of the input frame (i.e. output
by a decoder) that
corresponds to this output frame or packet. -1 if unavailable.
@item tb
-Encoder timebase, as a rational number @var{num/den}. Note that this may be
-different from the timebase used by the muxer.
+Timebase in which this frame/packet's timestamps are expressed, as a rational
+number @var{num/den}. Note that encoder and muxer may use different timebases.
@item tbi
Timebase for @var{ptsi}, as a rational number @var{num/den}. Available when
@@ -2169,31 +2169,39 @@ Presentation time of the frame or packet, as a decimal
number. Equal to
Presentation time of the input frame (see @var{ni}), as a decimal number. Equal
to @var{ptsi} multiplied by @var{tbi}. Printed as inf when not available.
-@item dts
+@item dts (@emph{packet})
Decoding timestamp of the packet, as an integer. Should be multiplied by the
-timebase to compute presentation time. Post-encoding only.
+timebase to compute presentation time.
-@item dt
+@item dt (@emph{packet})
Decoding time of the frame or packet, as a decimal number. Equal to
@var{dts} multiplied by @var{tb}.
-@item sn
-Number of audio samples sent to the encoder so far. Audio and pre-encoding
only.
+@item sn (@emph{frame,audio})
+Number of audio samples sent to the encoder so far.
-@item samp
-Number of audio samples in the frame. Audio and pre-encoding only.
+@item samp (@emph{frame,audio})
+Number of audio samples in the frame.
-@item size
-Size of the encoded packet in bytes. Post-encoding only.
+@item size (@emph{packet})
+Size of the encoded packet in bytes.
-@item br
+@item br (@emph{packet})
Current bitrate in bits per second. Post-encoding only.
-@item abr
+@item abr (@emph{packet})
Average bitrate for the whole stream so far, in bits per second, -1 if it
cannot
be determined at this point. Post-encoding only.
@end table
+Directives tagged with @emph{packet} may only be used with
+@option{-stats_enc_post_fmt} and @option{-stats_mux_pre_fmt}.
+
+Directives tagged with @emph{frame} may only be used with
+@option{-stats_enc_pre_fmt}.
+
+Directives tagged with @emph{audio} may only be used with audio streams.
+
The default format strings are:
@table @option
@item pre-encoding
--
2.40.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] fftools/ffmpeg: rework setting sub2video parameters
On Mon, May 29, 2023 at 02:49:55PM +0200, Anton Khirnov wrote: > Set them in ifilter_parameters_from_dec(), similarly to audio/video > streams. This reduces the extent to which sub2video filters need to be > treated specially. > --- > You can also get the updated tree from ffmpeg_sub2video in my repo > --- > fftools/ffmpeg.c| 6 ++--- > fftools/ffmpeg_demux.c | 21 +++ > fftools/ffmpeg_filter.c | 58 - > 3 files changed, 41 insertions(+), 44 deletions(-) breaks (looks like wrong width/height) after the change from ffmpeg_sub2video corresponding to this patch ./ffmpeg -i ~/tickets/4752/dump_dvbsubtitles.mp4 -y -ss 5 -t 1 -filter_complex '[0:v][0:s]overlay' /tmp/file4752.ts && ffplay /tmp/file4752.ts seems to be in ffmpeg-bugs/trac/ticket4752/dump_dvbsubtitles.mp4 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: rework setting sub2video parameters
Set them in ifilter_parameters_from_dec(), similarly to audio/video
streams. This reduces the extent to which sub2video filters need to be
treated specially.
---
You can also get the updated tree from ffmpeg_sub2video in my repo
---
fftools/ffmpeg.c| 6 ++---
fftools/ffmpeg_demux.c | 21 +++
fftools/ffmpeg_filter.c | 58 -
3 files changed, 41 insertions(+), 44 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4624960c17..e9e60407d2 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -153,9 +153,9 @@ static int sub2video_get_blank_frame(InputStream *ist)
AVFrame *frame = ist->sub2video.frame;
av_frame_unref(frame);
-ist->sub2video.frame->width = ist->dec_ctx->width ? ist->dec_ctx->width
: ist->sub2video.w;
-ist->sub2video.frame->height = ist->dec_ctx->height ? ist->dec_ctx->height
: ist->sub2video.h;
-ist->sub2video.frame->format = AV_PIX_FMT_RGB32;
+frame->width = ist->sub2video.w;
+frame->height = ist->sub2video.h;
+frame->format = AV_PIX_FMT_RGB32;
if ((ret = av_frame_get_buffer(frame, 0)) < 0)
return ret;
memset(frame->data[0], 0, frame->height * frame->linesize[0]);
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 561b4b0002..817ccbbedc 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -1228,6 +1228,27 @@ static void add_input_streams(const OptionsContext *o,
Demuxer *d)
av_log(ist, AV_LOG_FATAL, "Invalid canvas size: %s.\n",
canvas_size);
exit_program(1);
}
+
+/* Compute the size of the canvas for the subtitles stream.
+ If the subtitles codecpar has set a size, use it. Otherwise use
the
+ maximum dimensions of the video streams in the same file. */
+ist->sub2video.w = ist->dec_ctx->width;
+ist->sub2video.h = ist->dec_ctx->height;
+if (!(ist->sub2video.w && ist->sub2video.h)) {
+for (int j = 0; j < ic->nb_streams; j++) {
+AVCodecParameters *par1 = ic->streams[j]->codecpar;
+if (par1->codec_type == AVMEDIA_TYPE_VIDEO) {
+ist->sub2video.w = FFMAX(ist->sub2video.w,
par1->width);
+ist->sub2video.h = FFMAX(ist->sub2video.h,
par1->height);
+}
+}
+}
+
+if (!(ist->sub2video.w && ist->sub2video.h)) {
+ist->sub2video.w = FFMAX(ist->sub2video.w, 720);
+ist->sub2video.h = FFMAX(ist->sub2video.h, 576);
+}
+
break;
}
case AVMEDIA_TYPE_ATTACHMENT:
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 2a73e3a3e3..4b5ccf50bd 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -458,13 +458,13 @@ static int ifilter_bind_ist(InputFilter *ifilter,
InputStream *ist)
InputFilterPriv *ifp = ifp_from_ifilter(ifilter);
int ret;
+ifp->ist = ist;
+ifp->type_src= ist->st->codecpar->codec_type;
+
ret = ist_filter_add(ist, ifilter, filtergraph_is_simple(ifilter->graph));
if (ret < 0)
return ret;
-ifp->ist = ist;
-ifp->type_src= ist->st->codecpar->codec_type;
-
return 0;
}
@@ -1110,38 +1110,6 @@ void check_filter_outputs(void)
static int sub2video_prepare(InputStream *ist, InputFilter *ifilter)
{
-InputFilterPriv *ifp = ifp_from_ifilter(ifilter);
-AVFormatContext *avf = input_files[ist->file_index]->ctx;
-int i, w, h;
-
-/* Compute the size of the canvas for the subtitles stream.
- If the subtitles codecpar has set a size, use it. Otherwise use the
- maximum dimensions of the video streams in the same file. */
-w = ifp->width;
-h = ifp->height;
-if (!(w && h)) {
-for (i = 0; i < avf->nb_streams; i++) {
-if (avf->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
-w = FFMAX(w, avf->streams[i]->codecpar->width);
-h = FFMAX(h, avf->streams[i]->codecpar->height);
-}
-}
-if (!(w && h)) {
-w = FFMAX(w, 720);
-h = FFMAX(h, 576);
-}
-av_log(avf, AV_LOG_INFO, "sub2video: using %dx%d canvas\n", w, h);
-}
-ist->sub2video.w = ifp->width = w;
-ist->sub2video.h = ifp->height = h;
-
-ifp->width = ist->dec_ctx->width ? ist->dec_ctx->width :
ist->sub2video.w;
-ifp->height = ist->dec_ctx->height ? ist->dec_ctx->height :
ist->sub2video.h;
-
-/* rectangles are AV_PIX_FMT_PAL8, but we have no guarantee that the
- palettes for all rectangles are identical or compatible */
-ifp->format = AV_PIX_FMT_RGB32;
-
ist->sub2video.frame = av_frame_alloc();
if (!ist->sub2video.frame)
return AVERROR(ENOMEM);
@@ -1525,7 +1493,7 @@ int
[FFmpeg-devel] [PATCH] fftools/ffmpeg: rework handling -max_error_rate
Replace the decode_error_stat global with a per-input-stream variable.
Also, print an error message when the error rate is exceeded.
---
Now also printing the error rate value.
---
fftools/ffmpeg.c | 33 +
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_demux.c | 5 +++--
3 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 537f287637..414bae1747 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -121,7 +121,6 @@ static int64_t getmaxrss(void);
int64_t nb_frames_dup = 0;
int64_t nb_frames_drop = 0;
-static int64_t decode_error_stat[2];
unsigned nb_output_dumped = 0;
static BenchmarkTimeStamps current_time;
@@ -771,8 +770,8 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
static void check_decode_result(InputStream *ist, int *got_output, int ret)
{
-if (*got_output || ret<0)
-decode_error_stat[ret<0] ++;
+if (ret < 0)
+ist->decode_errors++;
if (ret < 0 && exit_on_error)
exit_program(1);
@@ -1807,14 +1806,15 @@ static int transcode_step(OutputStream *ost)
/*
* The following code is the main loop of the file converter
*/
-static int transcode(void)
+static int transcode(int *err_rate_exceeded)
{
-int ret, i;
+int ret = 0, i;
InputStream *ist;
int64_t timer_start;
print_stream_maps();
+*err_rate_exceeded = 0;
atomic_store(_init_done, 1);
if (stdin_interaction) {
@@ -1855,9 +1855,20 @@ static int transcode(void)
/* at the end of stream, we must flush the decoder buffers */
for (ist = ist_iter(NULL); ist; ist = ist_iter(ist)) {
+float err_rate;
+
if (!input_files[ist->file_index]->eof_reached) {
process_input_packet(ist, NULL, 0);
}
+
+err_rate = (ist->frames_decoded || ist->decode_errors) ?
+ ist->decode_errors / (ist->frames_decoded +
ist->decode_errors) : 0.f;
+if (err_rate > max_error_rate) {
+av_log(ist, AV_LOG_FATAL, "Decode error rate %g exceeds maximum
%g\n",
+ err_rate, max_error_rate);
+*err_rate_exceeded = 1;
+} else if (err_rate)
+av_log(ist, AV_LOG_VERBOSE, "Decode error rate %g\n", err_rate);
}
enc_flush();
@@ -1921,7 +1932,7 @@ static int64_t getmaxrss(void)
int main(int argc, char **argv)
{
-int ret;
+int ret, err_rate_exceeded;
BenchmarkTimeStamps ti;
init_dynload();
@@ -1958,7 +1969,7 @@ int main(int argc, char **argv)
}
current_time = ti = get_benchmark_time_stamps();
-ret = transcode();
+ret = transcode(_rate_exceeded);
if (ret >= 0 && do_benchmark) {
int64_t utime, stime, rtime;
current_time = get_benchmark_time_stamps();
@@ -1969,12 +1980,10 @@ int main(int argc, char **argv)
"bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
utime / 100.0, stime / 100.0, rtime / 100.0);
}
-av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded,
%"PRIu64" decoding errors\n",
- decode_error_stat[0], decode_error_stat[1]);
-if ((decode_error_stat[0] + decode_error_stat[1]) * max_error_rate <
decode_error_stat[1])
-exit_program(69);
-ret = received_nb_signals ? 255 : ret;
+ret = received_nb_signals ? 255 :
+ err_rate_exceeded ? 69 : ret;
+
exit_program(ret);
return ret;
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 3a332768df..87e684a147 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -413,6 +413,7 @@ typedef struct InputStream {
// number of frames/samples retrieved from the decoder
uint64_t frames_decoded;
uint64_t samples_decoded;
+uint64_t decode_errors;
} InputStream;
typedef struct LastFrameDuration {
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index df87e0f30a..401ae1f850 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -786,8 +786,9 @@ static void demux_final_stats(Demuxer *d)
ds->nb_packets, ds->data_size);
if (ist->decoding_needed) {
-av_log(f, AV_LOG_VERBOSE, "%"PRIu64" frames decoded",
- ist->frames_decoded);
+av_log(f, AV_LOG_VERBOSE,
+ "%"PRIu64" frames decoded; %"PRIu64" decode errors",
+ ist->frames_decoded, ist->decode_errors);
if (type == AVMEDIA_TYPE_AUDIO)
av_log(f, AV_LOG_VERBOSE, " (%"PRIu64" samples)",
ist->samples_decoded);
av_log(f, AV_LOG_VERBOSE, "; ");
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ffmpeg: Extend documentation for sws_flags option
On 17/05/2023 15:15, Gyan Doshi wrote: On 2023-05-17 05:22 pm, Tobias Rapp wrote: Clarify that -sws_flags are only applied to simple filtergraphs as a default, not complex filtergraphs. Add a reference to the scaler options. LGTM Regards, Gyan Applied. Thanks for review, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@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/ffmpeg: Extend documentation for sws_flags option
On 2023-05-17 05:22 pm, Tobias Rapp wrote:
Clarify that -sws_flags are only applied to simple filtergraphs as a
default, not complex filtergraphs. Add a reference to the scaler
options.
LGTM
Regards,
Gyan
---
doc/ffmpeg.texi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a12700e..c0fa90f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1023,7 +1023,12 @@ If @var{pix_fmt} is a single @code{+}, ffmpeg selects
the same pixel format
as the input (or graph output) and automatic conversions are disabled.
@item -sws_flags @var{flags} (@emph{input/output})
-Set SwScaler flags.
+Set default flags for the libswscale library. These flags are used by
+automatically inserted @code{scale} filters and those within simple
+filtergraphs, if not overridden within the filtergraph definition.
+
+See the @ref{scaler_options,,ffmpeg-scaler manual,ffmpeg-scaler} for a list
+of scaler options.
@item -rc_override[:@var{stream_specifier}] @var{override} (@emph{output,per-stream})
Rate control override for specific intervals, formatted as "int,int,int"
___
ffmpeg-devel mailing list
ffmpeg-devel@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/ffmpeg: Extend documentation for sws_flags option
Clarify that -sws_flags are only applied to simple filtergraphs as a
default, not complex filtergraphs. Add a reference to the scaler
options.
---
doc/ffmpeg.texi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a12700e..c0fa90f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1023,7 +1023,12 @@ If @var{pix_fmt} is a single @code{+}, ffmpeg selects
the same pixel format
as the input (or graph output) and automatic conversions are disabled.
@item -sws_flags @var{flags} (@emph{input/output})
-Set SwScaler flags.
+Set default flags for the libswscale library. These flags are used by
+automatically inserted @code{scale} filters and those within simple
+filtergraphs, if not overridden within the filtergraph definition.
+
+See the @ref{scaler_options,,ffmpeg-scaler manual,ffmpeg-scaler} for a list
+of scaler options.
@item -rc_override[:@var{stream_specifier}] @var{override}
(@emph{output,per-stream})
Rate control override for specific intervals, formatted as "int,int,int"
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: rework audio-decode timestamp handling
Stop using InputStream.dts for generating missing timestamps for decoded
frames, because it contains pre-decoding timestamps and there may be
arbitrary amount of delay between input packets and output frames (e.g.
dependent on the thread count when frame threading is used). It is also
in AV_TIME_BASE (i.e. microseconds), which may introduce unnecessary
rounding issues.
New code maintains a timebase that is the inverse of the LCM of all the
samplerates seen so far, and thus can accurately represent every audio
sample. This timebase is used to generate missing timestamps after
decoding.
Changes the result of the following FATE tests
* pcm_dvd-16-5.1-96000
* lavf-smjpeg
* adpcm-ima-smjpeg
In all of these the timestamps now better correspond to actual frame
durations.
---
The branch can also be downloaded as 'ffmpeg_audio_ts' in my tree.
---
fftools/ffmpeg.c| 98 -
fftools/ffmpeg.h| 8 +-
fftools/ffmpeg_demux.c | 6 +-
tests/ref/fate/adpcm-ima-smjpeg | 658 ++--
tests/ref/fate/pcm_dvd-16-5.1-96000 | 8 +-
tests/ref/lavf/smjpeg | 2 +-
6 files changed, 423 insertions(+), 357 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8829a163e0..8dcc70e879 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -881,6 +881,85 @@ static int send_frame_to_filters(InputStream *ist, AVFrame
*decoded_frame)
return ret;
}
+static AVRational audio_samplerate_update(InputStream *ist, const AVFrame
*frame)
+{
+const int prev = ist->last_frame_tb.den;
+const int sr = frame->sample_rate;
+
+AVRational tb_new;
+int64_t gcd;
+
+if (frame->sample_rate == ist->last_frame_sample_rate)
+goto finish;
+
+gcd = av_gcd(prev, sr);
+
+if (prev / gcd >= INT_MAX / sr) {
+av_log(ist, AV_LOG_WARNING,
+ "Audio timestamps cannot be represented exactly after "
+ "sample rate change: %d -> %d\n", prev, sr);
+
+// LCM of 192000, 44100, allows to represent all common samplerates
+tb_new = (AVRational){ 1, 28224000 };
+} else
+tb_new = (AVRational){ 1, prev / gcd * sr };
+
+// keep the frame timebase if it is strictly better than
+// the samplerate-defined one
+if (frame->time_base.num == 1 && frame->time_base.den > tb_new.den &&
+!(frame->time_base.den % tb_new.den))
+tb_new = frame->time_base;
+
+if (ist->last_frame_pts != AV_NOPTS_VALUE)
+ist->last_frame_pts = av_rescale_q(ist->last_frame_pts,
+ ist->last_frame_tb, tb_new);
+ist->last_frame_duration_est = av_rescale_q(ist->last_frame_duration_est,
+ist->last_frame_tb, tb_new);
+
+ist->last_frame_tb = tb_new;
+ist->last_frame_sample_rate = frame->sample_rate;
+
+finish:
+return ist->last_frame_tb;
+}
+
+static void audio_ts_process(InputStream *ist, AVFrame *frame)
+{
+AVRational tb_filter = (AVRational){1, frame->sample_rate};
+AVRational tb;
+int64_t pts_pred;
+
+// on samplerate change, choose a new internal timebase for timestamp
+// generation that can represent timestamps from all the samplerates
+// seen so far
+tb = audio_samplerate_update(ist, frame);
+pts_pred = ist->last_frame_pts == AV_NOPTS_VALUE ? 0 :
+ ist->last_frame_pts + ist->last_frame_duration_est;
+
+if (frame->pts == AV_NOPTS_VALUE) {
+frame->pts = pts_pred;
+frame->time_base = tb;
+} else if (ist->last_frame_pts != AV_NOPTS_VALUE &&
+ frame->pts > av_rescale_q_rnd(pts_pred, tb, frame->time_base,
+ AV_ROUND_UP)) {
+// there was a gap in timestamps, reset conversion state
+ist->filter_in_rescale_delta_last = AV_NOPTS_VALUE;
+}
+
+frame->pts = av_rescale_delta(frame->time_base, frame->pts,
+ tb, frame->nb_samples,
+ >filter_in_rescale_delta_last, tb);
+
+ist->last_frame_pts = frame->pts;
+ist->last_frame_duration_est = av_rescale_q(frame->nb_samples,
+tb_filter, tb);
+
+// finally convert to filtering timebase
+frame->pts = av_rescale_q(frame->pts, tb, tb_filter);
+frame->duration = frame->nb_samples;
+frame->time_base = tb_filter;
+}
+
static int decode_audio(InputStream *ist, AVPacket *pkt, int *got_output,
int *decode_failed)
{
@@ -910,23 +989,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt,
int *got_output,
ist->next_dts += ((int64_t)AV_TIME_BASE * decoded_frame->nb_samples) /
decoded_frame->sample_rate;
-if (decoded_frame->pts == AV_NOPTS_VALUE) {
-decoded_frame->pts = ist->dts;
-decoded_frame->time_base = AV_TIME_BASE_Q;
-}
-if (pkt &&
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: Added ability to set a input burst time before readrate is enforced
Your email client mangled the patch, so it cannot be applied as is.
Quoting Davy Durham (2023-04-07 09:57:54)
> Implemented is the -irb flag (i.e. "initial read burst") that
> causes ffmpeg to read the specified number of seconds of input before a
> given readrate starts to be enforced. All inputs have to reach this
> point before the readrate is enforced. The reason for this change is,
> in the scenario of live-streaming by transcoding from an pre-recorded or
> delayed source to an HLS or DASH webroot, we can more quickly prime the
> system of the first few seconds before the real-world read rate is
> imposed. Else, one must wait for an entire segment length before the
> data can be fetched from the web server.
>
> Signed-off-by: Davy Durham
> ---
> doc/ffmpeg.texi| 2 ++
> fftools/ffmpeg.h | 2 ++
> fftools/ffmpeg_demux.c | 13 -
> fftools/ffmpeg_opt.c | 3 +++
> 4 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index d433d60ce9..a519fea192 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -1709,6 +1709,8 @@ it may cause packet loss.
> It is useful for when flow speed of output packets is important, such
> as live streaming.
> @item -re (@emph{input})
> Read input at native frame rate. This is equivalent to setting
> @code{-readrate 1}.
> +@item -irb @var{seconds}
I think 'irb' is too short for an option that modifies behavior of
another, rather obscure, option. How about -readrate_burst or
-readrate_delay or something along these lines?
> @@ -1159,6 +1160,16 @@ int ifile_open(const OptionsContext *o, const
> char *filename)
> f->rate_emu = 0;
> }
> +f->initial_read_burst = o->initial_read_burst ?
> o->initial_read_burst : 0.0;
> +if (f->initial_read_burst < 0.0) {
> +av_log(NULL, AV_LOG_ERROR, "Option -irb for Input #%d is %0.3f;
Use f as the log context, then you can drop the input file number in the
string itself.
Same below.
Otherwise seems reasonable.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] ?????? [PATCH] fftools/ffmpeg: reset pointer, which could be reused by Android and iOS
Thank you for your reminding, George. I really ignore av_freep() above. Please ignore this patch. // xufuji456 ---- ??: "ffmpeg-devel" 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] fftools/ffmpeg: reset pointer, which could be reused by Android and iOS
"zhilizhao(赵志立)" (12023-03-03): > > av_freep(_files); > > av_freep(_files); > > +input_files = NULL; > > +output_files = NULL; > Until we decided to make ffmpeg cmd works as a library, > it doesn’t matter. It is worse than that: the patch completely ignores the semantic of av_freep(). Useless patch with no explanations at all in the mail => just ignore the mail. > I’m interested on the idea to make fftools > work like a library. But it depends on the community. That would be more or less what an extended libavfilter with movie source and sink would be. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@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] fftools/ffmpeg: reset pointer, which could be reused by Android and iOS
> On Mar 3, 2023, at 14:51, xufuji456 <839789...@qq.com> wrote: > > --- > fftools/ffmpeg.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 743bc0c6b6..0ce9531235 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -569,6 +569,13 @@ static void ffmpeg_cleanup(int ret) > av_freep(_files); > av_freep(_files); > > +nb_input_files= 0; > +nb_output_files = 0; > +nb_filtergraphs = 0; > +input_files = NULL; > +output_files = NULL; > +filtergraphs = NULL; > + Until we decided to make ffmpeg cmd works as a library, it doesn’t matter. I’m interested on the idea to make fftools work like a library. But it depends on the community. https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_929f62ab2f4e5e70082de99ae040769a1...@qq.com/ > uninit_opts(); > > avformat_network_deinit(); > -- > 2.32.0 (Apple Git-132) > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: reset pointer, which could be reused by Android and iOS
--- fftools/ffmpeg.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 743bc0c6b6..0ce9531235 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -569,6 +569,13 @@ static void ffmpeg_cleanup(int ret) av_freep(_files); av_freep(_files); +nb_input_files= 0; +nb_output_files = 0; +nb_filtergraphs = 0; +input_files = NULL; +output_files = NULL; +filtergraphs = NULL; + uninit_opts(); avformat_network_deinit(); -- 2.32.0 (Apple Git-132) ___ ffmpeg-devel mailing list ffmpeg-devel@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/ffmpeg: extend -dts_delta_threshold option description
On date Monday 2023-02-20 18:57:44 +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2023-02-11 03:30:00) > > On date Thursday 2023-02-09 00:41:18 +0100, Michael Niedermayer wrote: > > > On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote: > > [...] > > > > Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and > > > > -dts_delta_error > > > > options > > > > > > > > Review handling of -dts_delta_threshold and -dts_delta_error options, > > > > specify them as floating point expressed in seconds. > > Maybe it's a bit nitpicky, but these are decimal numbers, not floating > point. Fixed and pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@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] fftools/ffmpeg: Added ability to set a input burst time before readrate is enforced
Implemented is the -irb flag (i.e. "initial read burst") that
causes ffmpeg to read the specified number of seconds of input before a
given readrate starts to be enforced. All inputs have to reach this
point before the readrate is enforced. The reason for this change is,
in the scenario of live-streaming by transcoding from an pre-recorded or
delayed source to an HLS or DASH webroot, we can more quickly prime the
system of the first few seconds before the real-world read rate is
imposed. Else, one must wait for an entire segment length before the
data can be fetched from the web server.
Signed-off-by: Davy Durham
---
doc/ffmpeg.texi | 2 ++
fftools/ffmpeg.c | 3 ++-
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 13 +
4 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 767df69b7f..16ab1a336f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1633,6 +1633,8 @@ it may cause packet loss.
It is useful for when flow speed of output packets is important, such
as live streaming.
@item -re (@emph{input})
Read input at native frame rate. This is equivalent to setting
@code{-readrate 1}.
+@item -irb @var{seconds}
+Set an initial read burst time, in seconds, after which any specified
readrate will be enforced.
@item -vsync @var{parameter} (@emph{global})
@itemx -fps_mode[:@var{stream_specifier}] @var{parameter}
(@emph{output,per-stream})
Set video sync method / framerate mode. vsync is applied to all output
video streams
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..e4697c8772 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3768,6 +3768,7 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
(f->start_time != AV_NOPTS_VALUE ?
f->start_time : 0)
);
float scale = f->rate_emu ? 1.0 : f->readrate;
+int64_t burst_until = AV_TIME_BASE * f->initial_read_burst;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
int64_t stream_ts_offset, pts, now;
@@ -3775,7 +3776,7 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
stream_ts_offset = FFMAX(ist->first_dts != AV_NOPTS_VALUE
? ist->first_dts : 0, file_start);
pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
now = (av_gettime_relative() - ist->start) * scale +
stream_ts_offset;
-if (pts > now)
+if (pts - burst_until > now)
return AVERROR(EAGAIN);
}
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 391a35cf50..aa079ab3e9 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -116,6 +116,7 @@ typedef struct OptionsContext {
int loop;
int rate_emu;
float readrate;
+double initial_read_burst;
int accurate_seek;
int thread_queue_size;
int input_sync_ref;
@@ -422,6 +423,7 @@ typedef struct InputFile {
int nb_streams_warn; /* number of streams that the user was
warned of */
int rate_emu;
float readrate;
+double initial_read_burst;
int accurate_seek;
AVPacket *pkt;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 6e18a4a23e..57aa4929fa 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1378,6 +1378,16 @@ static int open_input_file(OptionsContext *o,
const char *filename)
f->rate_emu = 0;
}
+f->initial_read_burst = o->initial_read_burst ?
o->initial_read_burst : 0.0;
+if (f->initial_read_burst < 0.0) {
+av_log(NULL, AV_LOG_ERROR, "Option -irb for Input #%d is %0.3f;
it must be non-negative.\n", nb_input_files, f->initial_read_burst);
+exit_program(1);
+}
+if ((!f->readrate && !f->rate_emu) && f->initial_read_burst) {
+av_log(NULL, AV_LOG_WARNING, "Option -irb ignored since neither
-readrate nor -re were given\n");
+f->initial_read_burst = 0;
+}
+
f->pkt = av_packet_alloc();
if (!f->pkt)
exit_program(1);
@@ -3734,6 +3744,9 @@ const OptionDef options[] = {
{ "readrate", HAS_ARG | OPT_FLOAT | OPT_OFFSET |
OPT_EXPERT | OPT_INPUT, {
.off = OFFSET(readrate) },
"read input at specified rate", "speed" },
+{ "irb",HAS_ARG | OPT_DOUBLE | OPT_OFFSET |
+OPT_EXPERT | OPT_INPUT, {
.off = OFFSET(initial_read_burst) },
+"The initial amount of input to burst read before imposing any
readrate", "seconds" },
{ "target", HAS_ARG | OPT_PERFILE | OPT_OUTPUT, {
.func_arg = opt_target },
"specify target file type (\"vcd\", \"svcd\", \"dvd\", \"dv\"
or \"dv50\" "
"with optional prefixes \"pal-\", \"ntsc-\" or \"film-\")",
"type" },
--
2.25.1
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
Quoting Stefano Sabatini (2023-02-11 03:30:00) > On date Thursday 2023-02-09 00:41:18 +0100, Michael Niedermayer wrote: > > On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote: > [...] > > > Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and > > > -dts_delta_error > > > options > > > > > > Review handling of -dts_delta_threshold and -dts_delta_error options, > > > specify them as floating point expressed in seconds. Maybe it's a bit nitpicky, but these are decimal numbers, not floating point. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
On 2023-02-11 09:58 pm, Stefano Sabatini wrote: On date Saturday 2023-02-11 03:30:00 +0100, Stefano Sabatini wrote: On date Thursday 2023-02-09 00:41:18 +0100, Michael Niedermayer wrote: On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote: [...] Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and -dts_delta_error options Review handling of -dts_delta_threshold and -dts_delta_error options, specify them as floating point expressed in seconds. Also, review and simplify logic. Adjust values for tests, since in some cases the new values does not trigger the correction logic. PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252 --- doc/ffmpeg.texi | 36 --- fftools/ffmpeg.c| 72 - fftools/ffmpeg.h| 2 ++ fftools/ffmpeg_demux.c | 3 ++ tests/fate/filter-audio.mak | 2 +- tests/fate/mpeg4.mak| 2 +- 6 files changed, 77 insertions(+), 40 deletions(-) This seems to break a case with concat and vsync ./ffmpeg -y -i 'concat:///home/michael/videos/angels.mpg|/home/michael/videos/angels.mpg' -vsync 0 -an file.avi ... cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A [mpeg4 @ 0x55e051b8d4c0] Invalid pts (0) <= last (11)00.00 bitrate=N/A speed= 0x [vost#0:0/mpeg4 @ 0x55e051b9d700] Error submitting video frame to the encoder Conversion failed! Ill mail you the angels.mpg, i think its online somewhere but i cant find it Fixed, now the code should be equivalent to the previous implementation. What happened in this case (and apparently in the other fate tests failing), is that some sort of limit correction is applied: detected dts:-0.041711 < dts_limit:0.358789 ts delta 0.5005 applied => ts_offset_discont:0.5005 dts:0.458789 preventing the invalid pts error. The limit correction, hardcoded in the ffmpeg.c code, is completely unrelated to the dts_delta_threshold value, no idea if it would make sense to make this parametric (but at least now it should be a bit more clear from the code/logs). Moving the refactoring changes to a dedicated thread. Updating the doc extensions. 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] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
On date Saturday 2023-02-11 03:30:00 +0100, Stefano Sabatini wrote:
> On date Thursday 2023-02-09 00:41:18 +0100, Michael Niedermayer wrote:
> > On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote:
> [...]
> > > Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and
> > > -dts_delta_error
> > > options
> > >
> > > Review handling of -dts_delta_threshold and -dts_delta_error options,
> > > specify them as floating point expressed in seconds.
> > >
> > > Also, review and simplify logic. Adjust values for tests, since in
> > > some cases the new values does not trigger the correction logic.
> > >
> > > PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
> > > ---
> > > doc/ffmpeg.texi | 36 ---
> > > fftools/ffmpeg.c| 72 -
> > > fftools/ffmpeg.h| 2 ++
> > > fftools/ffmpeg_demux.c | 3 ++
> > > tests/fate/filter-audio.mak | 2 +-
> > > tests/fate/mpeg4.mak| 2 +-
> > > 6 files changed, 77 insertions(+), 40 deletions(-)
> >
> > This seems to break a case with concat and vsync
> > ./ffmpeg -y -i
> > 'concat:///home/michael/videos/angels.mpg|/home/michael/videos/angels.mpg'
> > -vsync 0 -an file.avi
> >
> > ...
> > cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
> > [mpeg4 @ 0x55e051b8d4c0] Invalid pts (0) <= last (11)00.00 bitrate=N/A
> > speed= 0x
> > [vost#0:0/mpeg4 @ 0x55e051b9d700] Error submitting video frame to the
> > encoder
> > Conversion failed!
> >
> >
> > Ill mail you the angels.mpg, i think its online somewhere but i cant
> > find it
>
> Fixed, now the code should be equivalent to the previous
> implementation.
>
> What happened in this case (and apparently in the other fate tests
> failing), is that some sort of limit correction is applied:
>
> detected dts:-0.041711 < dts_limit:0.358789
> ts delta 0.5005 applied => ts_offset_discont:0.5005 dts:0.458789
>
> preventing the invalid pts error.
>
> The limit correction, hardcoded in the ffmpeg.c code, is completely
> unrelated to the dts_delta_threshold value, no idea if it would make
> sense to make this parametric (but at least now it should be a bit
> more clear from the code/logs).
Moving the refactoring changes to a dedicated thread.
Updating the doc extensions.
>From f7df77c9d488fa0f470eba064cdcce915c519ca3 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Sat, 11 Feb 2023 17:18:39 +0100
Subject: [PATCH 3/3] doc/ffmpeg: extend documentation for -dts_delta_threshold
and -dts_error_threshold
PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
---
doc/ffmpeg.texi | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index d9d4b75567..63be7951e6 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1837,12 +1837,38 @@ results, but increase memory use and latency.
The default value is 10 seconds.
-@item -dts_delta_threshold
-Timestamp discontinuity delta threshold.
+@item -dts_delta_threshold @var{threshold}
+Timestamp discontinuity delta threshold, expressed as a floating point
+number of seconds.
+
+The timestamp discontinuity correction enabled by this option is only
+applied to input formats accepting timestamp discontinuity (for which
+the @code{AV_FMT_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
+is automatically disabled when employing the @code{-copy_ts} option
+(unless wrapping is detected).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will remove the discontinuity by
+decreasing/increasing the current DTS and PTS by the corresponding
+delta value.
+
+The default value is 10.
+
@item -dts_error_threshold @var{seconds}
-Timestamp error delta threshold. This threshold use to discard crazy/damaged
-timestamps and the default is 30 hours which is arbitrarily picked and quite
-conservative.
+Timestamp error delta threshold, expressed as a floating point number
+of seconds.
+
+The timestamp correction enabled by this option is only applied to
+input formats not accepting timestamp discontinuity (for which the
+@code{AV_FMT_DISCONT} flag is not enabled).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will drop the PTS/DTS timestamp
+value.
+
+The default value is @code{3600*30} (30 hours), which is arbitrarily
+picked and quite conservative.
+
@item -muxdelay @var{seconds} (@emph{output})
Set the maximum demux-decode delay.
@item -muxpreload @var{seconds} (@emph{output})
--
2.25.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] doc/ffmpeg: extend -dts_delta_threshold option description
On date Thursday 2023-02-09 00:41:18 +0100, Michael Niedermayer wrote:
> On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote:
[...]
> > Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and
> > -dts_delta_error
> > options
> >
> > Review handling of -dts_delta_threshold and -dts_delta_error options,
> > specify them as floating point expressed in seconds.
> >
> > Also, review and simplify logic. Adjust values for tests, since in
> > some cases the new values does not trigger the correction logic.
> >
> > PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
> > ---
> > doc/ffmpeg.texi | 36 ---
> > fftools/ffmpeg.c| 72 -
> > fftools/ffmpeg.h| 2 ++
> > fftools/ffmpeg_demux.c | 3 ++
> > tests/fate/filter-audio.mak | 2 +-
> > tests/fate/mpeg4.mak| 2 +-
> > 6 files changed, 77 insertions(+), 40 deletions(-)
>
> This seems to break a case with concat and vsync
> ./ffmpeg -y -i
> 'concat:///home/michael/videos/angels.mpg|/home/michael/videos/angels.mpg'
> -vsync 0 -an file.avi
>
> ...
> cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
> [mpeg4 @ 0x55e051b8d4c0] Invalid pts (0) <= last (11)00.00 bitrate=N/A speed=
> 0x
> [vost#0:0/mpeg4 @ 0x55e051b9d700] Error submitting video frame to the encoder
> Conversion failed!
>
>
> Ill mail you the angels.mpg, i think its online somewhere but i cant
> find it
Fixed, now the code should be equivalent to the previous
implementation.
What happened in this case (and apparently in the other fate tests
failing), is that some sort of limit correction is applied:
detected dts:-0.041711 < dts_limit:0.358789
ts delta 0.5005 applied => ts_offset_discont:0.5005 dts:0.458789
preventing the invalid pts error.
The limit correction, hardcoded in the ffmpeg.c code, is completely
unrelated to the dts_delta_threshold value, no idea if it would make
sense to make this parametric (but at least now it should be a bit
more clear from the code/logs).
>From 8e23638cbcfcf1e47d4b7d582d4eb12a29ad4f57 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Fri, 1 Apr 2011 01:13:35 +0200
Subject: [PATCH] ffmpeg: review -dts_delta_threshold and -dts_delta_error
options
Review handling of -dts_delta_threshold and -dts_delta_error options
in order to simplify a bit the logic and improve logging.
Also extend documentation.
PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
---
doc/ffmpeg.texi| 36 +---
fftools/ffmpeg.c | 98 ++
fftools/ffmpeg.h | 2 +
fftools/ffmpeg_demux.c | 3 ++
4 files changed, 96 insertions(+), 43 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index d9d4b75567..63be7951e6 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1837,12 +1837,38 @@ results, but increase memory use and latency.
The default value is 10 seconds.
-@item -dts_delta_threshold
-Timestamp discontinuity delta threshold.
+@item -dts_delta_threshold @var{threshold}
+Timestamp discontinuity delta threshold, expressed as a floating point
+number of seconds.
+
+The timestamp discontinuity correction enabled by this option is only
+applied to input formats accepting timestamp discontinuity (for which
+the @code{AV_FMT_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
+is automatically disabled when employing the @code{-copy_ts} option
+(unless wrapping is detected).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will remove the discontinuity by
+decreasing/increasing the current DTS and PTS by the corresponding
+delta value.
+
+The default value is 10.
+
@item -dts_error_threshold @var{seconds}
-Timestamp error delta threshold. This threshold use to discard crazy/damaged
-timestamps and the default is 30 hours which is arbitrarily picked and quite
-conservative.
+Timestamp error delta threshold, expressed as a floating point number
+of seconds.
+
+The timestamp correction enabled by this option is only applied to
+input formats not accepting timestamp discontinuity (for which the
+@code{AV_FMT_DISCONT} flag is not enabled).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will drop the PTS/DTS timestamp
+value.
+
+The default value is @code{3600*30} (30 hours), which is arbitrarily
+picked and quite conservative.
+
@item -muxdelay @var{seconds} (@emph{output})
Set the maximum demux-decode delay.
@item -muxpreload @var{seconds} (@emph{output})
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 064ec6d4b3..e88a78872a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3671,62 +3671,84 @@ static void decode_flush(InputFile *ifile)
static void ts_discontinuity_detect(InputFile *ifile, InputStream *ist,
AVPacket *pkt)
{
-const int fmt_is_discont =
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: rename -enc_stats* to -stats_enc*
On date Thursday 2023-02-09 15:26:43 +0100, Anton Khirnov wrote:
> This is consistent with -stats_mux*
>
> As the options were added very recently, this should not break any
> users.
> ---
> Changelog| 2 +-
> doc/ffmpeg.texi | 20 ++--
> fftools/ffmpeg_opt.c | 12 ++--
> 3 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index bd9fe9922d..11dfd7ef73 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -32,7 +32,7 @@ version :
> - WADY DPCM decoder and demuxer
> - CBD2 DPCM decoder
> - ssim360 video filter
> -- ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt],
> +- ffmpeg CLI new options: -stats_enc_pre[_fmt], -stats_enc_post[_fmt],
>-stats_mux_pre[_fmt]
> - hstack_vaapi, vstack_vaapi and xstack_vaapi filters
> - XMD ADPCM decoder and demuxer
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 076956d128..d9d4b75567 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -2061,30 +2061,30 @@ encoder/muxer, it does not change the stream to
> conform to this value. Setting
> values that do not match the stream properties may result in encoding
> failures
> or invalid output files.
>
> -@item -enc_stats_pre[:@var{stream_specifier}] @var{path}
> (@emph{output,per-stream})
> -@item -enc_stats_post[:@var{stream_specifier}] @var{path}
> (@emph{output,per-stream})
> +@item -stats_enc_pre[:@var{stream_specifier}] @var{path}
> (@emph{output,per-stream})
> +@item -stats_enc_post[:@var{stream_specifier}] @var{path}
> (@emph{output,per-stream})
> @item -stats_mux_pre[:@var{stream_specifier}] @var{path}
> (@emph{output,per-stream})
> Write per-frame encoding information about the matching streams into the file
> given by @var{path}.
>
> -@option{-enc_stats_pre} writes information about raw video or audio frames
> right
> -before they are sent for encoding, while @option{-enc_stats_post} writes
> +@option{-stats_enc_pre} writes information about raw video or audio frames
> right
> +before they are sent for encoding, while @option{-stats_enc_post} writes
> information about encoded packets as they are received from the encoder.
> @option{-stats_mux_pre} writes information about packets just as they are
> about to
> be sent to the muxer. Every frame or packet produces one line in the
> specified
> -file. The format of this line is controlled by @option{-enc_stats_pre_fmt} /
> -@option{-enc_stats_post_fmt} / @option{-stats_mux_pre_fmt}.
> +file. The format of this line is controlled by @option{-stats_enc_pre_fmt} /
> +@option{-stats_enc_post_fmt} / @option{-stats_mux_pre_fmt}.
>
> When stats for multiple streams are written into a single file, the lines
> corresponding to different streams will be interleaved. The precise order of
> this interleaving is not specified and not guaranteed to remain stable
> between
> different invocations of the program, even with the same options.
>
> -@item -enc_stats_pre_fmt[:@var{stream_specifier}] @var{format_spec}
> (@emph{output,per-stream})
> -@item -enc_stats_post_fmt[:@var{stream_specifier}] @var{format_spec}
> (@emph{output,per-stream})
> +@item -stats_enc_pre_fmt[:@var{stream_specifier}] @var{format_spec}
> (@emph{output,per-stream})
> +@item -stats_enc_post_fmt[:@var{stream_specifier}] @var{format_spec}
> (@emph{output,per-stream})
> @item -stats_mux_pre_fmt[:@var{stream_specifier}] @var{format_spec}
> (@emph{output,per-stream})
> -Specify the format for the lines written with @option{-enc_stats_pre} /
> -@option{-enc_stats_post} / @option{-stats_mux_pre}.
> +Specify the format for the lines written with @option{-stats_enc_pre} /
> +@option{-stats_enc_post} / @option{-stats_mux_pre}.
>
> @var{format_spec} is a string that may contain directives of the form
> @var{@{fmt@}}. @var{format_spec} is backslash-escaped --- use \@{, \@}, and
> \\
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index ed7ee6ab7d..055275d813 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -1544,16 +1544,16 @@ const OptionDef options[] = {
> { .off = OFFSET(bits_per_raw_sample) },
> "set the number of bits per raw sample", "number" },
>
> -{ "enc_stats_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
> OPT_STRING, { .off = OFFSET(enc_stats_pre) },
> +{ "stats_enc_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
> OPT_STRING, { .off = OFFSET(enc_stats_pre) },
> "write encoding stats before encoding" },
> -{ "enc_stats_post", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
> OPT_STRING, { .off = OFFSET(enc_stats_post) },
> +{ "stats_enc_post", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
> OPT_STRING, { .off = OFFSET(enc_stats_post) },
> "write encoding stats after encoding" },
> { "stats_mux_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
> OPT_STRING, { .off = OFFSET(mux_stats) },
>
[FFmpeg-devel] [PATCH] fftools/ffmpeg: rename -enc_stats* to -stats_enc*
This is consistent with -stats_mux*
As the options were added very recently, this should not break any
users.
---
Changelog| 2 +-
doc/ffmpeg.texi | 20 ++--
fftools/ffmpeg_opt.c | 12 ++--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Changelog b/Changelog
index bd9fe9922d..11dfd7ef73 100644
--- a/Changelog
+++ b/Changelog
@@ -32,7 +32,7 @@ version :
- WADY DPCM decoder and demuxer
- CBD2 DPCM decoder
- ssim360 video filter
-- ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt],
+- ffmpeg CLI new options: -stats_enc_pre[_fmt], -stats_enc_post[_fmt],
-stats_mux_pre[_fmt]
- hstack_vaapi, vstack_vaapi and xstack_vaapi filters
- XMD ADPCM decoder and demuxer
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 076956d128..d9d4b75567 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -2061,30 +2061,30 @@ encoder/muxer, it does not change the stream to conform
to this value. Setting
values that do not match the stream properties may result in encoding failures
or invalid output files.
-@item -enc_stats_pre[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
-@item -enc_stats_post[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
+@item -stats_enc_pre[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
+@item -stats_enc_post[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
@item -stats_mux_pre[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
Write per-frame encoding information about the matching streams into the file
given by @var{path}.
-@option{-enc_stats_pre} writes information about raw video or audio frames
right
-before they are sent for encoding, while @option{-enc_stats_post} writes
+@option{-stats_enc_pre} writes information about raw video or audio frames
right
+before they are sent for encoding, while @option{-stats_enc_post} writes
information about encoded packets as they are received from the encoder.
@option{-stats_mux_pre} writes information about packets just as they are
about to
be sent to the muxer. Every frame or packet produces one line in the specified
-file. The format of this line is controlled by @option{-enc_stats_pre_fmt} /
-@option{-enc_stats_post_fmt} / @option{-stats_mux_pre_fmt}.
+file. The format of this line is controlled by @option{-stats_enc_pre_fmt} /
+@option{-stats_enc_post_fmt} / @option{-stats_mux_pre_fmt}.
When stats for multiple streams are written into a single file, the lines
corresponding to different streams will be interleaved. The precise order of
this interleaving is not specified and not guaranteed to remain stable between
different invocations of the program, even with the same options.
-@item -enc_stats_pre_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
-@item -enc_stats_post_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
+@item -stats_enc_pre_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
+@item -stats_enc_post_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
@item -stats_mux_pre_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
-Specify the format for the lines written with @option{-enc_stats_pre} /
-@option{-enc_stats_post} / @option{-stats_mux_pre}.
+Specify the format for the lines written with @option{-stats_enc_pre} /
+@option{-stats_enc_post} / @option{-stats_mux_pre}.
@var{format_spec} is a string that may contain directives of the form
@var{@{fmt@}}. @var{format_spec} is backslash-escaped --- use \@{, \@}, and \\
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ed7ee6ab7d..055275d813 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1544,16 +1544,16 @@ const OptionDef options[] = {
{ .off = OFFSET(bits_per_raw_sample) },
"set the number of bits per raw sample", "number" },
-{ "enc_stats_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(enc_stats_pre) },
+{ "stats_enc_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(enc_stats_pre) },
"write encoding stats before encoding" },
-{ "enc_stats_post", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(enc_stats_post) },
+{ "stats_enc_post", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(enc_stats_post) },
"write encoding stats after encoding" },
{ "stats_mux_pre", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(mux_stats) },
"write packets stats before muxing" },
-{ "enc_stats_pre_fmt", HAS_ARG | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT |
OPT_STRING, { .off = OFFSET(enc_stats_pre_fmt) },
-"format of the stats written with -enc_stats_pre" },
-{ "enc_stats_post_fmt", HAS_ARG | OPT_SPEC |
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
On Mon, Feb 06, 2023 at 02:25:23AM +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-01-25 10:47:20 +0530, Gyan Doshi wrote:
> >
> >
> > On 2023-01-25 06:37 am, Stefano Sabatini wrote:
> > > ---
> > > doc/ffmpeg.texi | 17 +++--
> > > 1 file changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > > index 67b3294256..122f7e3387 100644
> > > --- a/doc/ffmpeg.texi
> > > +++ b/doc/ffmpeg.texi
> > > @@ -1823,8 +1823,21 @@ results, but increase memory use and latency.
> > > The default value is 10 seconds.
> > > -@item -dts_delta_threshold
> > > -Timestamp discontinuity delta threshold.
> > > +@item -dts_delta_threshold @var{threshold}
> > > +Timestamp discontinuity delta threshold, expressed as a floating point
> > > +number of @var{AV_TIME_BASE} units.
> > This is a CLI option and those users don't deal with AV_TIME_BASE . More
> > useful to say it's in seconds.
> >
> > > +
> > > +If a timestamp discontinuity is detected whose absolute value is
> > > +greater than @var{threshold} * @var{AV_TIME_BASE}, ffmpeg will remove the
> > > +discontinuity by decreasing/increasing the current DTS and PTS by the
> > > +corresponding delta value.
> >
>
> > Might want to mention that this only applies to AV_FMT_DISCONT demuxers, or
> > rather give a few examples, like MPEG-TS, HLS..etc.
> > For all other formats that users normally work with, clarify that only
> > dts_error_threshold is relevant.
>
>
> > > +
> > > +Timestamp discontinuity correction can be inhibited by setting a big
> > > value for
> > > +@var{threshold}, and is automatically disabled when employing the
> > > +@code{-copy_ts} option.
> >
> > For copy_ts, it is still applied for all negative deltas except the
> > smallest.
>
> Which is a bit arbitrary.
>
> >
> > Not blocking, but I'm reworking this code at present. Shouldn't really
> > affect this patch. See
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305539.html
>
> Updated (had to review the code to get some clarity on the current
> behavior).
>
> Thanks.
> doc/ffmpeg.texi | 36 ++
> fftools/ffmpeg.c| 72
> +++-
> fftools/ffmpeg.h|2 +
> fftools/ffmpeg_demux.c |3 +
> tests/fate/filter-audio.mak |2 -
> tests/fate/mpeg4.mak|2 -
> 6 files changed, 77 insertions(+), 40 deletions(-)
> 55e91624524749274a62bdc43cacdf8e47dd3598
> 0002-ffmpeg-review-dts_delta_threshold-and-dts_delta_erro.patch
> From 30ac56a14d66eb25428b71c9211f401f818bd057 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini
> Date: Fri, 1 Apr 2011 01:13:35 +0200
> Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and -dts_delta_error
> options
>
> Review handling of -dts_delta_threshold and -dts_delta_error options,
> specify them as floating point expressed in seconds.
>
> Also, review and simplify logic. Adjust values for tests, since in
> some cases the new values does not trigger the correction logic.
>
> PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
> ---
> doc/ffmpeg.texi | 36 ---
> fftools/ffmpeg.c| 72 -
> fftools/ffmpeg.h| 2 ++
> fftools/ffmpeg_demux.c | 3 ++
> tests/fate/filter-audio.mak | 2 +-
> tests/fate/mpeg4.mak| 2 +-
> 6 files changed, 77 insertions(+), 40 deletions(-)
This seems to break a case with concat and vsync
./ffmpeg -y -i
'concat:///home/michael/videos/angels.mpg|/home/michael/videos/angels.mpg'
-vsync 0 -an file.avi
...
cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
[mpeg4 @ 0x55e051b8d4c0] Invalid pts (0) <= last (11)00.00 bitrate=N/A speed=
0x
[vost#0:0/mpeg4 @ 0x55e051b9d700] Error submitting video frame to the encoder
Conversion failed!
Ill mail you the angels.mpg, i think its online somewhere but i cant
find it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
On 2023-02-06 06:55 am, Stefano Sabatini wrote: On date Wednesday 2023-01-25 10:47:20 +0530, Gyan Doshi wrote: For copy_ts, it is still applied for all negative deltas except the smallest. Which is a bit arbitrary. Possibly, but I imagine there was some trac ticket which prompted that handling. Does git blame shed any light? 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/ffmpeg: extend -dts_delta_threshold option description
On date Wednesday 2023-01-25 10:47:20 +0530, Gyan Doshi wrote:
>
>
> On 2023-01-25 06:37 am, Stefano Sabatini wrote:
> > ---
> > doc/ffmpeg.texi | 17 +++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 67b3294256..122f7e3387 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -1823,8 +1823,21 @@ results, but increase memory use and latency.
> > The default value is 10 seconds.
> > -@item -dts_delta_threshold
> > -Timestamp discontinuity delta threshold.
> > +@item -dts_delta_threshold @var{threshold}
> > +Timestamp discontinuity delta threshold, expressed as a floating point
> > +number of @var{AV_TIME_BASE} units.
> This is a CLI option and those users don't deal with AV_TIME_BASE . More
> useful to say it's in seconds.
>
> > +
> > +If a timestamp discontinuity is detected whose absolute value is
> > +greater than @var{threshold} * @var{AV_TIME_BASE}, ffmpeg will remove the
> > +discontinuity by decreasing/increasing the current DTS and PTS by the
> > +corresponding delta value.
>
> Might want to mention that this only applies to AV_FMT_DISCONT demuxers, or
> rather give a few examples, like MPEG-TS, HLS..etc.
> For all other formats that users normally work with, clarify that only
> dts_error_threshold is relevant.
> > +
> > +Timestamp discontinuity correction can be inhibited by setting a big value
> > for
> > +@var{threshold}, and is automatically disabled when employing the
> > +@code{-copy_ts} option.
>
> For copy_ts, it is still applied for all negative deltas except the
> smallest.
Which is a bit arbitrary.
>
> Not blocking, but I'm reworking this code at present. Shouldn't really
> affect this patch. See
> https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305539.html
Updated (had to review the code to get some clarity on the current
behavior).
Thanks.
>From 30ac56a14d66eb25428b71c9211f401f818bd057 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Fri, 1 Apr 2011 01:13:35 +0200
Subject: [PATCH 2/2] ffmpeg: review -dts_delta_threshold and -dts_delta_error
options
Review handling of -dts_delta_threshold and -dts_delta_error options,
specify them as floating point expressed in seconds.
Also, review and simplify logic. Adjust values for tests, since in
some cases the new values does not trigger the correction logic.
PR: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8252
---
doc/ffmpeg.texi | 36 ---
fftools/ffmpeg.c| 72 -
fftools/ffmpeg.h| 2 ++
fftools/ffmpeg_demux.c | 3 ++
tests/fate/filter-audio.mak | 2 +-
tests/fate/mpeg4.mak| 2 +-
6 files changed, 77 insertions(+), 40 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 67b3294256..cdd1d7 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1823,12 +1823,38 @@ results, but increase memory use and latency.
The default value is 10 seconds.
-@item -dts_delta_threshold
-Timestamp discontinuity delta threshold.
+@item -dts_delta_threshold @var{threshold}
+Timestamp discontinuity delta threshold, expressed as a floating point
+number of seconds.
+
+The timestamp discontinuity correction enabled by this option is only
+applied to input formats accepting timestamp discontinuity (for which
+the @code{AV_FMT_DISCONT} flag is enabled), e.g. MPEG-TS and HLS, and
+is automatically disabled when employing the @code{-copy_ts} option
+(unless wrapping is detected).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will remove the discontinuity by
+decreasing/increasing the current DTS and PTS by the corresponding
+delta value.
+
+The default value is 10.
+
@item -dts_error_threshold @var{seconds}
-Timestamp error delta threshold. This threshold use to discard crazy/damaged
-timestamps and the default is 30 hours which is arbitrarily picked and quite
-conservative.
+Timestamp error delta threshold, expressed as a floating point number
+of seconds.
+
+The timestamp correction enabled by this option is only applied to
+input formats not accepting timestamp discontinuity (for which the
+@code{AV_FMT_DISCONT} flag is not enabled).
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold}, ffmpeg will drop the PTS/DTS timestamp
+value.
+
+The default value is @code{3600*30} (30 hours), which is arbitrarily
+picked and quite conservative.
+
@item -muxdelay @var{seconds} (@emph{output})
Set the maximum demux-decode delay.
@item -muxpreload @var{seconds} (@emph{output})
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f722ae7632..cc58d98813 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3411,62 +3411,68 @@ static void decode_flush(InputFile *ifile)
static void ts_discontinuity_detect(InputFile *ifile, InputStream *ist,
AVPacket *pkt)
{
-
[FFmpeg-devel] [PATCH] fftools/ffmpeg: fix clearing previous output
Patch attached.
From 95efe0d6d7e6fe5e29e6372f2da38cfbc4453a83 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 29 Jan 2023 20:46:50 +0100
Subject: [PATCH] fftools/ffmpeg: fix clearing previous output
Signed-off-by: Paul B Mahol
---
fftools/ffmpeg.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9884e0c6c6..e39260ee90 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1539,6 +1539,7 @@ static void print_report(int is_last_report, int64_t timer_start, int64_t cur_ti
static int64_t last_time = -1;
static int first_report = 1;
static int qp_histogram[52];
+static int prev_buf_len = -1;
int hours, mins, secs, us;
const char *hours_sign;
int ret;
@@ -1696,11 +1697,14 @@ static void print_report(int is_last_report, int64_t timer_start, int64_t cur_ti
if (print_stats || is_last_report) {
const char end = is_last_report ? '\n' : '\r';
+if (prev_buf_len < 0)
+prev_buf_len = buf.len;
if (print_stats==1 && AV_LOG_INFO > av_log_get_level()) {
fprintf(stderr, "%s%c", buf.str, end);
} else
-av_log(NULL, AV_LOG_INFO, "%s%c", buf.str, end);
+av_log(NULL, AV_LOG_INFO, "%s%*c%c", buf.str, -FFMAX(0, buf.len - prev_buf_len), ' ', end);
+prev_buf_len = buf.len;
fflush(stderr);
}
av_bprint_finalize(, NULL);
--
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".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: add options for writing encoding stats
Similar to -vstats, but more flexible:
- works for audio as well as video
- frame and/or packet information
- user-specifiable format
---
doc/ffmpeg.texi | 88 +++
fftools/ffmpeg.c | 63 ++-
fftools/ffmpeg.h | 44
fftools/ffmpeg_mux.c | 8 ++
fftools/ffmpeg_mux_init.c | 224 ++
fftools/ffmpeg_opt.c | 9 ++
6 files changed, 433 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 67b3294256..1c7e65479c 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -2047,6 +2047,94 @@ encoder/muxer, it does not change the stream to conform
to this value. Setting
values that do not match the stream properties may result in encoding failures
or invalid output files.
+@item -enc_stats_pre[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
+@item -enc_stats_post[:@var{stream_specifier}] @var{path}
(@emph{output,per-stream})
+Write per-frame encoding information about the matching streams into the file
+given by @var{path}.
+
+@option{-enc_stats_pre} writes information about raw video or audio frames
right
+before they are sent for encoding, while @option{-enc_stats_post} writes
+information about encoded packets as they are received from the encoder. Every
+frame or packet produces one line in the specified file. The format of this
line
+is controlled by @option{-enc_stats_pre_fmt} / @option{-enc_stats_post_fmt}.
+
+When stats for multiple streams are written into a single file, the lines
+corresponding to different streams will be interleaved. The precise order of
+this interleaving is not specified and not guaranteed to remain stable between
+different invocations of the program, even with the same options.
+
+@item -enc_stats_pre_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
+@item -enc_stats_post_fmt[:@var{stream_specifier}] @var{format_spec}
(@emph{output,per-stream})
+Specify the format for the lines written with @option{-enc_stats_pre} /
+@option{-enc_stats_post}.
+
+@var{format_spec} is a string that may contain directives of the form
+@var{@{fmt@}}. @var{format_spec} is backslash-escaped --- use \@{, \@}, and \\
+to write a literal @{, @}, or \, respectively, into the output.
+
+The directives given with @var{fmt} may be one of the following:
+@table @option
+@item fidx
+Index of the output file.
+
+@item sidx
+Index of the output stream in the file.
+
+@item n
+Frame number. Pre-encoding: number of frames sent to the encoder so far.
+Post-encoding: number of packets received from the encoder so far.
+
+@item tb
+Encoder timebase, as a rational number @var{num/den}. Note that this may be
+different from the timebase used by the muxer.
+
+@item pts
+Presentation timestamp of the frame or packet, as an integer. Should be
+multiplied by the timebase to compute presentation time.
+
+@item t
+Presentation time of the frame or packet, as a decimal number. Equal to
+@var{pts} multiplied by @var{tb}.
+
+@item dts
+Decoding timestamp of the packet, as an integer. Should be multiplied by the
+timebase to compute presentation time. Post-encoding only.
+
+@item dt
+Decoding time of the frame or packet, as a decimal number. Equal to
+@var{dts} multiplied by @var{tb}.
+
+@item sn
+Number of audio samples sent to the encoder so far. Audio and pre-encoding
only.
+
+@item samp
+Number of audio samples in the frame. Audio and pre-encoding only.
+
+@item size
+Size of the encoded packet in bytes. Post-encoding only.
+
+@item br
+Current bitrate in bits per second. Post-encoding only.
+
+@item abr
+Average bitrate for the whole stream so far, in bits per second, -1 if it
cannot
+be determined at this point. Post-encoding only.
+@end table
+
+The default format strings are:
+@table @option
+@item pre-encoding
+@{fidx@} @{sidx@} @{n@} @{t@}
+@item post-encoding
+@{fidx@} @{sidx@} @{n@} @{t@}
+@end table
+In the future, new items may be added to the end of the default formatting
+strings. Users who depend on the format staying exactly the same, should
+prescribe it manually.
+
+Note that stats for different streams written into the same file may have
+different formats.
+
@end table
@section Preset files
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f722ae7632..b1ed5b55d9 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -554,6 +554,8 @@ static void ffmpeg_cleanup(int ret)
av_err2str(AVERROR(errno)));
}
av_freep(_filename);
+of_enc_stats_close();
+
av_freep(_nbthreads);
av_freep(_files);
@@ -798,6 +800,56 @@ static void update_video_stats(OutputStream *ost, const
AVPacket *pkt, int write
fprintf(vstats_file, "type= %c\n",
av_get_picture_type_char(ost->pict_type));
}
+static void write_enc_stats(OutputStream *ost, EncStats *es,
+const AVFrame *frame, const AVPacket *pkt)
+{
+AVIOContext *io = ost->enc_stats_pre.io;
+AVRational tb =
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: extend -dts_delta_threshold option description
On 2023-01-25 06:37 am, Stefano Sabatini wrote:
---
doc/ffmpeg.texi | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 67b3294256..122f7e3387 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1823,8 +1823,21 @@ results, but increase memory use and latency.
The default value is 10 seconds.
-@item -dts_delta_threshold
-Timestamp discontinuity delta threshold.
+@item -dts_delta_threshold @var{threshold}
+Timestamp discontinuity delta threshold, expressed as a floating point
+number of @var{AV_TIME_BASE} units.
This is a CLI option and those users don't deal with AV_TIME_BASE . More
useful to say it's in seconds.
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold} * @var{AV_TIME_BASE}, ffmpeg will remove the
+discontinuity by decreasing/increasing the current DTS and PTS by the
+corresponding delta value.
Might want to mention that this only applies to AV_FMT_DISCONT demuxers,
or rather give a few examples, like MPEG-TS, HLS..etc.
For all other formats that users normally work with, clarify that only
dts_error_threshold is relevant.
+
+Timestamp discontinuity correction can be inhibited by setting a big value for
+@var{threshold}, and is automatically disabled when employing the
+@code{-copy_ts} option.
For copy_ts, it is still applied for all negative deltas except the
smallest.
Not blocking, but I'm reworking this code at present. Shouldn't really
affect this patch. See
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305539.html
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/ffmpeg: extend -dts_delta_threshold option description
---
doc/ffmpeg.texi | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 67b3294256..122f7e3387 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1823,8 +1823,21 @@ results, but increase memory use and latency.
The default value is 10 seconds.
-@item -dts_delta_threshold
-Timestamp discontinuity delta threshold.
+@item -dts_delta_threshold @var{threshold}
+Timestamp discontinuity delta threshold, expressed as a floating point
+number of @var{AV_TIME_BASE} units.
+
+If a timestamp discontinuity is detected whose absolute value is
+greater than @var{threshold} * @var{AV_TIME_BASE}, ffmpeg will remove the
+discontinuity by decreasing/increasing the current DTS and PTS by the
+corresponding delta value.
+
+Timestamp discontinuity correction can be inhibited by setting a big value for
+@var{threshold}, and is automatically disabled when employing the
+@code{-copy_ts} option.
+
+Default value is 10.
+
@item -dts_error_threshold @var{seconds}
Timestamp error delta threshold. This threshold use to discard crazy/damaged
timestamps and the default is 30 hours which is arbitrarily picked and quite
--
2.25.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] fftools/ffmpeg: rename read_file() to avoid conflict with libass
Quoting Rémi Denis-Courmont (2022-10-20 10:06:45) > `file_read` is just as likely to cause naming conflicts. And I have > seen really insane libraries with no namespacing getting preloaded, so > it is unfortunately not even only a problem with libraries that FFmpeg > links with. > > If you're going to treat this as an FFmpeg bug... I fear that the only > solution consists of prefixing all extern symbols for namespacing. No, as far as I'm concerned this is libass bug and this is merely a workaround. I don't think we should preemptively try to work around other bugs in other libraries - they should be found and fixed there. Apparently this is going to be fixed in libass as well, but we still need to hanlde older versions. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: rename read_file() to avoid conflict with libass
Le 20 octobre 2022 10:12:28 GMT+03:00, Anton Khirnov a
écrit :
>libass defines a non-static read_file() symbol, which causes conflicts
>with static linking.
>---
> fftools/ffmpeg.h | 2 +-
> fftools/ffmpeg_mux_init.c | 4 ++--
> fftools/ffmpeg_opt.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
>index 2dcce45741..5966cac60e 100644
>--- a/fftools/ffmpeg.h
>+++ b/fftools/ffmpeg.h
>@@ -702,7 +702,7 @@ void remove_avoptions(AVDictionary **a, AVDictionary *b);
> void assert_avoptions(AVDictionary *m);
>
> void assert_file_overwrite(const char *filename);
>-char *read_file(const char *filename);
>+char *file_read(const char *filename);
> AVDictionary *strip_specifiers(AVDictionary *dict);
> const AVCodec *find_codec_or_die(const char *name, enum AVMediaType type, int
> encoder);
> int parse_and_set_vsync(const char *arg, int *vsync_var, int file_idx, int
> st_idx, int is_global);
>diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
>index c8b2552104..c77260c24b 100644
>--- a/fftools/ffmpeg_mux_init.c
>+++ b/fftools/ffmpeg_mux_init.c
>@@ -380,7 +380,7 @@ static char *get_ost_filters(OptionsContext *o,
>AVFormatContext *oc,
> }
>
> if (ost->filters_script)
>-return read_file(ost->filters_script);
>+return file_read(ost->filters_script);
> else if (ost->filters)
> return av_strdup(ost->filters);
>
>@@ -585,7 +585,7 @@ static OutputStream *new_video_stream(Muxer *mux,
>OptionsContext *o, int source_
> av_dict_set(>encoder_opts, "stats", logfilename,
> AV_DICT_DONT_OVERWRITE);
> } else {
> if (video_enc->flags & AV_CODEC_FLAG_PASS2) {
>-char *logbuffer = read_file(logfilename);
>+char *logbuffer = file_read(logfilename);
>
> if (!logbuffer) {
> av_log(NULL, AV_LOG_FATAL, "Error reading log file
> '%s' for pass-2 encoding\n",
>diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
>index ead4ee1b38..9245e02813 100644
>--- a/fftools/ffmpeg_opt.c
>+++ b/fftools/ffmpeg_opt.c
>@@ -1300,7 +1300,7 @@ static int open_input_file(OptionsContext *o, const char
>*filename)
> }
>
> /* read file contents into a string */
>-char *read_file(const char *filename)
>+char *file_read(const char *filename)
> {
> AVIOContext *pb = NULL;
> int ret = avio_open(, filename, AVIO_FLAG_READ);
>@@ -1725,7 +1725,7 @@ static int opt_filter_complex(void *optctx, const char
>*opt, const char *arg)
> static int opt_filter_complex_script(void *optctx, const char *opt, const
> char *arg)
> {
> FilterGraph *fg;
>-char *graph_desc = read_file(arg);
>+char *graph_desc = file_read(arg);
> if (!graph_desc)
> return AVERROR(EINVAL);
>
Hi,
`file_read` is just as likely to cause naming conflicts. And I have seen really
insane libraries with no namespacing getting preloaded, so it is unfortunately
not even only a problem with libraries that FFmpeg links with.
If you're going to treat this as an FFmpeg bug... I fear that the only solution
consists of prefixing all extern symbols for namespacing.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg: rename read_file() to avoid conflict with libass
libass defines a non-static read_file() symbol, which causes conflicts
with static linking.
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_mux_init.c | 4 ++--
fftools/ffmpeg_opt.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 2dcce45741..5966cac60e 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -702,7 +702,7 @@ void remove_avoptions(AVDictionary **a, AVDictionary *b);
void assert_avoptions(AVDictionary *m);
void assert_file_overwrite(const char *filename);
-char *read_file(const char *filename);
+char *file_read(const char *filename);
AVDictionary *strip_specifiers(AVDictionary *dict);
const AVCodec *find_codec_or_die(const char *name, enum AVMediaType type, int
encoder);
int parse_and_set_vsync(const char *arg, int *vsync_var, int file_idx, int
st_idx, int is_global);
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index c8b2552104..c77260c24b 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -380,7 +380,7 @@ static char *get_ost_filters(OptionsContext *o,
AVFormatContext *oc,
}
if (ost->filters_script)
-return read_file(ost->filters_script);
+return file_read(ost->filters_script);
else if (ost->filters)
return av_strdup(ost->filters);
@@ -585,7 +585,7 @@ static OutputStream *new_video_stream(Muxer *mux,
OptionsContext *o, int source_
av_dict_set(>encoder_opts, "stats", logfilename,
AV_DICT_DONT_OVERWRITE);
} else {
if (video_enc->flags & AV_CODEC_FLAG_PASS2) {
-char *logbuffer = read_file(logfilename);
+char *logbuffer = file_read(logfilename);
if (!logbuffer) {
av_log(NULL, AV_LOG_FATAL, "Error reading log file
'%s' for pass-2 encoding\n",
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ead4ee1b38..9245e02813 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1300,7 +1300,7 @@ static int open_input_file(OptionsContext *o, const char
*filename)
}
/* read file contents into a string */
-char *read_file(const char *filename)
+char *file_read(const char *filename)
{
AVIOContext *pb = NULL;
int ret = avio_open(, filename, AVIO_FLAG_READ);
@@ -1725,7 +1725,7 @@ static int opt_filter_complex(void *optctx, const char
*opt, const char *arg)
static int opt_filter_complex_script(void *optctx, const char *opt, const char
*arg)
{
FilterGraph *fg;
-char *graph_desc = read_file(arg);
+char *graph_desc = file_read(arg);
if (!graph_desc)
return AVERROR(EINVAL);
--
2.35.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] fftools/ffmpeg: fix av_display_rotation_set() type cast
> On Sep 1, 2022, at 14:17, Steven Liu wrote: > > Zhao Zhili 于2022年9月1日周四 10:59写道： >> >> From: Zhao Zhili >> >> Signed-off-by: Zhao Zhili >> --- >> fftools/ffmpeg.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c >> index fbabbe6ea2..ecaf3bd984 100644 >> --- a/fftools/ffmpeg.c >> +++ b/fftools/ffmpeg.c >> @@ -3263,7 +3263,7 @@ static int init_output_stream(OutputStream *ost, >> AVFrame *frame, >> return AVERROR(ENOMEM); >> memcpy(dst, sd->data, sd->size); >> if (ist->autorotate && sd->type == >> AV_PKT_DATA_DISPLAYMATRIX) >> -av_display_rotation_set((uint32_t *)dst, 0); >> +av_display_rotation_set((int32_t *)dst, 0); >> } >> } >> } >> -- >> 2.25.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". > > looks ok to me > Applied, thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@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] fftools/ffmpeg: Fix EOF pts for libavfilter in send_filter_eof()
Ping. Any comments on the updated patch?
On Tue, Sep 13, 2022 at 9:46 AM Li-Heng Chen wrote:
>
> On Tue, Sep 13, 2022 at 4:40 AM Paul B Mahol wrote:
> >
> > On 9/11/22, Li-Heng Chen wrote:
> > > When input is video bitstream (e.g. *.264) with framerate set by -r,
> > > ist->pts could be a nonsense value.
> > >
> > > In libavfilter/vf_fps, the pts value of EOF from above is compared to pts
> > > derived from inlink. The wrong EOF pts may trigger a bug, where ffmpeg
> > > keeps
> > > writting the last video frame to the output. This bug can be easily
> > > reproduced by the ffmpeg cmd below (h264 bitstreams in fate-suite can
> > > reproduce this issue):
> > >
> > > ffmpeg -r num_in/den_in -i bitstream -vf fps=num_out/den_out -f rawvideo
> > > out.yuv
> > >
> > > Example: ffmpeg -r 24/1 -i fate-suite/h264/bbc2.sample.h264 -vf fps=24/1
> > > -f
> > > rawvideo out.yuv
> > > Signed-off-by: Li-Heng Chen
> > > ---
> > > fftools/ffmpeg.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > > index 0e1477299d..e9a986c95b 100644
> > > --- a/fftools/ffmpeg.c
> > > +++ b/fftools/ffmpeg.c
> > > @@ -2383,6 +2383,9 @@ static int send_filter_eof(InputStream *ist)
> > > int64_t pts = av_rescale_q_rnd(ist->pts, AV_TIME_BASE_Q,
> > > ist->st->time_base,
> > >AV_ROUND_NEAR_INF |
> > > AV_ROUND_PASS_MINMAX);
> > >
> > > +if(ist->framerate.num)
> > > +pts = ist->cfr_next_pts;
> > > +
> >
> > Style is wrong
>
> Style fixed in the attached patch
>
> >
> > > for (i = 0; i < ist->nb_filters; i++) {
> > > ret = ifilter_send_eof(ist->filters[i], pts);
> > > if (ret < 0)
> > > --
> > > 2.32.1 (Apple Git-133)
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@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".
0001-fftools-ffmpeg-Fix-EOF-pts-for-libavfilter-in-send_f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg: Fix EOF pts for libavfilter in send_filter_eof()
On 9/11/22, Li-Heng Chen wrote:
> When input is video bitstream (e.g. *.264) with framerate set by -r,
> ist->pts could be a nonsense value.
>
> In libavfilter/vf_fps, the pts value of EOF from above is compared to pts
> derived from inlink. The wrong EOF pts may trigger a bug, where ffmpeg keeps
> writting the last video frame to the output. This bug can be easily
> reproduced by the ffmpeg cmd below (h264 bitstreams in fate-suite can
> reproduce this issue):
>
> ffmpeg -r num_in/den_in -i bitstream -vf fps=num_out/den_out -f rawvideo
> out.yuv
>
> Example: ffmpeg -r 24/1 -i fate-suite/h264/bbc2.sample.h264 -vf fps=24/1 -f
> rawvideo out.yuv
> Signed-off-by: Li-Heng Chen
> ---
> fftools/ffmpeg.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 0e1477299d..e9a986c95b 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2383,6 +2383,9 @@ static int send_filter_eof(InputStream *ist)
> int64_t pts = av_rescale_q_rnd(ist->pts, AV_TIME_BASE_Q,
> ist->st->time_base,
>AV_ROUND_NEAR_INF |
> AV_ROUND_PASS_MINMAX);
>
> +if(ist->framerate.num)
> +pts = ist->cfr_next_pts;
> +
Style is wrong
> for (i = 0; i < ist->nb_filters; i++) {
> ret = ifilter_send_eof(ist->filters[i], pts);
> if (ret < 0)
> --
> 2.32.1 (Apple Git-133)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] fftools/ffmpeg: fix av_display_rotation_set() type cast
Zhao Zhili 于2022年9月1日周四 10:59写道： > > From: Zhao Zhili > > Signed-off-by: Zhao Zhili > --- > fftools/ffmpeg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index fbabbe6ea2..ecaf3bd984 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -3263,7 +3263,7 @@ static int init_output_stream(OutputStream *ost, > AVFrame *frame, > return AVERROR(ENOMEM); > memcpy(dst, sd->data, sd->size); > if (ist->autorotate && sd->type == > AV_PKT_DATA_DISPLAYMATRIX) > -av_display_rotation_set((uint32_t *)dst, 0); > +av_display_rotation_set((int32_t *)dst, 0); > } > } > } > -- > 2.25.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". looks ok to me Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: fix av_display_rotation_set() type cast
From: Zhao Zhili Signed-off-by: Zhao Zhili --- fftools/ffmpeg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index fbabbe6ea2..ecaf3bd984 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -3263,7 +3263,7 @@ static int init_output_stream(OutputStream *ost, AVFrame *frame, return AVERROR(ENOMEM); memcpy(dst, sd->data, sd->size); if (ist->autorotate && sd->type == AV_PKT_DATA_DISPLAYMATRIX) -av_display_rotation_set((uint32_t *)dst, 0); +av_display_rotation_set((int32_t *)dst, 0); } } } -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: stop accessing av_stream_get_parser() from the main thread
It races with the demuxing thread. Instead, send the information along
with the demuxed packets.
Ideally, the code should stop using the stream-internal parsing
completely, but that requires considerably more effort.
Fixes races, e.g. in:
- fate-h264-brokensps-2580
- fate-h264-extradata-reload
- fate-iv8-demux
- fate-m4v-cfr
- fate-m4v
---
fftools/ffmpeg.c | 8 ++--
fftools/ffmpeg.h | 6 ++
fftools/ffmpeg_demux.c | 16 ++--
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ef7177fc33..ff74534ad0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2452,7 +2452,9 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
if (pkt && pkt->duration) {
duration_dts = av_rescale_q(pkt->duration,
ist->st->time_base, AV_TIME_BASE_Q);
} else if(ist->dec_ctx->framerate.num != 0 &&
ist->dec_ctx->framerate.den != 0) {
-int ticks= av_stream_get_parser(ist->st) ?
av_stream_get_parser(ist->st)->repeat_pict+1 : ist->dec_ctx->ticks_per_frame;
+int ticks = ist->last_pkt_repeat_pict >= 0 ?
+ist->last_pkt_repeat_pict + 1 :
+ist->dec_ctx->ticks_per_frame;
duration_dts = ((int64_t)AV_TIME_BASE *
ist->dec_ctx->framerate.den * ticks) /
ist->dec_ctx->framerate.num /
ist->dec_ctx->ticks_per_frame;
@@ -2555,7 +2557,9 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
} else if (pkt->duration) {
ist->next_dts += av_rescale_q(pkt->duration,
ist->st->time_base, AV_TIME_BASE_Q);
} else if(ist->dec_ctx->framerate.num != 0) {
-int ticks= av_stream_get_parser(ist->st) ?
av_stream_get_parser(ist->st)->repeat_pict + 1 : ist->dec_ctx->ticks_per_frame;
+int ticks = ist->last_pkt_repeat_pict >= 0 ?
+ist->last_pkt_repeat_pict + 1 :
+ist->dec_ctx->ticks_per_frame;
ist->next_dts += ((int64_t)AV_TIME_BASE *
ist->dec_ctx->framerate.den * ticks) /
ist->dec_ctx->framerate.num /
ist->dec_ctx->ticks_per_frame;
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 921e579c32..27ef92654c 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -348,6 +348,12 @@ typedef struct InputStream {
int64_t pts; ///< current pts of the decoded frame (in
AV_TIME_BASE units)
int wrap_correction_done;
+// the value of AVCodecParserContext.repeat_pict from the AVStream parser
+// for the last packet returned from ifile_get_packet()
+// -1 if unknown
+// FIXME: this is a hack, the avstream parser should not be used
+int last_pkt_repeat_pict;
+
int64_t filter_in_rescale_delta_last;
int64_t min_pts; /* pts with the smallest value in a current stream */
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 6dfb5bb35b..6e89f5999a 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -32,6 +32,9 @@
typedef struct DemuxMsg {
AVPacket *pkt;
int looping;
+
+// repeat_pict from the demuxer-internal parser
+int repeat_pict;
} DemuxMsg;
static void report_new_stream(InputFile *file, const AVPacket *pkt)
@@ -114,7 +117,7 @@ static int seek_to_start(InputFile *ifile)
return ret;
}
-static void ts_fixup(InputFile *ifile, AVPacket *pkt)
+static void ts_fixup(InputFile *ifile, AVPacket *pkt, int *repeat_pict)
{
InputStream *ist = input_streams[ifile->ist_index + pkt->stream_index];
const int64_t start_time = ifile->ctx->start_time;
@@ -167,6 +170,11 @@ static void ts_fixup(InputFile *ifile, AVPacket *pkt)
if (pkt->dts != AV_NOPTS_VALUE)
pkt->dts += duration;
+
+*repeat_pict = -1;
+if (ist->st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+av_stream_get_parser(ist->st))
+*repeat_pict = av_stream_get_parser(ist->st)->repeat_pict;
}
static void *input_thread(void *arg)
@@ -231,7 +239,7 @@ static void *input_thread(void *arg)
}
}
-ts_fixup(f, pkt);
+ts_fixup(f, pkt, _pict);
msg.pkt = av_packet_alloc();
if (!msg.pkt) {
@@ -352,6 +360,7 @@ int init_input_threads(void)
int ifile_get_packet(InputFile *f, AVPacket **pkt)
{
+InputStream *ist;
DemuxMsg msg;
int ret;
@@ -382,6 +391,9 @@ int ifile_get_packet(InputFile *f, AVPacket **pkt)
if (msg.looping)
return 1;
+ist = input_streams[f->ist_index + msg.pkt->stream_index];
+ist->last_pkt_repeat_pict = msg.repeat_pict;
+
*pkt = msg.pkt;
return 0;
}
--
2.35.1
___
ffmpeg-devel mailing
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: store a separate copy of input codec parameters
Quoting James Almer (2022-08-16 14:21:31) > On 8/13/2022 12:36 PM, Anton Khirnov wrote: > > Use it instead of AVStream.codecpar in the main thread. While > > AVStream.codecpar is documented to only be updated when the stream is > > added or avformat_find_stream_info(), it is actually updated during > > demuxing. Accessing it from a different thread then constitutes a race. > > Should we consider a bug that some demuxers update stream's codepars > post init? Or is the documentation not reflecting the actual behavior > what's wrong? Maybe? Disregarding the generic code we know about, I'd be interested to know which demuxers modify codecpar and whether they have a good reason for it. I already know dv updates the timebase all the time, which should be highly illegal. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: store a separate copy of input codec parameters
James Almer:
> On 8/13/2022 12:36 PM, Anton Khirnov wrote:
>> Use it instead of AVStream.codecpar in the main thread. While
>> AVStream.codecpar is documented to only be updated when the stream is
>> added or avformat_find_stream_info(), it is actually updated during
>> demuxing. Accessing it from a different thread then constitutes a race.
>
> Should we consider a bug that some demuxers update stream's codepars
> post init? Or is the documentation not reflecting the actual behavior
> what's wrong?
>
Some demuxers? It is the generic demuxing code (read_frame_internal(),
demux.c lines 1335-1347) that does this. And some demuxers probably do
it, too. At least the concat demuxer IIRC.
>>
>> Ideally, some mechanism should eventually be provided for signalling
>> parameter updates to the user. Then the demuxing thread could pick up
>> the changes and propagate them to the decoder.
>> ---
>> fftools/ffmpeg.c | 39 ---
>> fftools/ffmpeg.h | 6 ++
>> fftools/ffmpeg_opt.c | 6 +-
>> 3 files changed, 31 insertions(+), 20 deletions(-)
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 8eb7759392..ef7177fc33 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -608,6 +608,7 @@ static void ffmpeg_cleanup(int ret)
>> av_freep(>dts_buffer);
>> avcodec_free_context(>dec_ctx);
>> + avcodec_parameters_free(>par);
>> av_freep(_streams[i]);
>> }
>> @@ -1492,7 +1493,7 @@ static void print_final_stats(int64_t total_size)
>> for (j = 0; j < f->nb_streams; j++) {
>> InputStream *ist = input_streams[f->ist_index + j];
>> - enum AVMediaType type = ist->st->codecpar->codec_type;
>> + enum AVMediaType type = ist->par->codec_type;
>> total_size += ist->data_size;
>> total_packets += ist->nb_packets;
>> @@ -1809,7 +1810,7 @@ static void flush_encoders(void)
>> for (x = 0; x < fg->nb_inputs; x++) {
>> InputFilter *ifilter = fg->inputs[x];
>> if (ifilter->format < 0 &&
>> - ifilter_parameters_from_codecpar(ifilter,
>> ifilter->ist->st->codecpar) < 0) {
>> + ifilter_parameters_from_codecpar(ifilter,
>> ifilter->ist->par) < 0) {
>> av_log(NULL, AV_LOG_ERROR, "Error copying
>> paramerets from input stream\n");
>> exit_program(1);
>> }
>> @@ -1912,11 +1913,11 @@ static void do_streamcopy(InputStream *ist,
>> OutputStream *ost, const AVPacket *p
>> if (pkt->dts == AV_NOPTS_VALUE) {
>> opkt->dts = av_rescale_q(ist->dts, AV_TIME_BASE_Q,
>> ost->mux_timebase);
>> } else if (ost->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
>> - int duration =
>> av_get_audio_frame_duration2(ist->st->codecpar, pkt->size);
>> + int duration = av_get_audio_frame_duration2(ist->par,
>> pkt->size);
>> if(!duration)
>> - duration = ist->st->codecpar->frame_size;
>> + duration = ist->par->frame_size;
>> opkt->dts = av_rescale_delta(ist->st->time_base, pkt->dts,
>> - (AVRational){1,
>> ist->st->codecpar->sample_rate}, duration,
>> + (AVRational){1,
>> ist->par->sample_rate}, duration,
>>
>> >filter_in_rescale_delta_last, ost->mux_timebase);
>> /* dts will be set immediately afterwards to what pts is now */
>> opkt->pts = opkt->dts - ost_tb_start_time;
>> @@ -1976,7 +1977,7 @@ static int ifilter_send_frame(InputFilter
>> *ifilter, AVFrame *frame, int keep_ref
>> /* determine if the parameters for this input changed */
>> need_reinit = ifilter->format != frame->format;
>> - switch (ifilter->ist->st->codecpar->codec_type) {
>> + switch (ifilter->ist->par->codec_type) {
>> case AVMEDIA_TYPE_AUDIO:
>> need_reinit |= ifilter->sample_rate != frame->sample_rate ||
>>
>> av_channel_layout_compare(>ch_layout, >ch_layout);
>> @@ -2056,7 +2057,7 @@ static int ifilter_send_eof(InputFilter
>> *ifilter, int64_t pts)
>> } else {
>> // the filtergraph was never configured
>> if (ifilter->format < 0) {
>> - ret = ifilter_parameters_from_codecpar(ifilter,
>> ifilter->ist->st->codecpar);
>> + ret = ifilter_parameters_from_codecpar(ifilter,
>> ifilter->ist->par);
>> if (ret < 0)
>> return ret;
>> }
>> @@ -2212,9 +2213,9 @@ static int decode_video(InputStream *ist,
>> AVPacket *pkt, int *got_output, int64_
>> // The following line may be required in some cases where
>> there is no parser
>> // or the parser does not has_b_frames correctly
>> - if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
>> + if
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: store a separate copy of input codec parameters
On 8/13/2022 12:36 PM, Anton Khirnov wrote:
Use it instead of AVStream.codecpar in the main thread. While
AVStream.codecpar is documented to only be updated when the stream is
added or avformat_find_stream_info(), it is actually updated during
demuxing. Accessing it from a different thread then constitutes a race.
Should we consider a bug that some demuxers update stream's codepars
post init? Or is the documentation not reflecting the actual behavior
what's wrong?
Ideally, some mechanism should eventually be provided for signalling
parameter updates to the user. Then the demuxing thread could pick up
the changes and propagate them to the decoder.
---
fftools/ffmpeg.c | 39 ---
fftools/ffmpeg.h | 6 ++
fftools/ffmpeg_opt.c | 6 +-
3 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8eb7759392..ef7177fc33 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -608,6 +608,7 @@ static void ffmpeg_cleanup(int ret)
av_freep(>dts_buffer);
avcodec_free_context(>dec_ctx);
+avcodec_parameters_free(>par);
av_freep(_streams[i]);
}
@@ -1492,7 +1493,7 @@ static void print_final_stats(int64_t total_size)
for (j = 0; j < f->nb_streams; j++) {
InputStream *ist = input_streams[f->ist_index + j];
-enum AVMediaType type = ist->st->codecpar->codec_type;
+enum AVMediaType type = ist->par->codec_type;
total_size+= ist->data_size;
total_packets += ist->nb_packets;
@@ -1809,7 +1810,7 @@ static void flush_encoders(void)
for (x = 0; x < fg->nb_inputs; x++) {
InputFilter *ifilter = fg->inputs[x];
if (ifilter->format < 0 &&
-ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar) < 0) {
+ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->par) < 0) {
av_log(NULL, AV_LOG_ERROR, "Error copying paramerets from
input stream\n");
exit_program(1);
}
@@ -1912,11 +1913,11 @@ static void do_streamcopy(InputStream *ist,
OutputStream *ost, const AVPacket *p
if (pkt->dts == AV_NOPTS_VALUE) {
opkt->dts = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ost->mux_timebase);
} else if (ost->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int duration = av_get_audio_frame_duration2(ist->st->codecpar,
pkt->size);
+int duration = av_get_audio_frame_duration2(ist->par, pkt->size);
if(!duration)
-duration = ist->st->codecpar->frame_size;
+duration = ist->par->frame_size;
opkt->dts = av_rescale_delta(ist->st->time_base, pkt->dts,
-(AVRational){1,
ist->st->codecpar->sample_rate}, duration,
+(AVRational){1, ist->par->sample_rate},
duration,
>filter_in_rescale_delta_last,
ost->mux_timebase);
/* dts will be set immediately afterwards to what pts is now */
opkt->pts = opkt->dts - ost_tb_start_time;
@@ -1976,7 +1977,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
AVFrame *frame, int keep_ref
/* determine if the parameters for this input changed */
need_reinit = ifilter->format != frame->format;
-switch (ifilter->ist->st->codecpar->codec_type) {
+switch (ifilter->ist->par->codec_type) {
case AVMEDIA_TYPE_AUDIO:
need_reinit |= ifilter->sample_rate!= frame->sample_rate ||
av_channel_layout_compare(>ch_layout,
>ch_layout);
@@ -2056,7 +2057,7 @@ static int ifilter_send_eof(InputFilter *ifilter, int64_t
pts)
} else {
// the filtergraph was never configured
if (ifilter->format < 0) {
-ret = ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar);
+ret = ifilter_parameters_from_codecpar(ifilter, ifilter->ist->par);
if (ret < 0)
return ret;
}
@@ -2212,9 +2213,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
// The following line may be required in some cases where there is no parser
// or the parser does not has_b_frames correctly
-if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
+if (ist->par->video_delay < ist->dec_ctx->has_b_frames) {
if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264) {
-ist->st->codecpar->video_delay = ist->dec_ctx->has_b_frames;
+ist->par->video_delay = ist->dec_ctx->has_b_frames;
} else
av_log(ist->dec_ctx, AV_LOG_WARNING,
"video_delay is larger in decoder than demuxer %d > %d.\n"
@@ -,7 +2223,7 @@ static int decode_video(InputStream *ist,
[FFmpeg-devel] [PATCH] fftools/ffmpeg: store a separate copy of input codec parameters
Use it instead of AVStream.codecpar in the main thread. While
AVStream.codecpar is documented to only be updated when the stream is
added or avformat_find_stream_info(), it is actually updated during
demuxing. Accessing it from a different thread then constitutes a race.
Ideally, some mechanism should eventually be provided for signalling
parameter updates to the user. Then the demuxing thread could pick up
the changes and propagate them to the decoder.
---
fftools/ffmpeg.c | 39 ---
fftools/ffmpeg.h | 6 ++
fftools/ffmpeg_opt.c | 6 +-
3 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8eb7759392..ef7177fc33 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -608,6 +608,7 @@ static void ffmpeg_cleanup(int ret)
av_freep(>dts_buffer);
avcodec_free_context(>dec_ctx);
+avcodec_parameters_free(>par);
av_freep(_streams[i]);
}
@@ -1492,7 +1493,7 @@ static void print_final_stats(int64_t total_size)
for (j = 0; j < f->nb_streams; j++) {
InputStream *ist = input_streams[f->ist_index + j];
-enum AVMediaType type = ist->st->codecpar->codec_type;
+enum AVMediaType type = ist->par->codec_type;
total_size+= ist->data_size;
total_packets += ist->nb_packets;
@@ -1809,7 +1810,7 @@ static void flush_encoders(void)
for (x = 0; x < fg->nb_inputs; x++) {
InputFilter *ifilter = fg->inputs[x];
if (ifilter->format < 0 &&
-ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar) < 0) {
+ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->par) < 0) {
av_log(NULL, AV_LOG_ERROR, "Error copying paramerets
from input stream\n");
exit_program(1);
}
@@ -1912,11 +1913,11 @@ static void do_streamcopy(InputStream *ist,
OutputStream *ost, const AVPacket *p
if (pkt->dts == AV_NOPTS_VALUE) {
opkt->dts = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ost->mux_timebase);
} else if (ost->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int duration = av_get_audio_frame_duration2(ist->st->codecpar,
pkt->size);
+int duration = av_get_audio_frame_duration2(ist->par, pkt->size);
if(!duration)
-duration = ist->st->codecpar->frame_size;
+duration = ist->par->frame_size;
opkt->dts = av_rescale_delta(ist->st->time_base, pkt->dts,
-(AVRational){1,
ist->st->codecpar->sample_rate}, duration,
+(AVRational){1, ist->par->sample_rate},
duration,
>filter_in_rescale_delta_last,
ost->mux_timebase);
/* dts will be set immediately afterwards to what pts is now */
opkt->pts = opkt->dts - ost_tb_start_time;
@@ -1976,7 +1977,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
AVFrame *frame, int keep_ref
/* determine if the parameters for this input changed */
need_reinit = ifilter->format != frame->format;
-switch (ifilter->ist->st->codecpar->codec_type) {
+switch (ifilter->ist->par->codec_type) {
case AVMEDIA_TYPE_AUDIO:
need_reinit |= ifilter->sample_rate!= frame->sample_rate ||
av_channel_layout_compare(>ch_layout,
>ch_layout);
@@ -2056,7 +2057,7 @@ static int ifilter_send_eof(InputFilter *ifilter, int64_t
pts)
} else {
// the filtergraph was never configured
if (ifilter->format < 0) {
-ret = ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar);
+ret = ifilter_parameters_from_codecpar(ifilter, ifilter->ist->par);
if (ret < 0)
return ret;
}
@@ -2212,9 +2213,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
// The following line may be required in some cases where there is no
parser
// or the parser does not has_b_frames correctly
-if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
+if (ist->par->video_delay < ist->dec_ctx->has_b_frames) {
if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264) {
-ist->st->codecpar->video_delay = ist->dec_ctx->has_b_frames;
+ist->par->video_delay = ist->dec_ctx->has_b_frames;
} else
av_log(ist->dec_ctx, AV_LOG_WARNING,
"video_delay is larger in decoder than demuxer %d > %d.\n"
@@ -,7 +2223,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
"of this file to https://streams.videolan.org/upload/ "
"and contact the ffmpeg-devel mailing list.
(ffmpeg-devel@ffmpeg.org)\n",
ist->dec_ctx->has_b_frames,
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: move stream-dependent starttime correction to transcode_init()
On Thu, Aug 11, 2022 at 09:45:48AM +0200, Anton Khirnov wrote: > Currently this code is located in the discontinuity handling block, > where it does not belong. > --- > Now with previously missed 'is->start_time != AV_NOPTS_VALUE' check > --- > fftools/ffmpeg.c | 40 ++-- > 1 file changed, 22 insertions(+), 18 deletions(-) seems working fine thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: move stream-dependent starttime correction to transcode_init()
Currently this code is located in the discontinuity handling block,
where it does not belong.
---
Now with previously missed 'is->start_time != AV_NOPTS_VALUE' check
---
fftools/ffmpeg.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 16b1ba8af7..2e04b2ae81 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3313,6 +3313,28 @@ static int transcode_init(void)
input_streams[j + ifile->ist_index]->start =
av_gettime_relative();
}
+// Correct starttime based on the enabled streams
+for (i = 0; i < nb_input_files; i++) {
+InputFile *ifile = input_files[i];
+AVFormatContext*is = ifile->ctx;
+int64_t new_start_time = INT64_MAX;
+
+if (is->start_time == AV_NOPTS_VALUE ||
+!(is->iformat->flags & AVFMT_TS_DISCONT))
+continue;
+
+for (int j = 0; j < is->nb_streams; j++) {
+AVStream *st = is->streams[j];
+if(st->discard == AVDISCARD_ALL || st->start_time ==
AV_NOPTS_VALUE)
+continue;
+new_start_time = FFMIN(new_start_time,
av_rescale_q(st->start_time, st->time_base, AV_TIME_BASE_Q));
+}
+if (new_start_time > is->start_time) {
+av_log(is, AV_LOG_VERBOSE, "Correcting start time by %"PRId64"\n",
new_start_time - is->start_time);
+ifile->ts_offset = -new_start_time;
+}
+}
+
/* init input streams */
for (i = 0; i < nb_input_streams; i++)
if ((ret = init_input_stream(i, error, sizeof(error))) < 0)
@@ -3752,24 +3774,6 @@ static int process_input(int file_index)
if(!ist->wrap_correction_done && is->start_time != AV_NOPTS_VALUE &&
ist->st->pts_wrap_bits < 64){
int64_t stime, stime2;
-// Correcting starttime based on the enabled streams
-// FIXME this ideally should be done before the first use of starttime
but we do not know which are the enabled streams at that point.
-// so we instead do it here as part of discontinuity handling
-if ( ist->next_dts == AV_NOPTS_VALUE
-&& ifile->ts_offset == -is->start_time
-&& (is->iformat->flags & AVFMT_TS_DISCONT)) {
-int64_t new_start_time = INT64_MAX;
-for (i=0; inb_streams; i++) {
-AVStream *st = is->streams[i];
-if(st->discard == AVDISCARD_ALL || st->start_time ==
AV_NOPTS_VALUE)
-continue;
-new_start_time = FFMIN(new_start_time,
av_rescale_q(st->start_time, st->time_base, AV_TIME_BASE_Q));
-}
-if (new_start_time > is->start_time) {
-av_log(is, AV_LOG_VERBOSE, "Correcting start time by
%"PRId64"\n", new_start_time - is->start_time);
-ifile->ts_offset = -new_start_time;
-}
-}
stime = av_rescale_q(is->start_time, AV_TIME_BASE_Q,
ist->st->time_base);
stime2= stime + (1ULLpts_wrap_bits);
--
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] [PATCH] fftools/ffmpeg: remove OutputStream.stream_copy
There are currently three possible modes for an output stream:
1) The stream is produced by encoding output from some filtergraph. This
is true when ost->enc_ctx != NULL, or equivalently when
ost->encoding_needed != 0.
2) The stream is produced by copying some input stream's packets. This
is true when ost->enc_ctx == NULL && ost->source_index >= 0.
3) The stream is produced by attaching some file directly. This is true
when ost->enc_ctx == NULL && ost->source_index < 0.
OutputStream.stream_copy is currently used to identify case 2), and
sometimes to confusingly (or even incorrectly) identify case 1). Remove
it, replacing its usage with checking enc_ctx/source_index values.
---
fftools/ffmpeg.c | 23 +--
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_opt.c | 33 -
3 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 62ff1a98df..cf61706ac0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1566,9 +1566,7 @@ static void print_final_stats(int64_t total_size)
static void print_report(int is_last_report, int64_t timer_start, int64_t
cur_time)
{
AVBPrint buf, buf_script;
-OutputStream *ost;
int64_t total_size = of_filesize(output_files[0]);
-AVCodecContext *enc;
int vid, i;
double bitrate;
double speed;
@@ -1600,11 +1598,9 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
for (i = 0; i < nb_output_streams; i++) {
-float q = -1;
-ost = output_streams[i];
-enc = ost->enc_ctx;
-if (!ost->stream_copy)
-q = ost->quality / (float) FF_QP2LAMBDA;
+OutputStream * const ost = output_streams[i];
+const AVCodecContext * const enc = ost->enc_ctx;
+const float q = enc ? ost->quality / (float) FF_QP2LAMBDA : -1;
if (vid && ost->st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(, "q=%2.1f ", q);
@@ -3258,7 +3254,7 @@ static int init_output_stream(OutputStream *ost, AVFrame
*frame,
// copy estimated duration as a hint to the muxer
if (ost->st->duration <= 0 && ist && ist->st->duration > 0)
ost->st->duration = av_rescale_q(ist->st->duration,
ist->st->time_base, ost->st->time_base);
-} else if (ost->stream_copy) {
+} else if (ost->source_index >= 0) {
ret = init_output_stream_streamcopy(ost);
if (ret < 0)
return ret;
@@ -3343,7 +3339,7 @@ static int transcode_init(void)
* known after the encoder is initialized.
*/
for (i = 0; i < nb_output_streams; i++) {
-if (!output_streams[i]->stream_copy &&
+if (output_streams[i]->enc_ctx &&
(output_streams[i]->st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO
||
output_streams[i]->st->codecpar->codec_type ==
AVMEDIA_TYPE_AUDIO))
continue;
@@ -3417,9 +3413,7 @@ static int transcode_init(void)
av_log(NULL, AV_LOG_INFO, " [sync #%d:%d]",
ost->sync_ist->file_index,
ost->sync_ist->st->index);
-if (ost->stream_copy)
-av_log(NULL, AV_LOG_INFO, " (copy)");
-else {
+if (ost->enc_ctx) {
const AVCodec *in_codec= input_streams[ost->source_index]->dec;
const AVCodec *out_codec = ost->enc;
const char *decoder_name = "?";
@@ -3449,7 +3443,8 @@ static int transcode_init(void)
av_log(NULL, AV_LOG_INFO, " (%s (%s) -> %s (%s))",
in_codec_name, decoder_name,
out_codec_name, encoder_name);
-}
+} else
+av_log(NULL, AV_LOG_INFO, " (copy)");
av_log(NULL, AV_LOG_INFO, "\n");
}
@@ -3959,7 +3954,7 @@ static int process_input(int file_index)
OutputStream *ost = output_streams[j];
if (ost->source_index == ifile->ist_index + i &&
-(ost->stream_copy || ost->enc->type ==
AVMEDIA_TYPE_SUBTITLE)) {
+(!ost->enc_ctx || ost->enc->type ==
AVMEDIA_TYPE_SUBTITLE)) {
OutputFile *of = output_files[ost->file_index];
output_packet(of, ost->pkt, ost, 1);
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 6417db03bd..713de42e2b 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -540,7 +540,6 @@ typedef struct OutputStream {
char *apad;
OSTFinished finished;/* no more packets should be written for this
stream */
int unavailable; /* true if the steram is unavailable
(possibly temporarily) */
-int stream_copy;
// init_output_stream() has been called for this stream
// The encoder and the bitstream filters have been initialized and the
stream
diff
Re: [FFmpeg-devel] [PATCH v1] ffmpeg: add optional JSON output of inputs, outputs, mapping, and progress
2022.07.28. 16:09 keltezéssel, Anton Khirnov írta: Sorry, I do not like your patch. The problem is that this essentialy codifies ffmpeg's internal structure and makes into a kind of a public interface, which makes it harder for us to change it. Given that I'm currently in the middle of a big reshuffle of ffmpeg's internals, this patch would conflict with my work. And even after I'm done, we should think very carefully about exactly which parts of ffmpeg behaviour (if any at all) we want to guarantee. Hi Anton, I agree with you and we may split this whole thing into two separate decision: - should we make something in ffmpeg to be able monitored by automation (e.g. a "monitoring api" - for long running ffmpeg processes) - if the answer is yes, then we need to discuss about how we should do it. My answer is yes for the first question but I haven't got the knowledge to make a good proposal for the second question, but maybe anybody else can. best, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@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 v1] ffmpeg: add optional JSON output of inputs, outputs, mapping, and progress
Sorry, I do not like your patch. The problem is that this essentialy codifies ffmpeg's internal structure and makes into a kind of a public interface, which makes it harder for us to change it. Given that I'm currently in the middle of a big reshuffle of ffmpeg's internals, this patch would conflict with my work. And even after I'm done, we should think very carefully about exactly which parts of ffmpeg behaviour (if any at all) we want to guarantee. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] ffmpeg: add optional JSON output of inputs, outputs, mapping, and progress
;file_index,
> +ost->index);
> +goto next_output;
> +}
> +
> +av_bprintf(,
> +
> "{\"input\":{\"index\":%d,\"stream\":%d},\"output\":{\"index\":%d,\"stream\":%d}",
> +input_streams[ost->source_index]->file_index,
> +input_streams[ost->source_index]->st->index,
> +ost->file_index,
> +ost->index);
> +av_bprintf(, ",\"copy\":%s", ost->stream_copy ? "true" :
> "false");
> +
> +if (ost->sync_ist != input_streams[ost->source_index]) {
> +av_bprintf(,
> +",\"sync\":{\"index\":%d,\"stream\":%d}",
> +ost->sync_ist->file_index,
> +ost->sync_ist->st->index);
> +}
> +
> +av_bprintf(, "}");
> +
> +next_output:
> +if (i != (nb_output_streams - 1)) {
> +av_bprintf(, ",");
> +}
> +}
> +
> +av_bprintf(, "]}\n");
> +
> +av_log(NULL, AV_LOG_INFO, "%s", buf.str);
> +
> +if (progress_avio) {
> +avio_write(progress_avio, buf.str, FFMIN(buf.len, buf.size - 1));
> +avio_flush(progress_avio);
> +}
> +
> +av_bprint_finalize(, NULL);
> +}
> +
> /* open the muxer when all the streams are initialized */
> int of_check_init(OutputFile *of)
> {
> @@ -251,6 +556,8 @@ int of_check_init(OutputFile *of)
> av_dump_format(of->ctx, of->index, of->ctx->url, 1);
> nb_output_dumped++;
>
> +print_json_outputs();
> +
> if (sdp_filename || want_sdp) {
> ret = print_sdp();
> if (ret < 0) {
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 2c1b3bd0dd..20e991eca5 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -51,6 +51,7 @@
> #include "libavutil/parseutils.h"
> #include "libavutil/pixdesc.h"
> #include "libavutil/pixfmt.h"
> +#include "libavutil/bprint.h"
>
> #define DEFAULT_PASS_LOGFILENAME_PREFIX "ffmpeg2pass"
>
> @@ -169,6 +170,7 @@ int debug_ts = 0;
> int exit_on_error = 0;
> int abort_on_flags= 0;
> int print_stats = -1;
> +int print_jsonstats = 0;
> int qp_hist = 0;
> int stdin_interaction = 1;
> float max_error_rate = 2.0/3;
> @@ -3434,6 +3436,115 @@ static int open_files(OptionGroupList *l, const char
> *inout,
> return 0;
> }
>
> +/**
> + * Print all inputs in JSON format
> + */
> +static void print_json_inputs()
> +{
> +if (!print_jsonstats) {
> +return;
> +}
> +
> +AVBPrint buf;
> +int i, j;
> +
> +av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
> +
> +av_bprintf(, "json.inputs:[");
> +for (i = 0; i < nb_input_files; i++) {
> +InputFile *f = input_files[i];
> +AVFormatContext *ctx = f->ctx;
> +
> +float duration = 0;
> +if (ctx->duration != AV_NOPTS_VALUE) {
> +duration = (float)(ctx->duration +
> + (ctx->duration <= INT64_MAX - 5000 ? 5000 : 0)) /
> +(float)AV_TIME_BASE;
> +}
> +
> +for (j = 0; j < f->nb_streams; j++) {
> +InputStream *ist = input_streams[f->ist_index + j];
> +AVCodecContext *dec = ist->dec_ctx;
> +AVStream *st = ist->st;
> +AVDictionaryEntry *lang =
> +av_dict_get(st->metadata, "language", NULL, 0);
> +char *url = NULL;
> +
> +if (av_escape(,
> +ctx->url,
> +"\\\"",
> +AV_ESCAPE_MODE_BACKSLASH,
> +AV_UTF8_FLAG_ACCEPT_ALL) < 0) {
> +url = av_strdup("-");
> +}
> +
> +av_bprintf(, "{");
> +av_bprintf(,
> +
> "\"url\":\"%s\",\"format\":\"%s\",\"index\":%d,\"stream\":%d,",
> +url,
> +ctx->iformat->name,
> +i,
> +j);
> +av_bprintf(,
> +
> "\"type\":\"%s\",\"codec\":\"%s\",\"coder\":\"%s\",\"bitrate_kbps\":%" PRId64
> +",",
> +av_get_media_type_string(dec->codec_type),
> +avcodec_get_name(dec->codec_id),
> +dec->codec ? dec->codec->name : "unknown",
> +dec->bit_rate / 1000);
> +av_bprintf(,
> +"\"duration_sec\":%f,\"language\":\"%s\"",
> +duration,
> +lang ? lang->value : "und");
> +
> +av_free(url);
> +
> +if (dec->codec_type == AVMEDIA_TYPE_VIDEO) {
> +float fps = 0;
> +if (st->avg_frame_rate.den && st->avg_frame_rate.num) {
> +fps = av_q2d(st->avg_frame_rate);
> +}
> +
> +av_bprintf(,
> +
> ",\"fps\":%f,\"pix_fmt\":\"%s\",\"width\":%d,\"height\":%d",
> +fps,
> +st->codecpar->format == AV_PIX_FMT_NONE
> +? "none"
> +: av_get_pix_fmt_name(st->codecpar->format),
> +st->codecpar->width,
> +st->codecpar->height);
> +} else if (dec->codec_type == AVMEDIA_TYPE_AUDIO) {
> +char layout[128];
> +av_channel_layout_describe(
> +>ch_layout, layout, sizeof(layout));
> +
> +av_bprintf(,
> +",\"sampling_hz\":%d,\"layout\":\"%s\",\"channels\":%d",
> +dec->sample_rate,
> +layout,
> +dec->ch_layout.nb_channels);
> +}
> +
> +if (i == (nb_input_files - 1) && j == (f->nb_streams - 1)) {
> +av_bprintf(, "}");
> +} else {
> +av_bprintf(, "},");
> +}
> +}
> +}
> +
> +av_bprintf(, "]\n");
> +
> +av_log(NULL, AV_LOG_INFO, "%s", buf.str);
> +
> +if (progress_avio) {
> +avio_write(progress_avio, buf.str, FFMIN(buf.len, buf.size - 1));
> +avio_flush(progress_avio);
> +}
> +
> +av_bprint_finalize(, NULL);
> +}
> +
> int ffmpeg_parse_options(int argc, char **argv)
> {
> OptionParseContext octx;
> @@ -3467,6 +3578,8 @@ int ffmpeg_parse_options(int argc, char **argv)
> goto fail;
> }
>
> +print_json_inputs();
> +
> /* create the complex filtergraphs */
> ret = init_complex_filters();
> if (ret < 0) {
> @@ -3688,6 +3801,8 @@ const OptionDef options[] = {
> "enable automatic conversion filters globally" },
> { "stats", OPT_BOOL,{
> _stats },
> "print progress report during encoding", },
> +{ "jsonstats", OPT_BOOL,{
> _jsonstats },
> +"print JSON progress report during encoding", },
> { "stats_period",HAS_ARG | OPT_EXPERT, {
> .func_arg = opt_stats_period },
> "set the period at which ffmpeg updates stats and -progress output",
> "time" },
> { "attach", HAS_ARG | OPT_PERFILE | OPT_EXPERT |
>
> base-commit: 5d5a01419928d0c00bae54f730eede150cd5b268
> --
> 2.32.1 (Apple Git-133)
>
ping
Any comments on this patch? Thanks
--
Ingo
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg: Zero subtitle packet padding
Fixes uninitialized reads in the sub-lrc-remux test.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 632ac25cb2..1089cc48c4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1118,7 +1118,7 @@ static void do_subtitle_out(OutputFile *of,
exit_program(1);
}
-pkt->size = subtitle_out_size;
+av_shrink_packet(pkt, subtitle_out_size);
pkt->pts = av_rescale_q(sub->pts, AV_TIME_BASE_Q, ost->mux_timebase);
pkt->duration = av_rescale_q(sub->end_display_time, (AVRational){ 1,
1000 }, ost->mux_timebase);
if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE) {
--
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".
Re: [FFmpeg-devel] [PATCH v4] ffmpeg: add option -isync
On 2022-07-14 04:01 pm, Paul B Mahol wrote: On Thu, Jul 14, 2022 at 12:21 PM Gyan Doshi wrote: Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8 and cherry-picked to 5.1 Why? The cherry-pick? Because 5.1 hasn't been tagged yet as already explained in my last msg in v3 thread. 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 v4] ffmpeg: add option -isync
On Thu, Jul 14, 2022 at 12:21 PM Gyan Doshi wrote:
> Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8
> and cherry-picked to 5.1
>
Why?
>
> On 2022-07-14 01:46 pm, Gyan Doshi wrote:
> > This is a per-file input option that adjusts an input's timestamps
> > with reference to another input, so that emitted packet timestamps
> > account for the difference between the start times of the two inputs.
> >
> > Typical use case is to sync two or more live inputs such as from capture
> > devices. Both the target and reference input source timestamps should be
> > based on the same clock source.
> >
> > If either input lacks starting timestamps, then no sync adjustment is
> made.
> > ---
> > v4 change: fallback on reception timestamp removed.
> >
> > doc/ffmpeg.texi | 15 +++
> > fftools/ffmpeg.h | 2 ++
> > fftools/ffmpeg_opt.c | 60
> > 3 files changed, 77 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 1a534ff1cc..767df69b7f 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -518,6 +518,21 @@ see @ref{time duration syntax,,the Time duration
> section in the ffmpeg-utils(1)
> > Like the @code{-ss} option but relative to the "end of file". That is
> negative
> > values are earlier in the file, 0 is at EOF.
> >
> > +@item -isync @var{input_index} (@emph{input})
> > +Assign an input as a sync source.
> > +
> > +This will take the difference between the start times of the target and
> reference inputs and
> > +offset the timestamps of the target file by that difference. The source
> timestamps of the two
> > +inputs should derive from the same clock source for expected results.
> If @code{copyts} is set
> > +then @code{start_at_zero} must also be set. If either of the inputs has
> no starting timestamp
> > +then no sync adjustment is made.
> > +
> > +Acceptable values are those that refer to a valid ffmpeg input index.
> If the sync reference is
> > +the target index itself or @var{-1}, then no adjustment is made to
> target timestamps. A sync
> > +reference may not itself be synced to any other input.
> > +
> > +Default value is @var{-1}.
> > +
> > @item -itsoffset @var{offset} (@emph{input})
> > Set the input time offset.
> >
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 99d31c346e..391a35cf50 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -118,6 +118,7 @@ typedef struct OptionsContext {
> > float readrate;
> > int accurate_seek;
> > int thread_queue_size;
> > +int input_sync_ref;
> >
> > SpecifierOpt *ts_scale;
> > intnb_ts_scale;
> > @@ -410,6 +411,7 @@ typedef struct InputFile {
> >at the moment when looping happens */
> > AVRational time_base; /* time base of the duration */
> > int64_t input_ts_offset;
> > +int input_sync_ref;
> >
> > int64_t ts_offset;
> > int64_t last_ts;
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index e08455478f..359d8f60b8 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -235,6 +235,7 @@ static void init_options(OptionsContext *o)
> > o->chapters_input_file = INT_MAX;
> > o->accurate_seek = 1;
> > o->thread_queue_size = -1;
> > +o->input_sync_ref = -1;
> > }
> >
> > static int show_hwaccels(void *optctx, const char *opt, const char
> *arg)
> > @@ -287,6 +288,59 @@ static int parse_and_set_vsync(const char *arg, int
> *vsync_var, int file_idx, in
> > return 0;
> > }
> >
> > +static int apply_sync_offsets(void)
> > +{
> > +for (int i = 0; i < nb_input_files; i++) {
> > +InputFile *ref, *self = input_files[i];
> > +int64_t adjustment;
> > +int64_t self_start_time, ref_start_time, self_seek_start,
> ref_seek_start;
> > +int start_times_set = 1;
> > +
> > +if (self->input_sync_ref == -1 || self->input_sync_ref == i)
> continue;
> > +if (self->input_sync_ref >= nb_input_files ||
> self->input_sync_ref < -1) {
> > +av_log(NULL, AV_LOG_FATAL, "-isync for input %d references
> non-existent input %d.\n", i, self->input_sync_ref);
> > +exit_program(1);
> > +}
> > +
> > +if (copy_ts && !start_at_zero) {
> > +av_log(NULL, AV_LOG_FATAL, "Use of -isync requires that
> start_at_zero be set if copyts is set.\n");
> > +exit_program(1);
> > +}
> > +
> > +ref = input_files[self->input_sync_ref];
> > +if (ref->input_sync_ref != -1 && ref->input_sync_ref !=
> self->input_sync_ref) {
> > +av_log(NULL, AV_LOG_ERROR, "-isync for input %d references
> a resynced input %d. Sync not set.\n", i, self->input_sync_ref);
> > +continue;
> > +}
> > +
> > +if (self->ctx->start_time_realtime != AV_NOPTS_VALUE &&
> ref->ctx->start_time_realtime != AV_NOPTS_VALUE) {
> > +self_start_time =
Re: [FFmpeg-devel] [PATCH v4] ffmpeg: add option -isync
Pushed as 882aac99d2a7d15492ce1da9859676b0c04295b8
and cherry-picked to 5.1
On 2022-07-14 01:46 pm, Gyan Doshi wrote:
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start times of the two inputs.
Typical use case is to sync two or more live inputs such as from capture
devices. Both the target and reference input source timestamps should be
based on the same clock source.
If either input lacks starting timestamps, then no sync adjustment is made.
---
v4 change: fallback on reception timestamp removed.
doc/ffmpeg.texi | 15 +++
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 60
3 files changed, 77 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 1a534ff1cc..767df69b7f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -518,6 +518,21 @@ see @ref{time duration syntax,,the Time duration section
in the ffmpeg-utils(1)
Like the @code{-ss} option but relative to the "end of file". That is negative
values are earlier in the file, 0 is at EOF.
+@item -isync @var{input_index} (@emph{input})
+Assign an input as a sync source.
+
+This will take the difference between the start times of the target and
reference inputs and
+offset the timestamps of the target file by that difference. The source
timestamps of the two
+inputs should derive from the same clock source for expected results. If
@code{copyts} is set
+then @code{start_at_zero} must also be set. If either of the inputs has no
starting timestamp
+then no sync adjustment is made.
+
+Acceptable values are those that refer to a valid ffmpeg input index. If the
sync reference is
+the target index itself or @var{-1}, then no adjustment is made to target
timestamps. A sync
+reference may not itself be synced to any other input.
+
+Default value is @var{-1}.
+
@item -itsoffset @var{offset} (@emph{input})
Set the input time offset.
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 99d31c346e..391a35cf50 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -118,6 +118,7 @@ typedef struct OptionsContext {
float readrate;
int accurate_seek;
int thread_queue_size;
+int input_sync_ref;
SpecifierOpt *ts_scale;
intnb_ts_scale;
@@ -410,6 +411,7 @@ typedef struct InputFile {
at the moment when looping happens */
AVRational time_base; /* time base of the duration */
int64_t input_ts_offset;
+int input_sync_ref;
int64_t ts_offset;
int64_t last_ts;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index e08455478f..359d8f60b8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -235,6 +235,7 @@ static void init_options(OptionsContext *o)
o->chapters_input_file = INT_MAX;
o->accurate_seek = 1;
o->thread_queue_size = -1;
+o->input_sync_ref = -1;
}
static int show_hwaccels(void *optctx, const char *opt, const char *arg)
@@ -287,6 +288,59 @@ static int parse_and_set_vsync(const char *arg, int
*vsync_var, int file_idx, in
return 0;
}
+static int apply_sync_offsets(void)
+{
+for (int i = 0; i < nb_input_files; i++) {
+InputFile *ref, *self = input_files[i];
+int64_t adjustment;
+int64_t self_start_time, ref_start_time, self_seek_start,
ref_seek_start;
+int start_times_set = 1;
+
+if (self->input_sync_ref == -1 || self->input_sync_ref == i) continue;
+if (self->input_sync_ref >= nb_input_files || self->input_sync_ref <
-1) {
+av_log(NULL, AV_LOG_FATAL, "-isync for input %d references non-existent
input %d.\n", i, self->input_sync_ref);
+exit_program(1);
+}
+
+if (copy_ts && !start_at_zero) {
+av_log(NULL, AV_LOG_FATAL, "Use of -isync requires that start_at_zero
be set if copyts is set.\n");
+exit_program(1);
+}
+
+ref = input_files[self->input_sync_ref];
+if (ref->input_sync_ref != -1 && ref->input_sync_ref !=
self->input_sync_ref) {
+av_log(NULL, AV_LOG_ERROR, "-isync for input %d references a resynced
input %d. Sync not set.\n", i, self->input_sync_ref);
+continue;
+}
+
+if (self->ctx->start_time_realtime != AV_NOPTS_VALUE &&
ref->ctx->start_time_realtime != AV_NOPTS_VALUE) {
+self_start_time = self->ctx->start_time_realtime;
+ref_start_time = ref->ctx->start_time_realtime;
+} else if (self->ctx->start_time != AV_NOPTS_VALUE &&
ref->ctx->start_time != AV_NOPTS_VALUE) {
+self_start_time = self->ctx->start_time;
+ref_start_time = ref->ctx->start_time;
+} else {
+start_times_set = 0;
+}
+
+if (start_times_set) {
+self_seek_start = self->start_time == AV_NOPTS_VALUE ? 0 :
Re: [FFmpeg-devel] [PATCH v3] ffmpeg: add option -isync
On 2022-07-14 01:45 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-07-14 09:47:17) On 2022-07-14 12:16 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-07-10 20:02:38) On 2022-07-10 10:46 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-07-08 05:56:21) On 2022-07-07 03:11 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-07-04 18:29:12) This is a per-file input option that adjusts an input's timestamps with reference to another input, so that emitted packet timestamps account for the difference between the start times of the two inputs. Typical use case is to sync two or more live inputs such as from capture devices. Both the target and reference input source timestamps should be based on the same clock source. If not all inputs have timestamps, the wallclock times at the time of reception of inputs shall be used. FFmpeg must have been compiled with thread support for this last case. I'm wondering if simply using the other input's InputFile.ts_offset wouldn't achieve the same effect with much less complexity. That's what I initially did. But since the code can also use two other sources for start times (start_time_realtime, first_pkt_wallclock), those intervals may not exactly match the difference between fmctx->start_times so I use a generic calculation. In what cases is it better to use either of those two other sources? As per the commit message, the timestamps of both inputs are supposed to come from the same clock. Then it seems to me that offsetting each of those streams by different amounts would break synchronization rather than improve it. The first preference, when available, stores the epoch time closest to time of capture. That would eliminate some jitter. The 2nd preference is the fmctx->start_time. The 3rd is the reception wallclock. It is a fallback. It will likely lead to the worst sync. In which cases is this fallback useful? I would expect that all transports you'd want to use this with will have working timestamps. Agreed. I just kept it as a last resort scenario. Can do without it. No more objections to this patch, with this fallback dropped. Thanks. Since n5.1 hasn't been tagged just yet; will cherry-pick. 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 v4] ffmpeg: add option -isync
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start times of the two inputs.
Typical use case is to sync two or more live inputs such as from capture
devices. Both the target and reference input source timestamps should be
based on the same clock source.
If either input lacks starting timestamps, then no sync adjustment is made.
---
v4 change: fallback on reception timestamp removed.
doc/ffmpeg.texi | 15 +++
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 60
3 files changed, 77 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 1a534ff1cc..767df69b7f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -518,6 +518,21 @@ see @ref{time duration syntax,,the Time duration section
in the ffmpeg-utils(1)
Like the @code{-ss} option but relative to the "end of file". That is negative
values are earlier in the file, 0 is at EOF.
+@item -isync @var{input_index} (@emph{input})
+Assign an input as a sync source.
+
+This will take the difference between the start times of the target and
reference inputs and
+offset the timestamps of the target file by that difference. The source
timestamps of the two
+inputs should derive from the same clock source for expected results. If
@code{copyts} is set
+then @code{start_at_zero} must also be set. If either of the inputs has no
starting timestamp
+then no sync adjustment is made.
+
+Acceptable values are those that refer to a valid ffmpeg input index. If the
sync reference is
+the target index itself or @var{-1}, then no adjustment is made to target
timestamps. A sync
+reference may not itself be synced to any other input.
+
+Default value is @var{-1}.
+
@item -itsoffset @var{offset} (@emph{input})
Set the input time offset.
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 99d31c346e..391a35cf50 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -118,6 +118,7 @@ typedef struct OptionsContext {
float readrate;
int accurate_seek;
int thread_queue_size;
+int input_sync_ref;
SpecifierOpt *ts_scale;
intnb_ts_scale;
@@ -410,6 +411,7 @@ typedef struct InputFile {
at the moment when looping happens */
AVRational time_base; /* time base of the duration */
int64_t input_ts_offset;
+int input_sync_ref;
int64_t ts_offset;
int64_t last_ts;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index e08455478f..359d8f60b8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -235,6 +235,7 @@ static void init_options(OptionsContext *o)
o->chapters_input_file = INT_MAX;
o->accurate_seek = 1;
o->thread_queue_size = -1;
+o->input_sync_ref = -1;
}
static int show_hwaccels(void *optctx, const char *opt, const char *arg)
@@ -287,6 +288,59 @@ static int parse_and_set_vsync(const char *arg, int
*vsync_var, int file_idx, in
return 0;
}
+static int apply_sync_offsets(void)
+{
+for (int i = 0; i < nb_input_files; i++) {
+InputFile *ref, *self = input_files[i];
+int64_t adjustment;
+int64_t self_start_time, ref_start_time, self_seek_start,
ref_seek_start;
+int start_times_set = 1;
+
+if (self->input_sync_ref == -1 || self->input_sync_ref == i) continue;
+if (self->input_sync_ref >= nb_input_files || self->input_sync_ref <
-1) {
+av_log(NULL, AV_LOG_FATAL, "-isync for input %d references
non-existent input %d.\n", i, self->input_sync_ref);
+exit_program(1);
+}
+
+if (copy_ts && !start_at_zero) {
+av_log(NULL, AV_LOG_FATAL, "Use of -isync requires that
start_at_zero be set if copyts is set.\n");
+exit_program(1);
+}
+
+ref = input_files[self->input_sync_ref];
+if (ref->input_sync_ref != -1 && ref->input_sync_ref !=
self->input_sync_ref) {
+av_log(NULL, AV_LOG_ERROR, "-isync for input %d references a
resynced input %d. Sync not set.\n", i, self->input_sync_ref);
+continue;
+}
+
+if (self->ctx->start_time_realtime != AV_NOPTS_VALUE &&
ref->ctx->start_time_realtime != AV_NOPTS_VALUE) {
+self_start_time = self->ctx->start_time_realtime;
+ref_start_time = ref->ctx->start_time_realtime;
+} else if (self->ctx->start_time != AV_NOPTS_VALUE &&
ref->ctx->start_time != AV_NOPTS_VALUE) {
+self_start_time = self->ctx->start_time;
+ref_start_time = ref->ctx->start_time;
+} else {
+start_times_set = 0;
+}
+
+if (start_times_set) {
+self_seek_start = self->start_time == AV_NOPTS_VALUE ? 0 :
self->start_time;
+ref_seek_start = ref->start_time == AV_NOPTS_VALUE ? 0 :
ref->start_time;
+
+adjustment = (self_start_time -
