[FFmpeg-devel] Fwd: pipeline multithreading

[Daniel Oberhoff]

Von meinem iPhone gesendet

Anfang der weitergeleiteten E‑Mail:

> Von: Daniel Oberhoff <danieloberhoff at gmail.com>
> Datum: 25. November 2014 09:59:39 MEZ
> An: Timothy Gu <timothygu99 at gmail.com>
> Betreff: Re: [FFmpeg-devel] pipeline multithreading
> 
> 
> Von meinem iPhone gesendet
> 
>> Am 24.11.2014 um 16:54 schrieb Timothy Gu <timothygu99 at gmail.com>:
>> 
>> On Mon, Nov 24, 2014 at 3:35 AM, Daniel Oberhoff
>> <danieloberhoff at gmail.com> wrote:
>>> Hi,
>>> 
>>> From what I gather the filter graph is utilizing modern multicores by
>>> “striping” where filters support it, i.e. an image is divided in stripes
>>> and the filter gets called in separate threads for separate stripes.
>> 
>> In FFmpeg we call it slice threading.
>> 
>>> I was wondering if there is or will be pipeline multuthreading, i.e.
>>> with a setup such as
>>> 
>>> inout -> filter1 -> filter2 -> output
>>> 
>>> some threads processing frame n in the output (i.e. encoding),
>>> other threads procesing frame n+1 in filter2, others processing frame
>>> n+2 in filter1, and yet others processing frame n+3 decoding. This
>>> way non-parallel filters can be sped up, and diminishing returns for
>>> too much striping can be avoided. With modern cpus scaling easily
>>> up to 24 hardware threads I see this as neccessary to fully utilize the
>>> hardware.
>> 
>> We call it "frame threading." There are some decoders that already support it.
>> 
>>> 
>>> Is this already done? Or are there plans? If it is not done, how much
>>> more work is it? Could I help (not promising much, but I may find time,
>>> especially as this limits us…).
>> 
>> If the filter is independent of past and future frames then it is
>> pretty easy (just like the "intra-only" decoders). For other ones I am
>> not so sure. Clément knows more about it.
> 
> Most are, no? Otherwise they would need buffers, but frame multithreading would still be possible, the pipeline just gets deeper
> 
>> 
>> Timothy