PLEASE READ BEFORE POSTING:

If you are willing to offer some compensation for a new feature or bug fix, you can use the Help Wanted forum. Start a new topic for each new feature idea, and when someone someone decides to do it, please edit the Roadmap Wiki which lists active work.
LinuxMCE Forums
May 26, 2013, 09:07:26 am GMT-1 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com
 
   Home   Help Search Chat Login Register  
Pages: [1]
  Print  
Author Topic: Xine, broadcasting to multiple MDs...  (Read 1039 times)
colinjones
Alumni
LinuxMCE God
*
Posts: 3003


View Profile
« on: March 17, 2009, 11:43:42 pm »

Can I make a suggestion? Recently I was speculating on a new way of using Xine for audio and video play back http://forum.linuxmce.org/index.php?topic=7367.msg47277#msg47277

I realise that this would be some major re-plumbing, but I would like at least to have this idea posted for the record in the Features forum....

In short, the idea was to move to a model were there would be 2 xine DCE devices rather than 1, in each MD. The first would be a "Xine Server" and second a "Xine Client". When the media plugin wants to start a peice of media, it would send a DCE message to the Xine Server on the MD in question to pick up the stream object from the foundry, and start playing it in server/broadcast mode. It would then send another DCE message to the Xine Client on the same MD, telling it to connect to the broadcast of the Xine Server. In this way a new piece of media would start playing, with no apparent difference from how things are done currently.

However, now, if you want to bifurcate the stream using the media map, to extend that media to play on other MDs, the media plugin simply sends a DCE message to the Xine Client on the other MDs telling them to connect to the same broadcast stream from the original MDs Xine Server. In this way, we could guarantee that any media (audio or video) is perfectly sync'd no matter how many MDs were playing it - they would all be playing a real-time stream without the need for buffering, so the sync could only be out by the latency around the internal network which would be far lower than is noticable in media. This would replace the need to use the time stamp events. These would still be needed for resuming playback but relying on them for sync'ing media streams, as we all know, doesn't work very well.

This could even be extended to use a multicast address, which would save hugely on network bandwidth in environments that have large numbers of MDs (as the "broadcast" mode isn't a real TCP/IP broadcast, rather it would be multiple unicasts, each consuming bandwidth)

Further, this could be the nucleus of separating audio and video streams so that you could play the video-only from one piece media and the audio-only from another, on the same MD. Potentially, many different audio streams mixed together, and possibly even breaking up the screen of an MD to play multiple video streams simultaneously on the same screen. We could have as many Xine Client DCE devices as we want in each MD to allow for this. For audio, they just need to play nice together allowing the audio streams to be mixed (quite possible), for the video idea of course, this is much more complex....

Does this strike any of the developers as a good idea?
Logged
darrenmason
Addicted
*
Posts: 529


View Profile
« Reply #1 on: March 18, 2009, 12:39:27 am »

Colin,

This model sounds similar to what was (is) in place with the videolan (vlc) server model. VLC was effectively the Xine Server that you refer to. The difference from memory was that the videolan server was only put into place when multiple (more than 1) clients requested the stream. I always thought that surely it would be easier to remove this logic and only use the server whether there was 1 or more clients but assumed that there was reasoning behind it.
I am not sure how much of the videolan code is still in place or working as I havn't really used the functionaility much - but I plan to more soon with a couple more MDs coming online (particularly the spa MD Smiley

I will try and help you out where I can

Darren
Logged
chriss
Veteran
***
Posts: 140


View Profile
« Reply #2 on: March 18, 2009, 04:17:59 pm »

Nice approach, Colin. I think, tt would require to change a lot of stuff, though. However, I see a couple of emerging use cases like seamless integration of other streaming sources, e.g., web radio, OTA radio, IP-TV, surveillance cameras... all with the same infrastructure. Even mobile media directors would become possible in case of on-the-fly transcoding Wink

Anybody who knows more about the VLC plugin?
Logged
colinjones
Alumni
LinuxMCE God
*
Posts: 3003


View Profile
« Reply #3 on: March 18, 2009, 10:12:19 pm »

chriss - thanks! Much as I have respect for VLC as a desktop player app, I think that while xine is the encumbant, and has had the most work on integration done, and also seems to have the client/server/streamer model available as an option, perhaps we should stick with that? Actually, it seems to me that the current wrapped xine device could probably morph into the Xine Client device quite easily. The Xine Server would seem to be completely new and need to start from scratch. Its the changes to Media Plugin that worry me in terms of the effort involved... dunno...
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!