[vlc-devel] * ! * Re: Multiple Instances of access-udp module?

[Jean-Paul Saman]

Bill Dolson wrote:
> Jean-Paul Saman wrote:
>> Bill Dolson wrote:
> 
> Thanks for the suggestion.  For sure it was a OS buffer overflow.  The 
> input-slave access runs in the same input thread as the main one in a 
> simple polling loop.  The packet arrival rate of the annotation data 
> stream is far lower than the video stream and both were doing blocking 
> reads.  The data read block would result in dropped video stream 
> packets.  Rather than doing an OS-specific buffer size fix the solution 
> was to make the slave data stream read non-blocking.  There is a low 
> level network non-blocking read but making it accessible to a demux 
> proved very hackish.
> 
> This is something that should be looked at if the input-slave facility 
> is to be truly useful, as in allowing multiple streams to be muxed 
> together.  Having multiple blocking reads in the same polling loop is 
> not desirable.  I would think the input-slave read should always be 
> non-blocking.  If there is any agreement on this I will look at doing a 
> general patch.  I think the problem is how can an access determine 
> whether it is a slave.  Perhaps a more elegant solution would be to make 
> slave inputs a separate thread, but then can they feed the same muxer?
> 
> I am now successfully combining two input streams into a single output 
> stream using the ts muxer.  I would think someone would be interested in 
> muxing separate audio and video streams together.  Should be possible.
> 

Feel free to submit a patch.

Gtz,
Jean-Paul Saman