From: Jun Zhao
Fixes the compilation warnings
Signed-off-by: Jun Zhao
---
libavfilter/vf_frei0r.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index c775ed1..165fbd7 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavf
Subject should be lavfi/frei0r
On 4/21/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Fixes the compilation warnings
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_frei0r.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf
From: Jun Zhao
Signed-off-by: Jun Zhao
---
doc/examples/avio_reading.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
index cbfeb17..36ee02a 100644
--- a/doc/examples/avio_reading.c
+++ b/doc/examples/avio
By requiring that the decoder stay full, we introduce unnecessary
output latency when decoding from a real-time source. Additionally,
we can cause MPP to assert if we submit data, but don't actually
output a frame before closing our decoding session, because it
expects us to read the format change
On Sun, Apr 21, 2019 at 08:50:04AM +0200, Paul B Mahol wrote:
> On 4/21/19, Michael Niedermayer wrote:
> > On Wed, Apr 10, 2019 at 01:45:51PM +0200, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavcodec/agm.c | 404 +++--
> >> lib
I do not know if such vlc trees are allowed in agm, I have no specification
So i do not know if these should be treated as error, or not.
But the code does contain a check for idx < 0 already ...
untested due to lack of valid samples using this codepath
Fixes: Stack-buffer-overflow in get_tree_co
Fixes: SEGV on unknown address
Fixes:
14198/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5723579234123776
untested due to lack of valid samples using this codepath
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index c9d7be5521..7dcfaff4ad 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -943,7 +943,7 @@ static int make_new_tree(const uint
On 4/21/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/agm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index c9d7be5521..7dcfaff4ad 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.
On 4/21/19, Michael Niedermayer wrote:
> Fixes: SEGV on unknown address
> Fixes:
> 14198/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5723579234123776
>
> untested due to lack of valid samples using this codepath
>
> Found-by: continuous fuzzing process
> https://github.com/google/
On 4/21/19, Michael Niedermayer wrote:
> I do not know if such vlc trees are allowed in agm, I have no specification
> So i do not know if these should be treated as error, or not.
> But the code does contain a check for idx < 0 already ...
>
> untested due to lack of valid samples using this code
Paul B Mahol (12019-04-19):
> Generic resampling via aresample is completely another filtering that have
> nothing to do with this filters, for more info read:
>
> https://www.oblique-audio.com/technique/oversampling
Quite the opposite: this page makes it rather clear that oversampling is
a kind
On 4/21/19, Nicolas George wrote:
> Paul B Mahol (12019-04-19):
>> Generic resampling via aresample is completely another filtering that
>> have
>> nothing to do with this filters, for more info read:
>>
>> https://www.oblique-audio.com/technique/oversampling
>
> Quite the opposite: this page make
On Sun, Apr 21, 2019 at 11:36:00AM +0200, Paul B Mahol wrote:
> On 4/21/19, Michael Niedermayer wrote:
> > Fixes: SEGV on unknown address
> > Fixes:
> > 14198/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5723579234123776
> >
> > untested due to lack of valid samples using this code
On Sun, Apr 21, 2019 at 11:31:26AM +0200, Paul B Mahol wrote:
> On 4/21/19, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/agm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> > index
On Sun, Apr 21, 2019 at 11:31:10AM +0200, Paul B Mahol wrote:
> On 4/21/19, Michael Niedermayer wrote:
> > I do not know if such vlc trees are allowed in agm, I have no specification
> > So i do not know if these should be treated as error, or not.
> > But the code does contain a check for idx < 0
I apperciate the efforts to reply more than half a line.
Paul B Mahol (12019-04-21):
> It is not kind of resampling. Resampling is specific and belongs to
> separate library.
There is no doubt it IS a kind of resampling: it is in the name. The
question is whether is it specific enough to warrant
On Mon, Apr 08, 2019 at 02:03:31PM -0400, Andriy Gelman wrote:
> From: Andriy Gelman
>
> This commit replaces packet assignment operator with av_packet_move_ref
> when there is a packet ownership transfer.
> ---
> Michael, the update patch now has correct behavior for ticket 4221.
>
> libavform
On 4/21/19, Nicolas George wrote:
> I apperciate the efforts to reply more than half a line.
>
> Paul B Mahol (12019-04-21):
>> It is not kind of resampling. Resampling is specific and belongs to
>> separate library.
>
> There is no doubt it IS a kind of resampling: it is in the name. The
> questi
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Saturday, April 20, 2019 11:08 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl
> filter
>
> On 17/04/2019
From: Jun Zhao
Fixes the compilation warnings
Signed-off-by: Jun Zhao
---
libavfilter/vf_frei0r.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
index c775ed1..165fbd7 100644
--- a/libavfilter/vf_frei0r.c
+++ b/libavf
On 4/21/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Fixes the compilation warnings
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_frei0r.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c
> index c775ed1..165fbd7 1
Hello,
mpeg2_metadata currently has a bug wrt its handling of the
colour_description elements in case the input already had a
sequence_display_extension, but with colour_description set to zero.
Then the colour_description elements are zero at the end of the read
process; but zero is a forbidden v
Up until now, things that are merely unsupported by cbs_mpeg2 have been
declared to be invalid input. This has been changed.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 4 +---
libavcodec/cbs_mpeg2_syntax_template.c | 4 ++--
2 files changed, 3 insertions(+), 5
If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 24 +++-
libavcodec/cbs_mpeg2.h | 2 +-
libavcodec/cbs_mpeg2_syntax_template.c | 10 +-
3 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/libavcodec/cbs_mpeg2
horizontal/vertical_size_value (containing the twelve least significant
bits of the frame size) mustn't be zero according to the specifications;
and the value 0 is forbidden for the colour_description elements.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 17 +++
From: Andriy Gelman
During AVPacket assignment, it is currently not clear when the lhs takes
ownership of the packet. This commit replaces assignment with an
explicit av_packet_move_ref call when there is an ownership transfer to
clear the distinction.
---
libavformat/utils.c | 30 ++
On 4/21/2019 11:04 AM, Andreas Rheinhardt wrote:
> If a sequence display extension is read with colour_description equal to
> zero, but a user wants to add one or more of the colour_description
> elements, then the colour_description elements the user did not explicitly
> request to be set are set
On 4/21/2019 11:04 AM, Andreas Rheinhardt wrote:
> horizontal/vertical_size_value (containing the twelve least significant
> bits of the frame size) mustn't be zero according to the specifications;
> and the value 0 is forbidden for the colour_description elements.
>
> Signed-off-by: Andreas Rhein
On 4/20/19, Mark Thompson wrote:
> On 17/04/2019 03:08, Jarek Samic wrote:
>> This is a direct port of the CPU filter.
>>
>> Signed-off-by: Jarek Samic
>> ---
>> More fixes based on the comments from the second version of the patch
>> (moving sampler declaration into the program scope, `f`-suffix
On Thu, Apr 18, 2019 at 5:59 PM Jun Li wrote:
> Currently the strftime option generate timestamp based on generation
> time. The new option would calcualte timestamp from start_time_realtime
> and pkt->pts, based on output's timescale.
> ---
> doc/muxers.texi | 5 +
> libavformat/img2
On Sat, Apr 20, 2019 at 12:59:29AM +0300, Dan Sanders via ffmpeg-devel wrote:
> Date: Fri, 19 Apr 2019 14:52:01 -0700
> From: Dan Sanders
> To: FFmpeg development discussions and patches
> Subject: [PATCH] libavformat/mov: limit nb_frames_for_fps to INT_MAX
>
> Fixes: UBSan runtime error
> Found
On Sat, Apr 20, 2019 at 01:41:09AM +0200, Andreas Rheinhardt wrote:
> Up until now, a block's relative offset has been reported as the offset
> in the log messages output when writing blocks; given that it is
> impossible to know the real offset from the beginning of the file at
> this point due to
> 在 2019年4月22日，04:50，Jun Li 写道：
>
> On Thu, Apr 18, 2019 at 5:59 PM Jun Li wrote:
>
>> Currently the strftime option generate timestamp based on generation
>> time. The new option would calcualte timestamp from start_time_realtime
>> and pkt->pts, based on output's timescale.
>> ---
>> doc/mu
Michael Niedermayer:
> On Sat, Apr 20, 2019 at 01:41:09AM +0200, Andreas Rheinhardt wrote:
>> Up until now, a block's relative offset has been reported as the offset
>> in the log messages output when writing blocks; given that it is
>> impossible to know the real offset from the beginning of the f
Fix #7144.
The current packet duration calculation is heuristic, which uses the
historical durtion as current duration. This commit adds the option
to buffer one packet and calcuate its duration when next packet arrives.
Obviously it adds one frame latency, which might be significant for
VFR live c
Due to the next major release of android employs the sandbox mechanism, refer
to : https://source.android.com/security/app-sandbox.
The Old way of accessing files is not working anymore, the app cannot access
another app's private file directly by passing the filename parameter.
Is there any solu
On 4/21/2019 11:04 AM, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/cbs_mpeg2.c | 24 +++-
> libavcodec/cbs_mpeg2.h | 2 +-
> libavcodec/cbs_mpeg2_syntax_template.c | 10 +-
> 3 files changed, 17 inse
On 20-04-2019 03:01 PM, Gyan wrote:
Old patch that was never applied. Rebased.
Plan to push tonight if no changes.
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
On 4/17/19 11:28 AM, Karthick J wrote:
> This bug was introduced in the commit 951561b64ee6c11f01daedd9dcf73276cc1e765b
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5f1333e436..b88d4b34
Paul B Mahol (12019-04-21):
> https://dspguru.com/dsp/faqs/multirate/resampling/
>
> Resampling involves interpolation.
> If I do resampling with aresample and resampling with factor 2 from
> 44100 to 88200
> I can see there is still some spectrum data in highest frequencies.
Resampling MAY invol
42 matches
Mail list logo
