Plan to push set tomorrow.
On 2021-03-23 11:07, Gyan Doshi wrote:
---
libavformat/rtpenc_mpegts.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 22881461e4..f7ee5a4448 100644
--- a/libavformat/rtpenc_mp
Am Do., 25. März 2021 um 05:47 Uhr schrieb Alok Priyadarshi :
>
> Timestamp difference is available in media timebase (1/90K) where as
> rtcp time is in the default microseconds timebase. This patch fixes
> the calculated prft wallclock time by rescaling the timestamp delta
> to the microseconds ti
James Almer (12021-03-24):
> I think it's clear by now that nothing i could say will convince you it's
> better to not return a pointer to an internal array when there are safer
> alternatives, and i already gave my reasons why, none of which satisfied
> you, so i don't see the point in keeping thi
On 25 Mar 2021, at 12:55, Nicolas George wrote:
> James Almer (12021-03-24):
>> I think it's clear by now that nothing i could say will convince you it's
>> better to not return a pointer to an internal array when there are safer
>> alternatives, and i already gave my reasons why, none of which
On 3/25/2021 8:55 AM, Nicolas George wrote:
James Almer (12021-03-24):
I think it's clear by now that nothing i could say will convince you it's
better to not return a pointer to an internal array when there are safer
alternatives, and i already gave my reasons why, none of which satisfied
you,
In effect the patch does replace that one line. But it also adds the steps
to illustrate how the wallclock is calculated. Adding all the calculations
in a single line will make it too long and hard to read.
Note that delta_timestamp can be negative. It typically happens after rtcp
SR is received a
Hi everyone,
Kieran, thank you for your reply.
I already had a look at that document.
I need something more detailed about FFmpeg's threading architecture such as:
1. What threading model is used in FFmpeg (e.g., thread pool, pipeline, or
peer)?2. Have someone explored the performance of the th
The PutBitContext is big enough: It has just been initialized to 8192B.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vorbisenc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index 18a679f2dc..f8a08f816f 100644
--- a/libavcodec/vorbis
Compilation would fail if it were outcommented as it refers to a
nonexistent PutBitContext.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/sonic.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index 32e94d24f6..8339799dd3 100644
--- a/libavcodec/s
We are already word-aligned here, so one can just as well flush the main
PutBitContext.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mlpenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index 9782cb8261..40db76f350 100
The PutBits API checks the available space before every write,
so this check for overread is dead.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dvenc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index 233e2b68c7..134315a834 100644
--- a/li
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vorbisenc.c | 4 ++--
libavcodec/wmavoice.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index f8a08f816f..080017e2bf 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vo
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aacenc.c| 4 ++--
libavcodec/alacenc.c | 2 +-
libavcodec/asvenc.c| 2 +-
libavcodec/cbs.c | 2 +-
libavcodec/cfhdenc.c | 2 +-
libavcodec/cljrenc.c |
Often a caller doesn't want the amount of bits written via a
PutBitContext, but the amount of bytes. This in particular happens
after one has flushed the PutBitContext (e.g. at the end of encoding,
when one wants to know the actual packet size). The current way of doing
this is with put_bits_count(
A PutBitContext has a field called size_in_bits which is set to the
context's bitsize init_put_bits(); but it isn't used at all (the PutBits
API uses pointers directly and not bit indexes), so remove it (due to
ABI concerns the actual element is only removed at the next bump).
Furthermore, the mul
Several encoders used code like the following to check for the amount of
bytes left in a PutBitContext:
pb->buf_end - pb->buf - (put_bits_count(pb) >> 3)
Besides the fact that using the pointers directly might pose
a maintainence burden in the future this also leads to suboptimal code:
The above co
Despite write_huff_codes() receiving an ordinary buffer (not a
PutBitContext), it returned the amount of data written in bits,
not in bytes. This has been changed: There is now no intermediate
bitcount any more.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/utvideoenc.c | 10 --
1 fil
The function to write an ordinary (luma or chroma) plane as well as
the function for writing an alpha plane have some similarities:
They record the initial bitposition (despite said position always being
byte-aligned), flush the PutBitContext themselves and return the amount
of bytes they wrote.
T
Also avoid using bitcounts in case one is actually byte-aligned.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dvenc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index 134315a834..e0679c538c 100644
--- a/libavcodec/dvenc.c
+
This is important, for example, for connection timed out events,
when used over a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis
---
Sent the wrong version the first time, woops.
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c
This is important, for example, for connection timed out events,
when used ovr a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index aef5
On Thu, Mar 18, 2021 at 12:17:27AM +0100, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 31640/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5630883286614016
> Fixes:
> 31619/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5176667708456960
>
> Foun
On Thu, Mar 18, 2021 at 12:17:28AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2 * 1914708000 cannot be represented in type
> 'int'
> Fixes:
> 31639/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6303428239294464
>
> Found-by: continuous fuzzing process
> https://g
On Thu, Mar 18, 2021 at 09:49:56PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (>10sec -> <100ms)
> Fixes:
> 31515/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP4_fuzzer-5247114134290432
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projec
On Fri, Mar 19, 2021 at 01:19:28AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Mar 19, 2021 at 12:20:23AM +0100, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Fixes: null pointer dereference
> >>> Fixes:
> >>> 31588/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_
On Thu, Mar 18, 2021 at 09:49:57PM +0100, Michael Niedermayer wrote:
> Fixes: crash
> Fixes: check_pkt.mp4
>
> Found-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/movenc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
will apply
[...]
--
Michael
On Fri, Mar 19, 2021 at 04:26:51PM +0100, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: av_freep.mp4
>
> Found-by: Rafael Dutra
> Tested-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/aacpsy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 delet
On Mon, Mar 22, 2021 at 09:58:29PM +0100, Michael Niedermayer wrote:
> Fixes: null pointer dereference
> Fixes: h264_slice_header_init.mp4
>
> Found-by: Rafael Dutra
> Tested-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_slice.c | 5 +
> 1 file changed, 5 in
On Mon, Mar 22, 2021 at 09:58:33PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 31464/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-4843965653319680
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed
please remove excessive whitespaces
On Thu, Mar 25, 2021 at 6:09 PM Michael Niedermayer
wrote:
> On Thu, Mar 18, 2021 at 12:17:27AM +0100, Michael Niedermayer wrote:
> > Fixes: out of array access
> > Fixes:
> 31640/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SGA_fuzzer-5630883286614016
>
On Thu, Mar 25, 2021 at 02:21:43PM +0100, Marvin Scholz wrote:
> On 25 Mar 2021, at 12:55, Nicolas George wrote:
> > James Almer (12021-03-24):
> >> I think it's clear by now that nothing i could say will convince you it's
> >> better to not return a pointer to an internal array when there are safe
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2021年3月24日 15:39
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 3/3] lavfi/dnn_backend_tensorflow.c: fix mem
> leak in execute_model_tf
>
> Signed-off-by: Ting Fu
> ---
> libavfilter/dnn/dnn_backend
Andreas Rheinhardt:
> This check is outdated because the caller doesn't need to check that
> the multiplication overflows when using av_realloc_array() (the code
> in question used av_realloc() before that); furthermore, the check
> is also a remnant of the time in which our allocation functions
>
Andreas Rheinhardt:
> Also remove keyframe from vmd_frame, it is unused.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/sierravmd.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/sierravmd.c b/libavformat/sierravmd.c
> index 11a883614f..cfbf184
34 matches
Mail list logo
