RTSP VOD: VLC talks to itself (as a client) but not others

[torinw]

VLC and a phone I'm trying to stream to don't seem to work together. I can play a selected video to this phone using Quicktime, and I can play the same video using VLC to a PC (which also uses VLC as a client.) When I use VLC to stream to teh phone however, it appears to stream but somehow doesn't recognize the video format - instead of playing the video as it does when served up by Quicktime, It instead shows a "Connected" message and then, nothing. It just sits there for approximately the same length of time as it would take to play, then terminates with "Invalid Format". Using Wireshark, I am able to see that all of the packets (exactly the same number that would be sent to the VLC client) are sent to the phone. So, it appears, the phone is receiving the packets, but the client does not recognize the stream.

Have you experienced this? Is anyone able to make this work? I could use some advice, please.

I have tried changing various encoding parameters, codecs, bitrates, increasing the time to live, ensuring that b=AS:nn (nn=bandwidth of video or audio in kbps) SDP parameters exist, and quite a few other things. I have run out of ideas. If you have any suggestions at all, I'll try them.

This is how I currently do it:

(Start the server)

Code: Select all

vlc -vvv --ttl 64 -I telnet --telnet-password videolan --sout-rtp-port=2000 --rtsp-host 0.0.0.0:554

(Now I telnet to the VLC VOD server and type in my password, then issue the following:)

Code: Select all

new Test vod enabled setup Test input known-good-video.3gp setup Test output <options>

Where <options> can be anything from no options at all (straight delivery of video) to any of:

Code: Select all

#transcode{vcodec=mp4v,acodec=amr-nb} #transcode{vcodec=mp4v,vb=30000,acodec=amr-nb,ab=10200} #transcode{vcodec=mp4v,vb=50000,acodec=amr-nb,ab=24000} #transcode{vcodec=mp4v,acodec=mp4a,vb=30000,samplerate=32000,ab=10000,channels=1,fps=7,width=128,height=96}

Incidentally, the video file is a 3GP MPEG4 (mp4a,mp4v, 176x144, 800kbsv,64kbsa).

Like I said before. The video plays fine to a VLC client - just not the phone, and the phone plays the file just fine... just not if VLC delivers it. It's a conundrum, alright.


Torin...

[Jean-Baptiste Kempf]

ask ILEoo on IRC.

[torinw]

I sent an email to him via the Videolan forum. Does he come around here often?

[torinw]

I find it irritating that no one is the least bit interested in even speculating on what the problem might be! Come on... you guys wrote this stuff... I'll do the legwork to figure this out, but I need your expertise and familiarity with this function to figure it out why it's not working, especially that I may be on to something.

Note: The following post is lengthy, but I promise to make it interesting. You won't find reams of useless information here; I've included only what I believe to be essential to the problem.

GOOD AND BAD SESSIONS, Side by Side Comparison Using Wireshark

I decided to do a side-by-side comparison of two RTSP sessions using the Wireshark packet sniffer - one for a PC running VLC as a client (successful), and one for the Samsung phone client (failed.)

Once again, the server is set up in VOD mode and I issue commands (programmatically through the telnet interface) to set up and control the VOD server. When I run the VLC client against this server, the little 1 minute clip plays to the screen exactly as it should. I chuckle, due to its humourous content, and then save the captured data to a file. In this session, I observe the usual negotion:

Code: Select all

OPTIONS rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 Ok Cseq: 1 Server: VLC Server Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Content-Length: 0 DESCRIBE rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK Content-type: application/sdp Server: VLC Server Content-Length: 592 Cseq: 2 Cache-Control: no-cache v=0 o=- 1208895485920895 3 IN IP4 192.168.50.178 c=IN IP4 0.0.0.0 t=0 0 a=tool:vlc 0.8.6e a=range:npt=0-66.600 m=video 0 RTP/AVP 96 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3; config=000001b001000001b58913000001000000012000c4f8586588005504040c1463000001b24c61766335312e32382e30; a=control:rtsp://192.168.50.178:554/Test/trackID=0 m=audio 0 RTP/AVP 97 a=rtpmap:97 mpeg4-generic/32000 a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1290; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1; a=control:rtsp://192.168.50.178:554/Test/trackID=1 SETUP rtsp://192.168.50.178:554/Test/trackID=0 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=3874-3875 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK Transport: RTP/AVP/UDP;client_port=3874-3875 Server: VLC Server Content-Length: 0 Cseq: 3 Cache-Control: no-cache Session: 1804289383 SETUP rtsp://192.168.50.178:554/Test/trackID=1 RTSP/1.0 CSeq: 4 Transport: RTP/AVP;unicast;client_port=3876-3877 Session: 1804289383 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK Transport: RTP/AVP/UDP;client_port=3876-3877 Server: VLC Server Content-Length: 0 Cseq: 4 Cache-Control: no-cache Session: 1804289383 PLAY rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 5 Session: 1804289383 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK Server: VLC Server Content-Length: 0 Cseq: 5 Cache-Control: no-cache Session: 1804289383;timeout=5 *** AUTHOR'S NOTE: RTP Packets are delivered here - everything looks good. The video plays to the screen for approximately 1 minute *** TEARDOWN rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 6 Session: 1804289383 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)

You'll notice something funny about the IP addresses. I'm running this on an internal server that has been mapped to an external IP address using NAT translation. I suspect that this might be one of the many problems plaguing the Samsung phone's RTSP session, but I don't understand why the VLC client works. I can only surmise that the VLC client ignores subsequent RTSP IP address info, whereas the Samsung depends strictly upon it. My other suspicion is that there is no "b=AS:130" (for video) and "b=AS:22" (for audio) bandwidth parameters being sent in the SDP, which I read somewhere is required by 3GP devices (but again, why would the phone issue a PLAY command if those parameters were required?) I'll get to these later in the post.

Here's the same video session as played to the Samsung device:

Code: Select all

DESCRIBE rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 0 Accept: application/sdp User-Network: Qualcomm DeviceInfo: MSM6XX0 Supported: method.eos, com.pv.server_playlist x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-A746.xml User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 Accept-Encoding: compress, gzip RTSP/1.0 200 OK Content-type: application/sdp Server: VLC Server Content-Length: 592 Cseq: 0 Cache-Control: no-cache v=0 o=- 1208894671649489 3 IN IP4 192.168.50.178 c=IN IP4 0.0.0.0 t=0 0 a=tool:vlc 0.8.6e a=range:npt=0-66.600 m=video 0 RTP/AVP 96 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3; config=000001b001000001b58913000001000000012000c4f8586588005504040c1463000001b24c61766335312e32382e30; a=control:rtsp://192.168.50.178:554/Test/trackID=0 m=audio 0 RTP/AVP 97 a=rtpmap:97 mpeg4-generic/32000 a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1290; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1; a=control:rtsp://192.168.50.178:554/Test/trackID=1 SETUP rtsp://192.168.50.178:554/Test/trackID=0 RTSP/1.0 CSeq: 1 Transport: RTP/AVP;unicast;client_port=17758-17759 Blocksize: 1400 User-Network: Qualcomm DeviceInfo: MSM6XX0 Supported: method.eos, com.pv.server_playlist User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 RTSP/1.0 200 OK Transport: RTP/AVP/UDP;client_port=17758-17759 Server: VLC Server Content-Length: 0 Cseq: 1 Cache-Control: no-cache Session: 1804289383 SETUP rtsp://192.168.50.178:554/Test/trackID=1 RTSP/1.0 CSeq: 2 Session: 1804289383 Transport: RTP/AVP;unicast;client_port=17782-17783 Blocksize: 1400 User-Network: Qualcomm DeviceInfo: MSM6XX0 Supported: method.eos, com.pv.server_playlist User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 RTSP/1.0 200 OK Transport: RTP/AVP/UDP;client_port=17782-17783 Server: VLC Server Content-Length: 0 Cseq: 2 Cache-Control: no-cache Session: 1804289383 OPTIONS rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 3 Session: 1804289383 User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 ***** AUTHOR'S NOTE: Notice this OPTIONS parameter - it gets sent over and over, throughout the session, even though the phone issued the PLAY command. I don't know why this happens. Could the IP address be problematic? If so, why is the request still managing to get through to the proper machine? ***** PLAY rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 4 Session: 1804289383 Range: npt=0.000- User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 RTSP/1.0 200 Ok Cseq: 3 Server: VLC Server Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Content-Length: 0 RTSP/1.0 200 OK Server: VLC Server Content-Length: 0 Cseq: 4 Cache-Control: no-cache Session: 1804289383;timeout=5 ***** AUTHOR'S NOTE: RTP packets are flying to the client at this point, however the Samsung client is showing "Connected", when it should be saying "Buffering xx%". The phone will now sit in the "Connected" state for the duration of the video (1 minute) before failing with "Invalid Format" The video's duration and the client's timeout may be coincidental, BTW. I don't know that the phone even sees these packets. I only know that they are sent by the server. ***** OPTIONS rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 5 Session: 1804289383 User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 RTSP/1.0 200 Ok Cseq: 5 Server: VLC Server Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Content-Length: 0 ***** AUTHOR'S NOTE: <Lots of messages deleted> The OPTIONS command is issued [b]47[/b] additional times throughout the session before a teardown is requested ***** TEARDOWN rtsp://66.207.213.239/Test RTSP/1.0 CSeq: 53 Session: 1804289383 Connection: close User-Agent: SAMSUNG-SGH-A746/UXHC1 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1

At this point, the phone has come back with the message "Invalid Format", and has shut down the session.

I also noticed while comparing what was presented to stdout differs significantly with that sent on the wire:

This is what is written to STDOUT:

Code: Select all

v=0 o=- 1208898758677847 2 IN IP4 127.0.0.1 s=NONE t=0 0 a=tool:vlc 0.8.6e c=IN IP4 209.167.5.1 m=video 14480 RTP/AVP 96 b=AS:130 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3; config=000001b001000001b58913000001000000012000c4f8586588005504040c1463000001b24c61766335312e32382e30; m=audio 14486 RTP/AVP 97 b=AS:22 a=rtpmap:97 mpeg4-generic/32000 a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1290; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1;

This, is the the actual session description as captured by Wireshark sniffer.

Code: Select all

v=0 o=- 1208898753915286 3 IN IP4 192.168.50.178 c=IN IP4 0.0.0.0 t=0 0 a=tool:vlc 0.8.6e a=range:npt=0-66.600 m=video 0 RTP/AVP 96 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=3; config=000001b001000001b58913000001000000012000c4f8586588005504040c1463000001b24c61766335312e32382e30; a=control:rtsp://192.168.50.178:554/Test/trackID=0 m=audio 0 RTP/AVP 97 a=rtpmap:97 mpeg4-generic/32000 a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1290; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1; a=control:rtsp://192.168.50.178:554/Test/trackID=1

That's all for now. I'll post this to see if I pique anyone's curiosity.


Torin...