On Sat, Mar 29, 2025 at 6:21 AM Michael Niedermayer
wrote:
> Hi
>
> On Tue, Mar 25, 2025 at 10:59:28PM +0800, Nuo Mi wrote:
> > It is also referred to as:
> > SPI-FUJITSU
> > AUG-CCITT
> > CRC-CCITT (0x1D0F)
> > This CRC type used by
It is also referred to as:
SPI-FUJITSU
AUG-CCITT
CRC-CCITT (0x1D0F)
This CRC type used by H.274
---
libavutil/hash.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavutil/hash.c b/libavutil/hash.c
index fbc24194de..3659c71c7f 100644
--- a/libavutil/hash
+1 for VVC patches.
Thank you, Andreas
On Tue, Mar 18, 2025 at 4:00 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Patches attached.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman
On Thu, Mar 6, 2025 at 2:40 AM Frank Plowman wrote:
> If pps_single_slice_per_subpic_flag is 1,
> slice_{width,height}_in_tiles are undefined and we must instead get the
> dimensions of the slice by referring to the corresponding subpicture.
> Signed-off-by: Frank Plowman
> ---
> Changes since
On Sun, Mar 9, 2025 at 9:57 PM Nuo Mi wrote:
>
>
> On Thu, Mar 6, 2025 at 2:40 AM Frank Plowman
> wrote:
>
>> If pps_single_slice_per_subpic_flag is 1,
>> slice_{width,height}_in_tiles are undefined and we must instead get the
>> dimensions of the slice
On Thu, Mar 6, 2025 at 2:40 AM Frank Plowman wrote:
> If pps_single_slice_per_subpic_flag is 1,
> slice_{width,height}_in_tiles are undefined and we must instead get the
> dimensions of the slice by referring to the corresponding subpicture.
>
> Signed-off-by: Frank Plowman
> ---
> Changes since
On Sun, Mar 2, 2025 at 8:13 PM Frank Plowman wrote:
> When pps_num_exp_slices_in_tile[i] is nonzero, the ith tile is made up
> of pps_num_exp_slices_in_tile[i] slices stacked atop one another, where
> the height of the jth slice in the ith tile is given by
> pps_exp_slice_height_in_ctus_minus1[i]
On Fri, Mar 7, 2025 at 9:56 PM Martin Storsjö wrote:
> On Mon, 3 Mar 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
>
> > This patch replaces integer widening with halving addition, and
> > multi-step "emulated" rounding shift with a single asm instruction doing
> > exactly that.
> >
> > Benchma
On Sun, Feb 23, 2025 at 8:05 PM Frank Plowman wrote:
> Signed-off-by: Frank Plowman
>
Applied this one.
Thank you, Frank
> ---
> libavcodec/vvc/ps.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> index fae6655cc0..603a6d42
On Sun, Feb 23, 2025 at 8:05 PM Frank Plowman wrote:
> If pps_single_slice_per_subpic_flag is 1,
> slice_{width,height}_in_ctus are undefined and we must instead get the
> dimensions of the slice by referring to the corresponding subpicture.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/c
On Tue, Feb 25, 2025 at 3:16 AM Frank Plowman wrote:
> On 24/02/2025 02:23, James Almer wrote:
> > On 2/23/2025 9:04 AM, Frank Plowman wrote:
> >> Signed-off-by: Frank Plowman
> >> ---
> >> libavcodec/vvc/ps.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a
On Mon, Feb 24, 2025 at 2:44 AM Frank Plowman wrote:
> On 23/02/2025 13:37, Nuo Mi wrote:
> > This issue was introduced by commit
> bb8e95b650de30d6e07196761d1fc61857f5462d
> >
> > Reproduce steps:
> > ./configure --enable-ffmpeg --disable-everything --enable-dec
ffmpeg | branch: master | Nuo Mi | Sun Feb 23 21:37:19
2025 +0800| [dede00f003c51a8cbe8407df4a7063a07644a6a2] | committer: Nuo Mi
lavc/vvcdec: fix undefined reference to ff_h2645_pixel_aspect
This issue was introduced by commit bb8e95b650de30d6e07196761d1fc61857f5462d
Reproduce steps
On Sun, Feb 23, 2025 at 1:36 AM Frank Plowman wrote:
> On 22/02/2025 07:51, Nuo Mi wrote:
> > From: Frank Plowman
> >
> > This is essentially a re-implementation of
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-p...@frankplowman.c
This issue was introduced by commit bb8e95b650de30d6e07196761d1fc61857f5462d
Reproduce steps:
./configure --enable-ffmpeg --disable-everything --enable-decoder=vvc
--enable-parser=vvc --enable-demuxer=vvc --enable-protocol=file,pipe
--enable-encoder=rawvideo,wrapped_avframe --enable-muxer=rawvid
From: Frank Plowman
This is essentially a re-implementation of
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-p...@frankplowman.com/
That patch was not applied last time. Instead we opted to identify
issues which could be caused by invalid subpicture layouts and remedy
On Thu, Feb 20, 2025 at 4:29 AM Frank Plowman wrote:
> Hi,
>
> Thanks for your review.
>
> On 16/02/2025 15:19, Nuo Mi wrote:
> > Hi Frank,
> > Thank you for the patch.
> >
> > On Sun, Feb 9, 2025 at 11:45 PM Frank Plowman
> wrote:
> >
From: Frank Plowman
In the case pps_subpic_less_than_one_tile_slice is called, the
subpicture is smaller than the tile and so there are multiple
subpictures in the tile. Of course, then, not all the
subpictures can start in the top-left corner as the code before the
patch does. Patch fixes this
On Thu, Feb 20, 2025 at 4:33 AM Frank Plowman wrote:
> Ping
>
Sorry for missing this.
Thank you for the patch, applied
>
> On 02/02/2025 12:10, Frank Plowman wrote:
> > The clamping of idxYInv from H.266(V3) section 8.8.2.3 was missing.
> > This could lead to OOB reads from lmcs->pivot or input_
On Wed, Feb 19, 2025 at 5:38 AM Barry Warburton
wrote:
> LGTM.
>
Thank you, Barry,
Applied.
>
> On 03/02/2025 09:17, Nuo Mi wrote:
> > Previously, VUI information was not exposed.
> > If the container lacks HDR metadata, HDR videos appear washed out
> >
&g
ffmpeg | branch: master | Nuo Mi | Mon Feb 3 17:17:50
2025 +0800| [2d9433f25b2c1a1b02ffbc3b556d2ad1353e1e9b] | committer: Nuo Mi
lavc/vvcdec: refact, set AVCodecContext->has_b_frames in
sps_export_stream_params
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=co
ffmpeg | branch: master | Nuo Mi | Mon Feb 3 17:17:51
2025 +0800| [bb8e95b650de30d6e07196761d1fc61857f5462d] | committer: Nuo Mi
lavc/vvcdec: export stream level VUI information
Previously, VUI information was not exposed.
If the container lacks HDR metadata, HDR videos appear washed out
Hi Frank,
Thank you for the patch.
On Sun, Feb 9, 2025 at 11:45 PM Frank Plowman wrote:
> This is essentially a re-implementation of
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-p...@frankplowman.com/
>
> That patch was not applied last time. Instead we opted to
On Sun, Feb 9, 2025 at 5:43 AM Frank Plowman wrote:
> In the fail: block of decode_nal_units, a check as to whether fc->ref is
> nonzero is used. Before this patch, fc->ref was set to NULL in
> frame_context_setup. The issue is that, by the time frame_context_setup
> is called, falliable functi
On Fri, Feb 7, 2025 at 4:25 AM Frank Plowman wrote:
> On 02/02/2025 21:17, Michael Niedermayer wrote:
> > Fixes:
> 390565846/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-4990028521996288
> > Fixes: Null pointer dereference
> >
> > Found-by: continuous fuzzing process
> https://git
Previously, VUI information was not exposed.
If the container lacks HDR metadata, HDR videos appear washed out
Command: mp4box -add hdr.mp4#video:colr=nclc,1,1,1 -new new.mp4 && ffprobe
new.mp4
Before: Stream #0:0[0x1](und): Video: vvc (vvc1 / 0x31637676),
yuv420p10le(bt709), 1920x1080, 12164 kb
---
libavcodec/vvc/dec.c | 1 -
libavcodec/vvc/ps.c | 29 +++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 51dd60ae92..68fb26352e 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -812,7
ffmpeg | branch: master | Nuo Mi | Sun Jan 26 11:10:20
2025 +0800| [974d4a8f0a43baca57104359deb4b08703590135] | committer: Nuo Mi
lavc/vvcdec: remove unneeded VVCContext->pix_fmt
AVCodecContext->sw_pix_fmt is used to hold the software pixel format.
Co-authored-by: Frank Plowman
ffmpeg | branch: master | Nuo Mi | Sun Jan 26 11:10:21
2025 +0800| [ca3550948c4f1d9fe7dbdc24572b92e588846c7b] | committer: Nuo Mi
lavc/vvcdec: ensure slices contain nonzero CTUs
fixes https://github.com/ffvvc/tests/tree/main/fuzz/passed/000323.bit
Co-authored-by: Frank Plowman
> h
On Wed, Jan 29, 2025 at 4:40 PM Frank Plowman wrote:
> On 26/01/2025 03:10, Nuo Mi wrote:
> > fixes https://github.com/ffvvc/tests/tree/main/fuzz/passed/000323.bit
> >
> > Co-authored-by: Frank Plowman
> > ---
> > libavcodec/vvc/ps.c | 11 +--
> &
ffmpeg | branch: master | Nuo Mi | Sun Jan 26 11:10:19
2025 +0800| [61ff0fac351d849d014368b5d6ba815deeed287d] | committer: Nuo Mi
lavc/vvcdec: remove unneeded set_output_format
Downstream can determine the format from the output frame format
Co-authored-by: Frank Plowman
> h
On Sat, Jan 18, 2025 at 11:12 PM Nuo Mi wrote:
>
>
> On Sat, Jan 18, 2025 at 4:18 AM Frank Plowman
> wrote:
>
>> When the chroma format changes mid-sequence, c->pix_fmt and s->pix_fmt
>> can get out-of-sync. More specifically,
>> 1. export_frame_p
AVCodecContext->sw_pix_fmt is used to hold the software pixel format.
Co-authored-by: Frank Plowman
---
libavcodec/vvc/dec.c | 17 ++---
libavcodec/vvc/dec.h | 2 --
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index daf
fixes https://github.com/ffvvc/tests/tree/main/fuzz/passed/000323.bit
Co-authored-by: Frank Plowman
---
libavcodec/vvc/ps.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index c9f7c5c80f..01b4615eda 100644
--- a/libavcod
Downstream can determine the format from the output frame format
Co-authored-by: Frank Plowman
---
libavcodec/vvc/dec.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 1cb168de7e..daf537294f 100644
---
On Sun, Jan 19, 2025 at 12:40 AM Zhao Zhili <
quinkblack-at-foxmail@ffmpeg.org> wrote:
>
>
> > On Jan 18, 2025, at 23:30, Nuo Mi wrote:
> >
> > Hi Zhili,
> > Thank you for v2,
> > +1
> >
> > Nit: The if statement is too long. Move it afte
Hi Zhili,
Thank you for v2,
+1
Nit: The if statement is too long. Move it after generate_missing_ref and
break it up to simplify the logic.
like:
if (!ref) {
ref = generate_missing_ref(s, fc, poc);
if (!ref)
return AVERROR(ENOMEM);
}
+if (ref->flags &
uffers are not allocated for the
> new pixel format.
>
> Patch fixes this by not setting c->pix_fmt in set_output_format.
>
> Signed-off-by: Frank Plowman
> ---
> @Nuo Mi, Fei Wang:
> Does this look okay? I am not really sure why c->pix_fmt was set again
> in set_output_fo
On Mon, Jan 13, 2025 at 4:46 PM Zhao Zhili <
quinkblack-at-foxmail@ffmpeg.org> wrote:
> From: Zhao Zhili
>
> Hi Zhili,
Thank you for the patch.
This will fail on GDR clips, such as:
GDR_B_NOKIA_2.bit
GDR_C_NOKIA_2.bit
By design, a GDR frame refers to missing frames and gradually ref
e:
>
>> Sounds very good, thanks!
>>
>> Issue: https://trac.ffmpeg.org/ticket/11406
>>
>> I would be glad to try it.
>>
>>
>> On Wed, Jan 8, 2025 at 2:04 PM Nuo Mi wrote:
>>
>>>
>>>
>>> On Wed, Jan 8, 2025
information could be retrieved solely from the parser or the
CBS
>
>
>
>
> On Sun, Jan 12, 2025 at 4:38 AM Nuo Mi wrote:
>
> > On Sun, Jan 12, 2025 at 6:24 AM James Almer wrote:
> >
> > > On 1/11/2025 3:40 AM, Nuo Mi wrote:
> > > > Tested with:
&g
ffmpeg | branch: master | Nuo Mi | Sun Jan 12 11:34:17
2025 +0800| [8eb1d76e146a0e557d596a4039efebac746b4d83] | committer: James Almer
lavc/vvc/refs: export keyframe and picture type in output frames
fixes https://trac.ffmpeg.org/ticket/11406
Co-authored-by: Ruben Gonzalez
Signed-off-by
Thank you, Frank,
Applied with some minor changes.
On Sat, Jan 11, 2025 at 5:31 AM Frank Plowman wrote:
> The criteria for slice structure validity is similar to that of
> subpicture structure validity that we saw not too long ago [1].
> The relationship between tiles and slices must satisfy the
On Sat, Jan 11, 2025 at 11:49 PM James Almer wrote:
> As defined in
> https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_specs.md#v_mpegiisovvc
>
> Signed-off-by: James Almer
> ---
> libavformat/matroska.c| 1 +
> libavformat/matroskaenc.c | 10 --
> 2 files
On Sat, Jan 11, 2025 at 9:18 PM Frank Plowman wrote:
> In some scenarios, the VVCContext.pix_fmt and the
> AVCodecContext.pix_fmt can get out-of-sync. It is more robust here
> to check the AVCodecContext.pix_fmt, as we already do for the width and
> height, seeing as the AVCodecContext.pix_fmt i
On Sun, Jan 12, 2025 at 6:24 AM James Almer wrote:
> On 1/11/2025 3:40 AM, Nuo Mi wrote:
> > Tested with:
> > ```
> > wget
> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/CodingToolsSets_E_Tencent_1.zip
> > unzip C
Tested with:
```
wget
https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/CodingToolsSets_E_Tencent_1.zip
unzip CodingToolsSets_E_Tencent_1.zip CodingToolsSets_E_Tencent_1.bit
ffprobe -hide_banner CodingToolsSets_E_Tencent_1.bit -select_streams v
-show_fra
Tested with:
```
wget
https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/draft_conformance/draft6/CodingToolsSets_E_Tencent_1.zip
unzip CodingToolsSets_E_Tencent_1.zip CodingToolsSets_E_Tencent_1.bit
ffprobe -hide_banner CodingToolsSets_E_Tencent_1.bit -select_streams v
-show_fra
LGTM.
On Wed, Jan 8, 2025 at 7:51 PM Frank Plowman wrote:
> This sample is rather difficult, containing a lot of subtle edge cases
>
Are we still encountering issues with the latest code?
> which revealed errors in the VVC decoder. It covers 88.4% of lines in
> libavcodec/vvc and brings the lin
On Wed, Jan 8, 2025 at 12:35 AM Rubén Gonzalez
wrote:
> Hi Nuo Mi,
>
> thanks for your feedback. Unfortunately I don't have enough knowledge/time
> to improve the patch. I only mimicked H.26[45].
>
> IMHO, reporting AV_FRAME_FLAG_KEY is better than nothing, so I will send
On Sat, Jan 4, 2025 at 9:51 PM Nuo Mi wrote:
>
>
> On Fri, Jan 3, 2025 at 2:01 AM Frank Plowman
> wrote:
>
>> Thank you for your review.
>>
>> On 01/01/2025 04:30, Nuo Mi wrote:
>> > 👍
>> >
>> > On Tue, Dec 31, 2024 at 2:02 AM Frank P
n would complicate ff_vvc_alf_filter, so I pushed Chris's
instead.
Thank you patch and ping.
>
> Thanks and happy new year,
> Frank
>
> On 03/12/2024 02:17, Nuo Mi wrote:
> > Hi Chris and Frank,
> > Thank you for the patch and review.
> >
> > On Mon, Dec 2, 2
On Fri, Jan 3, 2025 at 2:01 AM Frank Plowman wrote:
> Thank you for your review.
>
> On 01/01/2025 04:30, Nuo Mi wrote:
> > 👍
> >
> > On Tue, Dec 31, 2024 at 2:02 AM Frank Plowman
> wrote:
> >
> >> When the current subpicture has sps_subpic_treate
Hi Ruben,
Thank you for the patch.
A B/P frame's first slice may be an I slice, so it can't be used to
determine the picture type.
The ph_inter_slice_allowed_flag can quickly identify an I frame, but B/P
frame still requires checking all slices.
On Fri, Jan 3, 2025 at 12:19 AM Ruben Gonzalez
wrot
👍
On Tue, Dec 31, 2024 at 2:02 AM Frank Plowman wrote:
> When the current subpicture has sps_subpic_treated_as_pic_flag equal to
> 1, motion vectors are cropped such that they cannot point to other
> subpictures. This was accounted for in the prediction logic, but not
> in pred_get_y, which is
On Sun, Dec 29, 2024 at 6:24 PM Frank Plowman wrote:
> Hi,
>
> Thank you for your review.
>
> It seems your mail did not reach the ML for whatever reason. I have
> ensured your comments are all left verbatim below so that others may
> read them.
>
Thank you.
>
&g
Hi Frank,
Thank you for the patch.
On Sun, Dec 22, 2024 at 9:40 PM Frank Plowman wrote:
> When the current subpicture has sps_subpic_treated_as_pic_flag equal to
> 1, motion vectors are cropped such that they cannot point to other
> subpictures. This was accounted for in the prediction logic, b
On Mon, Dec 23, 2024 at 11:18 PM flow gg wrote:
> Hi, It looks like you submitted your review comments not long after the
> patch was merged.
>
> Previously, regarding the VVC avg patch, you mentioned "LGTM for the RISC-V
> side. No clue about the VVC side",
> so I contacted Nuomi in the hope tha
On Sat, Dec 21, 2024 at 9:42 PM Rémi Denis-Courmont wrote:
> Hi
>
> The RISC-V bits look ok. No opinion on x86.
>
Thank you for the review.
Pushed.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg
On Sun, Dec 22, 2024 at 3:03 AM Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Dec 21, 2024 at 5:02 AM Nuo Mi wrote:
>
>> rename from libavcodec/x86/hevc_add_res.asm
>> rename to libavcodec/x86/hevc/add_res.asm
>>
>
> Good idea - LGTM. I should probably do this
ffmpeg | branch: master | Nuo Mi | Sat Dec 21 18:01:43
2024 +0800| [0a6388d1da174bb2ed3e793461c9226341e3629f] | committer: Nuo Mi
avcodec/hevcdec: remove hevc prefix for x86 asm files
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0a6388d1da174bb2ed3e793461c9226341e36
ffmpeg | branch: master | Nuo Mi | Sat Dec 21 18:01:42
2024 +0800| [8d27256a747fdd9eda41c480aa1eb7a065b88286] | committer: Nuo Mi
avcodec/vvcdec: remove vvc prefix for x86 and riscv
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=8d27256a747fdd9eda41c480aa1eb7a065b88
On Sat, Dec 21, 2024 at 2:06 PM flow gg wrote:
> Hi, other RISC-V assembly file names usually include the extensions being
> used, such as rvv, rvb, etc.
> How about naming them mc_rvv.S and sad_rvv.S?
>
Thank you for the comment.
Fixed by v2
>
> Nuo Mi 于202
---
libavcodec/x86/Makefile | 8
libavcodec/x86/hevc/Makefile | 12
.../x86/{hevc_add_res.asm => hevc/add_res.asm} | 0
.../x86/{hevc_deblock.asm => hevc/deblock.asm} | 0
libavcodec/x86/{hevcdsp_init.c => he
---
libavcodec/riscv/vvc/Makefile | 6 +++---
libavcodec/riscv/vvc/{vvcdsp_init.c => dsp_init.c} | 0
libavcodec/riscv/vvc/{vvc_mc_rvv.S => mc_rvv.S}| 0
libavcodec/riscv/vvc/{vvc_sad_rvv.S => sad_rvv.S} | 0
libavcodec/x86/vvc/Makefile| 12 +++
Applied,
Thank you,
On Tue, Dec 17, 2024 at 12:04 PM wrote:
> From: sunyuechi
>
> ---
> libavcodec/riscv/h26x/asm.S | 78 +
> 1 file changed, 18 insertions(+), 60 deletions(-)
>
> diff --git a/libavcodec/riscv/h26x/asm.S b/libavcodec/riscv/h26x/asm.S
> index
On Tue, Dec 17, 2024 at 9:00 PM Martin Storsjö wrote:
> On Tue, 3 Dec 2024, Zhao Zhili wrote:
>
> > From: Zhao Zhili
> >
> > Test on rpi 5 with gcc 12:
> >
> > apply_bdof_8_8x16_c: 7315.2 ( 1.00x)
> > apply_bdof_8_8x16_neon: 1876.8 (
---
libavcodec/x86/Makefile | 8
libavcodec/x86/hevc/Makefile | 12
.../x86/{hevc_add_res.asm => hevc/add_res.asm} | 0
.../x86/{hevc_deblock.asm => hevc/deblock.asm} | 0
libavcodec/x86/{hevcdsp_init.c => he
---
libavcodec/riscv/vvc/Makefile | 6 +++---
libavcodec/riscv/vvc/{vvcdsp_init.c => dsp_init.c} | 0
libavcodec/riscv/vvc/{vvc_mc_rvv.S => mc.S}| 0
libavcodec/riscv/vvc/{vvc_sad_rvv.S => sad.S} | 0
libavcodec/x86/vvc/Makefile| 12 +++
Thank you, Yuechi.
Applied.
On Sun, Dec 15, 2024 at 11:57 PM flow gg wrote:
> Resolved the conflict (because #elif ARCH_WASM was newly added in master).
>
> 于2024年12月15日周日 23:56写道：
>
>> From: sunyuechi
>>
>> ---
>> libavcodec/riscv/vvc/vvc_mc_rvv.S | 46 +++
>> 1 f
On Sat, Dec 14, 2024 at 10:43 AM Nuo Mi wrote:
>
>
> On Tue, Dec 10, 2024 at 10:37 PM flow gg wrote:
>
>> Thank you, this approach can indeed address similar if else scenarios.
>>
>> vsetvlstatic \w, \vlen, e8, mf8, mf4, mf2, m1, m2, m4
>> vsetvlstatic \w,
4, m8, m8
>
> I plan to submit it after this patch set gets merged.
>
Sure, will merge this in 2 days if no objections.
Thank you.
>
> Nuo Mi 于2024年12月10日周二 21:52写道：
>
> > Hi Yuechi,
> > The performance is good.
> >
> > There are many similar .if blocks
Hi Yuechi,
The performance is good.
There are many similar .if blocks in vsetvlstatic8, vsetvlstatic16, and
vsetvlstatic32.
Could we define an intermediate macro, vsetvlstatic, and use it to
implement the above macros?
like:
.macro vsetvlstatic8 w, vlen
vsetvlstatic 8, w, vlen, mf8, m
On Tue, Dec 10, 2024 at 3:35 PM Martin Storsjö wrote:
> On Tue, 10 Dec 2024, Zhao Zhili wrote:
>
> > From: Zhao Zhili
> >
> > Fix test failure:
> > ./tests/checkasm/checkasm --test=vvc_alf 3607569773
> > ---
> > libavcodec/aarch64/vvc/alf.S | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletio
Hi Frank,
Thank you for the detail
Applied.
On Sat, Nov 30, 2024 at 6:11 PM Frank Plowman wrote:
> Hi,
>
> Thank you very much for the review. Responses inline.
>
> On 30/11/2024 06:39, Nuo Mi wrote:
> > Hi Frank,
> > Thank you for the patch set; I will apply it exc
On Sat, Dec 7, 2024 at 5:54 PM Frank Plowman wrote:
> On 07/12/2024 02:22, Nuo Mi wrote:
> > On Wed, Dec 4, 2024 at 2:09 AM Frank Plowman
> wrote:
> >
> >> Hi,
> >>
> >> Thanks for your review.
> >>
> >> On 03/12/2024 10:
intra_mip_mode, 4 bits
> Into a single byte.
>
> Co-authored-by: Nuo Mi
> Signed-off-by: Frank Plowman
> ---
> Changes since v1 (posted as attachment in other thread).
> * Renamed (de)?structure_mip_info to (un)?pack_mip_info
> * Remove coerce_to_bool argument added to get
On Wed, Dec 4, 2024 at 5:20 AM Chris Warrington via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> Nuo Mi wrote:
> > This will introduce two writes for all blocks, even if there is no CC
> ALF.
> How about checking the sps_ccalf_enabled_flag in ff_vvc_alf_filter?
>
>
On Wed, Dec 4, 2024 at 2:09 AM Frank Plowman wrote:
> Hi,
>
> Thanks for your review.
>
> On 03/12/2024 10:04, Nuo Mi wrote:
> > Hi Frank,
> > Thank you for the patch
> >
> > On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman
> wrote:
> >
> >>
Hi Frank,
Thank you for the patch
On Sat, Nov 30, 2024 at 8:13 PM Frank Plowman wrote:
> On 30/11/2024 06:46, Nuo Mi wrote:
> > On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman
> wrote:
> >
> >> Previously, the code only stored the MIP mode and transpose flag in the
Thank you Alexander and Franek,
Applied
On Mon, Dec 2, 2024 at 5:44 AM Frank Plowman wrote:
> On 01/12/2024 19:44, Alexander Strasser via ffmpeg-devel wrote:
> > Introduced in commit 98698ed3c24bfd0b1e6e6db943b5f25f6046cee7
> >
> > Fixes: CID1635788 CID1635789
> > Signed-off-by: Alexander Strass
Hi Chris and Frank,
Thank you for the patch and review.
On Mon, Dec 2, 2024 at 10:27 PM Chris Warrington via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set
> indexes alf->ctb_cc_idc are being read uninitialized during ALF fi
On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman wrote:
> Previously, the code only stored the MIP mode and transpose flag in the
> relevant tables at the top-left corner of the CU. This information ends
> up being retrieved in ff_vvc_intra_pred_* not based on the CU position
> but instead the tran
Hi Frank,
Thank you for the patch set; I will apply it except for this one
On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman wrote:
> In 7.4.3.20 of H.266 (V3), there are two similarly-named variables:
> scalingMatrixDcPred and ScalingMatrixDcRec. The old code set
> ScalingMatrixDcRec, rather than
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:34
2024 +0800| [98698ed3c24bfd0b1e6e6db943b5f25f6046cee7] | committer: Nuo Mi
avcodec/cbs_h266: stricter validation for subpicture's max width and height
Co-authored-by: Frank Plowman
> http://git.videolan.org/gitweb.cgi/ffmpe
On Fri, Nov 29, 2024 at 6:23 AM Frank Plowman wrote:
> On 23/11/2024 09:32, Nuo Mi wrote:
> > According to section 6.3.3, 'Spatial or component-wise partitionings,'
> > Subpictures must cover the entire picture.
> > Therefore, the total number of subpicture slic
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:33
2024 +0800| [e06515b092225f7d954aa64aedde98df097515ee] | committer: Nuo Mi
avcodec/cbs_h266: improve readability in subpicture parser
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e06515b092225f7d954aa64aedde98df09751
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:36
2024 +0800| [4ec767abcc1036a424e4b30ef6d0d3b180d4eed4] | committer: Nuo Mi
avcodec/vvcdec: misc, reformat inter_data()
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=4ec767abcc1036a424e4b30ef6d0d3b180d4eed4
---
libavco
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:37
2024 +0800| [eb67e60cb004c17ecbbd43c6e3c6732c19de5d33] | committer: Nuo Mi
avcodec/vvcdec: schedule next stage only if the current stage reports no error
If the current stage reports an error, some variables may not be correctly
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:38
2024 +0800| [4de67e874697271e189022b03cd619329d54603c] | committer: Nuo Mi
avcodec/vvcdec: return error if CTU size > 128
The v3 spec reserves CTU size 256. Currently, we use an uint8_t* table to hold
cb_width and cb_height.
If a CTU s
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:32
2024 +0800| [5c5a08ecb53b1b9d97512ce398fa395c3fb8c1a8] | committer: Nuo Mi
avcodec/vvcdec: ensure every CTU belongs to a slice
According to section 6.3.3 "Spatial or component-wise partitionings,"
CTUs should fully cover slic
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:35
2024 +0800| [ba89c5b989938fad751ac451d1f6ef813bb42460] | committer: Nuo Mi
avcodec/vvcdec: inter_data, check the return value from hls_merge_data
Reported-by: Frank Plowman
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commi
ffmpeg | branch: master | Nuo Mi | Sat Nov 23 17:32:31
2024 +0800| [46006529a16efab45c865114a559914afe281341] | committer: Nuo Mi
avcodec/cbs_h266: check subpicture slices number
According to section 6.3.3, 'Spatial or component-wise partitionings,'
Subpictures must cover the enti
---
libavcodec/vvc/ctu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index 6c0c52b836..a32abdeb62 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -1779,7 +1779,7 @@ static int inter_data(VVCLocalContext *lc)
The v3 spec reserves CTU size 256. Currently, we use an uint8_t* table to hold
cb_width and cb_height.
If a CTU size of 256 is not split, cb_width and cb_height will overflow to 0.
To avoid switching to uint16_t, rejecting CTU size 256 provides a simple
solution.
---
libavcodec/vvc/ps.c | 6
If the current stage reports an error, some variables may not be correctly
initialized.
Scheduling the next stage could lead to the use of uninitialized variables.
---
libavcodec/vvc/thread.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/thread.c b/libavco
Co-authored-by: Frank Plowman
---
libavcodec/cbs_h266_syntax_template.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index fd42734166..43def9220f 100644
--- a/libavcodec/cbs_h266_syntax_t
Reported-by: Frank Plowman
---
libavcodec/vvc/ctu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index 1e06119cfd..6c0c52b836 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -1778,13 +1778,16 @@ static int inte
---
libavcodec/cbs_h266_syntax_template.c | 102 +-
1 file changed, 50 insertions(+), 52 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 8abd3d1ba7..fd42734166 100644
--- a/libavcodec/cbs_h266_syntax_template.c
According to section 6.3.3 "Spatial or component-wise partitionings,"
CTUs should fully cover slices with no overlaps, gaps, or additions.
No overlaps are ensured by task_init_parse.
No gaps and no additions are ensured by this patch.
Co-authored-by: Frank Plowman
---
libavcodec/vvc/thread.c | 7
1 - 100 of 1101 matches
Mail list logo
