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