[vls-devel] [PATCH] fix lots of bugs in vls affecting TV streaming

Andrew Baumann andrewb at cse.unsw.edu.au
Thu Oct 16 03:48:55 CEST 2003


I've been trying to get a V4L-captured TV stream out of vls for a few days 
now, and in the process I've found quite a few bugs. The attached patch:

 * changes C_Semaphore::TryWait() to accept any non-zero return value from
   sem_trywait() rather than just EAGAIN as indicating that the semaphore is
   held. The version in RedHat 9 was returning -1 rather than EAGAIN (might be
   related to the NPTL libraries, I'm not sure).

 * Puts the correct ES ID on the audio stream generated by raw2ts, rather than
   0x3 (MPEG1 audio). I had to do this to try to get AC3 working.

 * Fixes the video and audio grabbers / encoder thread to use a unique buffer
   for each frame / sample! Previously the audio grabber thread created one
   buffer, read each sample into that same buffer, and placed it into the
   fifo. This obviously isn't safe, and was causing the garbled audio that I
   was getting (and which others seem to have reported). I also noticed that
   the video code was doing the same thing, I can only imagine that it worked
   because on a fast CPU you'd be processing one frame at a time.

 * Fixes the video and audio threads not to call Release() on the condition
   variable after a Signal(), which itself already releases the lock (another
   race condition).

 * Changes the time stamping code in the audio capture thread not to use
   floating point arithmetic.

 * Fixes the V4L reader module not to open or ioctl the audio device if audio
   is muted.

 * Fixes the constructors of C_SyncFifo, C_DatedFifo, and C_NetList to
   initialise all of their instance variables.

...unfortunately after all that work I'm still having problems with the audio. 
It's no longer completely garbled, but there are discontinuities in the 
timestamps of audio samples that I can't resolve. The capture thread seems to 
block in the read() call for up to a second, even though threre is data 
available and the CPU has idle time. As a result the audio stream plays in 
VLC with parts of very sped up audio interspersed with silence.

I eventually gave up on vls and got vlc doing the streaming although 
interestingly MPEG4 video doesn't work any more (one thing that was working 
with VLS) -- the client's ffmpeg reports errors in the video stream and can't 
decode any frames, although it is the same ffmpeg version as on the server.

hope all this helps someone,

Your flux capacitor has gone bad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vls.diff
Type: text/x-diff
Size: 13770 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/vls-devel/attachments/20031016/ec0817c1/attachment.diff 

More information about the vls-devel mailing list