[FFmpeg-user] Multithreaded multioutput problem
cus at passwd.hu
Tue Apr 21 00:22:23 CEST 2015
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.
> 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
More information about the ffmpeg-user