Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hvdh]

Until now, I've always watched movies by playing from 1 dedicated pc (PC2), which I control from another PC (PC1) by RDP. Which worked fine.

Unfortunately, my sete-up has changed, and running an HDMI cable from PC2 to the projector has become rather cumbersome.

Is it possible to add a third PC (PC3), play media on PC 1, send the audio to JRiver on PC2, and the video to JRiver on PC3?

How do I set this up?

[hvdh]

Really, Nobody ?

[zybex]

Your request is not entirely clear. Do you want to split the audio and video outputs to different paths? If so, I believe that's possible with Zones, but I don't know the details.

JRiver can be configured as a DLNA renderer, so you could have:
- PC1, master JRiver PC connected to the projector for video
- PC2 with JRiver configured as a DLNA renderer, connected to your speakers - this would be seen by PC1 as an output device. Any other DLNA renderer would work for this
- PC3 with RDP or JRiver Client just to control playback

[hvdh]

Thanks,

I'm pretty sure this is exactly what I needed to know. I've got some homework to do now.

[eve]

No, this isn't a thing with JRiver. It's not even really a thing outside of the professional realm.

Video over IP at high fidelity is somewhat impractical still. However, audio over IP is very doable.

I transport all my audio over IP. A PC in a rack renders video (directly connected via 100ft fiber optic active HDMI 2.1) to the theater display, and the audio is sent out over IP (so just cat5) to a tiny fanless system located in my audio rack, which then feeds D/A to get audio out. This also means that my main workstation can similarly send it's audio over IP to either the main surround rig, or a headphone endpoint simultaneously.

If you have no need for that sort of flexibility or are working with a receiver, I highly recommend just running a decent active fiber optic HDMI and calling it a day.


Addendum: Yes, you can transport video over IP no problem, but you're using JRiver to get the best video quality possible, that means that compression or chroma subsampling applied is going to remove many of the benefits of using JRiver. Video is very high bitrate, audio, audio is easy. You can sling around 64-128 channels no problem.

[zybex]

Eve, I think the idea is to have PC1 connected via HDMI to the projector/TV, and audio streamed elsewhere. Your audio-over-IP suggestion is good, but do you know if MC can simply push audio to a DLNA receiver (or other MC instance, for audio only) while sending video to the local HDMI ? I think this should be possible?

[eve]

Eve, I think the idea is to have PC1 connected via HDMI to the projector/TV, and audio streamed elsewhere. Your audio-over-IP suggestion is good, but do you know if MC can simply push audio to a DLNA receiver (or other MC instance, for audio only) while sending video to the local HDMI ? I think this should be possible?

No, that's not really what DLNA does. It doesn't have the latency or synchronization required for watching a video and pushing the audio of that video to an endpoint.

[zybex]

Thanks for clearing that up. So the solution is to send the audio over IP or a long cable.
Perhaps JRiver has an opportunity here to add a good feature - sending audio over the network to another MC instance for synchronized playback. I thought Zones could already do that... or is that only for non-network devices?

[mattkhan]

I think you would need to use zone link to do this from MC and I would not be at all optimistic that that would.be accurate enough to work

[eve]

I think you would need to use zone link to do this from MC and I would not be at all optimistic that that would.be accurate enough to work

IIRC what that would do is just start playing back the file on both PCs no (if it even is supported for video? I've never tried in JRiver tbh)? That's absolutely not what you want here. On the surface that seems logical (for example streaming boxes or whatever aren't getting a 'live stream' as much as they are reading a file in chunks from a network source) but just doesn't work out in practice when we're talking about this sort of a use case. Synchronizing 2 PCs to play something back at the 'exact' same time is surprisingly way more complex than it seems and a solution to do that would most likely involve the underpinnings of AoIP anyways.

[mattkhan]

Sorry,.I am just saying it's the only way (that I am aware of) that you could (attempt to) do this using MC

I am not saying it will be useable (never tried myself either but "it won't" seems a safe bet)

[eve]

Perhaps JRiver has an opportunity here to add a good feature - sending audio over the network to another MC instance for synchronized playback.

Implementing RTP or some kind of AES67-like protocol isn't that hard, but I can't imagine supporting this is in the best interest of JRiver. Definitely way more user issues / questions that would arise constantly.

[zybex]

With that excuse nothing would get done.
Being able to do things no other software does is a selling point. Such a feature would be great for multi-room audio too. It's not trivial to implement, but also not that hard; MC already has most of the blocks in place.

Anyway, the suggestion is done, it's up to JRiver team to pick it up or discard it.

[JimH]

You could try ZoneSync.  It's roughly what you're talking about doing.

They problem with it is differing latency of the devices, which causes some drift.  We've tried to solve this, but it's not perfect.

Getting the audio there across the network is easy and already done.

[eve]

With that excuse nothing would get done.
Being able to do things no other software does is a selling point. Such a feature would be great for multi-room audio too. It's not trivial to implement, but also not that hard; MC already has most of the blocks in place.

Anyway, the suggestion is done, it's up to JRiver team to pick it up or discard it.

The problems I see primarily relate to factors outside of JRiver's control like user's local network topology / devices (far more complex than the typical issues troubleshooted by the JRiver staff). There are additionally more OS and network stack considerations. There are less stringent (from a time synchronization standpoint) ways to try and accomplish this but I'm not sure what the results would be.
I don't want to be a debbie downer here. I'd adore if JRiver offered direct to AES67 output but I'm not holding my breath. This whole AoIP thing (all the different flavors are pretty similar at the most basic level) is the future but at the moment primarily relegated to professionals / super nerds.