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