On Sun, 2022-09-04 at 22:14 -0700, Philip Langdale wrote:
> Signed-off-by: Philip Langdale
> ---
> libswscale/input.c | 25 +
> libswscale/utils.c | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/libswscale/input.c b/libswscale/input.c
> index 92681c9c53..8032
Limit the returned value from av_cpu_count to sensible amounts
in 32 bit builds.
This chosen limit, 64, is somewhat arbitrary - a 32 bit process
is capable of creating much more than 64 threads. But in many
cases, multiple parts of the encoding pipeline (decoder, filters,
encoders) all create a po
> Gesendet: Montag, 05. September 2022 um 00:50 Uhr
> Von: "Andreas Rheinhardt"
> An: ffmpeg-devel@ffmpeg.org
> Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
> initialization
> Lukas Fellechner:
> > Andreas Rheinhardt andreas.rheinhardt at outlook.com
> > Wed Aug 31
On Sat, Sep 3, 2022 at 11:56 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Paul B Mahol:
> > The FATE does not cover 9 (old) codebook, so make sure it is still
> working.
> >
>
> It's CRC checksum didn't change in patches 2-5.
>
Set LGTM.
>
> - Andreas
>
_
From: Wang Yaqiang
For example, if the jpeg contains exif information
and the rotation direction is included in the exif,
the displaymatrix will be set on the side_data of the frame when decoding.
However, when ffplay is used to play the image,
only the side data in the stream will be determined.
Lukas Fellechner:
>> Gesendet: Montag, 05. September 2022 um 00:50 Uhr
>> Von: "Andreas Rheinhardt"
>> An: ffmpeg-devel@ffmpeg.org
>> Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
>> initialization
>> Lukas Fellechner:
>>> Andreas Rheinhardt andreas.rheinhardt at out
On 9/3/2022 6:45 PM, Paul B Mahol wrote:
Patch attached.
[...]
From 0f220489eb6402c6be3bc1d897c95fa9bc10431c Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 3 Sep 2022 23:41:38 +0200
Subject: [PATCH] avcodec/x86/flacdsp: fix bug in decorrelation
Fixes #9297
Signed-off-by: Paul B Mah
Martin Storsjö:
> Limit the returned value from av_cpu_count to sensible amounts
> in 32 bit builds.
>
> This chosen limit, 64, is somewhat arbitrary - a 32 bit process
> is capable of creating much more than 64 threads. But in many
> cases, multiple parts of the encoding pipeline (decoder, filter
On Mon, 5 Sep 2022, Andreas Rheinhardt wrote:
Martin Storsjö:
Limit the returned value from av_cpu_count to sensible amounts
in 32 bit builds.
This chosen limit, 64, is somewhat arbitrary - a 32 bit process
is capable of creating much more than 64 threads. But in many
cases, multiple parts of
Martin Storsjö:
> On Mon, 5 Sep 2022, Andreas Rheinhardt wrote:
>
>> Martin Storsjö:
>>> Limit the returned value from av_cpu_count to sensible amounts
>>> in 32 bit builds.
>>>
>>> This chosen limit, 64, is somewhat arbitrary - a 32 bit process
>>> is capable of creating much more than 64 threads
This matches a similar cap on the number of automatic threads
in libavcodec/pthread_slice.c.
On systems with lots of cores, this does speed things up in
general (measurable on the level of the runtime of running
"make fate"), and fixes a couple fate failures in 32 bit mode on
such machines (where
On 9/4/2022 8:30 PM, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
libavfilter/avfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 965f5d0f63..6740339808 100644
--- a/libavfilter/avfilter.c
+++
>Gesendet: Montag, 05. September 2022 um 12:45 Uhr
>Von: "Andreas Rheinhardt"
>An: ffmpeg-devel@ffmpeg.org
>Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
>initialization
>Lukas Fellechner:
>>> Gesendet: Montag, 05. September 2022 um 00:50 Uhr
>>> Von: "Andreas Rheinh
On 8/25/2022 11:17 PM, Philip Langdale wrote:
static const char * const color_range_names[] = {
@@ -2778,7 +2871,7 @@ void ff_check_pixfmt_descriptors(void){
if (!d->name && !d->nb_components && !d->log2_chroma_w && !d->log2_chroma_h && !d->flags)
continue;
-//
> Gesendet: Freitag, 02. September 2022 um 01:46 Uhr
> Von: "Timo Rothenpieler"
> An: ffmpeg-devel@ffmpeg.org
> Betreff: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
> On 02.09.2022 01:32, Michael Niedermayer wrote:
>> Hi all
>>
>> Theres a use after free issue in H.264 Decoding on d3d11va w
Quoting Lukas Fellechner (2022-09-05 17:50:26)
> > Gesendet: Freitag, 02. September 2022 um 01:46 Uhr
> > Von: "Timo Rothenpieler"
> > An: ffmpeg-devel@ffmpeg.org
> > Betreff: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
> > On 02.09.2022 01:32, Michael Niedermayer wrote:
> >> Hi all
> >>
>
Patch attached.
From 81656532bdf649b43e3ac777637433b033b56d03 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 5 Sep 2022 18:12:10 +0200
Subject: [PATCH] avcodec/flac_parser: ensure there are more headers for
scoring
Previously invalid frame may be returned, happened when seeking.
Fixes #
From: Rémi Denis-Courmont
This uses the architected RISC-V 64-bit cycle counter from the
RISC-V unprivileged instruction set.
In 64-bit and 128-bit, this is a straightforward CSR read.
In 32-bit mode, the 64-bit value is exposed as two CSRs, which
cannot be read atomically, so a loop is necessar
On Sat, Sep 3, 2022 at 11:26 AM Tomas Härdin wrote:
>
> sön 2022-08-28 klockan 08:31 -0700 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > The MXF demuxer does not currently set AVStream::avg_frame_rate and
> > ::r_frame_rate
> > when J2K essence is wrapped according to SMPTE ST
Just a quick ping.
Looking forward to feedback.
This patchset is intended to address https://trac.ffmpeg.org/ticket/9842.
On Mon, Aug 22, 2022 at 10:11 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> The IMF CPL contains an optional timecode start address. This patch reads the
> latter, if pre
Patch attached.
From 01e931d2c7f50727d8893268cdc3ae0dbe75c250 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 5 Sep 2022 20:16:13 +0200
Subject: [PATCH] avcodec/flac_parser: add missed opportunity to check crc
Fixes #9621
Signed-off-by: Paul B Mahol
---
libavcodec/flac_parser.c | 11 +++
From: Pierre-Anthony Lemieux
The MXF demuxer does not currently set AVStream::avg_frame_rate and
::r_frame_rate
when J2K essence is wrapped according to SMPTE ST 422.
---
libavformat/mxfdec.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavformat/mxfdec.c b/
From: Pierre-Anthony Lemieux
---
tests/fate/mxf.mak | 4 ++
tests/ref/fate/mxf-probe-j2k | 78
2 files changed, 82 insertions(+)
create mode 100644 tests/ref/fate/mxf-probe-j2k
diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
index 3ab936b5de
Inside a function, the second ';' in ";;" is just a null statement,
but it is actually illegal outside of functions. Compilers
nevertheless accept it without warning, except when in -pedantic
mode when e.g. Clang emits a -Wextra-semi warning. Therefore
remove the unnecessary ';'.
Signed-off-by: An
On Mon, Sep 05, 2022 at 07:42:17AM +0200, Steve Lhomme wrote:
> Hi Anton,
>
> On 2022-09-02 22:59, Anton Khirnov wrote:
> > This state is not refcounted, so make sure it always has a well-defined
> > owner.
> > ---
> > Steve, could you please test this?
>
> I can confirm it doesn't leak the conte
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, September 5, 2022 7:59 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
>
> Quoting Soft Works (2022-09-04 09:43:36
On Mon, 5 Sep 2022, Martin Storsjö wrote:
This matches a similar cap on the number of automatic threads
in libavcodec/pthread_slice.c.
On systems with lots of cores, this does speed things up in
general (measurable on the level of the runtime of running
"make fate"), and fixes a couple fate fai
Ping.
This fixes Coverity issue #1512406.
On Thu, Aug 25, 2022 at 8:22 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> Fixes Coverity issue #1512406
>
> ---
> libavformat/imfdec.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/imfdec.c b/libavformat/i
Initializing DASH streams is currently slow, because each individual
stream is opened and probed sequentially. With DASH streams often
having somewhere between 10-20 streams, this can easily take up to
half a minute on slow connections.
This patch adds an "init_threads" option, specifying the max
open_url modifies the shared avio_opts dict (update cookies).
This can cause problems during multithreaded initialization.
To prevent this, I take a copy of avio_opts, use that in open_url,
and copy the updated dict back afterwards.
---
libavformat/dashdec.c | 34 --
This patch adds an "init_threads" option, specifying the max
number of threads to use. Multiple worker threads are spun up
to massively bring down init times.
---
libavformat/dashdec.c | 286 +-
1 file changed, 285 insertions(+), 1 deletion(-)
diff --git a/
For adding multithreading to the DASH decoder initialization,
the open_demux_for_component() method must be split up into two parts:
begin_open_demux_for_component(): Opens the stream and does probing
and format detection. This can be run in parallel.
end_open_demux_for_component(): Creates the A
Whitespace change only. No functional changes.
---
libavformat/dashdec.c | 74 +--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 19e657d836..22f727da3b 100644
--- a/libavformat/dashdec.c
+
Forgotten in 5c16df1b92c519238e10664eeab3adb3b9016edd,
because neither I nor patchwork ran fate with xmllint.
Signed-off-by: Andreas Rheinhardt
---
Will apply this soon.
tests/ref/fate/ffprobe_xsd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ref/fate/ffprobe_xsd b/t
Andreas Rheinhardt:
> Right now, it is nearly ordered by "left codes in the tree first";
> the only exception is the escape value which has been put at the
> end. This commit moves it to the place it should have according
> to the above order. This is in preparation for further commits.
>
> Signed
Andreas Rheinhardt:
> The FFV1 decoder only uses the last frame's data to conceal
> errors. The encoder does not have this problem and therefore
> only uses the current frame and none of the ThreadFrames.
> So only allocate them for the decoder.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> liba
> > cbs_av1_write_unit() check pbc size after parsing obu frame, and return
> > AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
> > frame will be parsed again, but this may cause error because
> > CodedBitstreamAV1Context has already been updated, for example
> > ref_order_hin
On Thu, 2022-08-18 at 14:59 +0800, Wenbin Chen wrote:
> Signed-off-by: Wenbin Chen
> ---
> doc/encoders.texi | 3 +++
> libavcodec/qsvenc.c | 18 +-
> libavcodec/qsvenc.h | 2 ++
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/doc/encoders.texi b/doc/encod
From: Haihao Xiang
AV_PIX_FMT_VUYX is used for 8bit 4:4:4 content in FFmpeg VAAPI, so
AV_PIX_FMT_VUYX should be used for 8bit 4:4:4 content in FFmpeg QSV too
because QSV is based on VAAPI on Linux. However the SDK only declares
support for AYUV and does nothing with the alpha, so this commit fudg
From: Haihao Xiang
AV_PIX_FMT_VUYX is used in FFmpeg and MFX_FOURCC_AYUV is used in the SDK
---
libavcodec/qsv.c | 14 ++
libavcodec/qsvdec.c | 2 ++
libavcodec/qsvenc_hevc.c | 1 +
libavcodec/qsvenc_vp9.c | 1 +
4 files changed, 18 insertions(+)
diff --git a/libavc
On Mon, 2022-09-05 at 18:40 +0800, 1035567...@qq.com wrote:
> From: Wang Yaqiang
>
> For example, if the jpeg contains exif information
> and the rotation direction is included in the exif,
> the displaymatrix will be set on the side_data of the frame when
> decoding.
> However, when ffplay is us
41 matches
Mail list logo
