INTERACT FORUM
More => Old Versions => JRiver Media Center 23 for Windows => Topic started by: RD James on June 05, 2017, 06:08:11 pm
-
Will JRiver move to 64-bit on Windows in v23?
It's seriously impacting the player's stability now that 4K videos are commonplace.
If you use tools like SVP for smooth video playback, 4K videos will crash 100% of the time if you use ROHQ due to the ~3GB memory cap that the 32-bit version of JRiver has.
Memory playback features were never fully implemented in v22 either, presumably as a result of limited memory access.
We're still limited to only storing a single track in memory.
-
We're investigating the feasibility of a 64-bit version for MC23, but MC is a complex product and every platform is different, so until it's actually out there are no promises.
-
This is an important consideration for me as well. Thanks in advance for moving to x64 at some later build.
-
I'd vote for a 64-bit Windows app.
I'm also interested in JRiver Media Center becoming a fully touch-enabled Windows 10 app.
That would add a lot to the product.
-
I'm also interested in JRiver Media Center becoming a fully touch-enabled Windows 10 app.
IMO, this certainly isn't feasible and isn't worth the development costs. A native Windows 10 app (Universal Windows Platform or UWP) would lack features (e.g. there's no madVR and LAV Filters available for UWP) and the platform isn't really popular (for example the very small Windows 10 Mobile market share plummets monthly and there's constant news of app developers discontinuing their UWP apps and ceasing development). Not only that, MC would likely be tied to Microsoft's Store, which likely isn't desirable. Look at VLC as an example, how limited it is in regards to features compared to the desktop Win32 app - it doesn't even support playback of DVDs or Blu-rays!
Basically, I wouldn't hold my breath on this one.
That would add a lot to the product.
Honestly? I don't think so (a lot of users hate and don't use Windows 10, avoid using UWP apps in general, etc.). Any potential users of the platform would be so small it wouldn't be worth the time and money developing a MC UWP app.
64-bit app, on the other hand, would be more than worth it, IMO.
-
<snip> (for example the very small Windows 10 Mobile market share plummets monthly and there's constant news of app developers discontinuing their UWP apps and ceasing development). <snip>
Agreed. Skype recently announced that it will discontinue all Windows Phone 8, 8.1, and Windows 10 Mobile Skype Apps in July this year. Skype is owned by Microsoft... So Microsoft is discontinuing support for a major Windows Mobile App.
That is the death knell for Windows 10 Mobile as far as I am concerned. I am a W10M user, and I'm thinking about trying to get Android onto my Lumia 650 phone!
-
I've not been following it too closely, but I thought they were killing off "windows mobile" and moving towards "windows 10" on all devices with cshell.
So you have one app that runs across all devices instead of separate mobile apps. (which didn't work out)
-
They are killing (have killed) "Windows Phone" and promoted "Windows 10 Mobile" in its place.
They have been talking about an ARM based Windows 10 version that would run a "mobile device that includes telephony", but "will not look anything like a smart phone". They are hinting that there will be such a hardware device from Microsoft, but they aren't called it a Surface Phone or anything similar. In fact they aren't calling it anything at all. Some pundits have suggested it may be called "Windows 10 Mini", or something like that. But that is all just hot air. Nothing real from Microsoft.
Regardless, running Windows 10 desktop or tablet Apps on a small device isn't going to help with the dearth of useful mobile Apps on the Windows 10 Mobile platform now. Being a Windows 10 Mobile user, and not a very demanding one in terms of Apps I use, I can state categorically that any Windows mobile platform is now dead.
My recent example; I wanted a good Windows 10 Mobile Shopping List App. I looked at them all. They are rubbish. All of them. There are quite a few. They have almost all been abandoned. Some have Windows 10 Desktop versions, which are even worse. I think children programed most of them. Or at least people that have never been shopping at a grocery store. Or written a program before. Some people claim they can run Android Apps on Windows 10 Mobile, yeah no, they can run, if you do all sorts of stupid things to your phone and risk loosing it all, including your identity, except you won't get any network, sound, Bluetooth, etc. functionality.
I started researching installing Android on my Lumia 650. Many people claim it can be done, quite easily. All of the sites those people link to are scams. It shows that there must be a lot of people desperate to get Android onto Lumia phones, if it is worthwhile setting up multiple scam sites.
Microsoft's mobile/portable/telephony strategy has failed, and when everyone realises, Android will start to appear on desktops. So to shall Microsoft fail, except perhaps in the business sector. Initially as an OS, then later and a service company, until finally it shall "merge" (be taken over, bought out, subsumed) by some larger services company.
Yeah, I'm pretty pissed off with Microsoft. >:(
-
...
I'm also interested in JRiver Media Center becoming a fully touch-enabled Windows 10 app.
That would add a lot to the product.
I know, off topic in regards to 64bit, but agreed! I often run JRiver Media Center on a Lenovo Tablet running Windows 10. It's great for travelling/camping.
However, a fully touch-enabled interface would make things much easier. Maybe a user option to load an interface like the one on JRemote?
-
UWP app? Not important.
But on topic 64 bit? Yes, I would even dare to call it overdue. It should come as soon as possible.
-
What will it give, 64-bit?
-
What will it give, 64-bit?
bigger code but more efficient usage of HW resources and execution (possibly faster)
-
I don't know, the advantage is usually access to more than 3GB of RAM.
Maybe JRiver 64-bit will be able to keep whole library in memory (I don't know what it is now), so that the scanning - slowest mechanism in my home use - will run faster?
When you recompile your software on 64-bit compiler, only pointers change to 64-bit, all the rest is still 32-bit.
But besides, now you need to take care of all your customers using plug-ins, drivers, compatibility tests.. etc.
+ which is less relevant to us, but all this OSS JRiver built upon like SoX must be also compiled into 64-bit
-
When you recompile your software on 64-bit compiler, only pointers change to 64-bit, all the rest is still 32-bit.
But besides, now you need to take care of all your customers using plug-ins, drivers, compatibility tests.. etc.
in theory compilers will also use the 64-bit extension of the intel x86 assembler
-
Yes, but they will probably need to rewrite portions of the code.
Just recompile into 64-bit is easy (if they don't have lot of assembly code and/or 3rd party)
-
Definitely support 64b, don't care about touch interface as I only use MC on my home theater system.
-
Yes, but they will probably need to rewrite portions of the code.
Just recompile into 64-bit is easy (if they don't have lot of assembly code and/or 3rd party)
32bit assembler should be backward compatible to 64bit assembler. It is hard to believe people is still using assembler around ... C compilers work like a charm
-
Will JRiver move to 64-bit on Windows in v23?
It's seriously impacting the player's stability now that 4K videos are commonplace.
If you use tools like SVP for smooth video playback, 4K videos will crash 100% of the time if you use ROHQ due to the ~3GB memory cap that the 32-bit version of JRiver has.
If, by SVP, you mean Sony Vegas Pro, that may be the old problem they had with our audio. Sony Vegas would crash whenever JRiver's ASIO was active. Newer versions of Sony Vegas do not crash.
https://yabb.jriver.com/interact/index.php/topic,89464.msg673714.html#msg673714
Please start a new thread on the problem or bump any old thread you started. I don't think there is a problem with 4K playback in general.
-
SVP probably refers to this: https://www.svp-team.com/wiki/Main_Page
-
I see some specific instructions for JRiver here:
https://www.svp-team.com/wiki/SVP:JRiver_Media_Center
Odd that they require ffmpeg to be installed.
-
To answer the original question, we will probably eventually do a 64 bit version, but ...
I agree with Hendrik's comments above.
This is a pretty geeky subject that has questionable benefits for most users and use cases. I don't believe RD James' comments are accurate. The cause of the crash is probably unrelated. The limits of a 32 bit process are 2GB or, in some cases 4GB. That's a lot of room to polka.
I would not expect it to be faster, except for some math operations, and these should be very rare. It would result in larger code and bigger download sizes.
It would also mean confusion since we would have to build, maintain, and offer for download two different versions -- a 32 bit version for compatibility with older hardware, and a 64 bit version for newer. People would sometimes download the wrong one and then wonder why it didn't work. We see this now with people trying to use 64 bit VST plug-ins with a 32 bit version of MC.
And ... all this work would be required would probably result in no increase in revenue ... unless we raised the price.
-
There is definitely performance improvements to be had, video decoding is nothing but math, and some formats have shown to decode almost twice as fast, including the new HEVC video codec thats being used for 4K on UHD Blu-ray discs and future broadcast standards. 4K video decoding is quite problematic in 32-bit due to those speed differences alone.
-
I don't know RD James' hardware. I think its a difference if one uses iGPU or dGPU for 4k videoplay. With my NVidia Card video memory grows for some 4k videos playing through ROHQ >4GB Memory. RAM used by CPU is typically near 2 GB. 4k video playback is really stable at my side.
I don't know what happens if one uses Intel iGPU for 4k with HDMI2.0b (RAM and Video Ram are shared!). The NUC with i7-7567U and Intel® Iris™ Plus Graphics 650 (video passmark ~1800) should be capable to this. Maybe the 32 bit implementation plays than a role?
-
I wonder what percentage of the windows user base is using a 32bit only cpu or OS. Any idea?
-
I wonder what percentage of the windows user base is using a 32bit only cpu or OS. Any idea?
A quick Google search wasn't illuminating. However, Apple is phasing out 32 bit applications entirely:
https://www.macrumors.com/2017/06/06/apple-to-phase-out-32-bit-mac-apps/
Microsoft wishes it could. They have been shipping a 64-bit OS including device drivers since 2007.
When I install a new 32-bit application, I have a stereotyped mental image of it probably being an orphan, with future development probably unlikely.
-
Even if it's only 5 or 10%, it will cause us problems. We will either have to say "no more 32 bit" or we'll need to provide two versions and provide support for people who make the wrong choice.
-
FWIW, a handful of linux distros are phasing out native 32-bit support entirely (while keeping some libraries around as a compatability layer). The last general purpose 32-bit only x86 processors intel shipped were 8 or 10 years ago. There's a still a fair bit of 32-bit presence in the ARM market, but that's an entirely separate question. Personally, if I had ten year old hardware that was no longer supported, I'd be vexed, but not surprised. I can understand not wanting to leave users behind though.
If multiple builds are desirable, one way other software companies handle it is to have the installer be a stub that programmatically identifies what the system supports and then downloads the correct build. Once the build is in place it can just upgrade itself along the correct path. Setting up such an installer is not free, but it's almost certainly less work than dealing with the support hassle. TL;DR I'm not sure supporting both architectures necessarily requires an increased support burden if you take the user entirely out of the build selection process.
-
I am no part of the company, but my suggestion would be to drop 32-bit support completely. If 32-bit is needed one can use an older client, like v23. However I do understand that people using older clients means no sale, so it might not be the best financial choice. But 4K is coming.
-
SVP probably refers to this: https://www.svp-team.com/wiki/Main_Page
Yes, Smooth Video Project, not Sony VEGAS Pro.
This is a pretty geeky subject that has questionable benefits for most users and use cases. I don't believe RD James' comments are accurate. The cause of the crash is probably unrelated. The limits of a 32 bit process are 2GB or, in some cases 4GB. That's a lot of room to polka.
That's not a lot of memory for high resolution or high framerate video playback.
If all you play is 1080p24 it's not a concern.
8K60 videos require about 6-8GB RAM.
4K playback with SVP (100 FPS) requires about 4-5GB RAM.
Without SVP, and just with madVR running, the buffer size has to be reduced to very low settings to prevent JRiver crashing, which makes it likely for playback to drop frames.
With SVP enabled, which I have interpolating videos to 100 FPS, 4K videos crash JRiver instantly regardless of buffer size.
You can watch the memory usage climb as the buffers are filled and then it crashes.
The problem is not specific to JRiver - it's a problem for all 32-bit video players.
If I use the 32-bit version of MPC-HC it crashes when filling up the buffers too - just like JRiver.
If I switch to the 64-bit version of MPC-HC, playback is completely stable.
A 64-bit video player is required to prevent this.
I don't know RD James' hardware. I think its a difference if one uses iGPU or dGPU for 4k videoplay. With my NVidia Card video memory grows for some 4k videos playing through ROHQ >4GB Memory. RAM used by CPU is typically near 2 GB. 4k video playback is really stable at my side.
I don't know what happens if one uses Intel iGPU for 4k with HDMI2.0b (RAM and Video Ram are shared!). The NUC with i7-7567U and Intel® Iris™ Plus Graphics 650 (video passmark ~1800) should be capable to this. Maybe the 32 bit implementation plays than a role?
I have a Ryzen 1700X with 32GB of ECC memory and a GTX 1070.
It's memory that the JRiver process is using, I've not been monitoring VRAM.
-
Please try without SVP and let us know whether you still have crashes.
-
While I'm not fussed either way, I tend to agree with the comments re there not having been a 32bit processor released now for donkey's years, and therefore if someone IS still running one of those, they can stick with v23. While I understand that may reduce your pool of potential repeat clients, I can't see that being by too many. Do you guys collect anonymous stats about OS environment etc. from us users? If not, perhaps a poll might provide some clarity (if that's what you're concerned about).
-
64-bit: The question is for me is more when you would move to 64 bit? At a certain time in the future market pressure and outgoing support for 32 bit will lead to 64-bit. Two examples: Roon already supports 64 bit as well as Kodi ....
In such situations (switching from an "old" architecture to a "new" one) there will always be people who are not satisfied (I must invest in more RAM, new CPU...). It is not an easy decision. Similar discussion is Win XP and to move to Win 10.
-
Personally, I'd replace the 32-bit build with the 64-bit build BUT offer 32-bit updates (to the stable channel only) every month or so for MC23 until MC24 or 25, then phase it out.
But yeah, 64-bit builds would be most welcome (for me being able to load entire albums into 4+ GB memory). Although, I do see how offering both 32-bit and 64-bit builds for Windows would increase build time.
Otherwise, can't both 32-bit and 64-bit binaries be combined within the same installer, which gives the user a choice on which one to install?
-
Please try without SVP and let us know whether you still have crashes.
Like I said, 4K60 videos still crash unless I reduce madVR to small queue sizes.
Videos are unwatchable on a monitor for me without SVP though, since only televisions have interpolation built in to smooth out playback.
Again: these crashes are 100% caused by the memory restrictions on 32-bit players, it's not that SVP is crashing.
-
With ROHQ and no other modifications, does it work?
-
With ROHQ and no other modifications, does it work?
I have to reduce the queue sizes in madVR.
Things like multi-zone playback, or running auto-import or the audio analyzer during playback can also cause JRiver to crash.
-
Is that a yes or a no?
-
Is that a yes or a no?
It's a no.
-
Just to confirm, with the stock ROHQ, using the stock madVR, no SVP, and no other activity, MC still crashes?
-
A few gigabytes of memory really isn't much if you start to deal with high resolution video, like 4K 10bit content. Stuff just adds up, the file reader needs a couple hundred megabytes, the video decoder alone can use almost a gigabyte on such content, then the renderer needs some more, and you hit the limits. It doesn't happen everytime or fully reproducibly, but any background processing like MC importing new videos or generating thumbnails can greatly increase the chances of it happening as well.
If you run out of memory, at best it'll stop functioning, at worst crash. In very few situations you have any hope of recovering from that.
Add to that the drastic performance improvements in video decoding in 64-bit, and its not something to just dismiss. We'll have to figure out how to do it, and it may take some time, but we definitely have to do that to bring MC into the 4K age. Just like Winter, 4K is coming. Most video advancements in the last years seem like "fads", but increase in resolution is not something thats going away.
-
Thank you Hendrik.
I understand that it will take time, but I'm glad that you realize this is going to be a necessary change for JRiver to continue supporting new video formats.
PC is starting to fall behind with video playback these days, but there's still a lot of 4K60 media being published on YouTube, and some channels are starting to upload 8K video.
If you use youtube-dl (https://rg3.github.io/youtube-dl/), this is a good sample for 8K60 playback: https://www.youtube.com/watch?v=1La4QzGeaaQ
Surprisingly, it seems to require DXVA Native decoding to play smoothly, not Copy-Back. At that resolution, the overhead for copy-back must be too much.
I recommend using Edge if you want to view it in a browser and your GPU supports 8K decoding. Chrome/Firefox won't play it smoothly for me.
-
RD James,
Could you comment?
Just to confirm, with the stock ROHQ, using the stock madVR, no SVP, and no other activity, MC still crashes?
-
RD James,
Could you comment?
It still crashes.
-
Could you get a log? Thanks.
-
Could you get a log? Thanks.
Doesn't appear to show much, since the program just disappears when it goes over the 32-bit memory limit, it doesn't crash with the standard Windows dialog box.
-
Could you post it?
-
I did some testing with the Peru video on Youtube, which was mentioned by RD James
https://www.youtube.com/watch?v=1La4QzGeaaQ (https://www.youtube.com/watch?v=1La4QzGeaaQ)
4k Version
- Plays on my PC with i7 and GTX 1070,3k LG PC Monitor and on my HTPC with i3 and GTX 960 and LG 4k TV without problems, if in Edge or if I download the video and play it then through MC - no problems
8k Version
- Plays on my PC in Edge without problems
- Can't play it in Firefox
- If I download the video and play it then through MC CPU utilization gets 100% if i7 or i3 (HTPC | HDMR passthrough through 4K LG TV) - memory utilization is about 5-6 GB - it does not crash but does not play smoothly.
Playing the 4k Version CPU utilization is <12%, the GPU's are in no stress - the fan's even spin.
I think something with the decoding does not work with the 8k video.
-
Addon to my previous message:
100% CPU Utilization does not depend if I choose RO Standard or ROHQ. Its for both the same.
-
if I download the video and play it then through MC - no problems
Are you downloading with youtube-dl, or via JRiver?
It's been years since I used JRiver to download anything now, but if I remember correclty, it does not download anything higher resolution than 1080p.
Whether it's 30/60 FPS, and the madVR scaling/processing options used may also affect this. (all affects memory usage)
- If I download the video and play it then through MC CPU utilization gets 100% if i7 or i3 (HTPC | HDMR passthrough through 4K LG TV) - memory utilization is about 5-6 GB - it does not crash but does not play smoothly.
Playing the 4k Version CPU utilization is <12%, the GPU's are in no stress - the fan's even spin.
I think something with the decoding does not work with the 8k video.
1. You say that "memory utilization is about 5-6GB". What memory utilization is that? For the JRiver process, or VRAM?
As soon as JRiver approaches 3GB it crashes for me.
2. All of a sudden, LAV Video is not using hardware acceleration for 4K or 8K videos for me now. I'm not sure what changed but it's now using avcodec instead of DXVA.
What worked before was to register LAV Video using an elevated command prompt window, and then use custom video mode settings in JRiver with LAV Video Decoder selected.
RegSvr32 "%APPDATA%\J River\Media Center 23\Plugins\lav\LAVVideo.ax"
With the decoder registered, you were able to open the LAV Video Decoder properties inside JRiver and select "DXVA2 (native)" as the hardware decoder.
JRiver uses "DXVA2 (Copy-Back)" by default, which is too slow for 8K video.
Your CPU will not be able to decode it quickly enough to fill up madVR's buffers and cause JRiver to crash.
But since something broke hardware-accelerated 8K playback in LAV Video for me, I can't play 8K videos at all now.
Still plays smoothly in Edge.
-
1. Downloaded the video via 4k Video Downloader
2. Memory Utilization is Total RAM Utilization in Windows Taskmanager , when playing the stored 8k video through MC
I tested it again - the MC process consumes ~2.7 GB on my PC. Downscaling from 7680x4320 ->3000,1440. madVR says no frame drops but rendering time is ~59 ms!-> slow motion, but it does not crash.
I have turned on hardware acceleration in MC and I use Jinc + AR for chroma up scaling and Lanzos 3 + AR for image up scaling and CR+AR for image downscaling if using madVR.
Compared to playing the 4k version the CPU utilization goes to 100% if playing the 8k version on a 3k or 4k display.
If I set hardware acceleration off, it makes no difference playing the 8k version. Using DXVA2 makes also only a minor difference. CPU if i3 or i7 still at 98%.
-
Serious question: What's the idea of playing 8k video? Do you have a display of some sort that can show 8k worth of resolution? Or is this more like playing with the next big thing that might be viable on a real display in 2 to 5 years?
Brian.
-
If I had to guess, playing 8K back (e.g. downscaled) to 4K or 1080p probably looks rather good. Kinda like some 4K YouTube videos downscaled to 1080p looks pretty nice.
-
Dell released an 8K monitor a few months ago, and high-end televisions will be going 8K in the next 6-18 months. The goal in Japan/Europe is to be broadcasting 8K by the 2020 Olympics.
8K downsampled is much higher quality than anything else streaming on the web right now.
It's not perfect, but is much closer in quality to what you get from disc-based media.
I wish I knew what changed that has stopped hardware acceleration working for 8K videos with LAV Video now though.
I can only think that it's something relating to a Windows Update, as I've downgraded video drivers and LAV versions and it's still using avcodec (CPU) instead of dxva2n (GPU) for decoding.
CUVID enables hardware acceleration with vp9 but not avc1 encoded videos, however it is too slow to play them back smoothly - just like dxva2cb.
Playback still works in Edge though.
I tested it again - the MC process consumes ~2.7 GB on my PC. Downscaling from 7680x4320 ->3000,1440. madVR says no frame drops but rendering time is ~59 ms!-> slow motion, but it does not crash.
Until hardware acceleration is fixed, it won't be crashing because your system (or virtually any system) is not fast enough to decode enough frames into memory to cause it to go over 3GB RAM and crash - which is why it's playing in slow motion.