[FFmpeg-user] Multithreaded multioutput problem

[Marton Balint]

On Mon, 20 Apr 2015, Deron wrote:

> On 4/20/15 1:48 PM, Marton Balint wrote:
>> On Mon, 20 Apr 2015, Deron wrote:
>> 
>>> Another user has contacted me with the exact same problem hoping that I 
>>> stumbled on a solution for the below problem. I did not, so I am adding 
>>> some more extensive log output in hopes that someone might recongize the 
>>> source of the problem.
>>> 
>> 
>> I have also experienced this problem. Depending on your use case you can 
>> face a similar situation with only one input and one output as well and a 
>> few cores. There is no buffering between the various stages of the ffmpeg 
>> encoder/filter/decoder pipeline, so even if the stages by themselves are 
>> multi threaded, you won't be able to scale up, because passing data between 
>> the stages is done in a single thread.
>> 
>> Or at least that is what I think is going on. So as far as I know you can 
>> only scale up properly by running multiple ffmpeg instances. E.g: create a 
>> multicast and encode that.
>> 
>> Regards,
>> Marton
>
>
> What would be the best way to solve this then? I'm not sure I understand what 
> you mean by multicast. Having multiple ffmpeg's decoding the same original 
> mpegts input would be pretty slow.

If that overhead is unacceptable, then I don't see any other way. You 
wrote you had plenty of free CPU :)

> Is there some way to have ffmpeg output a 
> multicast that is in a faster/raw format?

You may experiment with some raw/near-raw codecs with a lower resolution 
than your original video, but I'm not sure if it will be faster in the end 
than decoding the original stream multiple times.

>
> Seems like more overhead and more ways for it to go wrong.
>

Yes. I don't think there is a way with the current ffmpeg where you can 
avoid the CPU overhead and improve speed at the same time.

> Thanks for your input,
>

Sorry, that is all I could think of. Maybe others can give some additional 
insight.

Regards,
Marton