Alternatives to HTTP for on-demand unicast?

About encoding, codec settings, muxers and filter usage
MikeInMass
New Cone
New Cone
Posts: 8
Joined: 21 Jul 2006 04:33
Location: Boston, USA

Alternatives to HTTP for on-demand unicast?

Postby MikeInMass » 21 Jul 2006 04:42

I need to stream audio/video from a typical consumer grade cable modem connection to a consumer grade DSL subscriber with a different ISP.
I only need to stream to one particular remote client.

Right now I am attempting to stream MPEG-4 over HTTP.
On the client end, VLC plays the stream for a second or two, then hangs.
I suspect I am saturating the outbound cable modem pipe.
Here's my command line:

Code: Select all

C:\VideoLAN\VLC>\VideoLAN\VLC\vlc -vvv dshow:// :dshow-vdev="Hauppauge WinTV PVR PCI II Capture" :dshow-adev="none" :dshow-tuner-channel="51" :sout="#transcode{ vcodec=mp4v,acodec=mpga,vb=350,ab=64,fps=24,deinterlace,audio-sync,scale=0.5}:st andard{access=http,mux=ts,dst=192.168.1.100:8080}"

I think that using UDP would allow the client to drop packets and catch up.
But I don't want to be pushing out UDP when no client is connected to the video stream.

Also, the client's IP address might change from time to time.
With HTTP, I don't have to worry about that on the server end.

Should HTTP streams be able to cope with packet loss better than what I'm seeing, or is this freezing par for the course?

Is there another way for me to stream on demand to a single client?

wlarsong
Blank Cone
Blank Cone
Posts: 38
Joined: 09 Aug 2005 16:53

Postby wlarsong » 21 Jul 2006 06:11

Unfortuantly No, the over head involved with HTTP is due to the fact it is a TCP protocol, TCP must have certain packet sizes and the client will reask the server for any data it missed, which is why you re seeing it play for 2 seconds and stopping.

Secondly, no matter what protocol you use you will still be pushing packets, and if security is an issue, simply encrypt your transfer.

a couple of solutions for you.

Remote Desktop, you could install a remote desktop client such as UltraVNC google it.

Then you could set up the stream remotely from your clients machine

You could also create a PPTP or L2TP or IPSec VPN, either use the Windows/Linux client or use Open VPN, google it.

then you could have your cleint configure the VPN so it had a static address when logged into the VPN, providing you with a secure connection , encrypted connection and an IP address that would never be Dynamic and the convience of UDP, if you need instructions on how to do any of this let me know.

Good Luck

MikeInMass
New Cone
New Cone
Posts: 8
Joined: 21 Jul 2006 04:33
Location: Boston, USA

Postby MikeInMass » 21 Jul 2006 06:23

Thanks for getting back to me!
no matter what protocol you use you will still be pushing packets
Please help me understand this.

I think that, with HTTP streaming, I am only sending packets when the client is connected. Otherwise, the HTTP server is just listening on the port-- no packets are being sent.

If I set up UDP streaming and just let it run, then VLC will always be sending packets whether the client is listening or not, right?

What about RTSP? Is that always sending packets, or only when a client connects?

wlarsong
Blank Cone
Blank Cone
Posts: 38
Joined: 09 Aug 2005 16:53

Postby wlarsong » 21 Jul 2006 07:02

I miss spoke, yes the HTTP handshakes and then a connection is established but you are still serving data thats what i ment.

MikeInMass
New Cone
New Cone
Posts: 8
Joined: 21 Jul 2006 04:33
Location: Boston, USA

Postby MikeInMass » 21 Jul 2006 07:14

Okay, glad I understand HTTP properly.

I want to be serving data only during the hours that a client is connected, not 24/7. So I don't want to just leave a UDP stream broadcasting all the time.

I want to serve video only when a client is connected, as with HTTP.
But I want the stream to be able to recover from packet loss,
which HTTP doesn't do very well for me.

What options do I have?


Return to “VLC stream-output (sout)”

Who is online

Users browsing this forum: No registered users and 36 guests