Attached.
From 4c9bf661c74e598c623d05e4a170e5b48150e7cd Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 6 May 2023 01:50:08 +0200
Subject: [PATCH] avfilter/af_replaygain: export results into read-only options
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 10 ++
Similar to the decoder AVOptions above.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 12
tests/ref/fate/flv-demux | 4 ++--
tests/ref/fate/ts-demux | 6 +++---
tests/ref/fate/ts-opus-demux | 2 +-
tests/ref/fate/ts-small-demux | 2 +-
5 files
On 4/16/2023 1:48 PM, Michael Niedermayer wrote:
Fixes: signed integer overflow: 3011809745540902265 + 6323452730883571725
cannot be represented in type 'long'
Fixes:
45982/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-6687553022722048
Found-by: continuous fuzzing process
On Sat, May 06, 2023 at 12:24:15AM +0200, Paul B Mahol wrote:
> On Sat, May 6, 2023 at 12:15 AM Michael Niedermayer
> wrote:
>
> > On Tue, Apr 18, 2023 at 12:45:01AM +0200, Michael Niedermayer wrote:
> > > On Mon, Apr 17, 2023 at 09:04:48AM +0200, Paul B Mahol wrote:
> > > > NAK, breaks
On Sat, May 6, 2023 at 12:15 AM Michael Niedermayer
wrote:
> On Tue, Apr 18, 2023 at 12:45:01AM +0200, Michael Niedermayer wrote:
> > On Mon, Apr 17, 2023 at 09:04:48AM +0200, Paul B Mahol wrote:
> > > NAK, breaks decoding.
> >
> > The file you posted decodes the same before and after the patch
On Tue, Apr 18, 2023 at 12:45:01AM +0200, Michael Niedermayer wrote:
> On Mon, Apr 17, 2023 at 09:04:48AM +0200, Paul B Mahol wrote:
> > NAK, breaks decoding.
>
> The file you posted decodes the same before and after the patch
> is there some other issue ?
> or is tha patch ok with the whitespace
On Tue, May 02, 2023 at 05:39:27PM +0200, Paul B Mahol wrote:
> approved
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
Rework the code a bit to speed up the 10-bit bitpacked decoding
routine. This is probably about as fast as I can get it without
switching to assembly language.
Demonstratable with:
./ffmpeg -f lavfi -i "smptehdbars=size=3840x2160" -c bitpacked -f image2
-frames:v 1 source.yuv
./ffmpeg -f
On Thu, May 04, 2023 at 07:23:02AM +0800, Steven Liu wrote:
> Michael Niedermayer 于2023年5月3日周三 20:30写道：
> >
> > Its unexpected that a .avi or other "standard" file turns into a playlist.
> > The goal of this patch is to avoid this unexpected behavior and possible
> > privacy or security
On Fri, May 05, 2023 at 02:31:23PM +0300, Jan Ekström wrote:
> From: Martin Machalek
>
> Adds DTS to packets which would otherwise break tbr calculation
> within libavformat, as well as packet rate calculation in ffmpeg.
>
> An example of such input would be an MPEG-TS stream where a whole
>
Am 01.05.23 um 14:18 schrieb Marvin Scholz:
When no drawing is to be performed, tpad can work fine with
hardware frames, so advertise this in the query_formats
callback and ensure the drawing context is never initialised
when just cloning frames.
---
libavfilter/vf_tpad.c | 14 +++---
Hi,
Am 01.05.23 um 14:18 schrieb Marvin Scholz:
---
libavfilter/vf_tpad.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_tpad.c b/libavfilter/vf_tpad.c
index f0c065f0c3..88c3c99de4 100644
--- a/libavfilter/vf_tpad.c
+++
Attached.
From 0baf7e9f94e42f19f99fc4ff97936b7afe9230ae Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 May 2023 20:48:10 +0200
Subject: [PATCH 1/2] avfilter/af_asetnsamples: add commands support
Signed-off-by: Paul B Mahol
---
libavfilter/af_asetnsamples.c | 3 ++-
1 file changed, 2
The existing implementation made an attempt to remove duplicate
captions if increasing the framerate, but made no attempt to
handle reducing the framerate, nor did it rewrite the caption
payloads to have the appropriate cc_count (e.g. the cc_count needs
to change from 20 to 10 when going from
THis filter can correct certain issues seen from upstream sources
where the cc_count is not properly set or the CEA-608 tuples are
not at the start of the payload as expected.
Make use of the ccfifo to extract and immediately repack the CEA-708
side data, thereby removing any extra padding and
Unlike other cases where the closed captions are embedded in the
video stream as MPEG-2 userdata or H.264 SEI data, with MOV files
the captions are often found on a separate "e608" subtitle track.
Add support for playout of such files, leveraging the new ccfifo
mechanism to ensure that they are
Because the interlacing filter halves the effective framerate, we
need to ensure that no CEA-708 data is lost as frames are merged.
Make use of the new ccfifo mechanism to ensure that caption data
is properly preserved as frames pass through the filter.
Thanks to Thomas Mundt for review and
Various deinterlacing modes have the effect of doubling the
framerate, and we need to ensure that the caption data isn't
duplicated (or else you get double captions on-screen).
Use the new ccfifo mechanism for yadif (and yadif_cuda and bwdif
since they use the same yadif core) so that CEA-708
When transcoding video that contains 708 closed captions, the
caption data is tied to the frames as side data. Simply dropping
or adding frames to change the framerate will result in loss of
data, so the caption data needs to be preserved and reformatted.
For example, without this patch
Updated series that includes the change requested by Lance Wang and
the fate test reported by Michael Niedermayer. Also includes a fix for
a 58-byte memory leak on uninitialization detected via valgrind while
debugging the fate issue.
Devin Heitmueller (6):
ccfifo: Properly handle CEA-708
Am 27.04.23 um 20:08 schrieb Thilo Borgmann:
Hi,
support for animated WebP had been proposed twice in the past [1][2].
This did stall when Lynne called for some review on the demuxer in [1].
So these are the rebased patches from [1], pinging especially for demuxer
review.
Retested decoding
Hi Martin,
I updated these patches based on your comments, please help to review it
again. And My reply is as follows :
在 2023/5/4 16:49, Martin Storsjö 写道:
On Wed, 3 May 2023, myais wrote:
Hello,
- I splited this patch, Do I need to resubmit or just attach them as
attachments? (I
On Fri, May 5, 2023 at 10:10 AM Lance Wang wrote:
> > +int ff_ccfifo_inject(AVCCFifo *ccf, AVFrame *frame)
> > +{
> > +AVFrameSideData *sd;
> > +int ret;
> > +
> > +if (ccf->passthrough == 1 || ccf->cc_detected == 0)
> > +return 0;
> > +
> > +sd =
Hi Michael,
Thanks for testing.
On Fri, May 5, 2023 at 10:10 AM Michael Niedermayer
wrote:
> breaks fate
>
> make -j32 fate-filter-fps-down-eof-pass
Yeah, this was actually introduced in the last series due to removal
of the NULL checks per Anton's review of the patch. We need to put
one of
On Thu, May 04, 2023 at 06:02:16PM -0400, Devin Heitmueller wrote:
> The existing implementation made an attempt to remove duplicate
> captions if increasing the framerate, but made no attempt to
> handle reducing the framerate, nor did it rewrite the caption
> payloads to have the appropriate
On Fri, May 5, 2023 at 5:07 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> When transcoding video that contains 708 closed captions, the
> caption data is tied to the frames as side data. Simply dropping
> or adding frames to change the framerate will result in loss of
> data,
From: Romain Beauxis
This patch is the last of a series of patch to enhance FFmpeg's handling of
chained ogg streams.
Documentation for chained (and multiplexed) ogg bitstream can be found here:
https://xiph.org/ogg/doc/oggstream.html
My understanding of the current code is that the ogg
From: Romain Beauxis
This patch provides the same functionality as the previous patch but for
ogg/opus.
The need to accept empty packets on end of stream (EOS) is explained in the
final patch of the series.
---
libavformat/oggparseopus.c | 26 ++
1 file changed, 18
From: Romain Beauxis
This is the second version of a patch to add support for in-stream metadata
updates in the ogg/flac parser.
Currently, FFmpeg is unable to decode metadata in chained ogg/flac bitstreams
past the initial track. This impacts all users relying on the FFmpeg backend to
decode
Hi,
Not really. My old key had to be revoked, so it should probably not be listed
there.
(Sorry for top post)
Le 4 mai 2023 21:59:29 GMT+03:00, James Almer a écrit :
>On 5/3/2023 1:10 PM, Rémi Denis-Courmont wrote:
>> ---
>> MAINTAINERS | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff
Quoting Jan Ekström (2023-05-05 13:31:23)
> From: Martin Machalek
>
> Adds DTS to packets which would otherwise break tbr calculation
> within libavformat, as well as packet rate calculation in ffmpeg.
>
> An example of such input would be an MPEG-TS stream where a whole
> GOP is put into a
> On May 5, 2023, at 19:31, Jan Ekström wrote:
>
> From: Martin Machalek
>
> Adds DTS to packets which would otherwise break tbr calculation
> within libavformat, as well as packet rate calculation in ffmpeg.
>
> An example of such input would be an MPEG-TS stream where a whole
> GOP is put
From: Martin Machalek
Adds DTS to packets which would otherwise break tbr calculation
within libavformat, as well as packet rate calculation in ffmpeg.
An example of such input would be an MPEG-TS stream where a whole
GOP is put into a single PES packet.
Co-authored-by: Jan Ekström
There is an if condition "FFALIGN(linesize[i], align) == linesize[i]
src_linesize[i] == linesize[i]".
When src's linesize equals to dst, it has no padding in this case I think. If
has padding, it will execute
previous process. As a result, we could ignore the situation of padding in this
case.
It is not used outside of ffmpeg_filter.
---
fftools/ffmpeg.h| 2 --
fftools/ffmpeg_filter.c | 7 +--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 525a00bfcb..0231ebc84f 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@
Avoids the pointless overhead of transferring them to the main thread.
---
fftools/ffmpeg.c | 4
fftools/ffmpeg_demux.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1ae9445b5d..0edcd3466e 100644
--- a/fftools/ffmpeg.c
The two checks using eof_reached are testing whether more input can
possibly appear on this filtergraph input. InputFilterPriv.eof is the
more authoritative source for this information.
---
fftools/ffmpeg_filter.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
This code more properly belongs there.
---
fftools/ffmpeg.c| 25 +
fftools/ffmpeg_filter.c | 27 +++
2 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 38569c60a4..1ae9445b5d 100644
---
It is shorter and more efficient.
---
fftools/ffmpeg_filter.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 34c51c23d9..0165be8f77 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1415,7
These two functions are a part of a single logical action - determining
which, if any, output stream needs to be processed next. Keeping them
separate is a historical artifact that obscures what is actually being
done.
---
fftools/ffmpeg.c | 41 +++--
1 file
When an input stream terminates and no frames were successfully decoded,
filtering code will currently configure the filtergraph using demuxer
stream parameters. Use decoder parameters instead, which should be more
reliable. Also, initialize them immediately when an input stream is
bound to a
It is not used outside of ffmpeg_filter.
---
fftools/ffmpeg.h| 2 --
fftools/ffmpeg_filter.c | 16 +---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 8a2254d2a8..c7e225d1a0 100644
--- a/fftools/ffmpeg.h
+++
Replace it by simply calling choose_output() earlier.
---
fftools/ffmpeg.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8c1c5b7fec..983573b991 100644
--- a/fftools/ffmpeg.c
+++
It is not used outside of ffmpeg_filter.
---
fftools/ffmpeg.h| 1 -
fftools/ffmpeg_filter.c | 15 +--
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 0231ebc84f..8a2254d2a8 100644
--- a/fftools/ffmpeg.h
+++
When no frames are ever seen by an encoder, encoder flush will do a
last-ditch attempt to configure its source filtergraph in order to at
least get the stream parameters. This involves extracting demuxer
parameters from filtergraph source inputs, which is
* a bad layering violation
* probably
From: Zhao Zhili
Fix ticket #10342.
Signed-off-by: Zhao Zhili
---
fftools/ffmpeg_opt.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index cf385c388e..002df84dcc 100644
--- a/fftools/ffmpeg_opt.c
+++
It makes sense when copying 4K/8K video frame, got 2.7% speed up.
When the condition is no padding and src_linesize equals to dst,
we could copy plane instead of line by line.
beforeafter rate
4K video:
9145 89981.6%
9804 94653.4%
9645 93942.6%
8K video:
28411
Hi all,
any chance someone could possibly have a look at this patch, please?
Thanks in advance
Elias
On Wed, 2023-05-03 at 12:27 +, Carotti, Elias wrote:
> Sorry to revive an old thread, but I updated the patch for ffmpeg 6
> and
> this new patch should address the comments.
> Still this is
48 matches
Mail list logo
