Le ven. 14 juin 2024, 11:39, Frank Plowman a écrit :
> When the SPS associated with a particular SPS ID changes, invalidate all
> the PPSs which use that SPS ID. Fixes crashes with illegal bitstreams.
> This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
> ID reuse validatio
Hi Osamu,
Can you provide the list of J2K reference codestreams that this code
allows FFMPEG to support -- not including those already supported [1]?
[1] https://github.com/FFmpeg/FFmpeg/blob/master/tests/fate/jpeg2000.mak
Best,
-- Pierre
On Fri, Jun 14, 2024 at 8:15 PM Osamu Watanabe
wrote:
Right now both the ATRAC1 decoder implementation, and the AEA demuxer don't
accept 4-track and 8-track ATRAC data. This patch fixes that problem.From c42e05855a018e28159bf29b49137bb33f5e45fd Mon Sep 17 00:00:00 2001
From: asivery
Date: Sat, 15 Jun 2024 07:47:40 +0200
Subject: [PATCH] avformat/aea
This is the same as
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240607002549.2259139-1-owata...@es.takushoku-u.ac.jp/
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpeg2000dec.c b/lib
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000.h | 10 +
libavcodec/jpeg2000dec.c | 454 ++---
libavcodec/jpeg2000dec.h | 7 +
libavcodec/jpeg2000htdec.c | 225 ++
libavcodec/jpeg2000htdec.h | 2 +-
5 files changed, 518 insertio
On Sun, Jun 2, 2024 at 12:58 PM Michael Niedermayer
wrote:
>
> On Mon, May 27, 2024 at 01:52:28AM +0200, Michael Niedermayer wrote:
> > Coverity claims these are used uninitilaized in CID1598561 Uninitialized
> > pointer write and CID1598565 Uninitialized pointer write
> >
> > Sponsored-by: Sover
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin St
sön 2024-06-09 klockan 14:55 +0300 skrev Rémi Denis-Courmont:
> The vendor has long since switched to Arm, wit the last product
> reaching
> their official end-of-life over 11 years ago. Linux support for the
> ISA
> was dropped 7 years ago. More importantly, this architecture was
> never
> support
On Thu, Jun 13, 2024 at 10:41:19PM +0200, Michael Niedermayer wrote:
> On Thu, Jun 13, 2024 at 12:14:54PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > I intend to make 5.1.5 and 4.3.7 releases "soon"(1) for debian
> >
> > If you want something backported, now is your last chance to backpo
Le perjantaina 14. kesäkuuta 2024, 18.41.48 EEST James Almer a écrit :
> On 6/14/2024 12:11 PM, Rémi Denis-Courmont wrote:
> > Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a
écrit :
> >> And x86 only has MMX.
> >
> > And the x86 code uses inline assembler. That's not viabl
Hi,
Thanks for the patch. Unfortunately it looks to be corrupted and does
not apply. Also, it looks as though you submitted five near-identical
patches. I would suggest you try directing patches to your own mailbox
and re-applying them while debugging the formatting issues, rather than
sending
It is a better place for it; no non-h263-based decoder needs
these functions any more (both H.261 and the error resilience
code recently stopped doing so).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.c | 5 +
libavcodec/mpegvideo_dec.c | 6 --
2 files changed, 5 insert
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv10.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 65060d4ece..753c6c6cb3 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -385,11 +385,11 @@ static av_cold int rv10_d
It is an MPEG-4-only value; it is always five for the MPEG-4
encoder, so just hardcode this value and move the MpegEncContext
field to Mpeg4DecContext.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.c | 1 -
libavcodec/mpeg4video_parser.c | 2 +-
libavcodec/mpeg4videodec.c
The RV10 and RV20 decoders use ff_h263_decode_mb() and also the
H.263 DSP and VLCs. Despite not calling ff_h263_decode_frame(),
it is nevertheless beneficial to call ff_h263_decode_init()
to reduce code duplication.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263dec.c | 2 ++
libavcodec/r
The error resilience code does not make up block coefficients
and therefore zeroes them in order to disable the IDCT.
But this can be done in a simpler manner, namely by setting
block_last_index to a negative value. Doing so also has
the advantage that the dct_unquantize functions are never even
ca
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv10.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 3dcee0a065..c6baaa0269 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -498,12 +498,6 @@ static int rv10_decode_packet(AVCodecCont
Just do it one during init.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 852de8d535..cabca33c8d 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@
Don't use a LUT to negate followed by a conditional ordinary
negation immediately thereafter. Instead fold the two.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261dec.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
in
This is beneficial for performance: When concatenating
the file from the vsynth1-h261 fate-test 100 times,
performance (measured by timing the codec's decode callback)
improved by 9.6%.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261dec.c | 11 +--
libavcodec/mp
It is unnecessary because ff_mpeg1_dc_scale_table is the default
for both dc_scale_tables.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h261enc.c | 3 ---
libavcodec/msmpeg4.c | 4 +---
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
On Wed, Jun 12, 2024 at 4:54 PM Ramiro Polla wrote:
>
> Hi,
>
> On Tue, Jun 11, 2024 at 8:42 PM James Almer wrote:
> >
> > On 6/11/2024 3:26 PM, Michael Niedermayer wrote:
> > > On Tue, Jun 11, 2024 at 02:28:56PM +0200, Ramiro Polla wrote:
> > >> chrRangeFromJpeg_8_c: 28.7
> > >> chrRangeFromJpeg
On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla wrote:
>
> ---
> tests/checkasm/Makefile | 2 +-
> tests/checkasm/checkasm.c | 1 +
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/sw_range_convert.c | 134 ++
> 4 files changed, 137 inse
On 6/14/2024 12:11 PM, Rémi Denis-Courmont wrote:
Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a écrit :
And x86 only has MMX.
And the x86 code uses inline assembler. That's not viable on any ISA with sane
conventions such as Arm or RISC-V. The compiler will reject our
Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a écrit :
> And x86 only has MMX.
And the x86 code uses inline assembler. That's not viable on any ISA with sane
conventions such as Arm or RISC-V. The compiler will reject our vector
clobbers, unless the Vector extension is in
Le 14 juin 2024 17:33:16 GMT+03:00, James Almer a écrit :
>On 6/12/2024 1:47 AM, Rémi Denis-Courmont wrote:
>> ---
>> configure | 4 ++--
>> libavcodec/mpegvideo.c | 46 +++---
>> 2 files changed, 14 insertions(+), 36 deletions(-)
>>
>> diff
On 6/12/2024 1:47 AM, Rémi Denis-Courmont wrote:
---
configure | 4 ++--
libavcodec/mpegvideo.c | 46 +++---
2 files changed, 14 insertions(+), 36 deletions(-)
diff --git a/configure b/configure
index 6baa9b0646..eb9d1b1f5d 100755
--- a/confi
On Fri, Jun 14, 2024 at 1:53 PM Paul B Mahol wrote:
>
>
>
> On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel
> wrote:
>>
>> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>> wrote:
>> >
>> > The H.264 decoder does not support draw_horiz_band (it does not have
>> > the AV_CODEC_
On 6/11/2024 7:43 PM, Derek Buitenhuis wrote:
> Perhaps if type!=2D?
Changed locally to this and updated the test.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
On 6/11/2024 7:44 PM, James Almer wrote:
> This should ideally be the enum with value 0, but until next major when
> such a change can happen, it would be IMO a good idea if you set
> spherical->projection to AV_SPHERICAL_RECTANGULAR in av_spherical_alloc().
I think setting it to 0 (AV_STEREO3D_
On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
> wrote:
> >
> > The H.264 decoder does not support draw_horiz_band (it does not have
> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_hor
On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
wrote:
>
> The H.264 decoder does not support draw_horiz_band (it does not have
> the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the defa
Pushed patches 1-4
/Tomas
___
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".
Just try with:
ffmpeg -f lavfi -i sine=d=30 -af apad -f null -
Pressing 'q' will not stop it at all, because current ffmpeg code will try
to flush all frames, but because pad filter never receives EOF from next
filter in chain (sink) it will happily produce frame forever.
Tried to fix ffmpeg.c r
From: Niklas Haas
This is specified to be in the range -1 to 4095, apparently the only
extension level with such a restriction.
---
libavcodec/dovi_rpudec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index fc3b0a2b82..306efbb31f 10
From: Niklas Haas
---
libavcodec/dovi_rpudec.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index a477dbd4e3..fc3b0a2b82 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -127,7
On Sun, 09 Jun 2024 17:05:46 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> According to the spec, missing previous VDR RPU IDs do not constitute an
> error, but we should instead fallback first to VDR RPU with ID 0, and
> failing that, synthesize "neutral" metadata.
>
> That's nontrivial tho
>Envoyé : lundi 3 juin 2024 12:00
>>Envoyé : mardi 28 mai 2024 11:11
>>
>>This a new ping but I post the patch again to get fate cleanly completed on
>>patchwork.
>>BTW, the initial design of framesync/EOF was in n3.4-dev-1799-g4e0e9ce2dc, so
>>one can say that time has past...
>>
>>Thank you in
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to pus
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
On macOS, using cntvct_el0 gives measurements with the same
magnitude as mach_absolute_time (which is used currently), but
possibly with a little less overhead/noise.
---
cntvct_el0 should have less
On Fri, 14 Jun 2024, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to push th
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to push this, but I'm not entirely satisfied
with the opt
Andreas Rheinhardt:
> The H.264 decoder does not support draw_horiz_band (it does not have
> the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the default case is display order.
>
> Signed-o
On Fri, 14 Jun 2024, Zhao Zhili wrote:
On Jun 13, 2024, at 20:54, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Martin Storsjö wrote:
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_g
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to push this, but I'm not entirely satisfied with
the option name quite yet. I'm pondering if we shou
---
libavcodec/aaccoder_twoloop.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
index c1dcdbb5ed..c56abc68a7 100644
--- a/libavcodec/aaccoder_twoloop.h
+++ b/libavcodec/aaccoder_twoloop.h
@@ -101,7 +101,7 @@ sta
When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID. Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the S
seems the `sclip` macro was never used
---
libavcodec/aaccoder_twoloop.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
index 92dc2911a3..c1dcdbb5ed 100644
--- a/libavcodec/aaccoder_twoloop.h
+++ b/libavcodec/aaccoder_twoloop.h
@@
> On Jun 13, 2024, at 20:54, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Martin Storsjö wrote:
>
>> The default timer register pmccntr_el0 usually requires enabling
>> access with e.g. a kernel module.
>> ---
>> cntvct_el0 has significantly better resolution than
>> av_gettime_relative (whil
Fixes: CID1452759 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_deshake_opencl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_deshake_opencl.c b/libavfilter/vf_deshake_opencl.c
index 96e
Fixes: CID1452758 Out-of-bounds read (actual out of bounds access depends on a
frame with more than 3 planes)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_deshake_opencl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/liba
From: Fei Wang
Signed-off-by: Fei Wang
---
Changelog | 1 +
configure | 1 +
doc/decoders.texi | 2 +-
libavcodec/allcodecs.c | 1 +
libavcodec/qsv.c | 4
libavcodec/qsvdec.c| 7 ++-
libavcodec/version.h | 2 +-
7 files changed, 15 insertions(
From: Fei Wang
Signed-off-by: Fei Wang
---
configure | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 06a72e4114..6d31698142 100755
--- a/configure
+++ b/configure
@@ -3321,12 +3321,18 @@ nvenc_deps_any="libdl LoadLibrary"
aac_mf_en
From: Fei Wang
Slice address tab only been updated in software decode slice data.
Fixes hwaccel decoding after d725c737fe2a19091b481d4d115fd939e0a674b2.
Signed-off-by: Fei Wang
---
libavcodec/hevc/hevcdec.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a
On 13/06/2024 20:16, radu.taraib...@gmail.com wrote:
Update as discussed
The mode options are fine to me, will leave the implementation check and
final push to Michael.
(Only if you update the patch anyway I'd suggest rewording the commit
message to rephrase the "legacy" mode there, too, a
On 12/06/2024 10:44, Wu, Tong1 wrote:
From: ffmpeg-devel On Behalf Of Lynne
via ffmpeg-devel
Sent: Monday, June 10, 2024 10:01 AM
To: FFmpeg development discussions and patches
Cc: Lynne
Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
the dpb logic from VAAPI to base l
56 matches
Mail list logo
