Let's help SageTV do multizone sync on the HD200

[exdirtfarmer]

In search of the Holy Grail. HD200 doing multizone HD video synced in all zones.

Yes we all want it. Let's take some time and do a little research instead of the usual +1 vote thing. Get out the google, bing or dogpile search engines and fine some evidence of SOMEBODY on this planet capable of doing this.

We are looking for a product that is currently capable of multi-zone fully sychronized playback from a network source using IP based distribution. No matrix switch boxes allowed. No baluns or conversions to coax. Must be based on IP and be able to run converged on your current LAN. (just like the HD200)

Somebody please enlighten us all with a product which is already capable of doing this. If we find one it would be a glimmer of hope that it MAY be possible using todays technology.

I know of none.

[Brent]

I think Sonos does this for music.

Would be very challenging to do with Video though.

[stanger89]

Originally Posted by Brent

I think Sonos does this for music.

So do Squeezeboxes.

[exdirtfarmer]

Originally Posted by stanger89

So do Squeezeboxes.

It took Squeezebox a long time to get the multizone sync working. It's no easy feat. I have 7 zones of Sonos, and its solid, but proprietary, and audio only. Apple Airport Express can do audio also, but I don't think they have got synced video working yet.

I would think sonos had a look at video also.

Cisco had a crack at multizone media also, but It was a flop.

It's too bad multicast IP Streams didn't work better for video. Somebody would have got this figured out already.

[matt91]

I thought a year or two ago someone said they were going to try to write a little code to have the www server start videos at the 'same' time. Basically, IIRC, this would just fire off the "Play on extender xyz" command for the same media file for multiple extenders at once.

Obviously this would only be as good as the www server is. I imagine that your [1] to [n] extender might be a couple of seconds off, but I'd think that would be acceptable for many residential applications.

[xred]

Brainstorming but here goes....

Looking at all the the technologies in the current Sage "toolbox" I would venture a guess that Placeshifter mode is where the most opportunity for this type of functionality lies. I think both the HD100 and HD200 support Placeshifter mode as well.

We know the Sage server is capable of doing a real time encode of a video stream to a single Placeshifter client. The trick would be to create that single "master" stream with an embedded timecode and have multiple clients be able to tune it. So assuming that you have an existing streaming session between Server A and Client 1, the trick would be to have Clients 2,3,4 etc tune in to THAT specific streaming instance and decode it. Assuming all clients are decoding the stream as fast as it is fed (real time) you should have perfect or near perfect sync.


Now everyone explain why that's absolutely positively not possible =)

[GKusnick]

Originally Posted by xred

Assuming all clients are decoding the stream as fast as it is fed (real time) you should have perfect or near perfect sync.

Decoding isn't instantaneous; there's internal latency involved. Even if all clients receive the packets at the same time, they still have to buffer the incoming data, decode it, and render it, all of which takes time. If all clients have identical hardware, there might be some hope of near-sync on the output end of that pipeline, but as soon as you start mixing HD100s, HD200s, and PC clients on the same LAN, that hope disappears. What you need is some sort of "heartbeat" mechanism, independent of the data stream, for keeping the rendering in sync to within tens of milliseconds. A simple multicast won't accomplish that.

[Fuzzy]

actually, a multicast WOULD work for actually generating/distributing the heartbeat, and would probably get it 'close enough' for most uses. However, that'd be quite a feat to get integrated and tested in the firmware. i'm not sure sage even has that much granularity in the decoding, as it's kind of a slave to the decoder chip (can it seek forward/back by the millisecond?)

[stanger89]

Well, FWIW, if I were going to set this up/design it:

You'd want to start with a multicast "push" of the video, this would, at least on a home network, ensure that each device receives video in sync.

Now, the problem is you need some way to syncronize the decoding, this seems to be the big tricky bit. Each clock that each player runs off of can be a little different. You need to make sure none of the players decode too slow and fall behind, or decode too fast and run out of data.

You'd either have to somehow pull a clock signal out of the multicast packets, or maybe send out a separate master clock/sync signal.

Depending on the capabilities of the decoder, it could be as simple as creating a multicast video stream on the server, and then "tuning" each player to it, or you might have to do lots of custom coding.

[GKusnick]

Originally Posted by stanger89

You'd either have to somehow pull a clock signal out of the multicast packets, or maybe send out a separate master clock/sync signal.

I think you need both. At the very least you'd need two sets of timestamps in the mutlicast stream: one indicating what time each frame is meant to be rendered, and another indicating what time the server thinks it is right now (i.e. when the packet was transmitted). The client would have to pull out the second set immediately on packet receipt and adjust its internal clock accordingly.

Even then, though, there are still latencies between the time the server stamps the packet and the time the client performs the adjustment. These latencies could vary from packet to packet or subnet to subnet (depending, for instance, on how many switches the packet traverses and whether there are any collisions and retransmits along the way). So you'd probably have to resort to periodic pings to measure the round-trip latency to each client, averaged over time, and use that to guide the clock adjustment on the client side.

[stanger89]

Originally Posted by GKusnick

I think you need both. At the very least you'd need two sets of timestamps in the mutlicast stream: one indicating what time each frame is meant to be rendered, and another indicating what time the server thinks it is right now (i.e. when the packet was transmitted). The client would have to pull out the second set immediately on packet receipt and adjust its internal clock accordingly.

Not necessarilly, the reason is since it would be a push system, the all the clients would just be rendering as they receive data. I'm thinking something along the lines of how some AVRs sync their DAC clock to the incoming S/PDIF clock, or how a TV card encodes frames as they come, pulling it's clock off the sync signals.

Now this does bring up probably the first really big complication, how do you handle skipping seeking? Well, I think the server would have to handle that, rather than the client jumping to the right point in the stream, you'd have to have the server do the jump.

OK, I take that back if you're planning to maintain timeline functionality, even if you do all of the above, you do still need to tell the clients where in the stream they are, for the OSD to be correct.

Even then, though, there are still latencies between the time the server stamps the packet and the time the client performs the adjustment. These latencies could vary from packet to packet or subnet to subnet (depending, for instance, on how many switches the packet traverses and whether there are any collisions and retransmits along the way). So you'd probably have to resort to periodic pings to measure the round-trip latency to each client, averaged over time, and use that to guide the clock adjustment on the client side.

It does turn into a nasty rabbit hole doesn't it.

[paulbeers]

Bottom line for all of this, is that it is not a simple process. I used to use a program called Xlobby that allowed you to "sync" multiple computers in multiple locations for music playback. The problem was the internal audio clocks were just a little different (as mentioned in this thread) which would mean over time they would drift. I have also used a program (can't remember the name, something like Air XXXX). It worked fairly well the few times I tried it where it would push out a steady stream to the clients from a server; however, inevitably the clients would drift by a mere fraction of a second and then you would get a "hiccup" in the playback on the clients as it righted itself. This was unacceptable as the slight hiccup would drive me nuts.

Without going to the expense of Sonos or Squeezebox, I ended up just buying a Composite amplifier that could take 1 input and share it to 7 outputs. And then to each receiver/stereo/amplifier in my house is wired to that composite amplifier in my basement.

I would imagine to get this to work with Sage, would require much more expensive hardware or Sage would have to charge an arm and a leg to make it work.

[exdirtfarmer]

Originally Posted by paulbeers

Bottom line for all of this, is that it is not a simple process.

I would imagine to get this to work with Sage, would require much more expensive hardware or Sage would have to charge an arm and a leg to make it work.

Agreed.

My question is has ANYBODY been able to do it? Is there any company out there that has the ability to do what some expect Sage to do with their extenders using a software upgrade?

I'm not saying it can't be done, I'm just saying it probably can't be done using the current hardware. Then you get consumer Joe whining because it's stuttering on his wireless connection.

There are plenty of theories out there how it can be done. Show me the fact. Show me somebody able to do it.

[Fuzzy]

Honestly, i dont' thin there is that much need. at least not enough to warrant the large amount of R&D that it would take. It's so much 'simpler' to run the video/audio cables if you are prone to needing this feature often.

[exdirtfarmer]

Many people keep asking for it, not sure how many would actaully pay big for it.

Currently simpler to run extra wire than figure out how to carry it all on one medium. I guess that's the reality. I dream of a day when we can carry it all one one multistranded copper medium. More CAT6 and dongles and multipliers for now.

It may not be SageTV that figures out how but somebody will..... eventually.

[reggie14]

I think this is somewhat interesting feature request, but ultimately I don't think very many current Sage users have much of a use for it. This is probably more of a feature for a whole-house automation system. And I think Sage would have a long way to before it would really be appropriate for that.

[paulbeers]

Originally Posted by exdirtfarmer

My question is has ANYBODY been able to do it? Is there any company out there that has the ability to do what some expect Sage to do with their extenders using a software upgrade?

Not for video. The only way I am currently aware of this, is using some kind of Video Matrix or the ZvBox (see the other thread).

[MacDaddy]

This might be of interest. Not exactly a HD200 solution, but an example of delivering video over IP that might one day apply. Right now it takes a managed switch, multiple VLANs and some IGMP magic. But if it can take a source at the HDMI level, it seems to me that having something like the HD200 that has more "knowledge" of the stream it is processing could use similar techniques to get the same (or better) results.

http://www.justaddpower.com/VBS-Suit...-products.html

Santa - add another toy to my wish list.

[sic0048]

Well, that device is much closer to a matrix switch than a media player. I guess it really is a matrix switch, except the signals are sent over network cables instead of dedicated a/v wires. You still need to hook up a HD extender to the source device and this system simple acts as a video converter to send that signal out to multiple locations. I'm also not sure if the system will synch multiple locations exactly (I'm not saying it doesn't either - I don't know enough about the system to say).

I agree that the product is pretty cool, and could certainly revolutionize how a/v distribution systems are designed and installed. Of course it has to work well, and I'm not sure they have consistantly good results yet. There has been some discussion about this setup on the CQC forum. Hopefully a couple of integrators are going to experiment with the system.

[MacDaddy]

Good points. I certainly don't have the credentials to really dig in to this. But from my perspective it seems there are a few items that (if I had a free drop) could make for interesting mix-n-match.

1) the matrix switch Achilles heel - sampling the input source signal/converting to proprietary transmit format/restoring stream(s) at endpoint. The various conversions introduce motion blur, background artifacts, etc. Seems like the Justaddpower device would suffer from that as well. It seems to me that the stream that SageTV sends to an extender would be "better" in this case.

2) the synchronized streams on multiple outputs - once you can get a stream in a transportable format, this is where the traditional switchers shine - unfortunately most are proprietary in nature (although they might be using UTP cable to make the wiring approach more standard). The Justaddpower approach seems to offer an interesting alternative here. Using the managed switch to set up multiple VLANs, using the same IP address for their output device, using IGMP to multicast the stream (I'm in so far over my head here - I hope Stanger89 is gentle when he corrects me here :-) ) seems to be a way to get multiple outputs synchronized.

3) the mix-n-match - what if the SageTV stream could be set up to multicast to the same IP address on multiple VLANs with single HD200s (of same IP address) on each VLAN. When you need to talk to all the HD200s, then use IGMP to group all the VLANs and away you go. For a single HD200 to get its own stream, then isolate the VLAN (for someone who is completely ignorant of this technology, it sure seems like an easy answer).

It would be interesting if there was a way to leverage some of the more advanced networking techniques available today rather than having to cram every thing into the software application.