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. It might have been implemented on Chrome: http://code.google.com/p/chromium/issues/detail?id=117062 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. > > 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. What I intended to bring up for discussion was which architecture would enable video acceleration to be performed using a standard mechanism between XRDP and an RDP client so that that the accelerating intelligence is not split among different components on the client. Exaple: if you have 1000 linux RDP terminals, updating rdesktop or xfreerdp might be doable, but updating a whole bunch of multimedia related packages (ffmepg and company...) might be quite expensive in terms of logistics. Therefore I wonder if a simple Virtual Xvideo on remote RDP session <-> transport <-> Real Xvideo on RDP client (or Windows equivalent) bridge would be good enough, and if the same kind of thing is doable with VAAPI as well. 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. I hope this explanation was clear :-) Would also like to know if there is more people on this list interested in the subject. Cheers Gustavo -- 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
