On Mon, 20 Apr 2015, Deron wrote:
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.
In that case have you tried using the threaded input read support of
ffmpeg? You have to specify more than one inputs (add an extra dummy
input source) and play with -thread_queue_size option.
Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
