ok
On 10/2/19, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: signed integer overflow: 512 * 2147483647 cannot be represented in
> type 'int'
> Fixes:
> 17809/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA1_fuzzer-5634409947987968
>
> Found-by: continuous fuzzing pro
> > On Oct 1, 2019, at 23:07, Lukas Fellechner wrote:
> >
> > This has worked very well for quite a long time. But after upgrading to
> > FFmpeg 4.2, the build fails. A lot of changes and additions have been done
> > for ARM/NEON 64-bit, and it looks like many of them are not compatible with
> > Compiling FFmpeg with gas-preprocessor.pl and armasm or armasm64 fails
> > since FFmpeg 4.2.
> >
> > New .rdata sections have been added in ARM NEON assembly code (e.g.
> > libavutil/aarch64/asm.S).
> > This fix allows gas-preprocessor to translate those sections to armasm
> > compatible co
It seems that my first attempt to send the patch failed (probably because my
box where I executed "git send-email" failed reverse smtp check), so I'm going
to re-send it to this same thread.
---
When incoming media has non-zero start PTS,
segment muxer would fail to correctly calculate
the poin
---
libavformat/mpegts.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 5a3e71d9ab..02da272325 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -169,6 +169,7 @@ struct MpegTSCon
---
libavformat/mpegts.c | 45 +++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 587ed33327..5a3e71d9ab 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -169,7 +169,7 @@ struct
hi,
here the first version of NIT table extraction from DVB stream.
Patch 2/3 only open default NIT pid whereas patch 3/3 read PAT table
to open even non-standard NIT pid.
Anthony Delannoy
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6 ++
libavcodec/version.h| 2 +-
3 f
On Wed, Oct 02, 2019 at 02:58:05PM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavformat/avidec.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree
On Thu, Oct 03, 2019 at 08:54:19AM +0200, Paul B Mahol wrote:
> probably lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signat
On Thu, Oct 03, 2019 at 08:56:54AM +0200, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Desc
On Thu, Oct 03, 2019 at 08:52:49AM +0200, Paul B Mahol wrote:
> ok
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Des
Add support for properly handling PC/TV ranges and Rec601/Rec709 color spaces.
Example for PC range YUV, compare to ImageMagick decoding:
https://samples.ffmpeg.org/image-samples/dscf0013.tif
From 5e24edbf73f3a897fd203e36963e9cf5db5e688d Mon Sep 17 00:00:00 2001
From: Pavel Skakov
Date: Thu, 3 O
On Wed, Oct 02, 2019 at 09:05:35AM +0200, Matthieu Bouron wrote:
> On Wed, Oct 02, 2019 at 06:04:10AM +0200, Andreas Rheinhardt wrote:
> > Up until now, aiffenc didn't rely on the standard functions for adding
> > an element to a linked list and freeing the list, but instead
> > reimplemented them.
On Wed, Oct 02, 2019 at 09:10:18AM +0200, Matthieu Bouron wrote:
> On Wed, Oct 02, 2019 at 06:04:11AM +0200, Andreas Rheinhardt wrote:
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > libavformat/aiffenc.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib
On Wed, Oct 02, 2019 at 09:09:28AM +0200, Matthieu Bouron wrote:
> On Wed, Oct 02, 2019 at 06:04:12AM +0200, Andreas Rheinhardt wrote:
> > The check "if (!pb->seekable & AVIO_SEEKABLE_NORMAL)" is wrong, because
> > ! has higher precendence than &. But it is also redundant, because this
> > part of
On Thu, Oct 03, 2019 at 01:20:25PM +0200, Lukas Fellechner wrote:
> > > Compiling FFmpeg with gas-preprocessor.pl and armasm or armasm64 fails
> > > since FFmpeg 4.2.
> > >
> > > New .rdata sections have been added in ARM NEON assembly code (e.g.
> > > libavutil/aarch64/asm.S).
> > > This fix al
Am Do., 3. Okt. 2019 um 20:50 Uhr schrieb Skakov Pavel :
>
> Add support for properly handling PC/TV ranges and Rec601/Rec709 color spaces.
Can't this be implemented without using floats?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 10/3/2019 3:42 PM, Skakov Pavel wrote:
> Add support for properly handling PC/TV ranges and Rec601/Rec709 color
> spaces.
> Example for PC range YUV, compare to ImageMagick decoding:
> https://samples.ffmpeg.org/image-samples/dscf0013.tif
>
> 0001-avcodec-tiff-add-limited-support-for-ReferenceB
The rescaling can be done at muxing/encoding time, for formats that require it.
Signed-off-by: James Almer
---
libavformat/matroskadec.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
i
Am Fr., 4. Okt. 2019 um 01:59 Uhr schrieb James Almer :
>
> The rescaling can be done at muxing/encoding time, for formats that require
> it.
Doesn't this need a micro version bump?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
On Wed, Oct 2, 2019 at 3:42 PM Jun Li wrote:
>
>
> On Wed, Oct 2, 2019 at 3:22 PM Carl Eugen Hoyos
> wrote:
>
>> Am Mi., 2. Okt. 2019 um 02:21 Uhr schrieb Jun Li :
>> >
>> > On Tue, Oct 1, 2019 at 4:19 AM Carl Eugen Hoyos
>> wrote:
>> >
>> > > Am Di., 10. Sept. 2019 um 21:12 Uhr schrieb Jun Li
On 10/2/2019 8:04 PM, Mark Thompson wrote:
> ---
> With intent to add some sort of support for this in H.265 metadata, though
> it's not in this set.
>
> Is there any thought on what a human-usable text serialisation of
> AVMasteringDisplayMetadata should look like? Ideally it wants to be
> so
On 10/3/2019 9:26 PM, Carl Eugen Hoyos wrote:
> Am Fr., 4. Okt. 2019 um 01:59 Uhr schrieb James Almer :
>>
>> The rescaling can be done at muxing/encoding time, for formats that require
>> it.
>
> Doesn't this need a micro version bump?
No. The way these readers set the values is irrelevant. Wri
On 9/28/2019 2:54 PM, Andreas Rheinhardt wrote:
> The structure of a ProRes frame in mov/mp4 is that of a typical atom:
> First a 32 bit BE size field, then a tag detailling the content. Said
> size field includes the eight bytes of the atom header.
>
> This header is actually redundant, as the si
Chroma format was not checked properly as it's always set to
cudaVideoChromaFormat_420 regardless of the input pixel format.
0001-cuviddec-Properly-check-capability-for-chroma-format.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-de
On Tue, 1 Oct 2019 18:26:20 +0300
Lauri Kasanen wrote:
> Hi,
>
> I'll apply these in a couple days if no objections. Works ok in my
> tests.
Applying.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
You should use AVRationals instead. It's ideal seeing the way these
values are coded in the bitstream.
See libavutil/rational.h
Can AVRational be used even through the values are essentially unsigned?
LibTIFF really likes to encode 0..1 values with denominator 0x.
_
27 matches
Mail list logo
