[Live-devel] RTSP streaming question

Ross Finlayson finlayson at live555.com
Tue May 2 10:53:18 PDT 2017


Kurt,

Unfortunately I find your question rather confusing, for a number of reasons:


> I am attempting to use the VLC player (live555.com Streaming Server)

When VLC plays a RTSP stream, it is using our software (the “LIVE555 Streaming Media” software) to act as a RTSP client.  It is not a ‘Streaming Server’.


> to receive a live video stream from a DVR using RTSP.  The DVR uses byte-streaming protocol even though it is RTSP/RTP.

I’m not sure what this means.  Did you mean to say that the DVR (i.e., RTSP server) streams only RTP/RTCP-over-TCP (i.e., it sends RTP and RTCP packets over the RTSP (i.e., TCP) connection)?


>  The VLC player ‘chokes’ (generates packet decoding error and does not recover) when the DVR sends its name identification packet on the control channel.

What is the ‘control channel’?


>  The byte sequence of the RTCP is as below:
>  
> 24 01 00 38 80 C8 00 06 D0 3E 1A 9F DC 7D 5D 66 2B 03 4B 0E 84 21 3B 1A 00 00 00 01 00 00 1B 2A 81 CA 00 06 D0 3E 1A 9F 01 0E 55 6E 6E 61 6D 65 64 20 73 74 72 65 61 6D 00 00 00 00

No, that is not what a RTCP packet looks like.  You almost certainly did not receive this data as a RTCP packet.


>  As you can see, the RTCP packet contains a 00 00 00 and a 00 00 01 sequence.  This appears to be the cause of the ‘decoding’.  If I intercept the packet and reformat as below, no errors (added two ‘03’ escape bytes):
>  
> 24 01 00 3A 80 C8 00 06 D0 3E 1A 9F DC 7D 5D 66 2B 03 4B 0E 84 21 3B 1A 00 00 03 00 01 00 00 1B 2A 81 CA 00 06 D0 3E 1A 9F 01 0E 55 6E 6E 61 6D 65 64 20 73 74 72 65 61 6D 00 00 03 00 00

Here you seem to be referring to adding ‘emulation prevention’ bytes (the 0x03 bytes) to a H.264 NAL unit.  But H.264 NAL units do not appear within RTCP packets; they appear only within RTP packets.

In any case, our software does not decode the received H.264 video data; that’s the job of VLC.  Our software just passes H.264 NAL units (received within RTP packets) to a separate H.264 video decoder (i.e., within VLC).  So, I don’t think your problem (whatever it is :-) has anything to do with our software.

If you still think that your problem is related to RTSP or RTP/RTCP, then I suggest running a test, using our “openRTSP” command-line application (see <http://www.live555.com/openRTSP/>), rather than VLC, as a RTSP client:
	1/ Run “openRTSP” with your server’s “rtsp://“ URL.  (If your server streams only RTP/RTCP-over-TCP rather than RTP/RTCP-over-UDP, then you might need to add the “-t” option to get “openRTSP” to work.)
	2/ “openRTSP” should output a file (with a name beginning “video-“).  This will be a raw H.264 video bytestream.  Rename this file to have a “.h264” filename extension.  If it’s valid H.264, then the file should be playable by VLC (i.e., VLC used as a media file player, not as a RTSP client).
	3/ If VLC cannot play your file, then your H.264 is not valid - probably because your server needs to add H.264 ‘emulation prevention’ bytes.  If so, then that’s a problem with your server, and has nothing to do with us.

In any case, please try to clarify what your problem is.


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




More information about the live-devel mailing list