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
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
