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. ------------------------------------------------------------------------------ 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
