s and patches
> Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to
> reduce latency
>
> On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote:
>> Avoid constant N frames latency in video streaming.
>>
>> Signed-off-by: Jianhui Dai
&
development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to
reduce latency
On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> ---
&
READ_SLICE simultaneously：）
Thanks,
Jianhui Dai
-Original Message-
From: ffmpeg-devel On Behalf Of Derek
Buitenhuis
Sent: Thursday, March 12, 2020 6:44 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to
reduce latency
On 11/03/2020 20:42, Mart
On 11/03/2020 20:42, Martin Storsjö wrote:
> FWIW, while I agree it shouldn't be the default, I have occasionally
> considered the need for this particular feature.
Arguably slice threading should be used, but that assumes you have sane input,
which is obviously not always the case for some.
> C
On Wed, 11 Mar 2020, Derek Buitenhuis wrote:
On 11/03/2020 14:53, Devin Heitmueller wrote:
Regardless of the actual proposed patch, I think the author's use of
wallclock time to describe the problem is very reasonable. I do a
large amount of work where I'm measuring "glass-to-glass" latency,
w
On 11/03/2020 14:53, Devin Heitmueller wrote:
> Regardless of the actual proposed patch, I think the author's use of
> wallclock time to describe the problem is very reasonable. I do a
> large amount of work where I'm measuring "glass-to-glass" latency,
> where I am interested in the total pipelin
>
> Regardless of the actual proposed patch, I think the author's use of
> wallclock time to describe the problem is very reasonable. I do a
> large amount of work where I'm measuring "glass-to-glass" latency,
> where I am interested in the total pipeline (encode/network/decode),
> and I definitel
On Wed, Mar 11, 2020 at 10:28 AM Derek Buitenhuis
wrote:
> > E.g. in FF_THREAD_FRAME 4320x2160 30fps video streaming, 4 threads, the
> > frame caching is 99ms (33ms x 3frames)
> > If the cpu-decoding-execution-time is 80ms ~ 120ms (dependent on video
> > frame content).
>
> Also aside: It is no
On 11/03/2020 05:29, Dai, Jianhui J wrote:
> Like RTSP/RTMP/DASH, the latency is variable according to network bandwidth.
He is not talking about wallclock or een latency in the time domain.
Latency as in 'number of packets passed in before a frame is output'. Which this
patch makes both non-dete
On 11/03/2020 03:28, Dai, Jianhui J wrote:
> As reply in another thread, the sequence of output frames still follows
> standard, like display order POC in H264.
> Big enough frame cache can guarantee deterministic delay in some extent, but
> not always (decoding time > caching time).
That was my
On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> ---
> libavcodec/pthread_frame.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
This patch causes segfaults
./ffmpeg_g
control the frame caching size
is more flexible.
Thanks,
Jianhui Dai
-Original Message-
From: ffmpeg-devel On Behalf Of Kieran Kunhya
Sent: Wednesday, March 11, 2020 11:41 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get
On Wed, 11 Mar 2020 at 02:59, Dai, Jianhui J
wrote:
> It does not break FFmpeg output frames management logic (e.g.
> h264_select_output_frame), just enter that phase earlier.
>
> Perhaps my understanding is not correct.
> In my opinions, render should be the one considering variable latency
> is
rch 10, 2020 10:40 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to
reduce latency
On 10/03/2020 09:36, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> --
10:41 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to
reduce latency
On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J
wrote:
> Thanks, I will update the commit message.
>
> I test it with FFmpeg native sw H264 deco
On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J
wrote:
> Thanks, I will update the commit message.
>
> I test it with FFmpeg native sw H264 decoder.
> In previous FF_THREAD_FRAME, the latency is constant as N ( =
> thread_count - 1) frames.
> It won't sync thread state until no idle threads availab
PATCH] pthread_frame: attempt to get frame to
reduce latency
Am Di., 10. März 2020 um 10:37 Uhr schrieb Jianhui Dai
:
>
> Avoid constant N frames latency in video streaming.
Please add some numbers to the commit message, if possible without using
hardware acceleration.
On 10/03/2020 09:36, Jianhui Dai wrote:
> Avoid constant N frames latency in video streaming.
>
> Signed-off-by: Jianhui Dai
> ---
> libavcodec/pthread_frame.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
In addition to the points already raised (and which I agree
On 10/03/2020 11:33, Hendrik Leppkes wrote:
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changing delay.
I second this. A lot of software an usecases benefits (or requires) this.
Not to mention non-determinism...
- Derek
__
On Tue, 10 Mar 2020 at 12:07, Hendrik Leppkes wrote:
> On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai
> wrote:
> >
> > Avoid constant N frames latency in video streaming.
> >
>
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changin
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, March 10, 2020 19:34
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame
> to reduce latency
>
> On Tue, Mar 1
On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai wrote:
>
> Avoid constant N frames latency in video streaming.
>
Personally, I'm off the opinion that a predictable constant delay in
this case is better then a variable ever-changing delay.
- Hendrik
___
ff
Am Di., 10. März 2020 um 10:37 Uhr schrieb Jianhui Dai
:
>
> Avoid constant N frames latency in video streaming.
Please add some numbers to the commit message,
if possible without using hardware acceleration.
Carl Eugen
___
ffmpeg-devel mailing list
ffm
Avoid constant N frames latency in video streaming.
Signed-off-by: Jianhui Dai
---
libavcodec/pthread_frame.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index b5bd494474..aeb42800ef 100644
--- a/l
24 matches
Mail list logo
