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

[Bill Dolson]

Jean-Paul Saman wrote:
> Bill Dolson wrote:
>> Hi,
>>
>> I have been working for several months extending VLC to include support 
>> for private_data_1 streams carrying camera geopositioning and pointing 
>> data encoded as SMPTE KLV.  This is an emerging standard for many forms 
>> of remote sensing from satellite to autonomous vehicles.  I will start 
>> to submit patches when the work is a little further along.
>>
>> I am currently working on muxing together a data stream and video stream 
>> from two different sources.  I am using the input-slave control and have 
>> added a slave-demux control to allow forcing my demuxer for the data 
>> stream.  In testing this I set up each source as a UDP stream and the 
>> access-udp module is used for each, hence two instances.  (All on a 
>> UDP-safe LAN of course).  After some 15 seconds or so I start to get 
>> massive amounts of continuity counter errors on the video stream 
>> (typically 4-6 counts off), as if many packets were being dropped.  If I 
>> disable the access-udp which is reading the data stream everything is 
>> fine.  I suspect the two instances are somehow interfering with each other.
>>
>> Is there any reason why running two instances of access-udp should be a 
>> problem?  I took a quick look at the source and don't see anything 
>> obvious.  I am unhappy to report development is being done under Windows 
>> XP with the 0.8.6b sources (not my decision).  I have periodically tried 
>> the Windows nightlies and they don't seem to be all there yet. 
>> Obviously when I submit patches I will apply them to the current SVN.
>>
> What are the bitrates of the two streams? In my experience these packet 
> drops can be caused by overflowing the OS's its network buffers. From 
> you description this could be the case here. Under Linux you could test 
> this by increasing the receive buffer of the network stack, but I don't 
> know if that can be tweaked under win XP too.

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.

Thanks,
Bill