[FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
Derek Buitenhuis
derek.buitenhuis at gmail.com
Thu Mar 12 00:43:43 EET 2020
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.
> Consider a live stream with a very variable framerate, essentially varying
> in the full range between 0 and 60 fps. To cope with decoding the high end
> of the framerate range, one needs to have frame threading enabled - maybe
> not with something crazy like 16 threads, but say at least 5 or so.
>
> Then you need to feed 5 packets into the decoder before you get the first
> frame output (for a stream without any reordering).
That last bit is key there, but yes.
>
> Now if packets are received at 60 fps, you get one new packet to feed the
> decoder per 16 ms, and you get the first frame to output 83 ms later,
> assuming that the decoding of that individual frame on that thread took
> less than 83 ms
(I'm assuming network, etc. has been left out for example's sake. :))
> However, if the rate of input packets drops to e.g. 1 packet per second,
> it will take 5 seconds before I have 5 packets to feed to the decoder,
> before I have the first frame output, even though it actually was finished
> decoding in say less than 100 ms after the first input packet was given to
> the decoder.
>
> So in such a setup, being able to fetch output frames from the decoder
> sooner would be very useful - giving a closer to fixed decoding time in
> wallclock time, regardless of the packet input rate.
Not sure I would refer to it as closer to fixed, but the use case is certainly
valid - I never claimed otherwise.
If it is added, it needs be behind a flag/option with big bold letters saying
the risks, and off by default. And that segfault Michael saw investigated.
Thanks for the clear response that doesn't conflate the two.
- Derek
More information about the ffmpeg-devel
mailing list