More > JRiver Media Center 31 for Windows
Directions
jmone:
A "smart" video server may be interesting.
As background I was running my own file server (NextCloud) from home in a DMZ but ended up decommissioning it due to:
- Hassle of Maintaining it (I "broke it" several times during upgrades thanks to my lack of Linux knowledge)
- Limited functionality (eg I could upload a single video but there was no selective transcoding based on the client device, so to cater for both SDR and HDR I'd have to render out various versions)
I also tried to use the MC inbuilt "share" function but found it:
- hard to keep the SSL cert up to date
- Issues with some users not able to access the site due to Let’s Encrypt SSL certificate not being "trusted" by their setup (they got warnings that the certificate could be dodgy).
- limited control & stats on views etc
- not running in the DMZ
- Poor connection speeds and latency from geographically remote users
I'm currently testing just using YouTube (most a "private" links) and what +'ve and -'ve I've found so far is:
+'ve: I can upload my finished UHD HDR video that I would use with MC, and Youtube will create multiple renders for different clients (different resolutions, bitrates, SDR, HDR)
+'ve: All the stats on # of views, permissions, comments etc
+'ve: Once uploaded I don't have to worry about bandwidth, storage etc (not that any are every going to be a big hit)
+'ve: It's Free
-'ve: It's Free, but Alphabet is monetizing my "Stuff" somehow
-'ve: No control over what they render my videos out at (it is all VP9)
Given you are worried about hosting costs, I'm not sure expanding Cloudplay into the world of Video delivery will be a great idea unless it becomes some form of charged services. The other option is to let us host our own Cloudplay Video Server. Regardless of where it runs it would need to support:
- Trusted SSL, with an easy SLL install and maintenance (if self hosted)
- Recognition of client render capabilities and their "quality" preference for the delivery of the "correct" stream
- Either render versions OR fast enough Realtime rendering to satisfy the above
- User access mgt
- Comments etc
jmone:
Other ideas:
- JRVR: I agree with the comments regarding the expansion of JRVR. The madVR base is .... well.... discerning. You are not going to please them all, but as JRVR develops many will migrate across
- Other Front Ends: I don't know why on earth some users run other Front Ends but then use MC for the video playback. What do these other Front Ends have that is appealing to them? No idea, but it might be worth some investigation with these users.
- EDID mgt: I know this is a hardware thing, but is there anyway of having JRVR manage EDID persistence? Eg: when MC detects that the HTPC display becomes available, set it back to your "default" (resolution, framerate, bitdepth, HDR/SDR) and restore MC's window and focus? Too often, poorly implemented EDID HW leaves the screen in the "basic" config with MC minimised in the task bar.
- Smarter Auto Upgrade: Similar to the above, I've had to turn off Auto Upgrade as MC tries to do this when there is no screen attached (eg the AVR is off or on another source). This upgrade then fails as the UAC does not seem to like the no screen being attached and MC at some point must crash. You come back to a Windows desktop and MC is gone. When you then run MC again, you get the dialog saying MC did not start correctly with the options to "load default"
JimH:
Here's why knowing where to spend our time is sometimes difficult. Google is stopping support on five year old devices made by Lenovo and others:
https://gizmodo.com/google-smart-home-third-party-displays-android-things-1850320510
I just bought a Lenovo clock yesterday. The clock is ticking.
JimH:
--- Quote from: JimH on April 10, 2023, 11:14:06 am ---When Hendrik starts a new thread on it, please give us advice on what's still missing.
--- End quote ---
The thread on JRVR is here: https://yabb.jriver.com/interact/index.php/topic,135621.msg939644.html#msg939644
mattkhan:
one area where I think you have a serious gap regards regression testing in your DSP engine, there have been multiple regressions and feature breaks in this area when changes have been made, which are only detected by users performing their own testing but which should never have escaped because there should be automated tests to verify that the DSP behaves as expected. I think it's a serious gap given the potential to do damage to audio equipment (and, in the worst case, hearing) if bugs escape.
I think you could potentially turn this into a selling point if you were to extend this to cover jrvr in order to be able to objectively demonstrate correctness (which is one doubt I've seen raised elsewhere, that jrvr is not behaving correctly in certain scenarios)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version