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. Is there some way to have
ffmpeg output a multicast that is in a faster/raw format?
Seems like more overhead and more ways for it to go wrong.
Thanks for your input,
Deron
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
