Since ffmpeg 6.1 video stats are accidentally hidden from streamcopy progress
output.
This patch re-enables video stats (like frames=) in the progress output.
---
fftools/ffmpeg.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
Quoting Jan Garcia via ffmpeg-devel (2024-07-30 20:03:33)
> Since ffmpeg 6.1 video stats are accidentally hidden from progress output
> if no filters are used.
IIUC this applies only to streamcopy, not transcoding with no
user-specified filters.
> This patch re-enables video stats (like frames=)
Since ffmpeg 6.1 video stats are accidentally hidden from progress output
if no filters are used.
This patch re-enables video stats (like frames=) in the progress output.
---
Changelog| 1 +
fftools/ffmpeg.c | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git
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
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,
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
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
> +++
---
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
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
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
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
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) +=
---
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
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
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
+++
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
> > +++
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
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 +--
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
---
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
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
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
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
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
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(-)
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
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
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
Thank you for your reminding, George.
I really ignore av_freep() above.
Please ignore this patch.
// xufuji456
----
??:
"f
"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
> 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
---
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);
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]
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
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
> > >
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:
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
> > >
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
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 |
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
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
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
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
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
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
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
---
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
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
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
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
> 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
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
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
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
> +++
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
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
-
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
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
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
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
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
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
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
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
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
ON 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".
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
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.
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
1 - 100 of 455 matches
Mail list logo
