[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
Hi,
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,
Andrew
--
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