Quoting Nicolas George (2020-01-12 14:33:19)
> Anton Khirnov (12020-01-07):
> > Why would such filters exist and why would we accept them? I do not see
> > how can there be a clean user interface for a broken and undefined use
> > case.
>
> They are already there, they work very well, and people u
Fixes: memleak
Fixes:
19949/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5743636058210304
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/oggparsevorbis.c | 2 +-
1 file changed, 1 in
Quoting Hendrik Leppkes (2020-01-10 23:40:37)
> On Fri, Jan 10, 2020 at 7:31 PM James Almer wrote:
> > Yes, i agree with this if we were talking about clearly marked
> > non-public structs, fields and defines. In those cases, people using
> > them should be aware of the consequences. But these are
Signed-off-by: Guo, Yejun
---
libavfilter/vf_dnn_processing.c | 85 -
1 file changed, 24 insertions(+), 61 deletions(-)
diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
index 13273f2..492df93 100644
--- a/libavfilter/vf_dnn_pr
Quoting Marton Balint (2020-01-10 18:42:03)
>
>
> On Fri, 10 Jan 2020, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2019-12-30 23:23:40)
> >> Also add helper functions to allocate and free such a struct, and make it
> >> usable by providing a new av_eval_expr2 function for which you can spe
NAK
On 1/13/20, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 19949/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5743636058210304
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
On Sat, Jan 11, 2020 at 12:13:48 +0800, Jun Zhao wrote:
> +@item level
> +@item quality
> +Same as quality option. And the command accepts the @code{max} same as the
> @code{6}.
> +@end table
I'm sorry for coming in late, but this sentence doesn't make much sense
to me:
And the command accepts
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_eq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index f4cf499..de93901 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -390,5 +390,5 @@ AVFilter ff_vf_e
From: Limin Wang
One test case is different, before the patchset, it's:
"path" + "/" = "path/"
After applied the patchset, it's:
"path" + "/" = "path"
Signed-off-by: Limin Wang
---
libavutil/tests/avstring.c | 3 +++
tests/ref/fate/avstring| 3 +++
2 files changed, 6 insertions(+)
diff --
>> +if (container_word_bits && (container_word_bits+7)/8 !=
>> + (word_bits+7)/8) {
>
>Can it happen that word_bits is anything but 16 or 24 with a valid stream? If
>not then I'd check container_word_bits == word_bits && (word_bits == 16 ||
>word_bits == 24) or so
word_bits may be 20, and in
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/avstring.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 76a13ba..f4b8ed2 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -258,15 +258,17 @@ c
From: Limin Wang
I don't have a windows develoment system yet, so I had to test with modified
avutil/tests/avstring.c like below,
(change / to \\) and change HAVE_DOS_PATHS to 1 in config.h:
-TEST_APPEND_PATH_COMPONENT("path", "/", "path");
-TEST_APPEND_PATH_COMPONENT("path", "comp", "pat
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
>> 2796905e1f..ccb9576b84 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *s,
>> WAVDemuxContext *wav)
>> ret = AVERROR(ENOMEM);
>
>> if (CONFIG_SPDIF_DEMUXER && wav->spdif == 1)
>> return ff_spdif_read_packet(s, pkt);
>> -if (CONFIG_S337M_DEMUXER && wav->s337m == 1)
>> -return ff_s337m_read_packet(s, pkt);
>>
>> if (wav->smv_data_ofs > 0) {
>> int64_t audio_dts, video_dts; @@ -712,6 +
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 actual writing
has been perform
On Tue, Jan 7, 2020 at 2:56 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Since bae8844e the packet will always be unreferenced when a demuxer
> returns an error, so that a lot of calls to av_packet_unref() in lots of
> demuxers are now redundant and can be removed.
>
> Signed-off
On Mon, Jan 13, 2020 at 12:08:28 +0530, Parameshwaran Thangaraj wrote:
> I would like to cross compile ffmpeg and ffplay for linux embedded with ARM
> processor.
> Other parameters:
> *Toradex Apalis iMX6*
> *RAM 1GB*
>
> ffmpeg is working fine. But ffplay is not working. Shows following error,
Th
On 11/01/2020 09:18, fgodt...@hotmail.com wrote:
> From: FgoDt
>
> Add use_captureblt option for disable or use CAPTUREBLT flag, when useing the
> bitblt function with CAPTUREBLT may caused the Windows mouse cursor flicker.
> most time we don't need this flag to capture window
> I tested on Win
>> Test the new 'dolbyeprobe' AVOption.
>> Test dolby_e decoding for 24 bits with program config '5.1+2'
>> ---
>> tests/Makefile | 1 +
>> tests/fate-run.sh| 4
>> tests/fate/audio.mak | 5 +
>> 3 files changed, 10 insertions(+)
>>
>> diff --git a/tests/Makefile b/tests/Makefi
On 10/01/2020 14:51, Steven Liu wrote:
> fix ticket: 8461
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Can you explain the intent? The referenced bug seems specific to Windows?
- Derek
___
On 09/01/2020 10:52, lance.lmw...@gmail.com wrote:
> +default:
> +pict_type = AV_PICTURE_TYPE_NONE;
Is this ever possible to actually hit in the API, though?
Maybe more useful to return an error in such a case, since something
is really wrong probably?
- Derek
___
> 在 2020年1月14日，00:13，Derek Buitenhuis 写道：
>
> On 10/01/2020 14:51, Steven Liu wrote:
>> fix ticket: 8461
>>
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Can you explain the intent? The referenced bug seems specific to
On 10/01/2020 22:06, Lynne wrote:
> Patch attached.
>
> Very widespread, every NASA TIFF image has an ICC profile embedded, and its
> almost never sRGB, so this is really needed for proper color display.
[...]
> ---
> libavcodec/tiff.c | 13 +
> libavcodec/tiff.h | 1 +
> 2 files
> 在 2020年1月14日，00:29，Steven Liu 写道：
>
>
>
>> 在 2020年1月14日，00:13，Derek Buitenhuis 写道：
>>
>> On 10/01/2020 14:51, Steven Liu wrote:
>>> fix ticket: 8461
>>>
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavformat/hlsenc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Can you
On Mon, 13. Jan 10:56, Gyan wrote:
>
>
> On 13-01-2020 09:41 am, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > Signed-off-by: Andriy Gelman
> > ---
> > doc/decoders.texi | 12
> > doc/encoders.texi | 27 +++
> > 2 files changed, 39 insertions(+)
On 13/01/2020 16:31, Steven Liu wrote:
>>> Can you explain the intent? The referenced bug seems specific to Windows?
>> Yes, windows, there no problem since commit
>> 75aea52a1051a22bdebd0b7a8098ac6479a529a0
> s/since/before/g
OK. If you could add that in the commit message (and what broke), LGTM
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 2 +-
libavfilter/asrc_anoisesrc.c | 22 +++---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e691ec0bb2..ba070d40a8 100644
--- a/doc/filters.texi
+++ b/doc/
Jan 13, 2020, 16:06 by derek.buitenh...@gmail.com:
> On 10/01/2020 22:06, Lynne wrote:
>
>> Patch attached.
>>
>> Very widespread, every NASA TIFF image has an ICC profile embedded, and its
>> almost never sRGB, so this is really needed for proper color display.
>>
>
> [...]
>
>> ---
>> libavcod
This patch is Work-In-Progess, and I need your help...
The objective of this patch is to insert the Splicing Point Count data inside
the MPEG-TS header. The current code does it for every video packet. But this
is buggy as we need to insert this data at GOP boundaries. Then the code is
prepared to
This patch was initially composed of 7 patchs, the two first have been applied.
There was no feedback on these remaining 5 patchs for long, but I just have
catched in
the patchwork that Michael asked me to repost the whole set to facilitate the
review...
So here it is!
Thank you in advance for th
This will allow probing input coded side data, and also forwarding them to the
output.
---
libavformat/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3270d971c6..ddc36cce1c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@
This will allow avformat_find_stream_info() get side data from the codec
context.
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 11 +++
libavformat/utils.c| 15 +++
libavformat/version.h | 4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff --
This code is now shared with avformat_find_stream_info().
---
fftools/ffmpeg.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6bcd7b94d2..a513e9f3cc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3534,19 +35
Makes it behave similarly to av_stream_add_side_data().
---
libavcodec/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ab48754a64..d9af6053bb 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1978,6 +1978,11 @@ AVCPBProperti
This fixes mpeg2video stream copies to mpeg muxer like this:
ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
---
libavcodec/mpeg12dec.c | 7 +++
tests/ref/fate/mxf-probe-d10 | 3 +++
tests/ref/fate/ts-demux | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcod
Quoting Nicolas Gaullier (2020-01-13 19:54:55)
> This will allow avformat_find_stream_info() get side data from the codec
> context.
If the intention is to use this code from avformat_find_stream_info(),
then why should it be public? The documentation is very unclear as to
when/how an API user is
On 13/01/2020 17:50, Lynne wrote:
> Actually the entire condition needs to be gone. count is uint32_t. The length
> is already checked below.
> Copied this from ff_tadd_shorts_metadata which has an int count.
Ah.
> And the offset value isn't taken into account. TIFF allows the ICC profile to
>
mån 2020-01-13 klockan 14:02 + skrev Gaullier Nicolas:
> > > +if (container_word_bits && (container_word_bits+7)/8 !=
> > > + (word_bits+7)/8) {
> >
> > Can it happen that word_bits is anything but 16 or 24 with a valid
> > stream? If not then I'd check container_word_bits == word_bits &&
mån 2020-01-13 klockan 16:10 + skrev Gaullier Nicolas:
> > >
> > > +FATE_SAMPLES_AUDIO-$(call DEMDEMDEC, WAV, S337M, DOLBY_E) +=
> > > +fate-dolby-e-wav
> > > +fate-dolby-e-wav: CMD = dolbye2pcm16 -i
> > > +$(TARGET_SAMPLES)/dolby_e/512.wav
> > > +fate-dolby-e-wav: CMP = oneoff
> > > +fate-d
Am Mo., 13. Jan. 2020 um 19:55 Uhr schrieb Nicolas Gaullier
:
>
> This patch was initially composed of 7 patchs, the two first have been
> applied.
> There was no feedback on these remaining 5 patchs for long, but I just have
> catched in
> the patchwork that Michael asked me to repost the whole
Am Fr., 3. Jan. 2020 um 16:57 Uhr schrieb Nicolas Gaullier
:
>
> Similar to ff_spdif_probe() with two additionnal parameters:
> - an AVClass for logging
> - the bit resolution of the container as it may be 16 or 24 for s337m
> ---
> libavformat/s337m.c | 35 +++
> l
Am Fr., 3. Jan. 2020 um 16:56 Uhr schrieb Nicolas Gaullier
:
>
> This is a new version of my previous patchset reviewed by Tomas.
> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247677.html
>
> It takes into account the last feedback from Carl Eugen,
> I mean that the integration of s337m in
Am Mo., 13. Jan. 2020 um 15:53 Uhr schrieb Gaullier Nicolas
:
>
> >> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index
> >> 2796905e1f..ccb9576b84 100644
> >> --- a/libavformat/wavdec.c
> >> +++ b/libavformat/wavdec.c
> >> @@ -78,7 +78,7 @@ static void set_spdif_s337m(AVFormatContext *
Jan 13, 2020, 20:20 by derek.buitenh...@gmail.com:
> On 13/01/2020 17:50, Lynne wrote:
>
>> Actually the entire condition needs to be gone. count is uint32_t. The
>> length is already checked below.
>> Copied this from ff_tadd_shorts_metadata which has an int count.
>>
>
> Ah.
>
>> And the offset
On 13/01/2020 22:05, Lynne wrote:
> bytestream2_seek returns the amount of bytes since the start of the buffer
> after seeking. It clips to the size of the buffer so you can't seek past the
> end.
LGTM then.
- Derek
___
ffmpeg-devel mailing list
ffmpe
>If the intention is to use this code from avformat_find_stream_info(),
>then why should it be public? The documentation is very unclear as to
>when/how an API user is supposed to call it.
>
>Anton Khirnov
Sorry about that, I should have explained this in the cover letter, or maybe
even in the co
>Apart from what Anton wrote, it appears to me that not all patches in the
>series are necessary to fix the stream-copying.
>
>Carl Eugen
Precisely:
- 1/2/3 are working together : actual code from ffmpeg.c that is used for
stream encoding is now used for probing in libav, so it is "moved to publi
>Since you add an option in a later patch: Can you explain the
>reasoning for the whole patchset better?
>If DolbyE can be auto-detected (I assume so), this should be
>done and no further option should be needed.
>
>Carl Eugen
A common use case is stream copying : you want to be able to forward th
Am Mo., 13. Jan. 2020 um 17:10 Uhr schrieb Derek Buitenhuis
:
>
> On 11/01/2020 09:18, fgodt...@hotmail.com wrote:
> > From: FgoDt
> >
> > Add use_captureblt option for disable or use CAPTUREBLT flag, when useing
> > the bitblt function with CAPTUREBLT may caused the Windows mouse cursor
> > fli
Am Mo., 13. Jan. 2020 um 17:07 Uhr schrieb Moritz Barsnick :
>
> On Mon, Jan 13, 2020 at 12:08:28 +0530, Parameshwaran Thangaraj wrote:
> > I would like to cross compile ffmpeg and ffplay for linux embedded with ARM
> > processor.
> > Other parameters:
> > *Toradex Apalis iMX6*
> > *RAM 1GB*
> >
>
Jan 13, 2020, 22:07 by derek.buitenh...@gmail.com:
> On 13/01/2020 22:05, Lynne wrote:
>
>> bytestream2_seek returns the amount of bytes since the start of the buffer
>> after seeking. It clips to the size of the buffer so you can't seek past the
>> end.
>>
>
> LGTM then.
>
Pushed, thanks.
On Fri, 10 Jan 2020 22:05:21 +0100 (CET)
Lynne wrote:
> Patches attached
> Also pushed to https://github.com/cyanreg/FFmpeg/ master branch
> because they're 9 and they add about 7000 lines. Filtering won't work
> without a recent glslang version since they moved a header and broke
> API because t
Hi,
On Fri, Jan 10, 2020 at 9:59 AM Wonkap Jang
wrote:
>
> This commit reuses the configuration options for VP8 that enables
> temporal scalability for VP9. It also adds a way to enable three
> preset temporal structures (refer to the documentation for more
> detail) that can be used in offline e
HI,
On Mon, Jan 13, 2020 at 4:44 PM James Zern
wrote:
> Hi,
>
> On Fri, Jan 10, 2020 at 9:59 AM Wonkap Jang
> wrote:
> >
> > This commit reuses the configuration options for VP8 that enables
> > temporal scalability for VP9. It also adds a way to enable three
> > preset temporal structures (ref
On Mon, Jan 13, 2020 at 04:19:10PM +, Derek Buitenhuis wrote:
> On 09/01/2020 10:52, lance.lmw...@gmail.com wrote:
> > +default:
> > +pict_type = AV_PICTURE_TYPE_NONE;
>
> Is this ever possible to actually hit in the API, though?
>
> Maybe more useful to return an error in such a
On Mon, Jan 13, 2020 at 9:27 PM Moritz Barsnick wrote:
>
> On Sat, Jan 11, 2020 at 12:13:48 +0800, Jun Zhao wrote:
> > +@item level
> > +@item quality
> > +Same as quality option. And the command accepts the @code{max} same as the
> > @code{6}.
> > +@end table
>
> I'm sorry for coming in late, bu
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Monday, January 13, 2020 00:41
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt: add new pixel format
> y210
>
> Am So., 12. Jan. 202
by changing the type to unsigned.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 812d0ad64e..d721ec38fa 100644
--- a/libavformat/segafilmenc.c
+++ b/li
This muxer does not have any private options and so does not need a
private class.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index bd7c03faf5..5ac60ea5c3 100644
The current code only checks when writing the trailer whether the video
format and Codec ID are actually compatible with the container. At this
point, a lot of data will already have been written (in vain, of
course), so check during the init function instead.
Signed-off-by: Andreas Rheinhardt
--
Up until now, the Sega FILM muxer complained if the first stream wasn't a
video stream that there is no video stream at all which is of course
nonsense. So postpone this check.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 8
1 file changed, 4 insertions(+), 4 deleti
If an audio stream is present, the Sega FILM muxer checks for its
compability with the container during init, so that the very same check
needn't be repeated during writing the trailer.
Essentially the same is true for the presence of a video stream: It has
already been checked during init. Furthe
Prevents memleaks when the trailer is never written or when shifting the
data fails when writing the trailer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
by moving them around.
Signed-off-by: Andreas Rheinhardt
---
libavformat/segafilmenc.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index 4f881f4f2f..137f153331 100644
--- a/libavformat/segaf
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Monday, January 13, 2020 00:40
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support
> for Y210
>
> Am So., 29. Dez.
> Am 14.01.2020 um 04:20 schrieb Fu, Linjie :
>
> Zitierten Inhalt anzeigen
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Monday, January 13, 2020 00:40
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-
Am 14.01.2020 um 03:38 schrieb Fu, Linjie :
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Monday, January 13, 2020 00:41
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavu/pix_fmt:
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Ting
> Sent: Friday, January 10, 2020 01:58 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change
> inline assembly into nasm code
>
>
>
> > -Ori
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Ting
> Sent: Tuesday, January 14, 2020 02:15 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V7 1/2] libswscale/x86/yuv2rgb: Change
> inline assembly into nasm code
>
>
>
> > -Or
On 09-01-2020 11:31 am, Gyan wrote:
Barring further reviews, I'll retest and push the patchset on Monday.
Manual and FATE testing passed. Will push patchset in a day.
On 06-01-2020 11:44 am, Gyan wrote:
Ping for the remainder of patchset. Expression parsing and backup has
been factorized
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Tuesday, January 14, 2020 12:42
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/8] swscale: Add swscale input support
> for Y210
>
>
>
> > Am 14.0
71 matches
Mail list logo
