The VideoLAN Forums

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) (Now I telnet to the VLC VOD server and type in my password, then issue the following:) Where <options> can be anything from no options at all (straight delivery of video) to any of:
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...

ask ILEoo on IRC.

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

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:
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:
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:
This, is the the actual session description as captured by Wireshark sniffer. That's all for now. I'll post this to see if I pique anyone's curiosity.


Torin...