Le 17 juin 2024 01:08:29 GMT+02:00, Michael Niedermayer
a écrit :
>Ive been told that someone at the BCN video tech meetup claimed to be the
>"release maintainer for FFmpeg".
I don't think that this is appropriate in a commit message that'll go on a
blockchain never to be modifiable.
>If you
Le 17 juin 2024 01:08:27 GMT+02:00, Michael Niedermayer
a écrit :
>Fixes: signed integer overflow: 2314885530818453536 + 9151314442816847872
>cannot be represented in type 'long'
>Fixes:
>68359/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6571950311800832
>
>Found-by: continuous fuzzi
Rémi Denis-Courmont:
>
>
> Le 17 juin 2024 01:08:27 GMT+02:00, Michael Niedermayer
> a écrit :
>> Fixes: signed integer overflow: 2314885530818453536 + 9151314442816847872
>> cannot be represented in type 'long'
>> Fixes:
>> 68359/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-657195031
Fixed by making nx/ny always >= 0.
___
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".
On Tue, Jun 18, 2024 at 8:56 AM Rémi Denis-Courmont wrote:
>
>
> Le 17 juin 2024 19:52:10 GMT+02:00, Paul B Mahol a
> écrit :
> >On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont
> wrote:
> >
> >>
> >>
> >> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
> >> yigithanyigitde...@gmail.com
Le 17 juin 2024 22:33:01 GMT+02:00, Marton Balint a écrit :
>Signed-off-by: Marton Balint
>---
> libavutil/timestamp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
>index 2a3e3012a4..6c231a517d 100644
>--- a/libavutil/times
> On Jun 17, 2024, at 5:52 PM, Rémi Denis-Courmont wrote:
>
>
>
> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit
> mailto:yigithanyigitde...@gmail.com>> a écrit :
>> ---
>> libavfilter/af_volumedetect.c | 159 --
>> 1 file changed, 133 insertions(+), 26 del
Michael Niedermayer 于2024年6月17日周一 07:09写道：
>
> Ive been told that someone at the BCN video tech meetup claimed to be the
> "release maintainer for FFmpeg".
>
> If you have any doubt who maintains releases, just do something like the
> following and look at the output:
> VER=5.1
> echo commiters ;
Steven Liu 于2024年6月18日周二 17:53写道：
>
> Michael Niedermayer 于2024年6月17日周一 07:09写道：
> >
> > Ive been told that someone at the BCN video tech meetup claimed to be the
> > "release maintainer for FFmpeg".
> >
> > If you have any doubt who maintains releases, just do something like the
> > following a
Quoting Michael Niedermayer (2024-06-18 01:48:25)
> On Mon, Jun 17, 2024 at 09:07:23AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-06-17 01:08:29)
> > > Ive been told that someone at the BCN video tech meetup claimed to be the
> > > "release maintainer for FFmpeg".
> > >
> >
On Mon, Jun 17, 2024 at 11:02:31PM +0200, Rémi Denis-Courmont wrote:
>
>
> Le 17 juin 2024 20:34:39 GMT+02:00, Michael Niedermayer
> a écrit :
[...]
> >We should turn ffplay into a fully competetive player.
>
> No. First there is no such thing as "a fully competitive player". You would
> need
On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote:
>
>
> > On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote:
> >
> > On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili
> wrote:
> >>
> >>
> >>
> >>> On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
> >>>
> >>> Quoting Zhao Zhili (2024-06-17 07:19:26)
> >
Nuo Mi 于2024年6月18日周二 19:51写道：
>
> On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote:
>
> >
> >
> > > On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote:
> > >
> > > On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili
> > wrote:
> > >>
> > >>
> > >>
> > >>> On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
mån 2024-06-17 klockan 11:41 -0300 skrev James Almer:
> Signed-off-by: James Almer
> ---
> tests/fate/lavf-container.mak | 2 ++
> tests/ref/lavf-fate/hevc.mp4 | 3 +++
> 2 files changed, 5 insertions(+)
> create mode 100644 tests/ref/lavf-fate/hevc.mp4
Looks OK
/Tomas
___
On 6/17/2024 8:20 PM, Derek Buitenhuis wrote:
> 12 files changed, 490 insertions(+), 1 deletion(-)
Will push later today if there are no objections.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpe
James Almer:
> Signed-off-by: James Almer
> ---
> tests/fate/lavf-container.mak | 2 ++
> tests/ref/lavf-fate/hevc.mp4 | 3 +++
> 2 files changed, 5 insertions(+)
> create mode 100644 tests/ref/lavf-fate/hevc.mp4
>
> diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak
>
On 6/18/2024 10:32 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
tests/fate/lavf-container.mak | 2 ++
tests/ref/lavf-fate/hevc.mp4 | 3 +++
2 files changed, 5 insertions(+)
create mode 100644 tests/ref/lavf-fate/hevc.mp4
diff --git a/tests/fate/lavf-containe
The snow encoder uses block based motion estimation which can read out of array
if
insufficient alignment is used
Fixes: out of array access
Fixes:
68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
Fixes:
68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID
Signed-off-by: Michael Niedermayer
---
libavcodec/ratecontrol.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavcodec/ratecontrol.c b/libavcodec/ratecontrol.c
index 609d47faeb4..df27639ca73 100644
--- a/libavcodec/ratecontrol.c
+++ b/libavcodec/rat
Fixes: 5.92611e+20 is outside the range of representable values of type
'unsigned long'
Fixes:
68984/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5155755073273856
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: out of array read
Fixes:
69673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5476592894148608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/snowenc.c | 6 ++
1 fil
Fixes: signed integer overflow: 105788 * -20995 cannot be represented in type
'int'
Fixes: signed integer overflow: 923211729 + 2073948236 cannot be represented in
type 'int'
Fixes: signed integer overflow: 1281179284 + 2073948236 cannot be represented
in type 'int'
Fixes:
68975/clusterfuzz-tes
Fixes: left shift of 1431634944 by 2 places cannot be represented in type 'int'
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes:
69061/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC2_fuzzer-6325700826038272
Found-by: continuous fuzzing process
https://
Fixes: left shift of negative value -208
Fixes:
69073/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_KS_fuzzer-4745020002336768
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/prores
It seems this patch combines a lot of things that might be better to
split into separate patches for easier review
> @@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
> } else if (ncomponents == 1 && s->precision == 8) {
> s->avctx->pix_fmt = AV_PIX_FMT_GRAY8
> On Jun 18, 2024, at 19:50, Nuo Mi wrote:
>
> On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote:
>
>>
>>
>>> On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote:
>>>
>>> On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili
>> wrote:
> On Jun 17, 2024, at 15:05, Anton Khirnov w
lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> p0_10.j2k is one of the reference codestreams included in Rec. ITU-T
> T.803 | ISO/IEC 15444-4.
> ---
> tests/fate/jpeg2000.mak | 3 +++
> tests/ref/fate/jpeg2000dec-p0_10 | 6 ++
> 2 file
fre 2024-06-07 klockan 02:32 +0200 skrev Michael Niedermayer:
> Fixes: CID1592939 Dereference after null check
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/mxfdec.c b/
fre 2024-06-07 klockan 02:32 +0200 skrev Michael Niedermayer:
> Fixes: CID1524681 Logically dead code
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfenc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavfo
mån 2024-06-03 klockan 08:50 +0200 skrev Thilo Borgmann via ffmpeg-
devel:
> Am 02.06.24 um 22:14 schrieb Tomas Härdin:
> > sön 2024-06-02 klockan 20:01 +0200 skrev Michael Niedermayer:
> > > Hi
> > >
> > >
> > > On Sat, Jun 01, 2024 at 05:19:26PM +0200, Tomas Härdin wrote:
> > >
> > > [...]
> >
mån 2024-06-03 klockan 19:16 + skrev marcus:
> >
> >
> > > Check the return value of av_image_get_buffer_size() before
> > > adding
> >
> > > HEADER_SIZE to it. There will be a signed overflow (UB) for
> > > images of
> > > size 16385x16385 (and many others).
> >
> >
> > Sorry, I missed th
On Tue, Jun 18, 2024 at 7:25 AM Tomas Härdin wrote:
>
> lör 2024-06-15 klockan 21:47 -0700 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > p0_10.j2k is one of the reference codestreams included in Rec. ITU-T
> > T.803 | ISO/IEC 15444-4.
> > ---
> > tests/fate/jpeg2000.mak
Signed-off-by: Derek Buitenhuis
---
As requested by James.
---
libavformat/dump.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..8e8b9e1959 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -260,6 +260,15 @@ static
Am 09.06.24 um 21:51 schrieb Theo Fabi:
Video devices categorized by AVFoundation as
'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not
recognized by libavdevice.
Signed-off-by: Theo Fabi
---
libavdevice/avfoundation.m | 3 +++
1 file changed, 3 insertions(+)
Ok. Will
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a
On 2024-06-18 10:00 pm, Timo Rothenpieler wrote:
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file ch
Michael Niedermayer:
> The snow encoder uses block based motion estimation which can read out of
> array if
> insufficient alignment is used
>
> Fixes: out of array access
> Fixes:
> 68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
> Fixes:
> 68969/clusterfuz
On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla wrote:
>
> chrRangeFromJpeg_8_c: 29.2
> chrRangeFromJpeg_8_neon: 19.5
> chrRangeFromJpeg_24_c: 80.5
> chrRangeFromJpeg_24_neon: 34.0
> chrRangeFromJpeg_128_c: 413.7
> chrRangeFromJpeg_128_neon: 156.0
> chrRangeFromJpeg_144_c: 471.0
> chrRangeFromJpeg_14
On 18.06.2024 18:56, Gyan Doshi wrote:
FWIW, I had to do the same for securetransport on a project a couple of
years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
You mean the FFmpeg implementation of rtmps?
Cause if so, I think that only makes use of nonb
On 6/18/2024 12:31 PM, Derek Buitenhuis wrote:
Signed-off-by: Derek Buitenhuis
---
As requested by James.
---
libavformat/dump.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..8e8b9e1959 100644
--- a/libavformat/dump.c
++
Signed-off-by: Derek Buitenhuis
---
libavformat/dump.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..61a2c6a29f 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -259,7 +259,16 @@ static void dum
On 6/18/2024 7:34 PM, James Almer wrote:
> nit: These three could be combined into a single av_log call.
v2 sent.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
On 6/18/2024 3:55 PM, Derek Buitenhuis wrote:
Signed-off-by: Derek Buitenhuis
---
libavformat/dump.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 059fb84522..61a2c6a29f 100644
--- a/libavformat/dump.c
+++ b/libav
ffprobe is meant to generate parseable output, and if a field is present, it
should be printed even if it has a default value.
Signed-off-by: James Almer
---
fftools/ffprobe.c| 9 +++--
tests/ref/fate/matroska-spherical-mono | 3 +++
tests/ref/fate/matrosk
On Tue, 18 Jun 2024, Rémi Denis-Courmont wrote:
Le 17 juin 2024 22:33:01 GMT+02:00, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
libavutil/timestamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
index 2a3e301
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/ambient_viewing_environment.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/ambient_viewing_environment.c
b/libavutil/ambient_viewing_environment.c
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/masteri
Prevent potential divisions by 0 when using them immediately after allocation.
Signed-off-by: James Almer
---
libavutil/stereo3d.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index a40a9439bb..19e81e4124 100644
--
On Thu, 23 May 2024 19:50:23 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> not all clients support metadata compression, output when
> vdr_dm_metadata_changed fails the DV verifier.
>
> Compared to v2 this makes the dovi field name a parameter of the
> DOVI_ENCOD
On Wed, 22 May 2024 15:50:34 + Cosmin Stejerean via ffmpeg-devel
wrote:
> From: Cosmin Stejerean
>
> Some DolbyVision samples fail to parse currently due to mis-reading the
> el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has
> been extended in an as of yet undoc
Moves metadata compression out of the codecs and into a bitstream
filter. This is required by design, because keyframes must have
compression disabled (for obvious reasons). Therefore, we _must_
generate the dolby vision RPUs after encoding.
The downside of this approach is that it requires "redun
From: Niklas Haas
ff_dovi_rpu_parse() and ff_dovi_rpu_generate() are a bit inconsistent in
that they expect different levels of encapsulation, due to the nature of
how this is handled in the context of different APIs. Clarify the status
quo. (And fix an incorrect reference to the RPU payload byte
From: Niklas Haas
As the comment implies, DOVIContext.ext_blocks should also reflect the
current state after ff_dovi_rpu_generate().
Fluff for now, but will be needed once we start implementing metadata
compression for extension blocks as well.
---
libavcodec/dovi_rpuenc.c | 12
1
From: Niklas Haas
And only override it if we either have an exact match, or if we still
have unused metadata slots (to avoid an overwrite).
---
libavcodec/dovi_rpuenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
ind
From: Niklas Haas
Will be used to control compression, encapsulation etc.
---
libavcodec/dovi_rpu.h| 2 +-
libavcodec/dovi_rpuenc.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libx265.c | 3 ++-
5 files changed, 6 insertions(+), 5 deletions(-)
di
From: Niklas Haas
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
---
libavcodec/dovi_rpu.h| 16 ++--
libavcodec/dovi_rpuenc.c | 22 ++-
From: Niklas Haas
Keyframes must reset the metadata compression state, so we cannot enable
metadata compression inside the encoders. Solve this by adding a new
flag, rather than removing it entirely, because I plan on adding
a bitstream filter for metadata compression.
---
libavcodec/dovi_rpu.h
From: Niklas Haas
Provides direct access to the AVDOVIMetadata without having to attach it
to a frame.
---
libavcodec/dovi_rpu.h| 9 +
libavcodec/dovi_rpudec.c | 40 +++-
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/libavcodec/
From: Niklas Haas
This can be used to strip dovi metadata, or enable/disable dovi
metadata compression. Possibly more use cases in the future.
---
configure | 1 +
doc/bitstream_filters.texi | 21 +++
libavcodec/bitstream_filters.c | 1 +
libavcodec/bsf/Makefile
On Tue, 18 Jun 2024 21:35:33 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> And only override it if we either have an exact match, or if we still
> have unused metadata slots (to avoid an overwrite).
> ---
> libavcodec/dovi_rpuenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
On Sat, 15 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
bgra_to_uv_8_c: 13.4
bgra_to_uv_8_neon: 37.4
bgra_to_uv_128_c: 155.9
bgra_to_uv_128_neon: 91.7
bgra_to_uv_1080_c: 1173.2
bgra_to_uv_1080_neon: 822.7
bgra_to_uv_1920_c: 2078.2
bgra_to_uv_1920_neon: 1437.7
bgra_
On Sat, 15 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
bgr24_to_uv_8_c: 41.5
bgr24_to_uv_8_neon: 41.8
bgr24_to_uv_128_c: 133.5
bgr24_to_uv_128_neon: 94.3
bgr24_to_uv_1080_c: 960.5
bgr24_to_uv_1080_neon: 751.0
bgr24_to_uv_1920_c: 1695.3
bgr24_to_uv_1920_neon: 1357.
On Sun, 16 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf:
abgr_to_uv_8_c: 19.4
abgr_to_uv_8_neon: 29.9
abgr_to_uv_128_c: 146.4
abgr_to_uv_128_neon: 85.1
abgr_to_uv_1080_c: 1162.6
abgr_to_uv_1080_neon: 819.6
abgr_to_uv_1920_c: 2063.6
abgr_to_uv_1920_neon: 1435.1
abgr
On Tue, Jun 18, 2024 at 04:20:34PM -0300, James Almer wrote:
> Prevent potential divisions by 0 when using them immediately after allocation.
>
> Signed-off-by: James Almer
> ---
> libavutil/stereo3d.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
i must have applied th
On Tue, Jun 18, 2024 at 7:42 PM Ramiro Polla wrote:
>
> On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla wrote:
> >
> > chrRangeFromJpeg_8_c: 29.2
> > chrRangeFromJpeg_8_neon: 19.5
> > chrRangeFromJpeg_24_c: 80.5
> > chrRangeFromJpeg_24_neon: 34.0
> > chrRangeFromJpeg_128_c: 413.7
> > chrRangeFromJpe
On Sun, Jun 16, 2024 at 02:00:06PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/Makefile | 2 +-
> libavformat/avc.c | 164 +---
> libavformat/avc.h | 37 ---
> libavformat/flvenc.c | 3 +-
On Mon, Jun 17, 2024 at 09:49:01PM -0300, James Almer wrote:
> Fixes: out of array access
> Fixes:
> 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off
On Mon, Jun 17, 2024 at 07:27:16AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: out of array access
> > Fixes:
> > 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuz
On Mon, Jun 17, 2024 at 01:08:56PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Wed, Jun 12, 2024 at 03:48:33PM +0200, Andreas Rheinhardt wrote:
> >> The earlier code had two problems:
> >> 1. For reference frames that are not directly output (happens unless
> >> low_delay is set)
On 17/06/2024 20:34, Michael Niedermayer wrote:
On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote:
On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote:
Apr 22, 2024, 13:07 by stefa...@gmail.com:
On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote:
On 4/17/2024 10
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
From: Fei Wang
Fixes regression from 47d34ba7fbb81
Signed-off-by: Fei Wang
---
libavcodec/hevc/hevcdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 39beb7e4dc..8bb564f1b3 100644
--- a/libavcodec/hevc/hevc
On Mon, 2024-06-17 at 10:05 +0200, Anton Khirnov wrote:
> Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-14 10:18:19)
> > From: Fei Wang
> >
> > Slice address tab only been updated in software decode slice data.
> >
> > Fixes hwaccel decoding after
> > d725c737fe2a19091b481d4d115fd939e0a674
On 2024-06-18 11:53 pm, Timo Rothenpieler wrote:
On 18.06.2024 18:56, Gyan Doshi wrote:
FWIW, I had to do the same for securetransport on a project a couple
of years back to get rtmps working. Worked fine, and did not get any
reports of ill-effects.
You mean the FFmpeg implementation of rtm
First of all, I appreciate your kind review.
I'm writing to discuss the changes and would like to hear your feedback on
these.
> On Jun 18, 2024, at 23:20, Tomas Hardin wrote:
>
>
> It seems this patch combines a lot of things that might be better to
> split into separate patches for easier r
75 matches
Mail list logo
