Hello Jonathan, Your points are interesting. To keep the horses ahead of the cart we should now understand:
- if virtual VAAPI is hard / easy / doable on X11RDP (maybe Jay can comment) - if browsers actually implement it well (I will test Chrome...) - if we get enough people interested to support this development Cheers Gustavo P.S.: We also tested Pi both with X11 clients and dfreerdp and although it works basic window dragging is super sluggish. It will work well whenever basic acceleration is developed. Last time we tested only the vesa X11 driver was available. That driver is good enough for a terminal on CPUs, but not for the Pi. ----- Original Message ----- > From: "Jonathan Buzzard" <jonat...@buzzard.me.uk> > To: "Gustavo Homem" <gust...@angulosolido.pt> > Cc: "xrdp-devel" <xrdp-devel@lists.sourceforge.net>, "Jay Sorg" > <jay.s...@gmail.com> > Sent: Terça-feira, 11 de Junho de 2013 13:58:29 > Subject: Re: [Xrdp-devel] Improving XRDP performance > > On Mon, 2013-06-10 at 22:46 +0100, Gustavo Homem wrote: > > Hi Jonathan, > > > > > > > > > I also sympathize with the idea of having a transparent > > > > solution > > > > that > > > > is player independent. > > > > > > > > This would require: > > > > > > > > - a "virtual" accel extension on the remote X11rdp server > > > > > > VAAPI is probably the one to use. > > > > But which players support this? 99% of video usage today is related > > to > > browsers, using either flash or HTML5. This holds at least for > > buziness scenarios, but I'd say that for home users it tends to be > > that way as well. > > According to the VAAPI web page FFmpeg, GStreamer, MPlayer, Totem, > VLC > and Xine amoung others. That is the majority of the major players. It > is > also the primary high level video acceleration framework on Linux > going > forward. > > > > > It might have been implemented on Chrome: > > > > http://code.google.com/p/chromium/issues/detail?id=117062 > > Some testing suggests it does work. > > > > > Do you know about this? > > > > For Firefox I only found this: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=495727 > > > > > > > > > - a transport of the partially decoded video (YUV, unscaled) > > > > > > Nope you would want to take the media stream as much undecoded as > > > possible, ideally when it has just been unpacked from the file > > > format > > > container but not decoded and then put it back in the file format > > > container. > > > > Yes, as long as that chosen API is universally supported (or likely > > to > > be in the future) by the video players in use, which currently are > > mostly web browsers. XVideo used to be the most universal API. Are > > the > > browsers likely to start supporting VAAPI? Maybe that is the > > critical > > factor. > > Yes VAAPI is the open video acceleration framework going forward. > XVideo > only does YUV->RGB conversion and scaling/overlay and modern GPU's > are > capable of doing much than that, hence the introduction of newer > API's. > > As for browsers at least one does aka Chrome/Chromium. It would > therefore be feasible if you are running a terminal server with > xrdp/X11rdp to restrict the available browsers to ones that support > VAAPI acceleration. Of course some video formats such as Theora are > not > supported by the MS-RDPEV extension so the best you can hope for > there > is to recompress and use the RemoteFX extension. > > > > > > > > > As I read it MS-RDPEV wants fully undecoded media streams. Though > > > I > > > am > > > no expert on RDP and I could be reading the Microsoft > > > documentation > > > wrongly. > > > > The docs are painful but this kind of video passtrough has been > > done > > (as per Jay Sorg's email). But if I understand correctly the RDP > > client relies on FFMPEG to decode the video. And FFMPEG is a whole > > stack of evolving packages. > > It is. However if you stick to the Microsoft RDP extensions, then the > client is some body else's problem. That said for example the FreeRDP > client supports both RemoteFX and MS-RDPEV, so there is nothing to do > client side on Linux (though rdesktop does not support either of > these > extensions) and obviously on Windows the Microsoft provided client > supports these as well. > > There are loads of RDP clients out there for just about every > platform > under the sun. Consequently any solution that requires special > clients > with none standard extensions is in my view a none starter. That is > why > I outlined ways of doing video acceleration with xrdp/X11rdp using > the > existing Microsoft RDP extensions. > > > [SNIP] > > > The point here would be the self-containedness of the approach > > between > > the RDP server and the RDP client (given the right gfx driver on > > the > > client to expose the real API). The moment we accept the need to > > do > > complicated updates on thin clients - as would be the case if the > > whole ever changing codec "intelligence" was passed to them - > > then > > they are not thin anymore and this beatiful and very efficient > > concept > > becomes too similar to a PC. > > > > My mobile phone has hardware acceleration for both MPEG2 and H.264. > Just > about every ARM based SOC is the same, and one would hardly call a > Raspberry Pi anything other than thin client level hardware. There is > even a project to turn a Raspberry Pi into a cheap thin client. > > http://rpitc.blogspot.co.uk/ > > The importance of the two approaches to the video acceleration that I > made (using VAAPI in combination with MS-RDPEV and/or XVideo with > RemoteFX) is that you do nothing on the client. That is either the > client supports these official Microsoft extensions and gets > accelerated > video playback or it does not. If accelerated video playback is > important to your usage scenario, then you pick a suitable client. > > Personally I would look to implement the RemoteFX method first for > three > reasons. Firstly is is a good fallback method, anything that uses > XVideo > gets accelerated. Second it can also be used with VirtualGL type > stuff > for getting accelerated 3D as well. Thirdly it will definitely work. > > > JAB. > > -- > Jonathan A. Buzzard Email: jonathan (at) > buzzard.me.uk > Fife, United Kingdom. > > -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ xrdp-devel mailing list xrdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xrdp-devel
