[X2Go-User] RHEL 7 beta

[GZ Nianguan E.T.]

First of all, the main use case for mTelePlayer is thin client 
implementations where you may have 25-50+ concurrent users on the server 
and probably multiple servers to spread the load.
In these cases on the fly transcoding of quality content, with adequate 
performance would be damn near impossible... since most content now days 
are heavily encoded and compressed to begin with... unwrapping that and 
then packing it back in another heavily encoded/compressed format would 
take a lot of computing power... and quite frankly it would be a crappy 
user experience pretty much all the time not just "sometimes, in some 
situation".

If your talking about Sonys DLNA pet project...
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...

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

As for supported media formats..  if you cant play it with mplayer or 
VLC... its probably not a common nor widely used format? And you 
probably wouldn't be able to play it on any linux desktop anyway...

Most modern hardware have decent support for most common formats that 
are widely used....   And without HW support you're still getting better 
frame rate and audio sync than if you try to play it through X2Go the 
"old way"... Cause some how something needs to update your screen at a 
reasonable frame rate...


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

If your on a remote terminal, connected to the X2Go server via the 
internet, it could access online content directly instead of going 
through the tunnels... (if the admin on the serverside allows this and 
your client settings allow this).
Likewise if you are on a LAN connected terminal you could avoid the 
encryption  overhead too.... and you may actually use separate hardware 
as a media proxy...
Even when the X2Go server it self never sees any part of the actual 
media data... mTelePlayer will still behave and for the most part feel 
like an application running on the server side... as to provide a 
seamless and user-friendly experience.

Regardless, the overhead for unmolested x264/mp4 (or any other format) 
is quite low compared to what you'll see if you force the nxproxy bit of 
X2Go to deal with it....

I hope that adequately addresses your comments...
let me know if I missed something!

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


-GZNGET



On 03/19/2014 04:18 PM, Les Mikesell wrote:
> On Wed, Mar 19, 2014 at 2:21 AM, GZ Nianguan E.T.
> <opensource at 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.
>