Michael Niedermayer:
> On Wed, Oct 16, 2019 at 12:43:07PM +0200, Paul B Mahol wrote:
>> Could someone apply this?
>
> will apply
>
> thx
>
> [...]
>
Thanks. There is also a follow-up patch [1] to this that you have
already LGTM'ed in July. Can you apply it, too, please?
- Andreas
[1]:
ignore this, git send get the wrong version.
On Fri, Oct 18, 2019 at 09:15:09AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Threading is to avoid a core cpu being occupied fully with other filters like
> scale,
> regarding performance, if your cpu frequency is very high, the
From: Limin Wang
Threading is to avoid a core cpu being occupied fully with other filters like
scale,
regarding performance, if your cpu frequency is very high, the gain is very
small, but
with more cores and fewer cpu MHz cpus, you will get more improvements.
The following is my testing
From: Limin Wang
Threading is to avoid a core cpu being occupied fully with other filters like
scale,
regarding performance, if your cpu frequency is very high, the gain is very
small, but
with more cores and fewer cpu MHz cpus, you will get more improvements.
The following is my testing
On Thu, Oct 17, 2019 at 06:43:33PM +0200, Michael Niedermayer wrote:
> On Tue, Oct 15, 2019 at 06:37:10PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Threading is to avoid a core cpu being occupied fully with other filters
> > like scale,
> > regarding performance, if your
Oct 17, 2019, 23:25 by mich...@niedermayer.cc:
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 10 +++---
libavcodec/ffv1enc.c | 10 +++---
3 files changed, 15 insertions(+), 6 deletions(-)
Why 0x4964AF46 instead of 0x?
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
Now unconditionally propagating the field, since checking its value is
not correct usage of the field.
libavcodec/libdav1d.c | 25 -
1 file changed, 24 insertions(+), 1
On 10/17/2019 7:46 PM, Andrey Semashev wrote:
> On 2019-10-18 01:28, James Almer wrote:
>> On 10/17/2019 7:13 PM, Andrey Semashev wrote:
>>> On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
Please, ignore this patch.
On 2019-10-18 01:44, James Almer wrote:
On 10/17/2019 7:34 PM, Andrey Semashev wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Not sure why you decided to send a modified patch by another dev, and
with the author name changed, but that's
On 2019-10-18 01:28, James Almer wrote:
On 10/17/2019 7:13 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file
On 10/17/2019 7:34 PM, Andrey Semashev wrote:
> Actually reorder the values.
>
> Should effectively fix ticket #8300.
Not sure why you decided to send a modified patch by another dev, and
with the author name changed, but that's not ok.
> ---
> libavcodec/libdav1d.c | 26
Actually reorder the values.
Should effectively fix ticket #8300.
---
libavcodec/libdav1d.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..774e741db8 100644
--- a/libavcodec/libdav1d.c
On 10/17/2019 7:27 PM, Hendrik Leppkes wrote:
> On Fri, Oct 18, 2019 at 12:13 AM Andrey Semashev
> wrote:
>>
>> On 2019-10-17 23:11, James Almer wrote:
>>> Actually reorder the values.
>>>
>>> Should effectively fix ticket #8300.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>>
On 17.10.2019 23:59, James Almer wrote:
On 10/17/2019 6:43 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file
On 2019-10-18 01:27, Hendrik Leppkes wrote:
On Fri, Oct 18, 2019 at 12:13 AM Andrey Semashev
wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
On Fri, Oct 18, 2019 at 12:13 AM Andrey Semashev
wrote:
>
> On 2019-10-17 23:11, James Almer wrote:
> > Actually reorder the values.
> >
> > Should effectively fix ticket #8300.
> >
> > Signed-off-by: James Almer
> > ---
> > libavcodec/libdav1d.c | 21 -
> > 1 file
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 10 +++---
libavcodec/ffv1enc.c | 10 +++---
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index f0bb19350a..3edf9dfca3 100644
---
Fixes: signed integer overflow: -1094995529 * 2 cannot be represented in type
'int'
Fixes:
18281/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5692589180715008
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
On 10/17/2019 6:57 PM, Andrey Semashev wrote:
> On 2019-10-18 00:43, Andrey Semashev wrote:
>> On 2019-10-17 23:11, James Almer wrote:
>>> Actually reorder the values.
>>>
>>> Should effectively fix ticket #8300.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/libdav1d.c | 21
On 10/17/2019 7:13 PM, Andrey Semashev wrote:
> On 2019-10-17 23:11, James Almer wrote:
>> Actually reorder the values.
>>
>> Should effectively fix ticket #8300.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libdav1d.c | 21 -
>> 1 file changed, 20 insertions(+), 1
Fixes: Timeout (11sec -> 42ms)
Fixes:
18287/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5637866331308032
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rasc.c | 2 ++
1
This way they can be told apart easily
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index bc2b776754..738b1699ea 100644
--- a/libavcodec/ffv1dec.c
+++
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c
On 2019-10-18 00:43, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff
On 10/17/2019 6:43 PM, Andrey Semashev wrote:
> On 2019-10-17 23:11, James Almer wrote:
>> Actually reorder the values.
>>
>> Should effectively fix ticket #8300.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libdav1d.c | 21 -
>> 1 file changed, 20 insertions(+), 1
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..87abdb4569 100644
---
Add new required elements and constrain presence and values for existing
ones based on the spec.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c
If not available, set flags to 24 (bits corresponding to values 8 and 16 set),
to signal the wallclock value is read at the time of writing the atom.
Signed-off-by: James Almer
---
libavformat/movenc.c | 18 --
libavformat/movenc.h | 1 +
2 files changed, 17 insertions(+), 2
This way it will be in sync with the first wallclock value in the bitstream.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index
Will be needed by the next patch.
Signed-off-by: James Almer
---
libavformat/internal.h | 2 +-
libavformat/movenc.c | 2 +-
libavformat/rtpenc.c | 8
libavformat/rtpenc.h | 1 +
libavformat/utils.c| 4 ++--
5 files changed, 9 insertions(+), 8 deletions(-)
diff --git
As defined in section 5.12 from ISO/IEC FDIS 23009-1:2019
Initial implementation using capture time. Will be replaced by a following
commit.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 50 ++-
1 file changed, 40 insertions(+), 10 deletions(-)
In combination with the streaming option it constrains the value of a few
elements,
to prevet clients from buffering too much data before starting presentation.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff
Taken from Wallclock at the time the frame is submitted to the encoder.
Signed-off-by: James Almer
---
libavcodec/libx264.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index bfd91bb900..d2237577b5 100644
Signed-off-by: James Almer
---
TODO: Version bump and APIchanges entry.
libavcodec/avcodec.h | 23 +++
libavcodec/avpacket.c | 22 ++
libavcodec/internal.h | 2 ++
3 files changed, 47 insertions(+)
diff --git a/libavcodec/avcodec.h
Currently implemented by using the pic_type value from AV_PKT_DATA_QUALITY_STATS
packet side data.
Signed-off-by: James Almer
---
A (probably much slower) alternative would be inserting an AVCodecParserContext,
which would also enable this kind of fragment splitting for non encoding
scenarios.
Implemented as as a frag_duration muxer option and key=value entry in the
adaptation_sets muxer option. It has the same syntax as the seg_duration option.
A new frag_type option is also introduced to select the kind of fragmentation.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 80
Implemented as as a seg_duration key=value entry in the adaptation_sets muxer
option.
It has the same syntax as the global seg_duration option, and has precedence
over it if set.
Signed-off-by: James Almer
---
libavformat/dashenc.c | 49 ++-
1 file
This set implements some changes to the Dash muxer and related dependencies
to help in low latency streaming scenarios.
The Producer Reference Time side data is initially implemented for libx264,
which other encoders can then use as an example.
James Almer (11):
avformat/dashenc: allow setting
On Wed, Oct 16, 2019 at 06:53:44PM +0200, Paul B Mahol wrote:
> LGTM
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. --
On Wed, Oct 16, 2019 at 12:43:07PM +0200, Paul B Mahol wrote:
> Could someone apply this?
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: PGP signature
On Tue, Oct 15, 2019 at 06:37:10PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Threading is to avoid a core cpu being occupied fully with other filters like
> scale,
> regarding performance, if your cpu frequency is very high, the gain is very
> small, but
> with more cores and
On 10/17/2019 5:29 AM, Andreas Rheinhardt wrote:
> Up until now, the vp9_superframe bsf used distinct packets for input and
> output. But at no point in the bsf are the input and output packets used
> at the same time (except during a call to av_packet_move_ref()), so that
> one can avoid using
From: Andriy Gelman
Allows user to set maximum number of buffered packets when
probing a codec. It was a hard-coded parameter before this commit.
---
doc/formats.texi| 4
libavformat/avformat.h | 7 +++
libavformat/internal.h | 2 --
libavformat/options_table.h |
On 10/17/2019 6:11 AM, Andreas Rheinhardt wrote:
> Fixes ticket #8294.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ac3enc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
> index 76872a8fe0..25318f8631 100644
On 10/17/2019 6:20 AM, Paul B Mahol wrote:
> Fixes #8294
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/ac3enc_float.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/ac3enc_float.c b/libavcodec/ac3enc_float.c
> index d6e658b2b4..18df313c1a
On 10/17/2019 5:29 AM, Andreas Rheinhardt wrote:
> bytestream2_get_bytes_left returns an unsigned int; as a result,
> it returns big positive numbers if an overread already happened,
> making it unsuitable for scenarios where one wants to allow this
> (because the buffer is actually padded so that
zmbv has only one function for decoding intra frames, namely
decode_intra; and yet up until now it has been called via a function
pointer. This has been changed.
This also removes spec-incompliant conversions between function pointers
and pointers of type void * and thereby fixes the warning "ISO
> Am 17.10.2019 um 09:57 schrieb Yuki.Tsuchiya :
>
> Implemented according to the specification at
> https://www.iso.org/standard/69561.html
> The 'mhm1' sample entry is registered with MP4RA, which is defined as MHAS
> encapsulated single stream MPEG-H 3D Audio.
> 'MHAS' stands for MPEG-H
Will apply updated version.
___
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".
lgtm
On 10/17/19, Michael Niedermayer wrote:
> Fixes: Ticket8176
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/g729postfilter.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/g729postfilter.c b/libavcodec/g729postfilter.c
> index
probably ok
On 10/17/19, Michael Niedermayer wrote:
> Fixes: Ticket8176
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/g729dec.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
> index
Fixes: Ticket8176
Signed-off-by: Michael Niedermayer
---
libavcodec/g729dec.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
index 25951716ef..67054b71df 100644
--- a/libavcodec/g729dec.c
+++ b/libavcodec/g729dec.c
Fixes: Ticket8176
Signed-off-by: Michael Niedermayer
---
libavcodec/g729postfilter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/g729postfilter.c b/libavcodec/g729postfilter.c
index ef4fec4c95..fc9a8d54cc 100644
--- a/libavcodec/g729postfilter.c
+++
remove_doubling() returned a const float, but returning qualified types
is pointless anyway. This is all the more important given that GCC 4.2.1
(and maybe other compilers, too) seems to treat this as an error as several
FATE units that don't compile any more show.
Signed-off-by: Andreas
Can I have _any_ response please? It was more than a week of silence... :(
Thanks,
Vasily
чт, 10 окт. 2019 г., 13:05 Vasily :
> Anything else I have to do to make this patch eventually taken in?
>
> Thanks,
> Vasily
>
> пн, 7 окт. 2019 г. в 15:54, :
>
>> When incoming media has non-zero start
Fixes #8294
Signed-off-by: Paul B Mahol
---
libavcodec/ac3enc_float.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ac3enc_float.c b/libavcodec/ac3enc_float.c
index d6e658b2b4..18df313c1a 100644
--- a/libavcodec/ac3enc_float.c
+++
Fixes ticket #8294.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 76872a8fe0..25318f8631 100644
--- a/libavcodec/ac3enc.c
+++ b/libavcodec/ac3enc.c
@@ -2051,7
Fixes ticket #8295.
Signed-off-by: Andreas Rheinhardt
---
libavformat/nutenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index e9a3bb49db..4d10e70e9e 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -1170,8
If processing an input NAL unit triggers the insertion of data from
extradata in front of said NAL unit, the output packet is grown (i.e.
reallocated) once to accomodate both the new extradata as well as the
input NAL unit itself; this has been changed: In such a situation, the
packet is now grown
1. Left shifts of signed values are undefined as soon as the sign bit
is involved. Therefore make nal_size an uint32_t and drop the check for
whether it is < 0.
2. The two checks for overreads (whether the length field is contained
in the packet and whether the actual unit is contained in the
The format of an AVCDecoderConfigurationRecord, the out-of-band
extradata of H.264 in mp4, is as follows: First four bytes containing
version, profile and level, one byte for the length size and one byte
each for the number of SPS, followed by the SPS (each with its own size
field), followed by a
Up until now, the vp9_superframe bsf used distinct packets for input and
output. But at no point in the bsf are the input and output packets used
at the same time (except during a call to av_packet_move_ref()), so that
one can avoid using two packets if one switches to ff_bsf_get_packet_ref
at the
Up until now, h264_mp4toannexb stored the offset of the first SPS and
the first PPS in the (output) extradata in its context and used these
two numbers together with the size of the extradata and the pointer to
the extradata to determine what to insert when inserting extradata. This
led to some
Mainly reindentation, but some variables were also put into a smaller
scope.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_mp4toannexb_bsf.c | 52 +++
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
3469cfab added a check for whether the extradata coincided with the
beginning of the packet's data in order not to add extradata to packets
that already have it. But the check used was buggy for packets whose
size is smaller than the extradata's size. This commit fixes this.
Signed-off-by:
According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not
h264_mp4toannexb_filter currently uses both indices/offsets as well as
direct pointers comparisons for the checks whether one has reached or
even surpassed the end. This commit removes the offsets.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_mp4toannexb_bsf.c | 6 +-
1 file
This is done in order to improve legibility. No functional change is
intended with this commit at all; in particular, the unsafe read
functions are used throughout as h264_extradata_to_annexb already
performs its own checks. (These checks will nevertheless be improved in
further commits.)
Up until now, h264_mp4toannexb would grow the output packet's buffer by
the desired amount every time another NAL unit of the input packet has
been read; this commit changes this: The input buffer is now essentially
parsed twice, once to determine the final size of the output packet and
once to
Before reading a 16bit size field during parsing of extradata, no check
is performed to make sure that said length field is actually contained
in the extradata. Given that this overread is not dangerous (the extradata
is supposed to be padded), only a comment for it has been added; the error
Currently during parsing the extradata, h264_mp4toannexb checks for
overreads by adding the size of the current unit to the current position
pointer and comparing this to the end position of the extradata. But
pointer comparisons and pointer arithmetic is only defined if it does not
exceed the
bytestream2_get_bytes_left returns an unsigned int; as a result,
it returns big positive numbers if an overread already happened,
making it unsuitable for scenarios where one wants to allow this
(because the buffer is actually padded so that no segfaults can
happen). So add a function returning
There can be at most 31 SPS and 255 PPS in the mp4/Matroska extradata.
Given that each has a size of at most 2^16-1, the length of the output
derived from these parameter sets can never overflow an ordinary 32 bit
integer. So use a simple uint32_t instead of uint64_t and replace the
unnecessary
On Sun, Oct 13, 2019 at 2:14 PM Jun Li wrote:
> Fix #7620
> In the case tee muxer with both "bsf" and "use_fifo" parameters
> will trigger this bug. Tee muxer will first steal parameters (like "f",
> "select"...) and then "use_fifo" will try reading out remaining options
> and pass them to fifo
Implemented according to the specification at
https://www.iso.org/standard/69561.html
The 'mhm1' sample entry is registered with MP4RA, which is defined as MHAS
encapsulated single stream MPEG-H 3D Audio.
'MHAS' stands for MPEG-H audio stream, which contains encoded audio data and
corresponds
76 matches
Mail list logo
