[plug] Realplayer proxy

[Craig Ringer]

Derek Fountain wrote:
> Yep, that's my understanding too. In fact, I'm not sure if the video will go 
> over the X protocol either.

It will, but inefficiently. It's decompressed by the client, /then/ sent 
  using the X protocol. I /have/ played DVDs over remote X, and it does 
work, but the framerate wasn't great.

As for audio - while the X protocol doesn't (yet) transmit sound, there 
are soundservers that do. Realplayer supports the esd, so on the machine 
you want making the noise you run:

esd -tcp -nobeeps

then set realplayer to send sound using the esd protocol to the IP of 
the machine you want to make the noise. Note that esd transmits 
uncompressed pcm, so it's only realy suitable for LANs.

I'd /love/ to see the X-server gain the ability to have compressed video 
and audio streams passed to it as-is, then decode them internally using 
plugins. I think this would improve X's utility for multimedia on the 
network immensely. It'd be easy enough to have apps detect the lack of 
this ability (or notice that the X server doesn't support the video 
format) and go back to decoding things themselves. And just think ... if 
your housemates want to watch DVDs on your machine, you can just say 
"install Cygwin and use your machine, just put the disk in my drive".

BTW, have you considered just setting up an ssh SOCKS4 proxy (ssh -D)? 
If you can ssh to a machine that has the appropriate access to run Real, 
you can presumably also ssh to it and use ssh's dynamic proxying. I 
don't have RealPlayer, so I don't know if it'll work with a SOCKS4 server.

Using IP masquerading just for Real might also work if the gateway is a 
linux box. Ports can be discovered at:

http://service.real.com/firewall/adminfw.html

I haven't tested the following, and it might be the wrong way to go 
about it, but something like this _should_ work (assuming you have an 
internal DNS; if not you'll need to open up DNS access too):

# There's probably a less verbose way to do this next bit,
# and/or some rules are redundant:
iptables -A FORWARD -p tcp -m multiport --sports 7070,554 \
	--destination $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --sports 7070,554 \
	--source $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 7070,554 \
	--destination $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 7070,554 \
	--source $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD -p udp --sport 6970:7170 \
	--destination $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD -p udp --dport 6970:7170 \
	--destination $YOUR_INTERNAL_IP -j ACCEPT
iptables -A FORWARD --destination $YOUR_INTERNAL_IP -j DROP
iptables -A FORWARD --source $YOUR_INTERNAL_IP -j DROP
# now allow masquerading to that host
iptables -A PREROUTING --source $YOUR_INTERNAL_IP \
	-j MASQUERADE
iptables -A PREROUTING --destination $YOUR_INTERNAL_IP \
	-j MASQUERADE

I also found this:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-April/010949.html

which might be of interest.

(*woo* 1.5mbit/256kbit ADSL is cool...)

Craig Ringer