Klaus Schmidinger wrote:
> Udo Richter wrote:
>
>> Hi list,
>>
>> I've been hunting down a bandwidth problem in my little streaming
>> plugin, and finally realized that the performance bottleneck actually
>> is cRemux and its internal resultBuffer.
>>
>> The resultBuffer is initialized with resultBuffer->SetTimeouts(0,
>> 100), in other words, if no data is available, cRemux::Get will wait
>> up to 100ms for data to arrive. Thats fine as long as cRemux is filled
>> from another thread, but wastes time if cRemux is only filled from
>> within the same thread.
>>
>> Unfortunately, the resultBuffer is completely hidden inside the
>> cRemux, so I cannot change this behavior. Does anyone have good ideas
>> how to avoid this without spawning another thread? (the thread would
>> actually just copy data from one buffer to another...)
>>
>> This resultBuffer is really some kind of black hole, no way to control
>> it, no way to know how much is in it...
>
>
> Well, we could introduce
>
> cRemux::SetTimeouts(int PutTimeout, int GetTimeout) {
> resultBuffer->SetTimeouts(PutTimeout, GetTimeout); }
>
> Klaus
Haven't gotten any response on this suggestion so far.
Would this solve your problem?
Klaus
