1 Apr 2022, 04:13 by d...@lynne.ee:
> 1 Apr 2022, 02:20 by leo.i...@gmail.com:
>
>> This commit adds support to libavcodec to read and parse
>> encoded Jpeg XL images. Jpeg XL is intended to be an
>> extended-life replacement to legacy mjpeg.
>> ---
>> MAINTAINERS| 2 +
>>
1 Apr 2022, 02:20 by leo.i...@gmail.com:
> This commit adds support to libavcodec to read and parse
> encoded Jpeg XL images. Jpeg XL is intended to be an
> extended-life replacement to legacy mjpeg.
> ---
> MAINTAINERS| 2 +
> libavcodec/Makefile| 1 +
>
On Wed, Mar 30, 2022 at 09:44:08PM +0200, Marton Balint wrote:
>
>
> On Fri, 25 Mar 2022, Zhao Zhili wrote:
>
> > Signed-off-by: Zhao Zhili
> > ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 931cf4bd2c..5daa6f8e03 100644
>
On Fri, Apr 1, 2022 at 2:09 AM Mark Gaiser wrote:
> This patch adds support for:
> - ffplay ipfs://
> - ffplay ipns://
>
> IPFS data can be played from so called "ipfs gateways".
> A gateway is essentially a webserver that gives access to the
> distributed IPFS network.
>
> This protocol support
This commit adds encoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
configure | 3 +-
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libjxlenc.c | 379 +
4 files changed, 383
This commit adds support to libavcodec to read and parse
encoded Jpeg XL images. Jpeg XL is intended to be an
extended-life replacement to legacy mjpeg.
---
MAINTAINERS| 2 +
libavcodec/Makefile| 1 +
libavcodec/codec_desc.c| 9 +
libavcodec/codec_id.h | 1
This patchset adds the Jpeg XL Image format and a parser for this format,
as well as a decoder and encoder for it based on the external reference
implementation library, libjxl.
Changes:
v11:
- Fix regression I introduced in v10 with skipping boxes
v10:
- Make changes requested by Andreas
Add a fate test for the Jpeg XL parser in libavcodec and
its image2 wrapper inside libavformat.
---
tests/fate/image.mak| 10 ++
tests/ref/fate/jxl-parse-codestream | 6 ++
tests/ref/fate/jxl-parse-container | 6 ++
3 files changed, 22 insertions(+)
create mode
This commit adds support to libavformat for muxing
and demuxing Jpeg XL images as image2 streams.
---
libavformat/allformats.c | 1 +
libavformat/img2.c | 1 +
libavformat/img2dec.c| 21 +
libavformat/img2enc.c| 6 +++---
libavformat/mov.c| 1 +
This commit adds decoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
MAINTAINERS | 1 +
configure | 5 +
doc/general_contents.texi | 7 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
This patch adds support for:
- ffplay ipfs://
- ffplay ipns://
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a
Hi,
This patch series adds support for IPFS.
V11:
- Cleaned up the headers. What's there is actually needed now.
- Some more strict checking (namely on fgets)
- Merged long log in one log entry.
- Another allocation check (this time for "fulluri")
- Lots of formatting changes (not visual) to be
On Fri, Apr 1, 2022 at 1:01 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mark Gaiser:
> > On Thu, Mar 31, 2022 at 11:44 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Mark Gaiser:
> >>> On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
> >>>
Nicolas Gaullier:
> Avoid an infinite 'retry' loop in output_packet when flushing.
>
> Signed-off-by: Nicolas Gaullier
> ---
> libavformat/mpegenc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
> index
Mark Gaiser:
> On Thu, Mar 31, 2022 at 11:44 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Mark Gaiser:
>>> On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Mark Gaiser:
> On Wed, Mar 30, 2022 at 2:21 PM Andreas
On Fri, Apr 1, 2022 at 12:17 AM Mark Gaiser wrote:
> On Thu, Mar 31, 2022 at 11:44 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Mark Gaiser:
>> > On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
>> > andreas.rheinha...@outlook.com> wrote:
>> >
>> >> Mark Gaiser:
>>
On Thu, Mar 31, 2022 at 11:44 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mark Gaiser:
> > On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Mark Gaiser:
> >>> On Wed, Mar 30, 2022 at 2:21 PM Andreas Rheinhardt <
> >>>
On Thu, 31 Mar 2022, Ben Avison wrote:
The VC1 decoder was missing lots of important fast paths for Arm, especially
for 64-bit Arm. This submission fills in implementations for all functions
where a fast path already existed and the fallback C implementation was
taking 1% or more of the
Mark Gaiser:
> On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Mark Gaiser:
>>> On Wed, Mar 30, 2022 at 2:21 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Mark Gaiser:
> This patch adds support for:
> -
On Thu, 31 Mar 2022, Ben Avison wrote:
On 30/03/2022 15:14, Martin Storsjö wrote:
On Fri, 25 Mar 2022, Ben Avison wrote:
+// Clamp 16-bit signed block coefficients to signed 8-bit (biased by 128)
+// On entry:
+// x0 -> array of 64x 16-bit coefficients
+// x1 -> 8-bit results
+// x2 =
On Thu, 31 Mar 2022, Ben Avison wrote:
On 30/03/2022 14:49, Martin Storsjö wrote:
Looks generally reasonable. Is it possible to factorize out the individual
transforms (so that you'd e.g. invoke the same macro twice in the 8x8 and
4x4 functions) without too much loss?
There is a close
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refcmp-psnr-rgb because it was missed in
On Thu, 31 Mar 2022, Ben Avison wrote:
On 30/03/2022 13:35, Martin Storsjö wrote:
Overall, the code looks sensible to me.
Would it make sense to share the core of the filter between the
horizontal/vertical cases with e.g. a macro? (I didn't check in detail if
there's much differences in the
Also mark the function as av_cold while at it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9_raw_reorder_bsf.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/libavcodec/vp9_raw_reorder_bsf.c b/libavcodec/vp9_raw_reorder_bsf.c
index
In case the BSF has not been drained before flushing/closing,
the context's next_frame might be set; yet it is not freed
in flush or close. The former only zeroes it (which automatically
causes a leak in case it was set). So do this when closing
and flushing.
Signed-off-by: Andreas Rheinhardt
On Wed, Mar 30, 2022 at 11:25 AM Danil Chapovalov
wrote:
>
> ---
> doc/encoders.texi | 3 +++
> libavcodec/libvpxenc.c | 6 ++
> 2 files changed, 9 insertions(+)
>
lgtm. I'll submit this with a patch version bump soon if there aren't
any further comments.
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
vc1dsp.vc1_unescape_buffer_c: 918624.7
vc1dsp.vc1_unescape_buffer_neon: 142958.0
Signed-off-by: Ben Avison
---
libavcodec/arm/vc1dsp_init_neon.c | 61 +++
libavcodec/arm/vc1dsp_neon.S | 118
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
vc1dsp.vc1_unescape_buffer_c: 655617.7
vc1dsp.vc1_unescape_buffer_neon: 118237.0
Signed-off-by: Ben Avison
---
libavcodec/aarch64/vc1dsp_init_aarch64.c | 61
libavcodec/aarch64/vc1dsp_neon.S | 176
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
idctdsp.add_pixels_clamped_c: 313.3
idctdsp.add_pixels_clamped_neon: 24.3
idctdsp.put_pixels_clamped_c: 220.3
idctdsp.put_pixels_clamped_neon: 15.5
idctdsp.put_signed_pixels_clamped_c: 210.5
idctdsp.put_signed_pixels_clamped_neon: 19.5
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
vc1dsp.vc1_inv_trans_4x4_c: 158.2
vc1dsp.vc1_inv_trans_4x4_neon: 65.7
vc1dsp.vc1_inv_trans_4x4_dc_c: 86.5
vc1dsp.vc1_inv_trans_4x4_dc_neon: 26.5
vc1dsp.vc1_inv_trans_4x8_c: 335.2
vc1dsp.vc1_inv_trans_4x8_neon: 106.2
Includes a checkasm test.
Signed-off-by: Ben Avison
---
libavcodec/vc1dec.c | 20 ++--
libavcodec/vc1dsp.c | 2 ++
libavcodec/vc1dsp.h | 3 ++
tests/checkasm/vc1dsp.c | 67 +
4 files changed, 82 insertions(+), 10 deletions(-)
diff
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of
Signed-off-by: Ben Avison
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/idctdsp.c | 98 +++
tests/fate/checkasm.mak | 1 +
5 files changed, 104 insertions(+)
create mode 100644
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of
This test deliberately doesn't exercise the full range of inputs described in
the committee draft VC-1 standard. It says:
input coefficients in frequency domain, D, satisfy -2048 <= D < 2047
intermediate coefficients, E, satisfy-4096 <= E < 4095
fully inverse-transformed
Note that the benchmarking results for these functions are highly dependent
upon the input data. Therefore, each function is benchmarked twice,
corresponding to the best and worst case complexity of the reference C
implementation. The performance of a real stream decode will fall somewhere
between
The VC1 decoder was missing lots of important fast paths for Arm, especially
for 64-bit Arm. This submission fills in implementations for all functions
where a fast path already existed and the fallback C implementation was
taking 1% or more of the runtime, and adds a new fast path to permit
On 30/03/2022 15:14, Martin Storsjö wrote:
On Fri, 25 Mar 2022, Ben Avison wrote:
+// Clamp 16-bit signed block coefficients to signed 8-bit (biased by
128)
+// On entry:
+// x0 -> array of 64x 16-bit coefficients
+// x1 -> 8-bit results
+// x2 = row stride for results, bytes
+function
On Wed, Mar 30, 2022 at 5:16 PM Mark Gaiser wrote:
>
>
> On Wed, Mar 30, 2022 at 3:57 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Mark Gaiser:
>> > On Wed, Mar 30, 2022 at 2:21 PM Andreas Rheinhardt <
>> > andreas.rheinha...@outlook.com> wrote:
>> >
>> >> Mark Gaiser:
On 30/03/2022 14:49, Martin Storsjö wrote:
Looks generally reasonable. Is it possible to factorize out the
individual transforms (so that you'd e.g. invoke the same macro twice in
the 8x8 and 4x4 functions) without too much loss?
There is a close analogy here with the vertical/horizontal
On Thu, 2022-03-31 at 14:58 +, Xiang, Haihao wrote:
> On Tue, 2022-03-29 at 14:37 +, Xiang, Haihao wrote:
> > On Fri, 2022-03-11 at 13:24 +0100, Ingo Brückl wrote:
> > > Commit e050959103f375e6494937fa28ef2c4d2d15c9ef implemented passing in
> > > modifiers by using the PRIME_2 memory type,
On 30/03/2022 13:35, Martin Storsjö wrote:
Overall, the code looks sensible to me.
Would it make sense to share the core of the filter between the
horizontal/vertical cases with e.g. a macro? (I didn't check in detail
if there's much differences in the core of the filter. At most some
On Tue, 2022-03-29 at 14:37 +, Xiang, Haihao wrote:
> On Fri, 2022-03-11 at 13:24 +0100, Ingo Brückl wrote:
> > Commit e050959103f375e6494937fa28ef2c4d2d15c9ef implemented passing in
> > modifiers by using the PRIME_2 memory type, which only exists in v2 of
> > the library.
> >
> > To still
On Thu, 31 Mar 2022, Ben Avison wrote:
On 29/03/2022 21:37, Martin Storsjö wrote:
On Fri, 25 Mar 2022, Ben Avison wrote:
As with the rest of the checkasm tests - please unmacro most things where
possible (except for the RANDOMIZE_* macros, those are ok to keep macroed
if you want to).
In
On 29/03/2022 21:37, Martin Storsjö wrote:
On Fri, 25 Mar 2022, Ben Avison wrote:
+#define
TEST_UNESCAPE
\
+ do
{
\
On 3/31/2022 8:47 AM, Anton Khirnov wrote:
Quoting James Almer (2022-02-23 16:03:53)
A keyframe could be buffered in the bsf and not be output until more packets
had been fed to it.
Signed-off-by: James Almer
---
Changed the check from pkt to !eof, since a packet is always provided.
Quoting James Almer (2022-02-23 16:03:53)
> A keyframe could be buffered in the bsf and not be output until more packets
> had been fed to it.
>
> Signed-off-by: James Almer
> ---
> Changed the check from pkt to !eof, since a packet is always provided.
>
> fftools/ffmpeg.c | 4 +++-
>
Quoting Andreas Rheinhardt (2022-03-31 00:49:57)
> From: Andreas Rheinhardt
>
> Signed-off-by: Andreas Rheinhardt
> ---
> doc/APIchanges| 3 +++
> fftools/ffmpeg.c | 4 ++--
> fftools/ffprobe.c | 2 +-
> libavcodec/avcodec.h | 3 +--
> libavcodec/decode.c
From: Niklas Haas
Signed-off-by: Niklas Haas
---
Changes in v2:
- expand documentation of tone mapping curves
- slight rewording of some sections
- add more examples
---
doc/filters.texi | 494 +++
1 file changed, 494 insertions(+)
diff --git
Applied as e301a24fa191ad19574289b765ff1946b23c03f3
On Fri, 25 Mar 2022 16:11:19 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> Upstream gained a new tone-mapping API, which we never switched to. We
> don't need a version bump for this because it was included as part of
> the v4.192 release
Andreas Rheinhardt:
> They are only needed for the fuzzer, so check for CONFIG_OSSFUZZ.
> This decreases sizeof(FFCodec), which is important given that
> FFCodecs reside in .data.rel.ro in case of ELF with
> position-independent code which is always loaded and can't be shared
> between processes.
The width and height for qsv frame to download need to be
aligned with 16. Add the alignment operation.
Now the following command works:
ffmpeg -hwaccel qsv -f rawvideo -s 1920x1080 -pix_fmt yuv420p -i \
input.yuv -vf "hwupload=extra_hw_frames=16,format=qsv,hwdownload, \
format=nv12" -f null -
On 30/03/2022 22:31, Marton Balint wrote:
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
Ping for patch 1/2. rcombs has reviewed the patch on IRC. I decided to
drop patch 2/2.
> 11:05 rcombs: quink_: seems reasonable to me
> 11:06 quink_: rcombs: thanks : )
> 11:06 rcombs: not entirely sure what the deal with the second commit is but
> ¯\_(ツ)_/¯ it's harmless so w/e
> On Mar 10,
54 matches
Mail list logo
