[Live-devel] Live H264 Streaming Timing Problem

[Marc ARMSTRONG]

Thanks again for the feedback.

Yes, I am using windows and have no option but to carry on until I get this working. Yes, I can rename my captured video to 'test.264', stream this and play it in VLC player. Hopefully this means that I'm not too far away from a solution.

Windows pipes can be implemented asynchronously and there is also a 'peek' function provided to check for data before attempting to read. I tried this briefly but it didn't improve things - I probably implemented it incorrectly. So currently I do block when reading from the pipe.

Could you advise how best to use a 'peek' function within the Live555 model? Naturally I'll spend some time investigating the task scheduler background reading from file etc, but if you could point me in the right direction it would be very helpful.

Also, to improve my understanding of the live555 model could you tell me the impact of blocking. i.e. if there is no data currently available to stream, what other tasks will be going on?


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: 11 April 2012 20:39
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Live H264 Streaming Timing Problem

I am reading in H.264 data from a named pipe (which is essentially a file) and feeding into a H264VideoStreamFramer. I basically copied ByteStreamFileSource and read from a pipe rather than a file.

You shouldn't need to 'copy' the "ByteStreamFileSource" code.  Because your pipe appears - to the application - just like a named file, you should be able to use the "ByteStreamFileSource" class directly, without modification.


Incidentally, I used pipes because I am using visual studio

Oh god, you're using Windows.  I suspect that that's the cause of your problem (see below).



I am confident that the streamer application is receiving the frame count and of the integrity of the video input to the streamer application. I think the issue may lie with the speed of the capture from the hardware. Before I focus on this, can I ask a further question?

I am capturing H.264 data with low compression from a video encoder in 2Mb chunks and from the Live555 application to play in VLC player. Is this type of application well tested with the Live555 software?

Yes, I believe so.



i.e. high data content streaming in real time. When I capture to file and stream from the file the application works perfectly.

In other words, if you capture H.264 video to a file named "test.264", and then use "testH264VideoStreamer" or "testOnDemandRTSPServer" to stream it, then VLC (acting as a RTSP client) plays the stream OK??

If so, then I suspect that your problem is that the "ByteStreamFileSource" code - when run on Windows - reads from files (including pipes) synchronously - i.e., blocking if there's no data currently in the pipe.  Unfortunately there's no easy way to fix this, other than using a real operating system (one that treats open files as sockets).  I suspect that - if you want to stick with Windows - you will need to write your own "FramedSource" subclass to encapsulate your video capture device, and use that instead of "ByteStreamFileSource".

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120412/27e739f2/attachment-0001.html>