[FFmpeg-devel] [PATCH] fftools/ffmpeg: prefer real errors over EOF in err_merge()

2024-07-23 Thread Anton Khirnov
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

2024-04-05 Thread Andreas Rheinhardt
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

2024-03-22 Thread Anton Khirnov
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

2024-03-19 Thread Stefano Sabatini
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

2024-03-14 Thread Anton Khirnov
---
 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

2024-03-13 Thread James Almer
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

2024-02-25 Thread Mark Thompson

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

2024-02-24 Thread Anton Khirnov
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

2024-02-21 Thread Andreas Rheinhardt
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

2024-02-21 Thread Anton Khirnov
---
 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

2024-01-31 Thread Stefano Sabatini
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

2024-01-28 Thread 王昊然
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

2024-01-24 Thread Anton Khirnov
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

2024-01-24 Thread Andreas Rheinhardt
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

2024-01-24 Thread 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 = 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

2024-01-24 Thread Anton Khirnov
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

2024-01-15 Thread Marth64
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

2024-01-03 Thread Marth64
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

2023-12-11 Thread Anton Khirnov
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

2023-12-10 Thread Gyan Doshi




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

2023-12-10 Thread Marth64
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

2023-12-09 Thread Stefano Sabatini
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

2023-12-09 Thread Marth64
---
 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

2023-12-07 Thread Michael Niedermayer
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

2023-12-07 Thread Michael Niedermayer
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

2023-12-07 Thread Anton Khirnov
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

2023-12-06 Thread Anton Khirnov
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

2023-12-06 Thread Vittorio Giovara
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

2023-12-06 Thread Anton Khirnov
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

2023-12-06 Thread Cosmin Stejerean via ffmpeg-devel


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

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

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

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

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


- Cosmin





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading

2023-12-06 Thread Michael Niedermayer
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

2023-12-06 Thread Nicolas George
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

2023-12-06 Thread Nicolas George
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

2023-12-06 Thread Vittorio Giovara
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

2023-12-06 Thread Anton Khirnov
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

2023-12-06 Thread Marton Balint




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

2023-12-06 Thread Anton Khirnov
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

2023-12-06 Thread Nicolas George
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

2023-12-06 Thread Anton Khirnov
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

2023-12-06 Thread Nicolas George
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

2023-12-06 Thread Zhao Zhili

> 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

2023-12-06 Thread Nicolas George
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

2023-12-06 Thread Anton Khirnov
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

2023-11-23 Thread Anton Khirnov
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()

2023-09-05 Thread Anton Khirnov
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

2023-07-09 Thread Marton Balint




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

2023-07-03 Thread Marton Balint
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

2023-06-17 Thread Anton Khirnov
---
 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

2023-05-31 Thread Michael Niedermayer
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

2023-05-29 Thread Anton Khirnov
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

2023-05-18 Thread Anton Khirnov
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

2023-05-17 Thread Tobias Rapp

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

2023-05-17 Thread Gyan Doshi




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

2023-05-17 Thread Tobias Rapp
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

2023-04-29 Thread Anton Khirnov
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

2023-04-28 Thread Anton Khirnov
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

2023-03-03 Thread ??????
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

2023-03-03 Thread Nicolas George
"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

2023-03-03 Thread zhilizhao(赵志立)

> 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

2023-03-02 Thread xufuji456
---
 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

2023-02-28 Thread Stefano Sabatini
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

2023-02-23 Thread Davy Durham

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

2023-02-20 Thread Anton Khirnov
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

2023-02-11 Thread Gyan Doshi




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

2023-02-11 Thread Stefano Sabatini
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

2023-02-10 Thread Stefano Sabatini
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*

2023-02-10 Thread Stefano Sabatini
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*

2023-02-09 Thread Anton Khirnov
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

2023-02-08 Thread Michael Niedermayer
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

2023-02-05 Thread Gyan Doshi




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

2023-02-05 Thread Stefano Sabatini
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

2023-01-29 Thread Paul B Mahol
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

2023-01-25 Thread Anton Khirnov
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

2023-01-24 Thread Gyan Doshi




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

2023-01-24 Thread Stefano Sabatini
---
 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

2022-10-20 Thread Anton Khirnov
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

2022-10-20 Thread Rémi Denis-Courmont
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

2022-10-20 Thread Anton Khirnov
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

2022-09-22 Thread zhilizhao(赵志立)

> 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()

2022-09-17 Thread Li-Heng Chen
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()

2022-09-13 Thread Paul B Mahol
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

2022-09-01 Thread Steven Liu
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

2022-08-31 Thread Zhao Zhili
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

2022-08-22 Thread Anton Khirnov
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

2022-08-16 Thread Anton Khirnov
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

2022-08-16 Thread Andreas Rheinhardt
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

2022-08-16 Thread 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?




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

2022-08-13 Thread Anton Khirnov
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()

2022-08-12 Thread Michael Niedermayer
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()

2022-08-11 Thread Anton Khirnov
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

2022-08-06 Thread Anton Khirnov
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-31 Thread Bodecs Bela


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

2022-07-28 Thread Anton Khirnov
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

2022-07-25 Thread Ingo Oppermann
;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

2022-07-23 Thread Andreas Rheinhardt
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

2022-07-14 Thread Gyan Doshi




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

2022-07-14 Thread Paul B Mahol
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

2022-07-14 Thread Gyan Doshi

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

2022-07-14 Thread Gyan Doshi




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

2022-07-14 Thread Gyan Doshi
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 - 

  1   2   3   4   5   >