[Live-devel] Question on streams in Windows

Fri Mar 1 13:13:10 PST 2013

Okay, I did some more testing of the problem.

Step one: I set the max_key_interval in the encoder to 25 (one per second
and current fps).  Xvid sends a Bitstream header with each keyframe, so the
streamer shouldn't have to wait for more than a second max for that
information.

Step two: I wrote a tiny program that does nothing but open the pipe and
read data from it, using fopen and fread.  That program was able to connect
and pull data from the pipe, so I know the pipe is working.

At this point I switch back to the streamer program and tried again.  Still
no video in VLC.

Step three: I built openRTSP and tried to connect to the stream.  I got
what seems to be a good conversation between it and the streamer, which
ends with "Started playing session" and "Receiving streamed data..."  But
the video-MP4V-ES-1 file that it creates is only 58 bytes long.  As
openRTSP was connecting to the streamer, I watched it in Process Explorer,
and I saw that upon openRTSP connecting it was opening the pipe.  But once
openRTSP said "Started playing session", it closes the pipe.  (I'll attach
the output from openRTSP below)

What can be going on in the stream that will cause the live555 library to
close the file (which to what I can see only happens in the
~ByteStreamFileSource()) as it starts to stream, without error messages?

Chris Van Brederode

Software Engineer
International Logistics Systems, Inc.
http://www.intlogys.com

cvanbrederode at intlogsys.com

--------------------------------------------------
Output from openRTSP
--------------------------------------------------

Opening connection to 172.16.3.53, port 8554...
...remote connection opened
Sending request: OPTIONS rtsp://172.16.3.53:8554/test RTSP/1.0

CSeq: 2

User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15)

Received 152 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK

CSeq: 2

Date: Fri, Mar 01 2013 20:37:57 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER,
SET_PARAMETER

Sending request: DESCRIBE rtsp://172.16.3.53:8554/test RTSP/1.0

CSeq: 3

User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15)

Accept: application/sdp

Received 659 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK

CSeq: 3

Date: Fri, Mar 01 2013 20:38:04 GMT

Content-Base: rtsp://172.16.3.53:8554/test/

Content-Type: application/sdp

Content-Length: 497

v=0

o=- 1362170268711363 1 IN IP4 172.16.3.53

s=ECP ETA Streaming server

i=test

t=0 0

a=tool:LIVE555 Streaming Media v2013.01.15

a=type:broadcast

a=control:*

a=range:npt=0-

a=x-qt-text-nam:ECP ETA Streaming server

a=x-qt-text-inf:test

m=video 0 RTP/AVP 96

c=IN IP4 0.0.0.0

b=AS:500

a=rtpmap:96 MP4V-ES/90000

a=fmtp:96
profile-level-id=244;config=000001B0F4000001B509000001000000012008CA0D8800CE18A021E0A1C1000001B2446976583530336231333933000001B25876694430303634

a=control:track1

Opened URL "rtsp://172.16.3.53:8554/test", returning a SDP description:
v=0

o=- 1362170268711363 1 IN IP4 172.16.3.53

s=ECP ETA Streaming server

i=test

t=0 0

a=tool:LIVE555 Streaming Media v2013.01.15

a=type:broadcast

a=control:*

a=range:npt=0-

a=x-qt-text-nam:ECP ETA Streaming server

a=x-qt-text-inf:test

m=video 0 RTP/AVP 96

c=IN IP4 0.0.0.0

b=AS:500

a=rtpmap:96 MP4V-ES/90000

a=fmtp:96
profile-level-id=244;config=000001B0F4000001B509000001000000012008CA0D8800CE18A021E0A1C1000001B2446976583530336231333933000001B25876694430303634

a=control:track1

Created receiver for "video/MP4V-ES" subsession (client ports 50586-50587)
Sending request: SETUP rtsp://172.16.3.53:8554/test/track1 RTSP/1.0

CSeq: 4

User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15)

Transport: RTP/AVP;unicast;client_port=50586-50587

Received 201 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK

CSeq: 4

Date: Fri, Mar 01 2013 20:38:04 GMT

Transport:
RTP/AVP;unicast;destination=172.16.3.53;source=172.16.3.53;client_port=50586-50587;server_port=6970-6971

Session: 5FBE8E99

Setup "video/MP4V-ES" subsession (client ports 50586-50587)
Created output file: "video-MP4V-ES-1"
Sending request: PLAY rtsp://172.16.3.53:8554/test/ RTSP/1.0

CSeq: 5

User-Agent: openRTSP.exe (LIVE555 Streaming Media v2013.01.15)

Session: 5FBE8E99

Range: npt=0.000-

Received 183 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK

CSeq: 5

Date: Fri, Mar 01 2013 20:38:04 GMT

Range: npt=0.000-

Session: 5FBE8E99

RTP-Info: url=rtsp://
172.16.3.53:8554/test/track1;seq=16594;rtptime=2519251020

Started playing session
Receiving streamed data...
^C
----------------------------------------------------------
End of output
----------------------------------------------------------

On Fri, Mar 1, 2013 at 7:46 AM, temp2010 at forren.org <temp2010 at forren.org>wrote:

> Chris,
>
> I've gotten a very similar pipe thing working.  Ross was invaluable in
> helping.  Here are two points you may need to recall, to finally get it
> working properly.
>
> This advice relates to using H.264.  It may only partially relate to your
> application.
>
> 1) You must make sure that you're sending both an SPS and a PPS NAL to
> Live555 *after* VLC tries to connect.  My initial code wasn't doing this.
>  My stream origination used an H.264 encoder that sends these two NAL
> records out first, and it was always running.  So when VLC came along,
> those two NAL records had long since passed.  I had to use tricks to send
> them again *in response* to the VLC connecting.  Aside from Ross knowing it
> off the top, before hearing his advice I located this issue by tracing
> through the Live555 code and discovering it's refusal to continue without
> having seen those two NAL records.
>
> 2) With the above, I got video, but it was very choppy.  Again, Ross was
> correct in suggesting it had to do with providing a steady stream of input.
>  But how to do so was less obvious.  The culprit was partially a lack of
> horsepower on one machine to do the full job with the debug-compiled code.
>  The other culprit was needing to provide a large enough amount of memory
> to the pipe on creation.
>
> Good luck!
>
> On Thu, Feb 28, 2013 at 9:14 PM, Ross Finlayson <finlayson at live555.com>wrote:
>
>> As far as Windows developers who use gmail...I can understand the
>> anti-windows sentiment, but I don't know what you have against gmail...
>>
>>
>> This is explained clearly in the FAQ (that everyone was asked to read
>> before posting to the mailing list :-)
>>
>>
>> And I code in Windows because I'm paid too...and I know *exactly* how to
>> do asynchronous, non-blocking file IO in windows.  Be careful with the word
>> "impossible." ;-)
>>
>>
>> The issue with doing asynchronous file reading in Windows is that - in
>> Windows - extra work needs to be done to handle the 'data is available on
>> the open file' event.  In other OSs, open files are sockets that can be
>> passed to "select()", as we do in the the implementation of
>> "BasicTaskScheduler" (the "TaskScheduler" subclass that we provide with the
>> supplied code).  In (at least some versions of) Windows, however, open
>> files are not "select()"able sockets.  Therefore, to do asynchronous file
>> reads in Windows, you would need to write your own subclass of
>> "TaskScheduler" (that reimplements the "setBackgroundHandling()" virtual
>> function).
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130301/8947f121/attachment-0001.html>