Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index 750a476726..e016571304 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 55 ++--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index e016571304..c18cb4063f 100644
--- a/libavfilter/dnn/dnn_back
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_tf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index c18cb4063f..c0aa510630 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_tf.
On Sun, 2021-03-21 at 18:10 +0800, Linjie Fu wrote:
> Hi Fei,
>
> On Mon, Mar 15, 2021 at 1:13 PM Fei Wang
> wrote:
> >
> > Async depth will allow qsv filter cache few frames, and avoid force
> > switch and end filter task frame by frame. This change will improve
> > performance for some multi-t
sharp...@gmail.com:
> To Andreas Rheinhardt,
>
>> Why is this not possible? I just told you how you could set
>> max_dec_frame_buffering to a lower value. It seems you haven't tried it.
>
> Ahh...I thought what you care about is the unsafety of directly modifing
> num_reorder_frames and num_reord
To Andreas Rheinhardt,
> It is unsafe in the sense that it can lead to invalid and broken files.
> But it is way safer than actually modifying the slice headers, because
> the latter is absolutely irreversible, whereas one just needs to set big
> enough values to fix files broken by setting too lo
On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi wrote:
>
>
>
> On 2021-03-24 03:38, Andrey Rikunov wrote:
> > ---
> > libavformat/movenc.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/movenc.h b/libavformat/movenc.h
> > index cdbc407..8a152c0 100644
> >
Thanks, I am trying pick tonemap changes back, and I found tonemap relay on
single precision planar RGB pixel formats like AV_PIX_FMT_GBRPF32, which means
I need to pick these code, too.
I am working on it now, but I am not sure if there are a lot work to do to
make 3.2.4 support these pixel fo
Li Jinyao (12021-03-24):
> Can you give me some advice?
The only advice we can give you is that you post here the changes you
have made to the old FFmpeg and start working on making work with
current FFmpeg and getting integrated into the official version.
I hope you do not expect people here wil
Andreas Rheinhardt:
> Up until now, the VC-1 decoders allocated an AVFrame for usage with
> sprites during vc1_decode_init(); yet said AVFrame can be freed if
> (re)initializing the context (which happens ordinarily during decoding)
> fails. The AVFrame does not get allocated again lateron in this
On 2021-03-24 15:45, Jan Ekström wrote:
On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi wrote:
On 2021-03-24 03:38, Andrey Rikunov wrote:
---
libavformat/movenc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index cdbc407..
I didn't mean to offend neither expect free work. I only expect to get some
quick hit from here.
I am new to the old project and it have lot of history debt. The changes are
made by previous colleagues through years and it's mainly about custom live
infra. I am making search about make the modi
On 24/3/21 12:12 am, Zane van Iperen wrote:
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
As these are trivial patches, I will apply them tomorrow and backport to 4.4.
___
ffmpeg-dev
mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> Reduces codesize because the offset in pointer+offset addressing
> requires less bytes to encode. Reduces the size of .text from 8871B
> to 8146B (GCC 10, -O3, x64).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/kmvc.c | 4
Tomas Härdin:
> mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
>> Reduces codesize because the offset in pointer+offset addressing
>> requires less bytes to encode. Reduces the size of .text from 8871B
>> to 8146B (GCC 10, -O3, x64).
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>>
Gyan, thanks for clarification! It is all exactly as you described. I
thought to set MOV_TIMESCALE to either 60kHz or 90kHz as both are
divisible by most common fps values. And x10 increase is for further
precision in conversion to seconds. Say it's needed to
write segmentDuration=289.4892 sec in e
ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> > > Reduces codesize because the offset in pointer+offset addressing
> > > requires less bytes to encode. Reduces the size of .text from 8871B
> > > to 814
Tomas Härdin:
> ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>> mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
Reduces codesize because the offset in pointer+offset addressing
requires less bytes to encode. Reduces the size of .text from 887
ons 2021-03-24 klockan 15:26 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > ons 2021-03-24 klockan 14:49 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > mån 2021-03-22 klockan 03:06 +0100 skrev Andreas Rheinhardt:
> > > > > Reduces codesize because the offset in pointer+offset addr
James Almer (12021-03-23):
> If your creative API invention is better, then i have no problem with it
> even if it goes against existing conventions.
>
> Which for that matter reminds me that i changed my mind regarding your
> refcounted proposal, since the alternative of adding an AVRefCount stru
Fixes: STSC / STCO inconsistency and assertion failure
Fixes: crbug1184666.mp4
Found-by: Chromium ASAN fuzzer
Reviewed-by: Matt Wolenetz
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/
On 3/24/2021 12:15 PM, Nicolas George wrote:
James Almer (12021-03-23):
If your creative API invention is better, then i have no problem with it
even if it goes against existing conventions.
Which for that matter reminds me that i changed my mind regarding your
refcounted proposal, since the al
Hello.
Is there something I should be doing in order to get this patch
reviewed for inclusion in master? I couldn't find the proper
maintainer for this filter in the MAINTAINERS file.
--
Lucas Clemente Vella
lve...@gmail.com
___
ffmpeg-devel mailing li
James Almer (12021-03-24):
> Because it's not even a pointer that's guaranteed to be valid or point to
> valid data until the next call to one specific function or set of functions
> (Your example is basically av_dict_get(), where only calls to av_dict_set*()
> on a AVDictionary you own will make p
On 3/24/2021 4:48 PM, Nicolas George wrote:
James Almer (12021-03-24):
Because it's not even a pointer that's guaranteed to be valid or point to
valid data until the next call to one specific function or set of functions
(Your example is basically av_dict_get(), where only calls to av_dict_set*(
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/jacosubdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c
> index b44e3b7783..828c33057f 100644
> --- a/libavformat/jacosubdec.c
> +++ b/libavformat/jacosub
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pthread_frame.c | 127 -
> 1 file changed, 68 insertions(+), 59 deletions(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 7bcb9a7bcc..311d6ed771 1006
applied
smime.p7s
Description: S/MIME Cryptographic Signature
___
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 subje
applied
smime.p7s
Description: S/MIME Cryptographic Signature
___
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 subje
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 timebase.
---
libavformat/rtpdec.c | 9 +++--
1 file changed, 7 inser
Hi James,
This patch had a bug in the calculation of prft time. I did not account for
the timebase differences between media timestamp and wall clock. I have
sent a new patch for review.
-Alok
On Tue, Mar 23, 2021 at 3:04 PM James Almer wrote:
> On 3/23/2021 6:29 PM, Alok Priyadarshi wrote:
>
31 matches
Mail list logo
