[FFmpeg-user] Multithreaded multioutput problem

[Deron]

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