-by: Frank Plowman
---
libavcodec/vaapi_vvc.c | 2 +-
libavcodec/vvc.h | 11 +
libavcodec/vvc/dec.c | 99 +-
libavcodec/vvc/dec.h | 2 +-
libavcodec/vvc/ps.h| 10 ++---
5 files changed, 116 insertions(+), 8 deletions(-)
diff --git a
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index deb1b07b23..ac3f453440 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -1160,7 +1160,7 @@ fail
My OpenPGP key is available at
https://keys.openpgp.org/vks/v1/by-fingerprint/34E248D6B7DF476970C7330403A84C6A098F2C6B
and
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x34e248d6b7df476970c7330403a84c6a098f2c6b
Signed-off-by: Frank Plowman
---
Changes since v1:
* Add my OpenPGP
Signed-off-by: Frank Plowman
---
Was requested on IRC.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1d87752b9..485cca6c75 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,7 +266,7 @@ Codecs:
vp8
On 29/05/2025 11:20, Jiawei wrote:
>
> 在 2025/5/29 16:37, Zhao Zhili 写道:
>>
>>> On May 29, 2025, at 15:03, Jiawei wrote:
>>>
>>> This patch modifies the FFmpeg build system to remove the explicit disabling
>>> of GCC's auto-vectorization feature.
>>>
>>> Modern GCC versions have demonstrated stab
Add three missing requirements on bitstream conformance from 7.4.3.19 of
H.266 (V3). Issue found using fuzzing.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
Signed-off-by: Frank Plowman
---
Changes since v1: Spotted just after sending this that there was ongoing
effort to remove av_strerror calls in favour of av_err2str, so made that
substitution here.
---
libavcodec/h2645_parse.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
Signed-off-by: Frank Plowman
---
libavcodec/h2645_parse.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 82816999e8..4b9a9e0891 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -22,6
On 21/05/2025 11:17, Jiawei wrote:
>
> 在 2025/5/21 14:52, Nicolas George 写道:
>> Jiawei (HE12025-05-21):
>>> particularly improving
>>> performance on x86_64 (AVX), ARM64 (SVE) and RISC-V(RVV) architectures.
>> Benchmark needed.
>>
>> Regards,
>
>
> Hi Nicola
On 29/04/2025 14:24, Nuo Mi wrote:
> Hi Frank,
> Thank you for the detail.
>
> On Mon, Apr 28, 2025 at 10:35 PM Frank Plowman
> wrote:
>
>> On 28/04/2025 14:33, Nuo Mi wrote:
>>> Hi Frank,
>>> Thank you for the v2.
>>> Could we remove all asse
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman
---
Changes since v2:
* Remove av_asserts, return
referable
in that it also validates the predicted size by the looks of it
(although I don't have a stream which exercises this aspect).
>
> On Sun, May 18, 2025 at 5:05 AM Frank Plowman wrote:
>
>> "The value of CurrentPaletteSize[ startComp ] shall be in the range of 0
"The value of CurrentPaletteSize[ startComp ] shall be in the range of 0
to maxNumPaletteEntries, inclusive."
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ctu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/ctu.c b/libavcodec
ation details: perhaps this is a spec issue?
Signed-off-by: Frank Plowman
---
libavcodec/vvc/filter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vvc/filter.c b/libavcodec/vvc/filter.c
index e3886d008e..3815668bcf 100644
--- a/libavcodec/vvc/filter.c
+++ b/libavcodec/vvc/fil
, then we're incurring needless runtime penalty checking for
things which are always true. An av_assert2 is better because it is
only enabled in debug builds, and not where performance is essential.
>
> On Sun, Apr 27, 2025 at 4:48 PM Frank Plowman wrote:
>
>> In d5dbcc00d889fb179
On 27/04/2025 03:42, Nuo Mi wrote:
> On Fri, Apr 18, 2025 at 10:40 PM Frank Plowman
> wrote:
>
>> In d5dbcc00d889fb17948b025a468b00ddbea9e058, it was hoped that detection
>> of subpicture overlaps could be performed at the tile level, so as to
>> avoid introducing pe
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Merge pps_add_ctus and
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 81
On 16/04/2025 14:30, Nuo Mi wrote:
> Thank you, Frank.
>
> Hi samples-request,
> could you help
>
> On Wed, Apr 9, 2025 at 12:29 AM Frank Plowman wrote:
>
>> On 24/03/2025 18:10, Frank Plowman wrote:
>>> A sample with a particular partitioning structure
On 24/03/2025 18:10, Frank Plowman wrote:
> A sample with a particular partitioning structure that could not be read
> correctly before 26c5d8cf5d6dcd520e781754d986e9907d74270e
>
> Signed-off-by: Frank Plowman
> ---
> tests/fate/vvc.mak | 10 ++
>
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d6dcd520e781754d986e9907d74270e
Signed-off-by: Frank Plowman
---
tests/fate/vvc.mak | 10 ++
tests/ref/fate/vvc-wpp-single-slice-pic | 6 ++
2 files changed, 12
On 02/03/2025 12:41, Nuo Mi wrote:
> 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
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 v1:
* slice_height_in_tiles is also undefined if
pps
not exceed the height of the tile itself.
Signed-off-by: Frank Plowman
---
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index b84f3e29db..9f3ad0bb67 100644
On 02/03/2025 08:31, Ronan Waide wrote:
> hi folks,
>
> I submitted a patch yesterday which seems to have failed automated `make
> fate` tests in a place unrelated to the patch
> (https://patchwork.ffmpeg.org/check/114511/,
> https://patchwork.ffmpeg.org/check/114513/). I saw a few other patche
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/libavcodec/vvc/ps.c b/
On 23/02/2025 13:37, Nuo Mi wrote:
> 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
On 09/02/2025 10:58, Frank Plowman wrote:
> Signed-off-by: Frank Plowman
> ---
> tools/.gitignore | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/.gitignore b/tools/.gitignore
> index 7c45896923..f017fa2343 100644
> --- a/tools/.gitignore
Signed-off-by: Frank Plowman
---
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..603a6d42d1 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -368,9 +368,10 @@ static int
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/cbs_h266_syntax_template.c | 34 ++-
1 file
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.com/
>
> That patch was not applied last time. Instead we opted to identify
&g
Ping
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_pivot.
>
> I also changed the derivation of the forward LMCS idx to use a shift
> rather than a divisio
starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).
Signed-off-by: Frank Plowman
---
Changes since v1: None
---
libavcodec/vvc/ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index fae6655cc0
han in the CBS, which avoids duplicating some logic.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Set tile_idx to ty * pps->r->num_tile_columns + tx, rather than using
VVC_MAX_TILE_COLUMNS as the stride.
---
libavcodec/vvc/ps.c | 52 -
1
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:
>
>> This is essentially a re-implementation of
>>
>> https://patchwork.ffmpeg.org/project/ffmp
On 12/02/2025 01:21, Michael Niedermayer wrote:
> Hi all
>
> Ive added SDR to our GSoC 2025 page as there was just a single project
> on that page and the page needs to be more complete yesterday
>
> If people are against this say this NOW do not wait until we have accepted
> a student and then s
starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index fae6655cc0..9480540e03 100644
--- a
han in the CBS, which avoids duplicating some logic.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 52 -
1 file changed, 42 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 9480540e03..9af5e1250b 10
Signed-off-by: Frank Plowman
---
tools/.gitignore | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/.gitignore b/tools/.gitignore
index 7c45896923..f017fa2343 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -3,6 +3,7 @@
/bisect.need
/crypto_bench
/cws2fws
lves the issue by moving the assignment of
fc->ref to NULL to the very top of decode_nal_units, before any falliable
functions are called.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavc
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://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-
On 02/02/2025 21:17, Michael Niedermayer wrote:
> The spec seems to allow these to be negative
>
> Fixes: left shift of negative value -15
> Fixes:
> 392687035/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-6559804532785152
>
> Found-by: continuous fuzzing process
> https://githu
the specification (8.7.5.2).
Signed-off-by: Frank Plowman
---
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 01b4615eda..fae6655cc0 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -786,7 +78
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 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v
On 21/01/2025 11:51, Niklas Haas wrote:
> On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer
> wrote:
>> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 wrote:
Hello, in the context of a GA member,
t_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_format, was this accounting for some specific scenario?
In terms of bitstreams where the pix_fmt changes, I only have fuzzed
bitstreams unfortunat
On 16/01/2025 19:12, Vitaly Buka via ffmpeg-devel wrote:
> UBSAN by default is just prints a mesage and
> moves on. This hides a few UBs in fate-suite.
>
> Signed-off-by: Vitaly Buka
> ---
> configure | 4 ++--
> libavcodec/aacenc_pred.c | 1 +
> libavcodec/ffv1dec.c
;pix_fmt and vice-versa.
Signed-off-by: Frank Plowman
---
@Fei Wang: Could you please check this? I believe this is the source of
the issue and it fixes the issue for the software decoder but I am not
sure about hardware. In particular, is output->format in
set_output_format already a (
On 13/01/2025 06:29, Wang, Fei W wrote:
> On Sun, 2025-01-12 at 11:45 +0800, Nuo Mi wrote:
>>
>>
>> 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-
number of channels in the
allocated frame.
Fixes null dereferences if the chroma format changes mid-sequence.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 1cb168de7e
ameter set RBSP semantics
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index a5cf1d74bd..13f1cf02dd 100644
--- a/libavcodec/vvc/ps.c
+++ b/
On 08/01/2025 13:08, Nuo Mi wrote:
> 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?
>
No, most of my last patches are
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Remove
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman
---
Sorry this sat on the FATE
Sorry, #11325 is the original issue. #11367 is the duplicate.
On 02/01/2025 17:56, Frank Plowman wrote:
> Hi both,
>
> Can we push either of these? Someone else has reported the same issue
> on Trac (#11325). The difference between the two proposed
> implementations seems rat
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_treated_as_pic_flag equal to
>> 1, motion vectors are cropped such that they cannot point to oth
Hi both,
Can we push either of these? Someone else has reported the same issue
on Trac (#11325). The difference between the two proposed
implementations seems rather superficial to me.
Thanks and happy new year,
Frank
On 03/12/2024 02:17, Nuo Mi wrote:
> Hi Chris and Frank,
> Thank you for the
to the current subpicture in
pred_get_y.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Also clip max_y to the subpic_bottom, in order to prevent adding
unecessary dependencies. max_y is also clipped to the picture bottom
where it wasn't before. This doesn't make any differe
ent frame may begin. Consequently,
>> where a
>> motion vector pointed to a location significantly above the
>> current
>> subpicture, there was the possibility of a race condition. Patch
>> fixes
>> this by cropping the motion
to the current subpicture in
pred_get_y.
Signed-off-by: Frank Plowman
---
You can reproduce this issue with the bitstream available here:
https://chromium.googlesource.com/chromium/src/+/lkgr/media/test/data/vvc_frames_with_ltr.vvc?format=TEXT
Note this link downloads the file in base 64 format
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:04, Nuo Mi wrote:
>>> Hi Frank,
>>> Thank you for the patch
>>>
>>> On
Reduces memory consumption by ~4MB for 1080p video with a maximum delay
of 16 frames by packing various information related to MIP:
* intra_mip_flag, 1 bit
* intra_mip_transposed_flag, 1 bit
* intra_mip_mode, 4 bits
Into a single byte.
Co-authored-by: Nuo Mi
Signed-off-by: Frank Plowman
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:
>
>> On 30/11/2024 06:46, Nuo Mi wrote:
>>> On Fri, Nov 29, 2024 at 6:19 AM Frank Plowman
>> wrote
On 02/12/2024 14:27, Chris Warrington via ffmpeg-devel 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 filtering.
>
> This change initializes alf->ctb_cc_idc whenever ALF is enabled.
>
> Ref. https:
On 01/12/2024 19:44, Alexander Strasser via ffmpeg-devel wrote:
> Introduced in commit 98698ed3c24bfd0b1e6e6db943b5f25f6046cee7
>
> Fixes: CID1635788 CID1635789
> Signed-off-by: Alexander Strasser
> ---
>
> Just picked this up because of Coverity.
> Not sure how to verify/test this change, but i
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
>> relevant tables at the top-left corner of the CU. This information ends
>> up being retrieved in
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 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 ar
the criteria described in sections 8.6.2.3 and 6.4.4,
which do not include this constraint on the motion estimation region.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/mvs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/mvs.c b/libavcodec/vvc/mvs.c
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 slices should equal the number of
> picture slices
>
> C
Ping
On 16/11/2024 17:59, Frank Plowman wrote:
> Remove the MMX versions of these functions and modify the SSE
> implementations to avoid using MMX registers.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/x86/videodsp.asm| 61 ++-
> libavcode
H.266 (V3) section 7.4.12.8: "The value of lMvd[ compIdx ] shall be in
the range of −2^{17} to 2^{17} − 1, inclusive."
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ctu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/c
lag[id]. This could lead to decode
mismatches in sequences with explicitly-signalled scaling lists.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index f32f1cc5a1..9bd2d01
do for the MIP flag.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ctu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index 1e06119cfd..0030938cf5 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -975,8 +975,8
Per H.266 (V3) section 7.4.3.19, LmcsMaxBinIdx is set equal to
15 - lmcs_delta_max_bin_idx. The previous code instead had it equal to
15 - lmcs_min_bin_idx. This could cause decoder mismatches.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 2 +-
1 file changed, 1 insertion(+), 1
bounds for these syntax elements.
Signed-off-by: Frank Plowman
---
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 6b2d6534ef..83d945ec74 100644
--- a
e) Looks like it is
> running there:
>
> Can you pls guide how to capture ffmpeg crash specific logs which we are
> facing in Niagara?
>
>
> Regards,
> Rahul
>
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Frank
> Plowman
> Sen
On 22/11/2024 15:07, Kumar, Rahul via ffmpeg-devel wrote:
> I am experiencing a crash in Niagara Workbench when streaming video with the
> H.264 codec. The crash occurs during the first 3-4 attempts to initialize the
> stream but then stabilizes afterward. This issue started after upgrading
> FF
Add missing upper bounds for the width and height of the first
subpicture. Corresponding bounds were added for all other subpictures
in 01701bd, but were not included for the first subpicture (which has
slightly different syntax).
Signed-off-by: Frank Plowman
---
libavcodec
On 15/11/2024 20:55, Andreas Rheinhardt wrote:
> Frank Plowman:
>> Remove the MMX versions of these functions and modify the SSE
>> implementations to avoid using MMX registers.
>>
>> Signed-off-by: Frank Plowman
>> ---
>> This wasn't wholly straightfo
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman
---
libavcodec/x86/videodsp.asm| 61 ++-
libavcodec/x86/videodsp_init.c | 88 +-
2 files changed, 59
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman
---
This wasn't wholly straightforward as the existing SSE implementation did
not only use SSE but rather a blend of SSE and MMX. I would appreciate
On 10/11/2024 23:57, James Almer wrote:
> On 11/10/2024 3:38 PM, Frank Plowman wrote:
>> These assembly optimisations can use MMX. They failed to reset the
>> floating-point state when they are done, hence subsequent floating-point
>> operations return nonsense values.
>
promotion rules, this behavior does not extend to the
> unsigned int type.
>
> See "6.3.1.1 Boolean, characters, and integers" in the "ISO/IEC 9899" for
> details.
>
> Reported-by: Frank Plowman
> ---
> libavcodec/cbs_h266_syntax_template.c
This was the only floating point logic in the native VVC decoder.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/intra_utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vvc/intra_utils.c b/libavcodec/vvc/intra_utils.c
index 8c40eb1b16..7229222b95
-mingw32-gcc&time=20241110053421
Signed-off-by: Frank Plowman
---
libavcodec/x86/videodsp.asm | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
index 3cc07878d3..6144f13fca 100644
--- a/libavcodec/x86/videodsp.asm
+++ b/libavcodec
On 23/08/2024 13:36, Frank Plowman wrote:
> This reverts commit 110d8549d575aae6b2f627cd63e2eb7082ab8926.
>
> I have been working through fixing bugs, particularly crashes I've
> found using a fuzzer, in the VVC decoder for the past few months.
> While I won't claim
On 03/11/2024 03:37, Zhao Zhili wrote:>> -Original Message-
>> From: Frank Plowman
>> Sent: 2024年11月3日 2:03
>> To: Nuo Mi ; Zhao Zhili
; Michael Niedermayer
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fate/vvc: Add a sample
which lose frames before
Ping
On 10/10/2024 19:29, Frank Plowman wrote:
> Hello,
>
> I would like to request reimbursement for the following expenses
> incurred attending the Google Summer of Code mentor summit.
>
> Description
On 16/10/2024 13:17, Nuo Mi wrote:
> On Tue, Oct 15, 2024 at 7:54 AM Frank Plowman wrote:
>
>> Thank you for your reply.
>>
>> On 14/10/2024 16:16, Nuo Mi wrote:
>>> On Mon, Oct 14, 2024 at 3:14 AM Frank Plowman
>> wrote:
>>>
>>>>
On 15/10/2024 21:23, Frank Plowman wrote:
> On 14/10/2024 23:26, Michael Niedermayer wrote:
>> On Sat, Oct 05, 2024 at 03:38:05PM -0700, Frank Plowman wrote:
>>> The first branch of this ternary expression was intended to avoid
>>> having two shift operations in the c
On 14/10/2024 23:26, Michael Niedermayer wrote:
> On Sat, Oct 05, 2024 at 03:38:05PM -0700, Frank Plowman wrote:
>> The first branch of this ternary expression was intended to avoid
>> having two shift operations in the case the RHS is not known at
>> compile time. It only w
Ping
Here is a demo of the issue: https://godbolt.org/z/hYnYvbcjE
On 05/10/2024 23:38, Frank Plowman wrote:
> The first branch of this ternary expression was intended to avoid
> having two shift operations in the case the RHS is not known at
> compile time. It only works if the LHS has
Thank you for your reply.
On 14/10/2024 16:16, Nuo Mi wrote:
> On Mon, Oct 14, 2024 at 3:14 AM Frank Plowman wrote:
>
>> On 13/10/2024 05:43, Nuo Mi wrote:
>>> On Sun, Oct 6, 2024 at 6:49 AM Frank Plowman
>> wrote:
>>>
>>>> H.266 (V3) section
On 13/10/2024 05:43, Nuo Mi wrote:
> On Sun, Oct 6, 2024 at 6:49 AM Frank Plowman wrote:
>
>> H.266 (V3) section 6.3.3 dictates that the division of the picture into
>> subpictures must be exhaustive and mutually exclusive, i.e. that each
>> CTU "belongs to" one
Hello,
I would like to request reimbursement for the following expenses
incurred attending the Google Summer of Code mentor summit.
Description | Amount
--+
Train home to London
must check this is true ourselves.
Signed-off-by: Frank Plowman
---
libavcodec/cbs_h266_syntax_template.c | 46 +--
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index b4165b43b3..
for
different sizes of operand, then cast the LHS to the relevant signed
type.
Signed-off-by: Frank Plowman
---
libavutil/common.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index 3b830daf30..ec38752b64 100644
--- a/libavutil
On 20/09/2024 01:54, James Almer wrote:
> On 9/19/2024 9:34 PM, Michael Niedermayer wrote:
>> On Thu, Sep 19, 2024 at 08:53:07PM -0300, James Almer wrote:
>>> On 9/19/2024 7:56 PM, Michael Niedermayer wrote:
Fixes: shift exponent 62 is too large for 32-bit type 'int'
Fixes:
71020/clu
Hi Marvin,
Thanks for this patch and sorry for not getting around to it sooner.
Patch LGTM, yes it is a mistake I made when copy-pasting the logic for
the width -- sorry about that!
Thanks again,
Frank
On 31/08/2024 22:25, Marvin Scholz wrote:
> The us macro expect the range_max here, which see
Hi,
Thanks for your patch.
On 23/08/2024 20:15, Rajiv Harlalka wrote:
> Adds the PU21 encoding filter for high dynamic range images and video
> quality assessment
> Mantiuk, R., & Azimi, M. PU21: A novel perceptually uniform encoding
> for adapting existing quality metrics for HDR
> https://githu
1 - 100 of 199 matches
Mail list logo
