> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Monday, 30 August 2021 06:20
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/20] clean-up QSV filters
>
> On Thu, 2021-08-05 at 16:21 +, Soft Works wrote:
> > > -Original
On Thu, 2021-08-05 at 16:21 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Thursday, 5 August 2021 10:19
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH v5 00/20] clean-up QSV filters
avcodec/vorbisdec: Return value check for init_get_bits
As the second argument for init_get_bits can be crafted,
a return value check for this function call is necessary.
Also replace init_get_bits with init_get_bits8.
---
libavcodec/vorbisdec.c | 8 ++--
1 file changed, 6 insertions(+), 2
avcodec/vble: Return value check for init_get_bits
Similar to CVE-2021-38171 as the second argument for init_get_bits()
can be crafted, a return value check for this function call is necessary.
Also replace init_get_bits with init_get_bits8.
---
libavcodec/vble.c | 4 +++-
1 file changed, 3
On Fri, 2021-08-27 at 19:09 +0200, Hendrik Leppkes wrote:
> On Fri, Aug 27, 2021 at 1:54 PM Fei Wang
> wrote:
> >
> > Since av1 decoder is only available for hw acceleration. This will
> > gives out more accurate information if this decoder used but
> > doesn't
> > specificed a hwaccel.
> >
> >
From: Niklas Haas
This comment was wrong. It does not require an FFT, a straight sum is
enough. (An FFT is only required for high-passed grain, not generational
grain)
Also fix a misleading/redundant comment on avg_8x8_c - the right shift
is just part of the averaging logic.
---
Currently the APTX (HD) codecs set frame_size if unset and check
whether it is divisible by block_size (corresponding to block_align
as used by other codecs). But this is based upon a misunderstanding
of the API: frame_size is not in bytes, but in samples.*
Said value is also not intended to be
Otherwise one could read into the frame's padding when one encounters
the small last frame.
Signed-off-by: Andreas Rheinhardt
---
With this patch the last few samples of the last frame will be ignored.
It would be possible to avoid that by padding the frame to a multiple
of four samples. This
The APTX (HD) decoder decodes blocks of four (six) bytes to four
output samples. It makes no sense to handle incomplete blocks:
They would just lead to synchronization errors, in which case
the complete frame is discarded. So only handle complete blocks.
This also avoids reading from the packet's
It automatically honours block_align and it clears the
AV_PKT_FLAG_CORRUPT flag which up until now was always set
for the last packet if the number of input blocks was not
divisible by 256 (or equivalently: if the number of input
samples was not divisible by 1024).
It reads more data at once;
This field was misunderstood: It gives the number of samples
in a packet, not the number of bytes. Its usage was wrong for APTX HD.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aptxdec.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
APTX decodes four bytes of input to four stereo samples; APTX HD
does the same with six bytes of input. So it can be easily supported
in av_get_audio_frame_duration().
This fixes invalid durations and (derived) timestamps of demuxed
APTX HD packets and therefore fixed the timestamp in the aptx-hd
We have de- and encoders for APTX and APTX HD, yet not FATE tests.
This commit therefore adds a transcoding test to utilize them.
Furthermore, during creating these tests it turned out that
the duration is set incorrectly for APTX HD. This will be fixed
in a future commit.
Signed-off-by: Andreas
Up until now, the transcode() function allowed (and required) to specify
the input format as well as the format of the output format (i.e. the
muxer) of the generated file. But for reading the generated file
it relied on autodetection/probing. This does not always work, e.g.
not for aptx_hd, and
Also covers muxing and demuxing of nonstandard FLAC channel layouts
and the multi-dim-quant option of the FLAC encoder
(all of which was hitherto uncovered).
Signed-off-by: Andreas Rheinhardt
---
tests/fate/cover-art.mak| 10 +++
tests/ref/fate/cover-art-flac-remux | 111
This brings the FLAC demuxer in line with all the other demuxers.
Furthermore, if it is not done and the FLAC decoder is disabled,
the FLAC parser will overwrite the channel layout with the standard
channel layout for that number of channels.
Signed-off-by: Andreas Rheinhardt
---
One could
This allows nicer tests by having a greater range of inputs available
(without requiring adding further samples to the fate-suite).
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/fate-run.sh
Andreas Rheinhardt:
> The WebM DASH Manifest demuxer creates a comma-delimited list of
> all the timestamps of index entries. It allocates 20 bytes per
> timestamp; yet the largest 64bit numbers have 20 decimal digits
> (for int64_t it can be '-'+ 19 digits), so that one needs 21B
> per entry
On Sun, Aug 29, 2021 at 06:48:36PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-08-09 22:30:06)
> > On Sun, Aug 08, 2021 at 07:29:41PM +0200, Anton Khirnov wrote:
> > > ---
> > > libavfilter/vf_scale.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git
On Thu, Aug 26, 2021 at 09:50:15PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 9223372034248226491 + 3275247799 cannot be
> represented in type 'long'
> Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4538729166077952
>
> Reported-by: Matt Wolenetz
>
On Sun, Aug 29, 2021 at 9:21 PM Paul B Mahol wrote:
>
> probably fine if fate passes
Yea, FATE passes :) . I think this stuff not being noticed until now
is due to nothing checking the metadata values returned by vf_scale
(since pix_fmt and actual logic is not changed at all with these
output
probably fine if fate passes
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Sun, Aug 29, 2021 at 8:12 PM Paul B Mahol wrote:
>
> LGTM
Thanks, applied this patch as 06ce821bc7622c1394c5179fb69cabf02dd24869 .
Now it's just the chroma location coding bits.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Diederick C. Niehorster (12021-08-25):
> Several core developers stated to be in favor of locking lavd<->lavf
> together at the minor version, for instance since it solves a lot of
> the problems the intimate linking between the two libraries creates.
> Should this be turned into a patch somehow
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Signed-off-by: Paul B Mahol
---
libavcodec/gif.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 5e7cc47206..6f389c8ac3 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -514,6 +514,7 @@ static int gif_encode_frame(AVCodecContext *avctx,
Signed-off-by: Paul B Mahol
---
libavformat/gif.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/gif.c b/libavformat/gif.c
index cba87d3eae..61a45d73ca 100644
--- a/libavformat/gif.c
+++ b/libavformat/gif.c
@@ -87,6 +87,8 @@ static int gif_get_delay(GIFContext *gif, AVPacket
Quoting Michael Niedermayer (2021-08-09 22:30:06)
> On Sun, Aug 08, 2021 at 07:29:41PM +0200, Anton Khirnov wrote:
> > ---
> > libavfilter/vf_scale.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index b62fb37d4b..14e202bf77
Unlike libx264, libx265 does not handle the chroma format check
on its own side, so in order to not write out values which are
supposed to be ignored according to the specification, we limit
the writing out of chroma sample location to 4:2:0 only.
---
libavcodec/libx265.c | 13 +
1
Now both current usages utilize an already found descriptor.
---
libavcodec/libx265.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index b5c94b64a3..71affbf61b 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@
---
Updated to conform to the slice alignment requirements
---
libswscale/options.c | 3 ++
libswscale/swscale.c | 59 +
libswscale/swscale_internal.h | 14 ++
libswscale/utils.c| 82 +++
4 files changed,
---
Now with a new public function to query required slice alignment, which
fixes the yuv410p->yuv420p conversion issue reported by Michael.
---
libswscale/swscale.c | 294 ++
libswscale/swscale.h | 90 +++
libswscale/swscale_internal.h |
On Fri, Aug 27, 2021 at 12:58 AM Jan Ekström wrote:
>
> On Tue, Aug 24, 2021 at 12:47 AM Jan Ekström wrote:
> >
> > ---
> > libavcodec/libx264.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index d48e142e41..379c167e6f 100644
>
Fixed some minor issues and major ones (NANs poping out) and applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with
Implements a gray world color correction algorithm
using a log scale LAB colorspace
Signed-off-by: Paul Buxton
---
doc/filters.texi | 12 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_grayworld.c | 352
You're right those are unused now that the else statement is gone. Removing
and checking now.
Sorry this is turning into a bit of a grind!
On Sun, Aug 29, 2021 at 9:12 AM Paul Buxton
wrote:
> Implemants a gray world color correction algorithm
> using a log scale LAB colorspace
> ---
>
On Sun, Aug 29, 2021 at 10:12 AM Paul Buxton
wrote:
> Implemants a gray world color correction algorithm
>
Typo.
> using a log scale LAB colorspace
> ---
> doc/filters.texi | 12 ++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/version.h
Implemants a gray world color correction algorithm
using a log scale LAB colorspace
---
doc/filters.texi | 12 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_grayworld.c | 362
On Sun, Aug 29, 2021 at 9:39 AM Paul Buxton
wrote:
> Regarding the indentation. I think you mean adding whitespace to line up
> the values?
> I don't believe that is K, but sure. How far should I take it? Just the
> initialisers in the structure you indicated, or should I try and line up
> some
Regarding the indentation. I think you mean adding whitespace to line up
the values?
I don't believe that is K, but sure. How far should I take it? Just the
initialisers in the structure you indicated, or should I try and line up
some of the accesses to other structure members, which I see some
40 matches
Mail list logo
