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-boun...@ns.live555.com 
[mailto:live-devel-boun...@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/

_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to