Anton Khirnov (12020-05-28):
> These functions rely on deprecated libavformat APIs and apparently have
> zero users outside of cmdutils. Since the functionality they provide is
> apparently not useful to anyone, deprecate them without replacement.
Unacceptable and fallacious.
Libavdevice is a
Anton Khirnov (12020-05-28):
> Use opaque iteration state instead of the previous child class. This
> mirrors similar changes done in lavf/lavc.
>
> Deprecate the av_opt_child_class_next() API.
> ---
> libavutil/log.h | 13 +
> libavutil/opt.c | 24 ++--
>
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpeg12enc.c | 2 ++
libavcodec/profiles.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index cab7076..9fbbcef 100644
--- a/libavcodec/mpeg12enc.c
+++
Add support for encoding adpcm_ima_ssi and muxing to kvag.
v6: [2]
- move seekable check into kvag_write_init()
v5: [1]
- change AVERROR(EINVAL) to AVERROR_PATCHWELCOME
- Split "capabilities" argument and formatting out into new commits
- If too verbose, patch 3 may be squashed into
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/kvag.c | 82 +++-
libavformat/version.h| 2 +-
5 files changed, 85 insertions(+), 2 deletions(-)
diff
Anton Khirnov (12020-05-28):
> ---
> libavfilter/framesync.c | 7 +++
> libavfilter/framesync.h | 3 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
> index b32a5cba6c..04119d686c 100644
> --- a/libavfilter/framesync.c
> +++
From: Limin Wang
Signed-off-by: Limin Wang
---
try to avoid floods of warning message for my testing linux host. If you
have better way, fix it anyway.
Below is my Linux system information and gcc version:
[lmwang@vpn2 ffmpeg.git]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
according iso 23009-1 , mimetype is mandatory attibutes, must contain it
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 6f8de5762b..f71c1364b4 100755
---
according iso 23009-1 4th , one Latency element should contain
referenceId , target , max ,min atrributes
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index
according iso 23009-1 , in live cases , mpd refresh period should be
changeable
and default 500 seconds is too long , in normal live cases , it should be
2~5 seconds
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
mode change
sidx box is used for single file cases , should not apply to streaming/live
case
Signed-off-by: SiyuanHuang
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index df081ce3ef..2b2a77267b 100755
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Test content
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
for test latency , need sub-seconds level timestamp watermark
Signed-off-by: SiyuanHuang
---
libavfilter/vf_drawtext.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
mode change 100644 => 100755 libavfilter/vf_drawtext.c
diff --git
On 5/29/2020 4:19 AM, Siyuan Huang wrote:
> sidx box is used for single file cases , should not apply to streaming/live
> case
>
>
>
> Signed-off-by: SiyuanHuang
>
> ---
>
> libavformat/dashenc.c | 2 +-
>
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
> diff --git
On 5/29/2020 4:18 AM, Siyuan Huang wrote:
> according iso 23009-1 , mimetype is mandatory attibutes, must contain it
>
>
>
> Signed-off-by: SiyuanHuang
>
> ---
>
> libavformat/dashenc.c | 4 ++--
>
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
>
> diff --git
On Fri, 29 May 2020 at 14:11, Michael Niedermayer
wrote:
> On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote:
> > >
> > > More generally though (outside this unsafe flag case)
> > > i do disagree with your argument a bit, performance does matter.
> > > Iam regularly reminded of that
On Fri, May 29, 2020 at 02:22:03PM +0100, Kieran Kunhya wrote:
> On Fri, 29 May 2020 at 14:11, Michael Niedermayer
> wrote:
>
> > On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote:
> > > >
> > > > More generally though (outside this unsafe flag case)
> > > > i do disagree with your
On 5/29/2020 4:18 AM, Siyuan Huang wrote:
> according iso 23009-1 , in live cases , mpd refresh period should be
> changeable
>
> and default 500 seconds is too long , in normal live cases , it should be
> 2~5 seconds
It's set to 500 when timeline isn't used (for example, template only),
in
On 5/29/2020 4:19 AM, Siyuan Huang wrote:
> according iso 23009-1 4th , one Latency element should contain
>
> referenceId , target , max ,min atrributes
>
>
>
> Signed-off-by: SiyuanHuang
>
> ---
>
> libavformat/dashenc.c | 2 +-
>
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
On 5/29/2020 10:10 AM, Michael Niedermayer wrote:
> while, what you quote above was not about h264 at all
> let me provide benchmarks of most fate h264 samples with and without
> flag_unsafe
> the script that made that is after it. a reply to the 2nd part of your mail is
> also below
>
>
>
On Fri, May 29, 2020 at 10:37:59AM -0300, James Almer wrote:
> On 5/29/2020 10:10 AM, Michael Niedermayer wrote:
> > while, what you quote above was not about h264 at all
> > let me provide benchmarks of most fate h264 samples with and without
> > flag_unsafe
> > the script that made that is
On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote:
> >
> > More generally though (outside this unsafe flag case)
> > i do disagree with your argument a bit, performance does matter.
> > Iam regularly reminded of that for example, so much software becomes
> > slower on each upgrade with
May 29, 2020, 00:09 by mich...@niedermayer.cc:
> On Sat, May 23, 2020 at 06:09:06PM +, Lynne wrote:
>
> This modifies global state, is neither thread safe nor can it be used from a
> library (it breaks a user application using rand())
>
Thanks for noticing, changed to use
Use an uint32_t for the NAL unit size of an AVC H.264 NAL unit instead
of an int as a left shift of a signed value is undefined behaviour
if the result doesn't fit into the target type.
Also make the log message never output negative lengths.
Signed-off-by: Andreas Rheinhardt
---
On 5/29/20, Jean-Baptiste Kempf wrote:
>
>
> On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote:
>> > The responses are "aggressive" because many people want "fast" mode
>> > gone.
>>
>>
>> This still doesnt explain the aggressive tone we have here.
>
> 1% agree
>
> Whatever the
On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer
wrote:
>
> On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > I have attempted to write a JPEG2000 Parser. Have tested
> > by generating a file containing 14 frames, as mentioned
> > by
When a slice is encountered, the H.264 parser up until now always
unreferenced and reset the currently active PPS; immediately
afterwards, the currently active PPS is set again which includes
referencing it. Given that it is typical for the active parameter
sets to change only seldomly, most of
On Fri, May 29, 2020, at 16:33, Michael Niedermayer wrote:
> > The responses are "aggressive" because many people want "fast" mode gone.
>
>
> This still doesnt explain the aggressive tone we have here.
1% agree
Whatever the technical discussion, there is no reason to be uncivil to each
Andreas Rheinhardt:
> Kieran Kunhya:
>> On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
>> andreas.rheinha...@gmail.com> wrote:
>>
>>> Kieran Kunhya:
On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, the H.264 parser has
This could happen if a four byte NAL unit size is encountered that is
bigger than INT_MAX when read as an uint32_t. This has been changed:
The size is now treated as uint32_t (so that no cast is needed any more
to prevent undefined behaviour when shifting) throughout the code.
Signed-off-by:
On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer
wrote:
>
> On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > I have attempted to write a JPEG2000 Parser. Have tested
> > by generating a file containing 14 frames, as mentioned
> > by
On Fri, May 29, 2020 at 11:23:20PM +0530, Gautam Ramakrishnan wrote:
> On Fri, May 29, 2020 at 5:01 AM Michael Niedermayer
> wrote:
> >
> > On Fri, May 29, 2020 at 12:33:01AM +0530, gautamr...@gmail.com wrote:
> > > From: Gautam Ramakrishnan
> > >
> > > I have attempted to write a JPEG2000
On Thu, May 14, 2020 at 03:31:47PM -0700, Dale Curtis wrote:
> Avoids overflow from fuzzed skip_samples values.
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/utils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint:
current_picture was not writable here because a reference existed in
at least avctx->coded_frame, and potentially elsewhere if the caller
created new ones from it.
Signed-off-by: James Almer
---
For that matter, there are two filters that depend on whatever
s->mpvencdsp.draw_edges is doing on
On Fri, May 29, 2020 at 03:47:03AM +, Zane van Iperen wrote:
> On Thu, 28 May 2020 18:44:55 +0200
> "Michael Niedermayer" wrote:
>
>
> > > The index table should only ever be indexed between [0,7], so this
> > > looks like a bug in adpcm_ima_cunning_expand_nibble() instead.
> >
> > maybe
On Thu, May 14, 2020 at 03:31:49PM -0700, Dale Curtis wrote:
> Signed-off-by: Dale Curtis
> ---
> libavformat/oggparsetheora.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a
Finishes fixing the regression introduced in
a1133db30ef07896afd96f067e5c51531a4e85ab
after the partial fix in b6d6597bef66531ec07c07a7125b88aee38fb220.
Signed-off-by: James Almer
---
libavcodec/decode.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Dale Curtis
---
libavformat/oggparsetheora.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
no_start_time_update_v0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Fri, 29 May 2020, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/mpeg12enc.c | 2 ++
libavcodec/profiles.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index cab7076..9fbbcef 100644
---
On 5/29/2020 8:18 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> try to avoid floods of warning message for my testing linux host. If you
> have better way, fix it anyway.
>
> Below is my Linux system information and gcc version:
>
> [lmwang@vpn2
> Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com:
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> try to avoid floods of warning message for my testing linux host. If you
> have better way, fix it anyway.
>
> Below is my Linux system information and gcc version:
>
>
Hello,
This is a partial implementation of the decoder of the FLIF16 image
format [1]. A large amount of this code has been adapted from the
reference implementation of the FLIF16 (de)coder, written in C++ [2].
The main reason I am posting this patch is to get comments on the
method the
Just to clarify, the raangecoded bitstream is decoded in function
flif16_read_second_header in libavcodec/flif16dec.c. Here the
aforementioned switch statement - segment variable system is used.
Regards,
Anamitra
___
ffmpeg-devel mailing list
On Fri, May 29, 2020 at 09:07:52PM +0200, Marton Balint wrote:
>
>
> On Fri, 29 May 2020, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/mpeg12enc.c | 2 ++
> > libavcodec/profiles.h | 6 ++
> > 2 files changed, 8
On Fri, 29 May 2020 23:41:46 +0200
"Michael Niedermayer" wrote:
>
> On Fri, May 29, 2020 at 10:54:59AM +, Zane van Iperen wrote:
> > Signed-off-by: Zane van Iperen
> > ---
> > Changelog| 1 +
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> >
On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote:
> current_picture was not writable here because a reference existed in
> at least avctx->coded_frame, and potentially elsewhere if the caller
> created new ones from it.
Please elaborate when and how the encoder internal buffer becomes
On Fri, May 29, 2020 at 11:46:05PM +0200, Carl Eugen Hoyos wrote:
>
>
>
> > Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > try to avoid floods of warning message for my testing linux host. If you
> > have better
Fixes: assertion failure
Fixes:
21079/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5737046523248640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hq_hqa.c | 2 +-
1 file
Hi, everyone,
I do some tests with doc/examples/filtering_audio.c on audio formats like mp3,
m4a(aac), mpc, ogg, ape, flac, tta, wma and so on. The original
program(filtering_audio.c) always failed with audio format ape, and I do some
modifications on this program, and runs properly after test.
> Am 28.05.2020 um 12:37 schrieb Martin Storsjö :
>
>> On Mon, 25 May 2020, Martin Storsjö wrote:
>>
>>> On Sun, 24 May 2020, Carl Eugen Hoyos wrote:
>>>
>>> Am So., 24. Mai 2020 um 21:53 Uhr schrieb Martin Storsjö
>> :
>>>
configure --enable-gpl --arch=i686 --cc=clang-cl --ld=lld-link
On Fri, May 29, 2020 at 07:00:12PM -0300, James Almer wrote:
> On 5/29/2020 5:37 PM, Michael Niedermayer wrote:
> > On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote:
> > > current_picture was not writable here because a reference existed in
> > > at least avctx->coded_frame, and
On Fri, May 29, 2020 at 11:46 PM Carl Eugen Hoyos wrote:
>
>
>
>
> > Am 29.05.2020 um 13:18 schrieb lance.lmw...@gmail.com:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > try to avoid floods of warning message for my testing linux host. If you
> > have better way, fix it
On 5/29/2020 5:37 PM, Michael Niedermayer wrote:
On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote:
current_picture was not writable here because a reference existed in
at least avctx->coded_frame, and potentially elsewhere if the caller
created new ones from it.
Please elaborate
On 5/29/2020 7:38 PM, Michael Niedermayer wrote:
> On Fri, May 29, 2020 at 07:00:12PM -0300, James Almer wrote:
>> On 5/29/2020 5:37 PM, Michael Niedermayer wrote:
>>> On Fri, May 29, 2020 at 02:20:37PM -0300, James Almer wrote:
current_picture was not writable here because a reference
On Fri, May 29, 2020 at 06:17:54PM +0200, Andreas Rheinhardt wrote:
> Use an uint32_t for the NAL unit size of an AVC H.264 NAL unit instead
> of an int as a left shift of a signed value is undefined behaviour
> if the result doesn't fit into the target type.
>
> Also make the log message never
On Fri, 29 May 2020, Carl Eugen Hoyos wrote:
Am 28.05.2020 um 12:37 schrieb Martin Storsjö :
Any further comments on this patch?
Please wait a few days more, I am not happy about the patch and at least
I’d like to understand better why this is a good and why there is no
alternative.
Fair
On Sat, May 30, 2020 at 2:01 AM Michael Niedermayer
wrote:
>
> Fixes: assertion failure
> Fixes:
> 21079/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5737046523248640
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On Fri, May 29, 2020 at 10:54:59AM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/kvag.c | 82 +++-
>
On Thu, May 28, 2020 at 1:33 PM Michael Niedermayer
wrote:
> I dont really have an oppinion about start_time, its more the change in
> timestamps & duratiion on the output side which is whats user vissible
> and that looked worse for the testcase
>
The difference is due to the decode stage
On Sat, May 23, 2020 at 7:04 PM wrote:
> From: Mark Reid
>
> changes since v1:
> * cleaned up code style
> * slightly reworked apply_lut functions to feel more consistent with code
>
> ---
> libavfilter/vf_lut3d.c | 372 +++--
> 1 file changed, 317
On Sun, 10. May 15:01, Andriy Gelman wrote:
> From: Andriy Gelman
>
> Signed-off-by: Andriy Gelman
> ---
>
> Same as commit d1e52e396b8aa778bd8d12bf25864beca0937d0a
>
> doc/developer.texi | 2 +-
> fftools/cmdutils.c | 2 +-
> fftools/ffmpeg.c | 2 +-
> 3 files changed, 3 insertions(+), 3
On Mon, May 11, 2020 at 9:37 PM Neil Birkbeck
wrote:
>
>
> On Wed, May 6, 2020 at 8:45 AM James Almer wrote:
>
>> On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
>> > On Tue, May 5, 2020 at 5:11 AM Kieran O Leary > >
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I broke the threading with my last reply, i
Signed-off-by: Andreas Rheinhardt
---
libavcodec/anm.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index e9b19d880d..134640ee36 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -31,13
Then one doesn't need to free the frame in case the length turns out to
be insufficient.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/anm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index cd1fcc5998..e9b19d880d 100644
---
65 matches
Mail list logo
