From: Gautam Ramakrishnan
bpno becoming negative is not an error. This check has
been verified with openjpeg, where the loop ends safely
when bpno becomes negative, instead of returning an error.
This patch must resolve ticket #5630.
---
libavcodec/jpeg2000dec.c | 3 +--
1 file changed, 1 insert
Signed-off-by: Ruiling Song
---
libswscale/swscale.c | 16 +---
libswscale/swscale_internal.h | 5 +
libswscale/x86/swscale.c | 3 +--
3 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 8436f056d4..001c
Andreas Rheinhardt:
> mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the
> WavPack extradata (containing the WavPack version) during remuxing from
> a Matroska file; currently our demuxer would treat every WavPack block
> encountered as invalid data (unless the WavPack stream is
---
libavformat/img2dec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 40f3e3d499e..93cd51c1932 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -775,6 +775,7 @@ static int jpeg_probe(const AVProbeData *p)
When the user opted to write the Cues at the beginning, the Cues were
simply written without checking in advance whether enough space has been
reserved for them. If it wasn't enough, the data following the space
reserved for the Cues was simply overwritten, corrupting the file.
This commit changes
The Matroska muxer has the ability to write the Cues (the index) at the
beginning of the file (in front of the Cluster): The user inputs the
amount of space that should be reserved at the beginning of the file and
if this is sufficient, the Cues will be written there and the part of the
reserved sp
When the Cues are written in front of the Cluster, the muxer would seek
to the beginning (to where the Cues ought to be written) and write the
Cues; afterwards it would seek back to the end of the file only to seek
to the beginning once again to update several elements there. This
commit removes th
On 31/03/2020 00:36, Michael Bradshaw wrote:
> The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
> experimental and the clli atom is not written by default.
Would it make sense to allow it by default for QTFF only, since it is properly
defined in it? OR would that perhaps be a
On 01/04/2020 09:52, Matthieu Bouron wrote:
> ---
> libavformat/img2dec.c | 1 +
> 1 file changed, 1 insertion(+)
Looks correct, but a commit message explaining why would be good.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ff
On Wed, Apr 1, 2020 at 6:04 AM Derek Buitenhuis
wrote:
> Would it make sense to allow it by default for QTFF only, since it is
> properly
> defined in it? OR would that perhaps be a little confusing from a user
> perspective?
>
Do you know where it's properly defined for QTFF? The only reference
LGTM
On 4/1/20, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> bpno becoming negative is not an error. This check has
> been verified with openjpeg, where the loop ends safely
> when bpno becomes negative, instead of returning an error.
> This patch must resolve ticket #5630.
> ---
On 01/04/2020 13:30, Michael Bradshaw wrote:
> On Wed, Apr 1, 2020 at 6:04 AM Derek Buitenhuis
> wrote:
> Do you know where it's properly defined for QTFF? The only references that
> I've been able to find about this atom are in the two links in my original
> email, which isn't satisfactory to me
Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
:
>
> ---
> libavformat/img2dec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 40f3e3d499e..93cd51c1932 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @
Hi!Is it working? I try everything but constantly get error from overlay_cuda:
ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid -c:v
h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png -filter_complex
"[1:v]format=nv12,hwupload[img];[0:v][img]overlay_cuda=x=50:y=8
On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
> :
> >
> > ---
> > libavformat/img2dec.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > index 40f3e3d499e
On 01.04.2020 15:43, Alex wrote:
Hi!Is it working? I try everything but constantly get error from overlay_cuda:
ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid -c:v h264_cuvid
-resize 1920x1080 -i 720p.mp4 -i watermark.png -filter_complex
"[1:v]format=nv12,hwupload[i
On Wed, 1 Apr 2020 at 16:43, Alex <3.1...@ukr.net> wrote:
> Hi!Is it working? I try everything but constantly get error from
> overlay_cuda:
>
>
> ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvid
> -c:v h264_cuvid -resize 1920x1080 -i 720p.mp4 -i watermark.png
> -filter_co
How does the NVDEC path work out?
It fails to even initialize the filter on his hardware, no path will
work any differently.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visi
On Wed, Apr 01, 2020 at 01:04:58PM +0100, Derek Buitenhuis wrote:
> On 01/04/2020 09:52, Matthieu Bouron wrote:
> > ---
> > libavformat/img2dec.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> Looks correct, but a commit message explaining why would be good.
>
Would "Skips the DHT segment in jpe
On 01/04/2020 14:28, Matthieu Bouron wrote:
> Would "Skips the DHT segment in jpeg_probe() to avoid looking for JPEG
> markers in the DHT segment data" be OK ?
Sounds OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
Hi!My GPU is GTX 1080Ti.
Trying Your command but same error result.
I tested on windows build downloaded from https://ffmpeg.zeranoe.com/builds/
Stream mapping:
Stream #0:0 (h264) -> overlay_cuda:main
Stream #1:0 (png) -> format
overlay_cuda -> Stream #0:0 (h264_nvenc)
Press [q] to stop, [?]
My GPU is GTX 1080Ti.
--- Original message ---
From: "Timo Rothenpieler"
Date: 1 April 2020, 16:51:27
On 01.04.2020 15:43, Alex wrote:
> Hi!Is it working? I try everything but constantly get error from overlay_cuda:
>
>
> ffmpeg -y -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuvi
Am Mi., 1. Apr. 2020 um 06:47 Uhr schrieb Fu, Linjie :
> > Attached patch fixes compilation with opencl for powerpc where bool
> > always had a meaning different from other architectures. Other
> > work-arounds certainly exist but we usually don't like bool anyway.
> > Fixes ticket #8591.
> >
> >
Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > ---
> > > libavformat/img2dec.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > >
Driver 445.75 (Win 10)
--- Original message ---
From: "Alex" <3.1...@ukr.net>
Date: 1 April 2020, 17:01:28
My GPU is GTX 1080Ti.
--- Original message ---
From: "Timo Rothenpieler"
Date: 1 April 2020, 16:51:27
On 01.04.2020 15:43, Alex wrote:
> Hi!Is it working? I try everything but constantly
On Wed, Apr 01, 2020 at 04:09:08PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > ---
> >
Am Mi., 1. Apr. 2020 um 16:24 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 04:09:08PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> > > > Am Mi., 1. Apr.
Hi!
Attached patches fix three wrong format specifiers, the variables are
all of type int but the specifier PRId16 is used.
Please comment, Carl Eugen
From ac68cb557371842d50f8debec58cc447b4ddb96c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 1 Apr 2020 16:53:04 +0200
Subject: [PATC
Hi!
Attached patch silences a few warnings when compiling with cl.exe or
clang-cl.exe.
Or are there any working options?
Please comment, Carl Eugen
From c1c8a1aad6651e9316863b582912e66231b89924 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 1 Apr 2020 16:57:40 +0200
Subject: [PATCH]
On 01.04.2020 16:14, Alex wrote:
Driver 445.75 (Win 10)
I just tested a similar commandline on the same driver:
./ffmpeg_g.exe -v verbose -init_hw_device cuda=cuda -filter_hw_device
cuda -hwaccel_output_format cuda -hwaccel cuda -i recode.mkv -i test.png
-filter_complex
"[1:v]format=nv12,hw
Driver is ok (I just updated it and same result), and nvenc working without
without cuda filters. But with overlay_cuda or scale_cuda ffmpeg is failing.
Then I try to install ffmpeg on linux machine and looks like all working ok,
but not on windows for me.
--- Original message ---
From: "Timo
Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
Failure reported in:
http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random
Signed-off-by: Linjie Fu
---
libavcodec/vaapi_decode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcod
But on my linux machine is rtx2070 card, not 1080ti. Do You testing filter on
10xx gpu card?
1 April 2020, 18:12:22, by "Alex" < 3.1...@ukr.net >:
Driver is ok (I just updated it and same result), and nvenc working without
without cuda filters. But with overlay_cuda or scale_cuda ffmpeg is fai
On 01.04.2020 17:12, Alex wrote:
Driver is ok (I just updated it and same result), and nvenc working without
without cuda filters. But with overlay_cuda or scale_cuda ffmpeg is failing.
Then I try to install ffmpeg on linux machine and looks like all working ok,
but not on windows for me.
D
On Wed, Apr 1, 2020 at 7:21 AM Derek Buitenhuis
wrote:
> I might have mistakenly be thinking of mdcv, which the PDf you linked from
> Apple
> lists as being in SMPTE 2084 (I don't have a copy of that spec on hand
> currently...).
>
I just checked SMPTE ST 2084 and it doesn't mention mdcv (or ISO
Fixes probing of JPEG files containing MPF metadata appended at the end
of the file.
The MPF metadata chunk can contains multiple JPEG images (thumbnails)
which makes the jpeg_probe fails (return 0) because it finds a SOI
marker after EOI.
---
This patch fixes probing of JPEG files containing MPF
Attached is an updated patch that resolves merge conflicts against the
latest master.
0001-avformat-movenc-add-write_mdcv-flag-to-write-mdcv-at.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
:
>
> Fixes probing of JPEG files containing MPF metadata appended at the end
> of the file.
>
> The MPF metadata chunk can contains multiple JPEG images (thumbnails)
> which makes the jpeg_probe fails (return 0) because it finds a SOI
> mar
On Wed, Apr 01, 2020 at 04:29:16PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 16:24 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 04:09:08PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed,
Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
:
>
> Fixes probing of JPEG files containing MPF metadata appended at the end
> of the file.
>
> The MPF metadata chunk can contains multiple JPEG images (thumbnails)
> which makes the jpeg_probe fails (return 0) because it finds a SOI
> mar
On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> :
> >
> > Fixes probing of JPEG files containing MPF metadata appended at the end
> > of the file.
> >
> > The MPF metadata chunk can contains multiple JPEG images (thumbn
On Wed, Apr 01, 2020 at 06:19:56PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> :
> >
> > Fixes probing of JPEG files containing MPF metadata appended at the end
> > of the file.
> >
> > The MPF metadata chunk can contains multiple JPEG images (thumbn
Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > Fixes probing of JPEG files containing MPF metadata appended at the end
> > > of the file
On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > Fixes p
Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > > > Am Mi., 1. Apr.
On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed,
Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > > > Am Mi., 1. Apr.
containing updated extradata, in this case a new FLAC streaminfo.
Furthermore, it also tests that the Matroska muxer is able to preserve
uncommon channel layouts by adding Vorbis comments to the CodecPrivate.
Signed-off-by: Andreas Rheinhardt
---
This is in particular intended to test patch [1] (
Andreas Rheinhardt:
> Reserving space in Matroska works by writing a Void element. And until
> now this worked as follows: The current position was recorded and the
> EBML ID as well as the length field written; then the new position was
> recorded to know how much more to write. Afterwards the act
On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed,
Am Mi., 1. Apr. 2020 um 21:07 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> > > > Am Mi., 1. Apr.
Am Mi., 1. Apr. 2020 um 20:42 Uhr schrieb Andreas Rheinhardt
:
>
> containing updated extradata, in this case a new FLAC streaminfo.
> Furthermore, it also tests that the Matroska muxer is able to preserve
> uncommon channel layouts by adding Vorbis comments to the CodecPrivate.
>
> Signed-off-by:
On 4/1/20 12:53 AM, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the
>> WavPack extradata (containing the WavPack version) during remuxing from
>> a Matroska file; currently our demuxer would treat every WavPack block
>> encou
Am Di., 31. März 2020 um 01:36 Uhr schrieb Michael Bradshaw
:
>
> The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
> experimental and the clli atom is not written by default.
>
> The clli atom is referenced by e.g., [1][2] and is already parsed in FFmpeg
> in mov.c.
>
> Once IS
Am Di., 31. März 2020 um 19:00 Uhr schrieb Michael Bradshaw
:
>
> The mdcv atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
> experimental and the mdcv atom is not written by default.
>
> The mdcv atom is referenced by e.g., [1][2] and is already parsed in FFmpeg
> in mov.c.
>
> Once IS
Carl Eugen Hoyos:
> Am Mi., 1. Apr. 2020 um 20:42 Uhr schrieb Andreas Rheinhardt
> :
>>
>> containing updated extradata, in this case a new FLAC streaminfo.
>> Furthermore, it also tests that the Matroska muxer is able to preserve
>> uncommon channel layouts by adding Vorbis comments to the CodecPr
Am Mi., 1. Apr. 2020 um 21:19 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Am Mi., 1. Apr. 2020 um 20:42 Uhr schrieb Andreas Rheinhardt
> > :
> >>
> >> containing updated extradata, in this case a new FLAC streaminfo.
> >> Furthermore, it also tests that the Matroska muxer is able to
Am Mi., 1. Apr. 2020 um 17:24 Uhr schrieb Linjie Fu :
>
> Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
>
> Failure reported in:
> http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/vaapi_d
Am Mi., 1. Apr. 2020 um 06:58 Uhr schrieb Linjie Fu :
>
> Signed-off-by: Linjie Fu
> ---
> tests/api/api-h264-slice-test.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
> index dee93b8..b7aa405 100644
> --- a/tests/api/ap
On Wed, Apr 01, 2020 at 08:01:48AM +0530, Gautam Ramakrishnan wrote:
> On Wed, Apr 1, 2020 at 6:17 AM Michael Niedermayer
> wrote:
> >
> > On Tue, Mar 31, 2020 at 05:32:41PM +0530, gautamr...@gmail.com wrote:
> > > From: Gautam Ramakrishnan
> > >
> > > This patch adds functional changes to suppor
Hi!
It seems to me that this was forgotten when the codec was originally ported.
Please comment, Carl Eugen
From 3077d14fed1c19afbcdfd8282fac2a7f1bf3492d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 1 Apr 2020 21:28:09 +0200
Subject: [PATCH] lavc/sbc: Remove bool usage.
---
libav
On Mon, Mar 30, 2020 at 09:48:13PM -0700, John Rummell wrote:
> Hit send too soon. Patch attached.
>
> On Mon, Mar 30, 2020 at 9:44 PM John Rummell wrote:
>
> > Another uninitialized memory access detected by the Chromium fuzzers.
> >
> amr.c |6 --
> 1 file changed, 4 insertions(+), 2
Fixes: Infinite loop
Fixes: Ticket8594
Signed-off-by: Michael Niedermayer
---
libavformat/oggdec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index de2f24b967..95190589ab 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -389,
On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
>
> If this patch is a good idea (if it fixes playback visually on some devices -
> do I understand that correctly?), it should not be optional imo.
It won't be optional once it's standardized in ISO/IEC 14496-12. But I
think it's good to hav
On Wed, Apr 01, 2020 at 09:10:19PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 21:07 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed,
Am Mi., 1. Apr. 2020 um 21:39 Uhr schrieb Matthieu Bouron
:
>
> On Wed, Apr 01, 2020 at 09:10:19PM +0200, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 21:07 Uhr schrieb Matthieu Bouron
> > :
> > >
> > > On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> > > > Am Mi., 1. Apr.
Am Mi., 1. Apr. 2020 um 21:39 Uhr schrieb Michael Bradshaw
:
>
> On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
> >
> > If this patch is a good idea (if it fixes playback visually on some devices
> > -
> > do I understand that correctly?), it should not be optional imo.
>
> It won't be op
On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 21:39 Uhr schrieb Michael Bradshaw
> :
>>
>> On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
>>>
>>> If this patch is a good idea (if it fixes playback visually on some devices
>>> -
>>> do I understand that correctly?)
On Tue, Mar 31, 2020 at 01:30:22PM -0700, John Rummell wrote:
> Thanks. Updated.
>
> On Tue, Mar 31, 2020 at 5:23 AM Moritz Barsnick wrote:
>
> > On Mon, Mar 30, 2020 at 15:27:46 -0700, John Rummell wrote:
> > > +if (c->aes_decrypt)
> > > +av_free(c->aes_decrypt);
> >
> > av_free() a
On Mon, Mar 30, 2020 at 03:26:28PM -0700, John Rummell wrote:
> Refactoring my previous patch into smaller items. Starting with the one
> found by the Chromium fuzzers.
> oggdec.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> ce9987e85bb11b197e37a6320c7efd8c939e1f42
> 0001-liba
On Wed, Apr 1, 2020 at 11:07 PM James Almer wrote:
>
> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 21:39 Uhr schrieb Michael Bradshaw
> > :
> >>
> >> On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
> >>>
> >>> If this patch is a good idea (if it fixes playback
Updated to return AVERROR_INVALIDDATA.
On Wed, Apr 1, 2020 at 12:33 PM Michael Niedermayer
wrote:
> On Mon, Mar 30, 2020 at 09:48:13PM -0700, John Rummell wrote:
> > Hit send too soon. Patch attached.
> >
> > On Mon, Mar 30, 2020 at 9:44 PM John Rummell
> wrote:
> >
> > > Another uninitialized
> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> If there already are devices that support it, it should not be optional.
There are, but these boxes aren't technically standardized for mp4/mov
as far as I can tell. I'm reluctant (but not entirely opposed) to
enable something by default that isn't
On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote:
> Hi!
>
> It seems to me that this was forgotten when the codec was originally
> ported.
>
why removing "stdbool.h"?
it was defined in 2001? so, most compiler should support it..
Should we not check for the compiler support of it and if not
On 4/1/2020 6:18 PM, Michael Bradshaw wrote:
>> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
>> If there already are devices that support it, it should not be optional.
>
> There are, but these boxes aren't technically standardized for mp4/mov
> as far as I can tell. I'm reluctant (but not entirel
On Thu, Apr 2, 2020 at 12:19 AM Michael Bradshaw
wrote:
>
> > On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> > If there already are devices that support it, it should not be optional.
>
> There are, but these boxes aren't technically standardized for mp4/mov
> as far as I can tell. I'm reluctant (
On 3/31/20 2:47 AM, Anton Khirnov wrote:
> Quoting David Bryant (2020-03-28 21:22:40)
>> On 3/28/20 6:23 AM, Anton Khirnov wrote:
>>> Quoting David Bryant (2020-03-27 23:51:19)
On 3/27/20 5:57 AM, Anton Khirnov wrote:
> The current design, where
> - proper init is called for the first
On Wed, Apr 1, 2020 at 3:34 PM James Almer wrote:
> Your patch to write the colr box by default is an example of this. You
> didn't remove the option like one would expect, but made it "official"
> and left for users the ability to disable the atom's presence. It should
> instead be removed and th
On Wed, Apr 01, 2020 at 03:28:06PM +0200, Matthieu Bouron wrote:
> On Wed, Apr 01, 2020 at 01:04:58PM +0100, Derek Buitenhuis wrote:
> > On 01/04/2020 09:52, Matthieu Bouron wrote:
> > > ---
> > > libavformat/img2dec.c | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > Looks correct, but a commi
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, April 2, 2020 03:22
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure
> when hevc_vaapi is disabled
>
> Am Mi., 1. Apr. 2020 um 1
On Thu, Apr 2, 2020 at 12:58 AM Michael Niedermayer
wrote:
>
> On Wed, Apr 01, 2020 at 08:01:48AM +0530, Gautam Ramakrishnan wrote:
> > On Wed, Apr 1, 2020 at 6:17 AM Michael Niedermayer
> > wrote:
> > >
> > > On Tue, Mar 31, 2020 at 05:32:41PM +0530, gautamr...@gmail.com wrote:
> > > > From: Gau
vf_dnn_processing.c recently changed to use swscale to trasfer data
between AVFrame and dnn model.
Signed-off-by: Guo, Yejun
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 21827ee..56888a5 100755
--- a/configure
+++ b/configure
@@ -3498,6 +3498,7 @@
> From: ffmpeg-devel On Behalf Of
> Guo, Yejun
> Sent: Thursday, April 2, 2020 11:37
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun
> Subject: [FFmpeg-devel] [PATCH] configure: fix build issue of
> vf_dnn_processing.c when --disable-swscale
>
> vf_dnn_processing.c recently changed to use swscale
This flag was added in 492026209 in conjunction with av_demuxer_open()
to allow to pass private options to demuxers. It worked as follows:
av_open_input_stream() (the predecessor of avformat_open_input()) would
not call the read_header function if this flag is set. Instead the user
could set privat
From 854a6197ecae1ddf226876952d0e7935830db2cf Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sat, 1 Jan 2000 09:00:00 +
Subject: [PATCH v2] Add support for playing Audible AAXC (.aaxc) files
The AAXC container format is the same as the (already supported) Audible
AAX format but it use
David Bryant:
> On 4/1/20 12:53 AM, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the
>>> WavPack extradata (containing the WavPack version) during remuxing from
>>> a Matroska file; currently our demuxer would treat every Wa
86 matches
Mail list logo
