On 02-01-2020 09:21 pm, Gyan Doshi wrote:
The user-set forced KF times are parsed *after* this deleted
loop and rescaled right after parsing.
---
fftools/ffmpeg.c | 4
1 file changed, 4 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9af2bc2fb5..2c5fcc0532 100644
--
On 03-01-2020 04:05 pm, Gyan wrote:
On 03-01-2020 03:30 pm, Michael Niedermayer wrote:
On Fri, Jan 03, 2020 at 12:35:22PM +0530, Gyan Doshi wrote:
Prevents a run of consecutive duplicate frames from all being encoded
as keyframes, when force_key_frames is set to source.
---
fftools/ffmpeg
From: Zhao Zhili
This is a micro-optimization. Saving almost 200 reallocations makes it
worth a try.
---
v3: fix an obvious infinite loop and pass fate-filter test
libavfilter/formats.c | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git
On 1/3/2020 10:16 PM, James Zern wrote:
> Signed-off-by: James Zern
> ---
> libavcodec/libvpxenc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 3f659b4b67..0b8a070304 100644
> --- a/libavcodec/libvpxenc.c
> +++
Signed-off-by: James Zern
---
libavcodec/libvpxenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 3f659b4b67..0b8a070304 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1041,8 +1041,7 @@ static int
IFF-PBM-HAM6 can read out of array without this overallocation
Fixes: Out of array read
Fixes:
19752/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5675331403120640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-b
Hi,
On Tue, Dec 31, 2019 at 9:21 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> In case of failure, all the successfully set entries are stored in
> *pm. We need to manually free the created dictionary to avoid
> memory leak.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/libvpxenc.c |3 +--
>
On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick wrote:
> On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote:
> > I think this was discussed on this list in the past.
> > Not sure what the conclusion was, but I think an unconditional flag like
> > this being added wasn't all that well r
On 03/01/2020 22:59, Derek Buitenhuis wrote:
On 02/01/2020 23:09, Michael Niedermayer wrote:
I think if entry 128 is 0 then the whole table must be 0.
If that is the case, checking the entry 128 of table 4 and 5 would be enough
and caching the entry comparission is maybe not needed.
Is this gua
On Fri, Jan 3, 2020 at 1:56 PM Nicolas George wrote:
> Thierry Foucu (12020-01-03):
> > So, right now, we cannot build ffmpeg with optimization on Mac Os 10.15.
>
> Can't you pass the option as extra-cflags to configure? It should work,
> until a proper fix is proposed.
>
Yes i can, but why shou
On 02/01/2020 23:09, Michael Niedermayer wrote:
> I think if entry 128 is 0 then the whole table must be 0.
> If that is the case, checking the entry 128 of table 4 and 5 would be enough
> and caching the entry comparission is maybe not needed.
Is this guaranteed somehow? It isn't mentioned in the
Thierry Foucu (12020-01-03):
> So, right now, we cannot build ffmpeg with optimization on Mac Os 10.15.
Can't you pass the option as extra-cflags to configure? It should work,
until a proper fix is proposed.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
On Fri, Jan 3, 2020 at 10:37 AM Moritz Barsnick wrote:
> On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote:
> > I think this was discussed on this list in the past.
> > Not sure what the conclusion was, but I think an unconditional flag like
> > this being added wasn't all that well
On Fri, 3 Jan 2020, Marton Balint wrote:
On Fri, 3 Jan 2020, Martin Storsjö wrote:
On Fri, 3 Jan 2020, Marton Balint wrote:
Throughout libavformat there are lots of avio_flush() calls which are
unneeded:
- Instances found at the end of write_header, write_packet and
write_trailer
callba
On Fri, 3 Jan 2020, Martin Storsjö wrote:
On Fri, 3 Jan 2020, Marton Balint wrote:
Throughout libavformat there are lots of avio_flush() calls which are
unneeded:
- Instances found at the end of write_header, write_packet and
write_trailer
callbacks. These are handled by the generic code
On Fri, 3 Jan 2020, Marton Balint wrote:
Throughout libavformat there are lots of avio_flush() calls which are unneeded:
- Instances found at the end of write_header, write_packet and write_trailer
callbacks. These are handled by the generic code in libavformat/mux.c.
They are only handled by
On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote:
> I think this was discussed on this list in the past.
> Not sure what the conclusion was, but I think an unconditional flag like
> this being added wasn't all that well received.
Yes, discussed in this thread in November:
http://ffm
Removing explicit avio_flush() calls helps us to buffer more data and avoid
flushing the IO context too often which causes reduced IO throughput for
non-streamed file output.
By converting the avio_flush() calls in the middle of write_packet callbacks we
make flushing a possibility not a requireme
Throughout libavformat there are lots of avio_flush() calls which are unneeded:
- Instances found at the end of write_header, write_packet and write_trailer
callbacks. These are handled by the generic code in libavformat/mux.c.
- Instances in the middle of write_header and write_trailer which are
avio_close_dyn_buf() also does avio_flush().
Signed-off-by: Marton Balint
---
libavformat/hlsenc.c | 2 --
libavformat/oggenc.c | 1 -
libavformat/rtpdec.c | 2 --
3 files changed, 5 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 561e3ff736..d130f03ea6 100644
--- a/
> +This filter freeze video frames using frame from 2nd input.
^
Grammar nit: freezes
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
quinkbl...@foxmail.com:
> From: Zhao Zhili
>
> This is a micro-optimization. Saving almost 200 reallocations makes it
> worth a try.
> ---
> libavfilter/formats.c | 43 +++
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/libavfilter/fo
On Fri, 03. Jan 22:25, quinkbl...@foxmail.com wrote:
> From: Zhao Zhili
>
> This is a micro-optimization. Saving almost 200 reallocations makes it
> worth a try.
> ---
> libavfilter/formats.c | 43 +++
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
On Fri, 27 Dec 2019, Marton Balint wrote:
Deprecated since March 28, 2017.
Applied the series.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above
On Fri, 27 Dec 2019, Lou Logan wrote:
On Fri, Dec 27, 2019, at 12:14 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/muxers.texi | 52 ++--
1 file changed, 26 insertions(+), 26 deletions(-)
LGTM
Thanks, applied, as well as pa
Add s337m probing/reading similarly to spdif.
Add a new AVOption 'dolbyeprobe' to enable it.
---
libavformat/wavdec.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 575c667452..2796905e1f 100644
--- a/l
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 +++
libavformat/s337m.h | 19 +++
2 files changed, 54 insertions
Fix reading beyond data_end.
---
libavformat/wavdec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index ccb9576b84..039ec1658e 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -643,8 +643,6 @@ static int wav
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/Makefile
index e5f41008d4..65ccca
---
libavformat/wavdec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 039ec1658e..0980d85189 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -714,14 +714,14 @@ smv_out:
size = FFMIN(S
---
libavformat/wavdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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,
WAVD
Prepare use of s337m_get_packet from outside.
---
libavformat/s337m.c | 28 +---
libavformat/s337m.h | 38 ++
2 files changed, 59 insertions(+), 7 deletions(-)
create mode 100644 libavformat/s337m.h
diff --git a/libavformat/s337m.c b/li
Prepare the support of s337m in muxers other than raw (ex: wav).
For example, this forbids reading 16 bits DolbyE stream from a 24 bit wav file.
---
libavformat/s337m.c | 20 ++--
libavformat/s337m.h | 3 ++-
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/libavfor
s337m_get_offset_and_codec does not make use of
AVFormatContext: AVClass is enough for logging.
Will facilitate further use from outside
---
libavformat/s337m.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/s337m.c b/libavformat/s337m.c
index 48ab66a6da
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 wav is now similar to the existing one
for spdif,
main differences rem
From: Zhao Zhili
This is a micro-optimization. Saving almost 200 reallocations makes it
worth a try.
---
libavfilter/formats.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 33c6
On Fri, Jan 3, 2020 at 7:39 AM Michael Niedermayer
wrote:
>
> On Thu, Jan 02, 2020 at 07:55:05PM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > In case of failure, all the successfully set entries are stored in
> > *pm. We need to manually free the created dictionary to avoid
> > memory leak.
On 03-01-2020 03:30 pm, Michael Niedermayer wrote:
On Fri, Jan 03, 2020 at 12:35:22PM +0530, Gyan Doshi wrote:
Prevents a run of consecutive duplicate frames from all being encoded
as keyframes, when force_key_frames is set to source.
---
fftools/ffmpeg.c | 3 ++-
1 file changed, 2 insertio
On Fri, Jan 3, 2020 at 9:24 AM Andrey Semashev
wrote:
>
> On 2020-01-03 09:14, Kieran Kunhya wrote:
> >>
> >>> Thanks.
> >>
> >> Ping?
> >>
> >
> > Have you tried using our LATM mux?
>
> No, I'm trying to avoid libavformat dependency. I'm sure my LATM code is
> fine because it works with libfdk-aa
I think this was discussed on this list in the past.
Not sure what the conclusion was, but I think an unconditional flag like
this being added wasn't all that well received.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
On Fri, Jan 03, 2020 at 12:35:22PM +0530, Gyan Doshi wrote:
> Prevents a run of consecutive duplicate frames from all being encoded
> as keyframes, when force_key_frames is set to source.
> ---
> fftools/ffmpeg.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
maybe ok (i wonder if this
On Fri, Jan 03, 2020 at 06:59:28AM +, Fu, Ting wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Friday, December 27, 2019 07:38 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH V4 1/2]
On 2020-01-03 09:14, Kieran Kunhya wrote:
Thanks.
Ping?
Have you tried using our LATM mux?
No, I'm trying to avoid libavformat dependency. I'm sure my LATM code is
fine because it works with libfdk-aac.
___
ffmpeg-devel mailing list
ffmpeg-de
43 matches
Mail list logo
