On 4/20/15 4:22 PM, Marton Balint wrote:
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 :)
Speaking of CPU and having been away from the problem for many weeks, I
forget about the important part. The encoding process for the data runs
at better than real time (nearly 2x) when pulling from a file instead of
the /dvb device. So I don't think that this is thread bound for me but
something else.
I'm still missing a piece of the puzzle. Something else is causing me grief.
Thanks for the help,
Deron
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
