On Do, 2023-12-28 at 09:24 +0800, fei.w.wang-at-intel@ffmpeg.org wrote:
> From: Fei Wang
>
> Otherwise decoding maybe successful but output result is incorrect.
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/av1dec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcode
On So, 2024-02-25 at 19:51 +, Mark Thompson wrote:
> Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
> held multiple frames output by the filter graph in internal queues
> without telling the filter which created the frames that it is going to
> do so. This broke many VAA
On Sun, Feb 25, 2024 at 06:21:14PM -0600, Marth64 wrote:
> Thank you Michael, for the opportunity. I have some initial questions
> while others add the remaining detail.
>
> 1) What is the flow of test result data like? e.g. do individual test
> servers send the data via API? Or does this tool
On Sun, 2024-02-25 at 19:15 +, Mark Thompson wrote:
> On 23/02/2024 07:14, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > update:
> > Print mbbrc status with "ON/OFF" instead of "0/1".
> >
> > doc/encoders.texi | 3 +++
> >
AACContext is not used by the encoder at all.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aac.h | 143 ---
libavcodec/aacdec.c | 1 +
libavcodec/aacdec.h | 179 ++
libavcodec/aacdec_fixed.c | 1
It is decoder-only; furthermore, there is already
an AACContext in use by libfdk-aacenc.
Also make aacdec.h provide the typedef for AACContext;
up until now, this has been done by sbr.h.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec.c | 10 ++--
libavcodec/aacdec.h
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacsbr.c | 2 +-
libavcodec/aacsbr_fixed.c| 2 +-
libavcodec/aacsbr_template.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index da9e160a57..aafc00049a 100644
--- a/l
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacsbr.h | 2 ++
libavcodec/aacsbr_template.c | 4 ++--
libavcodec/mips/aacsbr_mips.c | 2 +-
libavcodec/sbr.h | 4 +---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.
The AAC decoders share no common code with the AAC encoder,
so they are not restricted to using the same structures.
This implies that one can use different structs for each
component and remove elements not used by the decoders/
the encoder. This leads to quite sizeable savings:
sizeof(ChannelElem
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacsbr_template.c | 131 ++-
1 file changed, 66 insertions(+), 65 deletions(-)
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index ce3834e2dc..72bec96d2c 100644
--- a/libavcodec/aacsbr_tem
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacps.c | 5 -
libavcodec/aacps.h | 7 ++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aacps.c b/libavcodec/aacps.c
index 5a3e6b3dfd..6008edd332 100644
--- a/libavcodec/aacps.c
+++ b/libavcodec/aacps.c
@@ -740,
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacdec_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index fa2a68535c..cfaa25873f 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_tem
The wav demuxer by default tried to demux 4096-byte packets which caused
packets with very few number of samples for files with high channel count.
This caused a significant overhead especially since the latest ffmpeg.c
threading changes.
So let's use a similar approach for selecting audio frame s
Since PTS is changed randomly for every audio frame, it matters. Also add some
forgotten filter dependencies.
Signed-off-by: Marton Balint
---
tests/fate/libswresample.mak | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/fate/libswresample.mak b/tests/fate/l
This also fixes resampling with filter_size=1 and phase_shift=0, depending on
input chunk size noticable corrpution was hearable with this command line:
ffplay -f lavfi -i
"sine=440:r=8000:samples_per_frame=32,aresample=24000:filter_size=1:phase_shift=0"
Signed-off-by: Marton Balint
---
libswr
GEN=1 is used to generate reference files in the source tree, not
auto-generated reference samples.
Without this patch GEN=1 could overwrite the auto generated reference files
in each test where they are used causing failures.
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 2 +-
1 file ch
On Sun, 25 Feb 2024, Michael Niedermayer wrote:
On Sun, Feb 25, 2024 at 05:38:27PM +0100, Marton Balint wrote:
Hi,
I am working on a patch to select a better default packet size for the wav
demuxer, since it reads at most 4096 bytes which can cause insanely small
packets for files with high
Thank you Michael, for the opportunity. I have some initial questions
while others add the remaining detail.
1) What is the flow of test result data like? e.g. do individual test
servers send the data via API? Or does this tool query them directly.
2) Are you open to Docker containerization (wit
I apologize for the previous letter, I forgot to translate)
Dear developers. I simply wrote a patch, tested its operation on Intel with
Hevc Rext support by decoding on all possible HEVC formats - 420 12bit, 422
8/10/12bit, 444 8/10/12bit.
There is no particular desire to describe why exactly th
Fixes: signed integer overflow: -9300 - 922337203683900 cannot be
represented in type 'long'
Fixes:
64546/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-5110813828186112
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-o
Fixes: Timeout
Fixes:
64479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EIGHTBPS_fuzzer-5434435386081280
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/8bps.c | 2 +-
1 file changed, 1
On 2/25/2024 8:18 PM, Michael Niedermayer wrote:
Hi all
about a month has passed
wanted to remind that we seem to have 2 blocking issues on trac
#10826 Short trim inside filter_complex leads to empty output
new defect criticalffmpeg unspe
Hi all
about a month has passed
wanted to remind that we seem to have 2 blocking issues on trac
#10826 Short trim inside filter_complex leads to empty output
new defect criticalffmpeg unspecified
#10857 Stream-level side data propagated to
Hi,
On Sun, Feb 25, 2024 at 5:30 PM Henrik Gramner via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> On Sun, Feb 25, 2024 at 5:42 PM Ronald S. Bultje
> wrote:
> > +movam13, [pw_8]
> > +paddw m10, m12, m12
> > +paddw m12, m10 ; 9 * (q0 - p0) - 3 * (
Previously, the following syntax elements were not read in the case
sps_num_subpics_minus is 0:
* sps_subpic_id_len_minus1
* sps_subpic_id_mapping_explicitly_signalled_flag
* sps_subpic_id_mapping_present_flag
* sps_subpic_id[i]
This was causing failures to decode bitstreams, for example the DVB's
On Sun, Feb 25, 2024 at 5:42 PM Ronald S. Bultje wrote:
> +movam13, [pw_8]
> +paddw m10, m12, m12
> +paddw m12, m10 ; 9 * (q0 - p0) - 3 * ( q1 - p1 )
> paddw m12, m13; + 8
Memory operand
> +paddw m10, m13, m13
> +paddw
Уважаемые разработчики.
Я просто написал патч, протестировал его работу на Intel с поддержкой Hevc Rext
декодированием на все возможных форматах HEVC — 420 12bit, 422 8/10/12bit, 444
8/10/12bit.
Расписывать почему именно так или так как-то нет особого желания. Но он сейчас
в полностью рабочем с
On 25/02/2024 19:50, James Almer wrote:
> On 2/25/2024 2:51 PM, Frank Plowman wrote:
>> The spec says "the value of sps_num_subpics_minus1 shall be in the
>> range of 0 to MaxSlicesPerAu − 1, inclusive."
>>
>> Signed-off-by: Frank Plowman
>> ---
>> libavcodec/cbs_h266_syntax_template.c | 2 +-
>>
Reported-by: James Almer
Signed-off-by: Frank Plowman
---
libavcodec/vvc.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
index 7d165cdb86..c4cec1eb8f 100644
--- a/libavcodec/vvc.h
+++ b/libavcodec/vvc.h
@@ -
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the filter graph in internal queues
without telling the filter which created the frames that it is going to
do so. This broke many VAAPI filter->encode cases because a fixed-size
frame pool is use
On 2/25/2024 2:51 PM, Frank Plowman wrote:
The spec says "the value of sps_num_subpics_minus1 shall be in the
range of 0 to MaxSlicesPerAu − 1, inclusive."
Signed-off-by: Frank Plowman
---
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Marth64
adding Timothy and baptiste to the CC
On Sun, Feb 25, 2024 at 12:36:08AM -0600, Marth64 wrote:
> I'm willing to help. I have experience with Node.JS and Express (the
> rewrite).
great.
So i guess the first goal would be to make it possible to switch
fate.ffmpeg.org to the rewrite tha
On 23/02/2024 07:14, fei.w.wang-at-intel@ffmpeg.org wrote:
From: Fei Wang
Signed-off-by: Fei Wang
---
update:
Print mbbrc status with "ON/OFF" instead of "0/1".
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.c | 11 ++-
libavcodec/vaapi_encode.h | 9 -
3
On Sun, Feb 25, 2024 at 1:44 PM Sean McGovern wrote:
>
>
> Here is the error reported by FATE (snipped for brevity) for
> 'fate-aac-encode-pred':
>
Ooops! I should copy-paste more often -- that should be
'fate-aac-pred-encode' :)
-- Sean McGovern
___
---
libavcodec/aacenc_pred.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacenc_pred.c b/libavcodec/aacenc_pred.c
index f87fcd5a00..d3efade85e 100644
--- a/libavcodec/aacenc_pred.c
+++ b/libavcodec/aacenc_pred.c
@@ -162,9 +162,11 @@ void ff_aac_adjust_common_p
From: Sean McGovern
Hi FFmpeg-devel,
I've started looking into the results posted by the UBsan FATE node --
http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ubsan
Here is the error reported by FATE (snipped for brevity) for
'fate-aac-encode-pred':
[aist#0:0/pcm_s16le @ 0x77fee40]
On Sun, Feb 25, 2024 at 05:38:27PM +0100, Marton Balint wrote:
> Hi,
>
> I am working on a patch to select a better default packet size for the wav
> demuxer, since it reads at most 4096 bytes which can cause insanely small
> packets for files with high channel count.
>
> Unfortunately some swres
The spec says "the value of sps_num_subpics_minus1 shall be in the
range of 0 to MaxSlicesPerAu − 1, inclusive."
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/lib
Hi,
On Sun, Feb 25, 2024 at 11:28 AM James Almer wrote:
> On 2/25/2024 1:22 PM, Ronald S. Bultje wrote:
> > On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje
> > wrote:
> >
> >> Hi,
> >>
> >> On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote:
> >>
> >>> Weak filter can overflow in delta0 calcula
Hi,
I am working on a patch to select a better default packet size for the wav
demuxer, since it reads at most 4096 bytes which can cause insanely small
packets for files with high channel count.
Unfortunately some swresample fate tests blew up, and I wonder if the
result of the resampling s
On 2/25/2024 1:22 PM, Ronald S. Bultje wrote:
On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje
wrote:
Hi,
On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote:
Weak filter can overflow in delta0 calculation before >> 4 in int16.
Signed-off-by: J. Dekker
---
I do not know x86 simd at all,
Hi,
On Sun, Feb 25, 2024 at 11:22 AM Ronald S. Bultje
wrote:
>
>
> On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje
> wrote:
>
>> Hi,
>>
>> On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote:
>>
>>> Weak filter can overflow in delta0 calculation before >> 4 in int16.
>>>
>>> Signed-off-by: J. De
On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje
wrote:
> Hi,
>
> On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote:
>
>> Weak filter can overflow in delta0 calculation before >> 4 in int16.
>>
>> Signed-off-by: J. Dekker
>> ---
>>
>> I do not know x86 simd at all, so this is just an attempt to
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
fixed-size pool of frames (common in some hardware APIs where the output
frames must be
On Sun, 25 Feb 2024, Mark Thompson wrote:
On 25/02/2024 15:01, Marton Balint wrote:
On Sun, 25 Feb 2024, Mark Thompson wrote:
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder t
Hi,
On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote:
> Weak filter can overflow in delta0 calculation before >> 4 in int16.
>
> Signed-off-by: J. Dekker
> ---
>
> I do not know x86 simd at all, so this is just an attempt to fix
> the implementation rather than write extremely performant code.
On Sun, Feb 25, 2024 at 11:36 AM Mark Thompson wrote:
>
> On 25/02/2024 02:22, Водянников А.В. via ffmpeg-devel wrote:
> > From ed8fda62bbdbc62f7565891c935966c931d001ca Mon Sep 17 00:00:00 2001
> > From: Aleksoid
> > Date: Thu, 22 Feb 2024 19:15:48 +1000
> > Subject: [PATCH 1/2] Add support d
On 25/02/2024 15:01, Marton Balint wrote:
On Sun, 25 Feb 2024, Mark Thompson wrote:
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
On Sun, 25 Feb 2024, Mark Thompson wrote:
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
fixed-size pool of frames (common in som
Andreas Rheinhardt:
> Forgotten in e7f9edb4698e94135aab24c302226734713548f0.
>
> 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 3aa20085ed..daa7c367
Andreas Rheinhardt:
> Common symbols are not part of ISO-C and therefore not used
> by FFmpeg at all. Yet linker warnings to ensure it stays
> that way are nevertheless wrong, because the existence of
> common symbols does not imply that there is a bug in our code.
>
> More precisely, Clang's ASAN
From: Niklas Haas
See previous commit.
---
libavcodec/av1dec.c | 25 +
libavcodec/av1dec.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 7debc4dedaa..f42dc77148f 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/a
From: Niklas Haas
Instead of the nal_prefix, this profile inside wraps the RPU inside an
EMDF header, as specified in ETSI TS 102 366. This particular usage is
supposedly specified in ETSI TS 103 572, at least according to European
Patent EP 3 588 964 A1, but I could not find any references to DV
From: Niklas Haas
This is thankfully passed through verbatim by libdav1d, so we can parse
it in our own code.
In theory, taking the DV profile from the packet-level configuration
struct is redundant since there is currently only one possible DV level
for AV1 (and all others would fail parsing),
Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has
held multiple frames output by the decoder in internal queues without
telling the decoder that it is going to do so. When the decoder has a
fixed-size pool of frames (common in some hardware APIs where the output
frames must be
On 25/02/2024 02:22, Водянников А.В. via ffmpeg-devel wrote:
> From ed8fda62bbdbc62f7565891c935966c931d001ca Mon Sep 17 00:00:00 2001
> From: Aleksoid
> Date: Thu, 22 Feb 2024 19:15:48 +1000
> Subject: [PATCH 1/2] Add support d3d11va Intel Hevc Rext decoder.
>
> Signed-off-by: Aleksoid
> ---
>
On 25/02/2024 01:55, Andreas Rheinhardt wrote:
The SEI message read/write functions are called
via function pointers where the SEI message-specific
context is passed as void*. But the actual function
definitions use a pointer to their proper context
in place of void*, making the calls undefined b
Quoting Andreas Rheinhardt (2024-02-25 00:31:15)
> Broken in a2fc86378a18b2c2966ce3438df8f27f646438e5.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> fftools/ffmpeg_mux.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
ok
--
Anton Khirnov
___
On 2024/02/11 19:24, Andreas Rheinhardt wrote:
Akihiko Odaki:
noopenh264 is a "fake implementation of the OpenH264 library we can link
from regardless of the actual library being available":
https://gitlab.com/freedesktop-sdk/noopenh264
A distributor may wish to link against openh264/noopenh264
Weak filter can overflow in delta0 calculation before >> 4 in int16.
Signed-off-by: J. Dekker
---
I do not know x86 simd at all, so this is just an attempt to fix
the implementation rather than write extremely performant code.
Suggestions welcome.
libavcodec/x86/hevc_deblock.asm | 47 +
60 matches
Mail list logo
