On Thu, Mar 6, 2014 at 5:46 PM, Michael DePaulo <mikedep333@gmail.com> wrote:

Right. RHEL7 beta includes KDE4.

Yes, that worked (after I installed it...). Seems a little quirky about drawing the task bar and menu button but it always snaps into place if I resize the window.

-- Les Mikesell lesmikesell@gmail.com

"GNOME3 fallback session" was removed in GNOME 3.8. "GNOME3 Classic Mode" was added, but it does require 3D.

GNOME3 fallback session It was re-released as GNOME Flashback, consisting of gnome-panel 3.8.0. https://wiki.gnome.org/Projects/GnomeFlashback However, almost no distros include it, and it doesn't work with GNOME 3.10. I discovered that it doesn't work with GNOME 3.10 the hard way, see this thread: https://www.mail-archive.com/x2go-user@lists.berlios.de/msg01641.html

Also, even when you do install it, "gnome-session" still checked for 3D acceleration. So you have to use the workaround mentioned in that thread.

Still, RHEL7 does use GNOME 3.8, so Gnome Flashback / Gnome-Panel 3.8 should work with it. If anyone can find that/those package(s) for RHEL7 beta, please reply to this thread.

On Thu, Mar 6, 2014 at 7:52 PM, Reinhard Tartler <siretart@gmail.com> wrote:

On Thu, Mar 6, 2014 at 6:00 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

On Do 06 Mär 2014 19:43:51 CET, Les Mikesell wrote:

...

Are there any tricks to getting an x2go session to work with the x2goserver package from EPEL for the RHEL 7 beta distribution? My first attempts asking for a gnome session from a windows client connect, open a window, but then display an 'Oh no! Something has gone wrong' error message instead of drawing the desktop. Is this because everything is beta and not quite working yet or am I doing something wrong?

GNOMEv3 will not work with X2Go. Use a more 2D'ish desktop shell instead (MATE, XFCE, LXDE, also KDE4).

I guess the gnome3 fallback session should work just fine. We "just" need to make sure to call it explicitly, just like x2go did in the past with prefering unity2d over the compiz based stuff.

-- regards, Reinhard

---

X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user

Hi Les,

----- Original message -----

On Thu, Mar 6, 2014 at 7:13 PM, Michael DePaulo <mikedep333@gmail.com> wrote:

...

"GNOME3 fallback session" was removed in GNOME 3.8. "GNOME3 Classic Mode" was added, but it does require 3D.

Is that going to be a permanent problem?  That is, will x2go ever be able to do 3d remotely?

We have the crazy idea to integrate NX into latest Xorg. That work we can only commit via a funded project. The next crazy idea is to do the funding via a crowd funding context.

However, this will need people to support the administrative side of the funding and also people doing the promotion work.

Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148

GnuPG Key ID 0x25771B13 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

Hi Les

----- Original message -----

On Fri, Mar 7, 2014 at 9:57 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

...

...

Is that going to be a permanent problem?    That is, will x2go ever be able to do 3d remotely?

We have the crazy idea to integrate NX into latest Xorg.

So _every_ X connection can have caching proxies at both ends?  I like it.  I always thought it was too bad RAM and fast CPU's weren't cheap when the original X development happened.

X connections carry a high payload. What it needs is integrating the NX proto into Xorg (as a second way of transferring the X stream).

...

That work we can only commit via a funded project. The next crazy idea is to do the funding via a crowd funding context.

...

However, this will need people to support the administrative side of the funding and also people doing the promotion work.

Aren't there some frameworks for doing this already?

Yeah, and it still needs someone to handle that. Heinz has agreed to work on that, but his time schedule is very tight. Having people around him, would be gorgeous...

Mike

On Fr 07 Mär 2014 18:32:03 CET, Les Mikesell wrote:

On Fri, Mar 7, 2014 at 10:34 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

...

...

...

...

Is that going to be a permanent problem? That is, will x2go ever be able to do 3d remotely?

We have the crazy idea to integrate NX into latest Xorg.

So _every_ X connection can have caching proxies at both ends? I like it. I always thought it was too bad RAM and fast CPU's weren't cheap when the original X development happened.

X connections carry a high payload. What it needs is integrating
the NX proto into Xorg (as a second way of transferring the X
stream).

Any chance of throwing in a chromecast/airplay-like streaming video mirror in the process (w/h.264 compression and decent performance...)? That might stir up more interest.

We are currently working on some other solution for video playing...
(keywords: TeleKinesis with TelePlayer).

Mike

DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

Hi Les.

For your everyday playback that you would normally use a media player for there’s the mTelePlayer...

For online media there will be a mTelePlayer browser plugin.

The fundamental thinking behind the Telekinesis framework and the mTelePlayer is to having a minimal impact on server side resource usage...

The following video is an early demo of A high resolution 1080p movie trailer playing through X2Go Telekinesis with the mTelePlayer, on a 1080P monitor: http://www.gznianguan.com/x2go/mTelePlayer_telekinesis_demo01.mov (Actually to be fair... thats a 2.39:1 aspect ratio file... so the actual size of the picture is 1920x804, but its a proper high quality trailer not the less...)

To get flawless performance you'd need a client that support hardware acceleration of media playback, and enough BW between the client and server to transport the media info in a timely fashion.. And if you want surround sound, you'd ofcourse need hardware on the clientside that support such things..

-GZNGET

On 03/10/2014 03:42 PM, Les Mikesell wrote:

On Mon, Mar 10, 2014 at 8:49 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:

...

...

Any chance of throwing in a chromecast/airplay-like streaming video mirror in the process (w/h.264 compression and decent performance...)? That might stir up more interest.

We are currently working on some other solution for video playing... (keywords: TeleKinesis with TelePlayer).

What devices/apps would be able to send to that?

The browser plugin is still just a list of ideas and features on a whiteboard.... But as soon as mTelePlayer is released... a basic browser plugin should be done quite soon after...

We got a lot of things we want to do with it but I think we will release a basic version as soon as possible and follow up with the full featured plugin later on.

There is no Chroma keying involved... the plugin... much like the mTelePlayer it self, will be just a GUI that don't touch the media data... Its kind of like an embedded mplayer but with the embedded mplayer instance (being client side) at the other end of the Telekinesis wormhole and the GUI being server side.

The basic idea is almost embarrassingly simple... but making it behave as and feel like its any other player running on the server... takes a bit of tinkering... and requires quite a bit of information being passed back and forth... And as the communication bit of it grew, we thought it would be a good idea to separate it out of the player and make it a framework others can utilize to do other stuff..

We will post some videos soon, showing some of the latest progress and pretty soon we'll release both Telekinesis and the mTelePlayer.

The full featured browser plugin would aim to take on as many video websites as possible... piping the video content through the "wormhole". But that’s going to require a bit of community effort..... More about that once we are closer to actually doing it...

-GZNGET

On 03/18/2014 01:12 PM, Stefan Baur wrote:

Am 18.03.2014 12:22, schrieb GZ Nianguan E.T.:

...

Hi Les.

For your everyday playback that you would normally use a media player for there’s the mTelePlayer...

For online media there will be a mTelePlayer browser plugin.

Do you think you could provide a video of that, too? I'd be interested in seeing how you handle that task. Does the plugin provide a chroma-key*-like rectangle and mTelePlayer on the client then overlays the video image in that rectangle locally?

• http://en.wikipedia.org/wiki/Chroma_key

Also, will mTelePlayer be available for Windows and Mac as well as for Linux?

-Stefan

Hi again,

It should not be a big ordeal to make use of VLC but first we would like to iron out the kinks on the mplayer based implementation first.

If you started media playback in your X2Go session today... and open something like "top" or another system monitor... You'd see not only does the media player consume a massive chunk of your CPU but a couple X2Go related processes goes nuts too and your audio quite possibly would be randomly out of sync. Depending on your tolerance, you'd may be fine with one or two users playing back small low res videos... and get somewhat viewable results. Though on a server with 40-50+ users that simply is not going to be fun... And of-course since the the client don't know any better... It wont give you hardware acceleration on the clientside either... so your client will get bogged down too.... So you basically have a bunch of overworked processes of either side (client and server) thats inhibiting you from getting an enjoyable viewing experience...

With the Telekinesis approach... mTelePlayer directs your media "untouched" to the client side.... where a mplayer (or even VLC) instance, controlled through telekinesis is doing the actual playback with full HW acceleration (if you got the HW for it) and surround sound (if you got the HW for that too). So even when playing high quality 1080p media, you'd get flawless audio and visual performance (as long as your client hardware can actually handle that). And while you're playing the 1080p video.... On the server side you probably wont spot mTelePlayer in "top".... you'll probably see CPU hogs like lxpanel and xfce4-panel using a lot more CPU.

The original intended use for Telekinesis and mTelePlayer was to provide good video playback on our X2Go centric thin client hardware (HW still under development). But it has kind of grown past that... And even though the thin client is primarily intended for boring stuff like offices and edu... With the media performances we're seeing... Its should also work quite well as a thin media client in your living room.

The basic concept of Telekinesis & mTelePlayer is quite simple and proof of concept code was written up quite fast, but getting it to work as you'd expect a media player to work and making it "consumer ready" has been and still continues to be quite the journey...

We've spent quite a bit of time on testing which path provides the highest level of performance and uses the least amount of server side resources. While at the same time, for the end user... just simply be and function the way you'd expect a media player to be... So I certainly hope some of you will find it useful.

Anyway I should wrap this up before it turns into a book....

-GZNGET

On 03/18/2014 04:34 PM, Les Mikesell wrote:

On Tue, Mar 18, 2014 at 6:22 AM, GZ Nianguan E.T. <opensource@gznianguan.com> wrote:

...

Hi Les.

For your everyday playback that you would normally use a media player for there's the mTelePlayer...

Would there be a way to make it work with vlc? I already trust that to play about anything I throw at it. And how different is the transfer protocol than if you just play a video in the remote X session now?

-- Les Mikesell lesmikesell@gmail.com

Synchronized playback is somewhere on the "to do" list.

As for client side requiring support for the media format... The alternative is turn everything into a "known" format on the server side...(transcoding?) which is just takes too much server resources... and introduces a bunch of other issues... In a linux thin client environment distributing new codecs or update to existing codecs is not a big deal.. As for clients running as an application on traditional desktops, we may integrate some form of codec distribution system.

mTelePlayer certainly not a 100% perfect solution, but I dare say its a pretty decent step up from the current state of things... The reason we started working on this particular solution is simply because in our opinion media playback was the the only thing left where MS RDP could consistently beat open source solutions. I'd really love to know how Telekinesis and mTelePlayer stacks up against the MS RDP video stuff...

Though resizing and moving the GUI window works pretty good. Due to the nature of being spread over two separate systems, some things simply wont be 100% as perfect as your average "normal" player.

Recent studies done by the "GIOCS" (Global Institute of Obvious and Common Sense) show that the average user care more about the quality of media playback than the appearance of the GUI.

But we have and are still putting a lot of effort into making the mTelePlayer user experience feel right and "natural" (for lack of a better word).

-GZNGET

On 03/18/2014 06:50 PM, Les Mikesell wrote:

On Tue, Mar 18, 2014 at 12:30 PM, GZ Nianguan E.T. <opensource@gznianguan.com> wrote:

...

Depending on your tolerance, you'd may be fine with one or two users playing back small low res videos... and get somewhat viewable results. Though on a server with 40-50+ users that simply is not going to be fun...

I've always thought there should be a special-case handler for many thin-clients watching the same video in sync (like a classroom) where the server would multicast the stream to a client-local player. Might be good for multi-room music or videos too.

...

With the Telekinesis approach... mTelePlayer directs your media "untouched" to the client side.... where a mplayer (or even VLC) instance, controlled through telekinesis is doing the actual playback with full HW acceleration

That sounds good, but will depend on the client-side player handling every format you need. That's a common issue with the similar DLNA concept since the standard doesn't actually require it.

...

The original intended use for Telekinesis and mTelePlayer was to provide good video playback on our X2Go centric thin client hardware (HW still under development). But it has kind of grown past that... And even though the thin client is primarily intended for boring stuff like offices and edu... With the media performances we're seeing... Its should also work quite well as a thin media client in your living room.

The basic concept of Telekinesis & mTelePlayer is quite simple and proof of concept code was written up quite fast, but getting it to work as you'd expect a media player to work and making it "consumer ready" has been and still continues to be quite the journey...

Even vlc seems kind of clunky in the user interface department.

Yes there is indeed a chance of exploiting holes in codecs etc... but hows that any bigger issue than it is for EVERY user in the world that views video on their desktop anyway? This is certainly not a bigger concern on a netbooted stateless thin client than it would be on your average desktop setup, now is it?

Sure... a transcoder can be thrown into "the mix" but that kind of goes a against the basic core idea of being gentle with the server side resources. But who is to say the transcoder would not be the actual target for attack..?

Security issues with codecs tend to get fixed just as security holes in SSH related stuff tend to be taken care of... Quite frankly I would be just as concerned about security holes in the nxproxying and pulse audio... (and i seem to remember some very real and very serious cupsd issues some time ago...)

Just simply always get the latest security updates for the stuff your running....

In use cases with need for extreme security, you would probably not want to be trusting your "graphical firewall" client software either, to be running on your sensitive hardware.

If your in possession of something that someone with resources really wants... and your targeted... you targeted... and your "graphical firewall" could turn into their entry point... be it X2Go, RDP, Citrix or VNC or what ever else...

Anyway, do not worry! You will not be forced to run Telekinesis or mTelePlayer... it will be a separate package you would need to explicitly install.

-GZNGET

On 03/19/2014 08:47 AM, Stefan Baur wrote:

Am 19.03.2014 08:21, schrieb GZ Nianguan E.T.:

...

As for client side requiring support for the media format... The alternative is turn everything into a "known" format on the server side...(transcoding?) which is just takes too much server resources... and introduces a bunch of other issues... In a linux thin client environment distributing new codecs or update to existing codecs is not a big deal.. As for clients running as an application on traditional desktops, we may integrate some form of codec distribution system.

There is a security tradeoff here, though: For the average Joe, who just wants to play videos and doesn't care about security, your solution will work just fine, but if you're using X2Go as a "graphic firewall", where only images and sounds are passed to the client, you cannot use Telekinesis, since you're running an unchanged audio/video stream - and there have been exploits that work by passing a specially crafted image file/audio/video stream. So all of a sudden you're executing malicious code on your client. Transcoding into a known format would lower the chance of that happening (because the attacker would have to craft his file/stream in a way that it does its nasty deed *after* being transcoded), but it would not eliminate it entirely.

-Stefan

On Wed, Mar 19, 2014 at 2:21 AM, GZ Nianguan E.T. <opensource@gznianguan.com> wrote:

Synchronized playback is somewhere on the "to do" list.

As for client side requiring support for the media format... The alternative is turn everything into a "known" format on the server side...(transcoding?) which is just takes too much server resources... and introduces a bunch of other issues...

I'm not sure that sometimes, in some situations, some servers not having enough resources should rule out a software design that is useful in other scenarios. Consider a home server driving one media player to push things to a big screen.

In a linux thin client environment distributing new codecs or update to existing codecs is not a big deal.. As for clients running as an application on traditional desktops, we may integrate some form of codec distribution system.

Maybe - if it is all automatic and transparent. But what about the situation where the client has hardware support for one codec - and needs it for performance, and that's not the media format?

mTelePlayer certainly not a 100% perfect solution, but I dare say its a pretty decent step up from the current state of things...

How does it differ from what you could do with a DLNA server/viewer/controller - or components that provide DLNA-compatible functionality with the controller part running in the server? That approach would let the client interoperate with other media servers - and perhaps allow playing directly to some devices with embedded clients, although I'm not sure if many currently accept remote controllers.

Or, will this all go through the ssh tunnels to the clients with overhead for encryption?

Recent studies done by the "GIOCS" (Global Institute of Obvious and Common Sense) show that the average user care more about the quality of media playback than the appearance of the GUI.

I think the most frustrating part is when the media and the player are incompatible - and with the proliferation of formats that tends to be common.

-- Les Mikesell lesmikesell@gmail.com

On Wed, Mar 19, 2014 at 8:45 PM, GZ Nianguan E.T. <opensource@gznianguan.com> wrote:

If your talking about Sonys DLNA pet project...

And Microsoft media server/player/extender/xbox and a few hundred other things...

Thats mainly consumer oriented, and mostly used at home where you have only one or few clients... And when indeed it does do transcoding its usually with the aid of hardware acceleration.... and most devices with support for hardware accelerated on the fly transcoding only support one concurrent stream.... and if anything supports multiple streams its certainly still a very limited amount of streams...

The transcoding part is optional, and only done where the player couldn't otherwise work at all. In terms of a DLNA server just tossing streams to clients that don't require transcoding, the network activity should be about the same as what you'll have to do.

Anyway the use case for DLNA stuff is a bit different than the use case for mTelePlayer.... The mTelePlayer main goal is to bring decent video performance to the X2Go desktop on thin clients, not to be a media server in the same arena as the DLNA stuff....

I just like things that follow standards and interoperate... And the case of using a DLNA controller to say 'play to' a display device seems remarkably similar to what the x2go server will have to do to the displaying app in the client.

Currently you would not want to be using a thin X2Go client as your media box in the living room... Though we have no intention to push into your living room, a thin X2Go client with mTelePlayer would work quite well to extend your desktop computer into your livingroom.

Having a cheap device that could do both at every TV in the house sounds attractive to me, although realistically it would probably make more sense to just run vlc locally with local controls and access files over the network or from a DLNA server.

As for tunneling.... The default thing is always to go through the X2Go tunnels. But mTelePlayer is situational aware.. and try to adapt to give you the best possible viewing experience at all times.... That being said, security policies set by the admin, overrides your desire to watch Game of Thrones at decent frame-rates...

I'd expect ssh encryption of those 50 streams to be a problem at the bandwidth you need for quality.

I think the purpose of mTelePlayer will be more clear once we release some more demo videos and the actual player it self...

I do get the idea. I'm just thinking more in terms of a TV-connected media player. Maybe Apple or Google TV will get that right eventually.

-- Les Mikesell lesmikesell@gmail.com