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
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 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
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 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
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 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.
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
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
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
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
---
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
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
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
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
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
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
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, 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(-)
>
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
> +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
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/
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
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
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
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, 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:
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, 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
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 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
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 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 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
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 +--
>
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
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
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
> +++
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 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
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
--
43 matches
Mail list logo
