"Pushing" PC display to Pi running raspbmc

And it works!

Well, to a degree. I'm currently getting about one frame per minute. This is wireless, and I am sending a 1920x1600 video over with standard compression settings and codec, so some tweaking will help. It's a start, anyway.

deKay

--
  Lofi Gaming - http://lofi-gaming.org.uk 
  Gaming Diary - http://lofi-gaming.org.uk/diary 
  Blog - http://lofi-gaming.org.uk/blog 
  My computer runs at 3.5MHz and I'm proud of that
Reply to
deKay
Loading thread data ...

.

it at

Wow, that's slow! If it helps, I just tried something here which worked:

  1. Ran RealVNC server in service mode on a Windows machine.

  1. From a Linux machine ran Remote Desktop Viewer (which is in the menu system on this machine under "Internet") pointing it at the IP address of the Windows host.

Et voila!

The Remote Desktop Viewer can allow control or be run in view-only mode. I understand the latter is what you want. There are also various compression options for both the number of screen colours and the communications protocol so it might be quicker than what you have now.

I had seen people recommend TightVNC so assumed you had a VNC solution to try. I've always used RealVNC so cannot comment on another product but this was very easy, worked first time and seems reasonably quick to update the screen.

(If the Windows firewall prevents contact from the Linux machine you might need to configure it to permit the access. You can easily test whether the firewall is an issue by disabling it temporarily.)

James

Reply to
James Harris

...

Having just read over some comments again I see you mentioned you have no X11. X11 can be used to remotely display a desktop but that is not necessary for VNC.

However, having now looked at the Raspbmc FAQ I see they say it cannot run a VNC server so they may be talking about X11 purely local to the Raspberry Pi. Possibly Raspbmc has no desktop environment?

The question is not really about the server but whether Raspbmc can run a VNC *client*. If it can you should be OK. If not then my comments in the previous post won't help. Maybe a more complete desktop environment would be better for you in the long run. There may be other standard unixy things you want to do later which also won't work with Raspbmc.

James

Reply to
James Harris

Thanks. Some others had suggested this, but the main issue was that VNC needs X (which raspbmc doesn't have). Turns out, there are the X-less implimentations which I haven't looked at yet.

deKay

--
  Lofi Gaming - http://lofi-gaming.org.uk 
  Gaming Diary - http://lofi-gaming.org.uk/diary 
  Blog - http://lofi-gaming.org.uk/blog 
  My computer runs at 3.5MHz and I'm proud of that
Reply to
deKay

Hi,

You've probably found a good way to do this by now, but I otherwise just wa nted to point you in the direction of streaming your pc desktop using VLC w ith for example RTSP (using a bat script or from the GUI) and then simply d isplaying in Raspbmc by opening a file with the URL to the stream. Works fi ne for me, albeit a little laggish.

/JT

deKay wrote:

g
Reply to
JT

g

I too wonder where this lies. Most if not all smart devices code and decod e h.264 video with a dedicated hardware chip. Therefore, if the final goal is a screen mirroring tool that any device may use to project the contents of it's screen to another networked device (wired/wireless), it would make sense the transmitting device use h.264 encoding. It is a reverse VNC sce nario. Overview architecture would be h.264 encoding of the client (client being iOS, Android, Windows, Apple) device to a h.264 stream. Somehow the re would need to be a security and auto-discover mechanism to ensure the co rrect display is being connected to making the assumption that no one would invest network dollars to completely isolate devices in a multi-device env ironment. Once negotiation with the appropriate endpoint happens, all the endpoint device needs to do for processing would be to decode and display t he h.264 stream. I envision an army of Raspberry Pi devices (capable of ha rdware h.264 decoding at 1080p) living on a network connected to LED displa ys.

**Also would need a mechanism that allowed the displaying endpoint to rejec t a connection request while being used. Probably also need some sort of l ocal override button in case someone accidentally hi-jacked an endpoint acc identally.

Multiple apps would need to be developed in an environment where there is a lready competition (Airplay, Miracast, Intel WiDi, etc...).

Reverse Client-Server model. Lot's of security pain points.

Reply to
jared.ambrose

this might be the solution

formatting link

http://kodi.wiki/view/AirPlay

g
Reply to
msramalho

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.