INTERACT FORUM
More => Old Versions => JRiver Media Center 29 for Windows => Topic started by: Hendrik on November 16, 2021, 07:10:42 am
-
JRVR, or JRiver Video Renderer, is our new in-house cross-platform video renderer, being developed as part of MC28, and on-going development in MC29.
In this thread, we'll discuss the current status, future plans, and announce upcoming changes.
For general information and feedback, see the announcement thread: https://yabb.jriver.com/interact/index.php/topic,130657.0.html
We'll keep this thread up-to-date as well as announce upcoming changes here, so you can keep an eye on the status of JRVR!
Status
Not all features are available, and everything is still subject to change as we develop it further. However, it is already in a quite usable state, and we encourage testing and reporting the experiences.
JRVR is available on Windows, Linux and Mac. On Linux and Mac it is already the default renderer, on Windows you can opt into using it in Options -> Video -> Video Mode: Red October JRVR
Available Features:
- High Quality Upscaling/Downscaling
- Various scaling algorithms can be selected through the settings
- Linear Light or Sigmoidal Light scaling for the highest quality
- Advanced Scaling filters (image doubling)
- SuperRes enhancement (post-processing to remove the artifacts from upscaling)
- Accurate color processing
- HDR to SDR tonemapping, for HDR10 and HLG
- HDR Passthrough
- High bitdepth processing, and dithering to the final output bitdepth
- Subtitle support, with color correction
- DVD and Blu-ray Menu support (Windows only)
- Hardware Decoding integration (Windows only)
- Playback of Rotated videos
- Color calibration through ICC profiles, and 3DLUTs
- Image post-processing options
- Debanding
JRVR is designed as a cross-platform video renderer, which means that we aim to offer as many features as possible to all supported platforms.
However, JRVR is only the video renderer, and more work is required to add missing features to the video ecosystem on Linux and Mac, so not all features will immediately be available everywhere - but with JRVR we're laying a foundation to enable us to add these features in the future.
Plans
Upcoming Features:
- Hardware Decoding integration for Linux and Mac
We are of course also open to hearing about suggestions for other features, as long as they fit into the scope and design of JRVR.
The goal is to provide a curated selection of high-quality video features, while keeping JRVR easy to use ("It just works!"), as well as keeping the core functionality efficient to enable playback on slower hardware.
----
We welcome discussions on upcoming changes and our plans!
For general feedback, help, or questions, please either create a new topic, or use the main JRVR topic at https://yabb.jriver.com/interact/index.php/topic,130657.0.html
-
Recent and Upcoming Changes
29.0.48
- NEW: "Screen Grab to File" and "Use Screen Grab for Thumbnail" are supported with JRVR.
29.0.46
- Changed: Re-designed the JRVR General and Output options pages to be more user friendly.
- Changed: Adjusted the default for HDR to SDR conversion brightness.
29.0.40
- NEW: Added support for manual color controls to JRVR (Brightness, Contrast, Hue, Saturation).
29.0.39
- Changed: JRVR Output settings are now per-display, existing settings have been migrated.
- NEW: JRVR support for color calibration using ICC/ICM profiles and 3D Cube LUTs (.cube).
- Changed: Tweaked JRVR SuperRes Enhancement for a better balance of sharpness and ringing.
29.0.29
- Fixed: The D3D11 hardware deinterlacing in JRVR is fully reset when seeking or changing to progressive, to avoid artifacts.
- Fixed: Seeking with JRVR would blank out the frame before the new frame was available, for a visible blinking effect.
- Changed: The JRVR OSD shows the Media Center version for easy identification.
29.0.28
- Fixed: The default video playback mode was set to Advanced in some cases instead of Red October JRVR in 29.0.26.
29.0.26
- Fixed: Playing a Blu-ray with VC-1 video in Menu mode could result in stuttering playback.
- Changed: Red October JRVR is now the default recommended video playback mode (in favor of Red October Standard).
- Changed: Renamed Red October HQ to "Red October madVR" to clearly indicate the difference in renderer used.
29.0.24
- Fixed: Improved DVD Menu behavior in JRVR when the menu consists of still frames.
29.0.23
- Fixed: Mixed interlaced and progressive content could show a few frames out of order at the cross-over with JRVR.
- Fixed: JRVR will allow rendering the OSD even when no image from the source has arrived yet.
29.0.21
- Changed: Variable Refresh Rate/GSYNC will be disabled for Media Center on NVIDIA GPUs by creating a custom profile on first video playback.
29.0.20
- Fixed: Improved the consistency of text subtitle placement with JRVR.
29.0.18
- Changed: Updated libplacebo in JRVR for improved tonemapping, dithering, and various performance, stability and compatibility fixes.
- Changed: Moved and reworded the "Gamut Handling" JRVR setting to better reflect that it is going to be used for SDR as well, as well as adding a new default setting.
- Changed: Introduced a set of Trade Quality for Performance options in JRVR to limit the bitdepth of frame buffers and disable the use of frame buffers entirely for very low end systems (not recommended otherwise).
29.0.17
- NEW: Re-designed ASS/SSA subtitle renderer for JRVR for significant performance improvements.
- NEW: Ctrl-R will reset the JRVR performance metrics.
29.0.14
- NEW: Support for playback of rotated videos in JRVR.
- Changed: Updated LAV Filters to 0.76.1, fixing an issue with hardware acceleration in JRVR on Intel GPUs, and improving integration of DVD menus with JRVR.
29.0.10
- Changed: Bitmap subtitles in JRVR will now be rendered at their original resolution and resized by JRVR (faster!).
- Fixed: HDR subtitles and menus from UHD BDs are now properly tonemapped in JRVR.
- Changed: Text subtitles with JRVR will more consistently make use of black bars to display, if present.
29.0.9
- Fixed: Subtitles in JRVR could stop working after seeking backwards.
- Changed: Subtitles in JRVR are now handled in small rectangles, instead of the full frame, for faster rendering.
29.0.8
- Changed: Internal changes how JRVR handles subtitles (faster!)
- Fixed: JRVR is more lenient when dealing with files with invalid HDR metadata.
- Fixed: JRVR would not toggle the OS HDR mode when playing HLG or DV HDR content with pass-through enabled.
29.0.2
- Fixed: Enabling direct mismatched size rendering in JRVR could result in a larger border then expected.
- Changed: Disabled JRVR Peak Detection by default due to its performance cost and potential for brightness shifts, and moved the option into the Advanced section.
29.0.1
- NEW: Enabled Ctrl-J JRVR functionality in TV engine and non-DirectShow JR Video Player (on Windows, Mac, and Linux).
- NEW: JRVR support for Dolby Vision playback (non-passthrough).
- Changed: Re-designed JRVR HDR tone mapping and related options.
- NEW: DVD playback with JRVR will now use hardware deinterlacing.
- NEW: Added a JRVR performance option to avoid extraneous frame copies for systems with low memory bandwidth.
- NEW: Playing HLG HDR content with JRVR can now be transformed to HDR10 for pass-through.
- NEW: JRVR now caches shaders between runs, for faster subsequent startups.
=== Media Center 28 ===
28.0.93
- Fixed: Resolved an issue that could result in not all JRVR settings being saved consistently when interacting with the settings dialog.
28.0.92
- NEW: JRVR will show rendering performance metrics on the Info OSD (Ctrl-J).
- NEW: Chroma upscaling in JRVR can be enhanced by using Bilateral scaling (Chroma upscaling guided by Luma).
- NEW: Image upscaling in JRVR can use advanced Image Doubling algorithms for enhanced quality when playing low resolution videos.
28.0.91
- Fixed: JRVR could crash when using SuperRes in combination with Hardware Decoding.
- Fixed: External subtitles did not start rendering with JRVR in all cases.
28.0.90
- Changed: Introduced more advanced options for JRVR to control dithering and a few performance related options.
- NEW: Implemented SuperRes Enhancement for upscaling with JRVR. SuperRes refines the image after upscaling for more sharpness and reduced artifacts.
28.0.89
- Fixed: JRVR in combination with hardware decoding could show a faint bright line at the bottom of the image in certain resolutions.
28.0.88:
- Fixed: Hardware deinterlacing in JRVR in combination with hardware decoding could result in a green line artifact on some videos.
28.0.87:
- Fixed: Subtitles could boost the overall image brightness in JRVR when using HDR pass-through.
- Changed: The JRVR information OSD is scaled by the Media Center size setting.
- Changed: Lowered the brightness of subtitles when using HDR pass-through with JRVR to be more consistent with SDR content, as well as improve the color reproduction.
28.0.86:
- NEW: HDR10 pass-through with Red October JRVR (Windows and Linux with Vulkan).
- NEW: Support for 10-bit output with Red October JRVR (Windows only).
- NEW: Added an information on-screen display to JRVR (Ctrl-J to toggle).
- NEW: Support for Frame-Stepping (Shift-Right Arrow in Pause) with Red October JRVR (Windows only).
28.0.85
- Fixed: Blu-ray Menu playback with JRVR could get stuck or end prematurely.
28.0.84
- Changed: JRVR will report the actual screen refresh rate to VideoClock for more accurate timing adjustments. (Windows Only)
- NEW: The Playback OSD is rendered natively with JRVR. (Windows Only)
- NEW: Support for Blu-ray Menu playback with JRVR. (Windows Only)
OSD rendering will come to Linux/Mac in a future update.
28.0.83
- Changed: Improved timeout in JRVR when detecting rendering glitches to allow a more graceful recovery.
28.0.82
- NEW: Support for DVD playback with Red October JRVR. (Windows Only)
- Changed: Improved JRVR timing accuracy when using NTSC-style display refresh rates (eg. 23.976 Hz).
-
jmone said it well:
1) A great cross platform Renderer,
2) with the key features, and
3) without needing to delve into hundreds of options.
and I added:
And efficient, so it runs on low end machines.
-
From the other thread
* Some form of profile system for settings as per https://yabb.jriver.com/interact/index.php/topic,130905.msg908443.html#msg908443 which potentially allows for per client configuration in conjunction with per library item configuration
* Support for scaling for use with anamorphic lens as per the posts following https://yabb.jriver.com/interact/index.php/topic,130905.msg907932.html#msg907932 (also needs to be client specific)
-
* Support for scaling for use with anamorphic lens as per the posts following https://yabb.jriver.com/interact/index.php/topic,130905.msg907932.html#msg907932 (also needs to be client specific)
I'm pretty sure you can already do this with the scaling and pan&scan support we have now. But then I have no idea whats required for anamorphic lenses, since I never owned one, and possibly never will.
It would be important to distinguish here if some sort of scaling configuration is still missing, or "just" the ability to set this up on a per-screen basis - if that is even required, which it might not be with the right settings.
-
I'm pretty sure you can already do this with the scaling and pan&scan support we have now. But then I have no idea whats required for anamorphic lenses, since I never owned one, and possibly never will.
It would be important to distinguish here if some sort of scaling configuration is still missing, or "just" the ability to set this up on a per-screen basis - if that is even required, which it might not be with the right settings.
madvr applies a custom stretch factor as per https://yabb.jriver.com/interact/index.php?topic=124128.0 used in conjunction with its zoom control to deal with black bars. In my case, I have a 1.33x horizontal expansion lens so use a 4/3 stretch factor so the renderer stretches it in one direction then my lens stretches it on the other. Stretch factor has to be configurable because lens can have different ratios and also come in vertical compression form (more common recently with 4k 17:9 panels)
The madvr configuration options are described in more detail in https://forum.kodi.tv/showthread.php?tid=259188&pid=2238958#pid2238958
As far as I understand it, the gaps atm are:
* per client configuration (i.e. in a multi client setup, it's highly likely that only 1 will have a lens)
* custom (stretch) scaling which is user configurable
The user experience gap, which I think can be plugged by @jmone's SOT app, is automated black bar detection
I'll get time to verify the above at some point soon.
-
Can I request:
1. chapter listings for MKV files. My previous player MPC-BE had this.
2. Overlay of video data to help with debugging and settings (Dropped frames etc)
-
As some news for the weekend, HDR pass-through is coming along nicely.
JRVR can already pass-through the HDR signal and the appropriate metadata to the display, even confirmed correct metadata is arriving with the help of a HDFury Arcana.
The only missing piece is toggling HDR mode for those of us that are not running it permanently yet, but hopefully that'll come together for the next build early next week!
One interesting thing I noticed, if you send a HDR signal to Windows without having a HDR display (or HDR mode enabled), it'll actually tonemap it. It does an "OK" job at it, although JRVR tonemapping looks better to me. :)
In combination with this will come the ability to output using 10-bit, which is always used if available for HDR, and I plan to add an advanced option to enable or disable it for SDR, as in the past there were some issues with 10-bit output, so testing it would probably be good.
-
Sounds great!
-
I split the performance question from whoareyou to here: https://yabb.jriver.com/interact/index.php/topic,131274.0.html
If you have specific questions on your setup, or bugs, please either use the main announcement thread or just create a new one, so that we can keep this thread to discuss the plans, changes and features.
-
Hi,
I just tried it and got a black screen, no video. So first question: Does it work with Windows 7 at all?
-
We don't generally test with Windows 7 any longer, since it's out of support by Microsoft and will no longer receive future updates.
What I would recommend to test would be disabling hardware accelerated decoding, because I know for sure that won't work on Windows 7.
Otherwise, open a new thread and attach logs (individual support should be kept out of these central threads), maybe we can see something simple and obvious. But there are no guarantees that it will work on 7.
-
Thanks, Hendrik.
I disabled Hardware Acceleration when possible (which was on) and restarted the computer (which I hadn't done since installing 28) but it didn't work. Will make a new thread. :)
-
28.0.86 is coming soon with quite a bunch of JRVR changes
NEW: HDR10 pass-through with Red October JRVR.
NEW: Support for 10-bit output with Red October JRVR.
You can now pass-through HDR10 on Windows (and theoretically on Linux when using Vulkan, but its harder to test). JRVR will pass both the original HDR10 data (converted to RGB, naturally), as well as the HDR10 metadata to your TV, so hopefully we'll get accurate HDR10 rendering.
HDR10 pass-through is only available if the HDR option in Windows is enabled. To make that process easier, there is a separate option available to toggle Windows HDR when playing a HDR file.
That process is not quite seamless, and can feel as disruptive as changing the resolution, hence it needs to be explicitly enabled. If you are on Windows 11 already, it might be easier to keep it enabled at all times and tweak the SDR to HDR conversion to your liking, if possible.
To make HDR10 work properly, JRVR now also supports 10-bit output on Windows, which can also be enabled for SDR. We may automate that in the future if we can either figure out that your display is actually 10-bit, or we let you configure the display bit depth, but for now you can enable 10-bit SDR in the Advanced settings.
How do you know if 10-bit output is on and working, or HDR pass-through is on?
NEW: Added an information on-screen display to JRVR (Ctrl-J to toggle).
You can now press Ctrl-J to show an information display on the video, which shows video properties, as well as the output mode. Performance metrics are not currently included (queue size, renderering time), as we first need to implement measuring them. Note that Ctrl-J is not a "global" hotkey, and if its not working, make sure you focus the video window, for example by clicking onto it.
And finally, to also help testing and comparison, forwards frame-stepping is now supported in JRVR.
NEW: Support for Frame-Stepping (Shift-Right Arrow in Pause) with Red October JRVR.
Note that this update includes a big change to the internal architecture and some dependencies, so please keep an eye out for any new breakage, so we can deal with it!
-
Nice! So HDR on Linux could also possibly work. That's great news.
ctrl-j is used to check new MC version. Is it now changed or does it still do both? As MadVR also uses ctrl-j for OSD maybe it would make sense to change update check to some other shortcut
-
Yes, HDR pass-through on Linux should "theoretically" work, in practice that may be another can of worms. We'll work on Linux-specific improvements and more thorough testing and tweaking as development progresses, for now all I know is that we instruct Vulkan to render in HDR as well as pass the metadata. How this integrates with the compositor or X11 on Linux, we'll have to figure out, I suppose. I'm being told X11 and HDR won't cooperate. So maybe Wayland or DRM (Direct Rendering) might be required. Linux is unfortunately a bit behind on the video front here, and this can get complicated fast.
-
Nice! So HDR on Linux could also possibly work. That's great news.
ctrl-j is used to check new MC version. Is it now changed or does it still do both? As MadVR also uses ctrl-j for OSD maybe it would make sense to change update check to some other shortcut
We've used ctrl-j for updates since before madVR existed. We're not going to change that. It works with madVR when the madVR display is up.
-
V86 looks good so far (just a quick 5 min test) with HDR passthrough and OSD info. Will test tonight and post in the testing thread. Will be interesting to see how the NUCs go in this mode
-
Build 86 added the following:
NEW: HDR10 pass-through with Red October JRVR.
NEW: Support for 10-bit output with Red October JRVR.
NEW: Added an information on-screen display to JRVR (Ctrl-J to toggle).
NEW: Support for Frame-Stepping (Shift-Right Arrow in Pause) with Red October JRVR.
It's at the top of this board.
-
Coming in Build 90, we implemented SuperRes Enhancement, a filter to refine the image after upscaling, which increases sharpness and reduces scaling artifacts, like ringing or aliasing.
While the filter can feel rather subtle, it definitely helps to produce a sharper image, and is the first custom shader we're using, so it also serves as a test for other custom shaders in the future, primarily more advanced scaling implementations.
-
JR is much stronger now! and when JRVR gets all the goodies will be become unstoppable!
-
In build 92, JRVR will introduce support for more advanced scaling algorithms. These are specialized in scope, and can only apply to either the Luma (brightness) or Chroma (color) channel of video, as well as only exactly double the resolution. Hence, they are also often referred to as Image Doublers, or sometimes pre-scalers, as they come before the final scaling to the target resolution.
For Luma, we are introducing 2 new algorithms:
- RAVU (Rapid and Accurate Video Upscaling), a balanced image scaler with decent performance, especially on modern GPUs which support Compute. This is a safe default most people with any dedicated graphics card can likely run, and it produces quite good results.
- FSRCNNX, in an 8 neuron and 16 neuron configuration. "Fast Super-Resolution Convolutional Neural Network" is an advanced scaler based on a deep neural network, which rivals other state-of-the-art upscaling algorithms. Of course quality comes at a cost, and running FSRCNNX requires rather good hardware - especially the 16 neuron variant.
It should be noted that SuperRes introduced in build 90 is a strong contender in this field as well. SuperRes combined with Jinc or Lanczos comes very close to the quality of RAVU, while being more flexible.
For Chroma, we now support a specialized Chroma scaler, Bilateral scaling. Bilateral uses the Luma information as a guide to upscale the Chroma signal, which works especially well for relatively clean sources, like any high-quality video.
Since practically every video we watch requires Chroma upscaling, this algorithm should not be ignored, even if Chroma has overall a smaller impact on the image quality.
To properly judge the performance with these new algorithms, the Ctrl-J Info OSD will now show performance metrics on the rendering performance. Do note however that metrics measured in runtime are not 100% fool proof, as graphics cards like to change their speed dynamically to match the workload given, so we recommend to keep that in mind when evaluating this new information.
These enhancements bring us ever closer to our goals of high image quality and state of the art features, and proper scalability from low-end to high-end hardware, with new algorithms now that can make use of your hardware if you have it - but of course all optional at no extra performance cost to those who don't.
By default, none of these new algorithms are activated, so check them out in the JRVR settings! For anyone feeling overwhelmed by the JRVR settings already, do not fear, we are thinking of you. As a first step, we plan to introduce performance presets which let you select a set of pre-selected settings on a range of Quality vs Speed to match to your hardware, without needing to dig into a dozen or so settings. But its important that we introduce many of the settings first that would be driven by these presets, so hang on for a bit longer!
We're also working on a JRVR support page on the wiki to explain the options in more detail, more on that soon!
-
sounds awsome! cant wait to test it out!!!!!!!
-
These are really great news. Wow. Thanks, Hendrik, for all the work :) This'll be interesting to test. Maybe, I finally give JRVR a test drive once that new build is out for the public. Cool 8)
-
28.0.92 is available now: https://yabb.jriver.com/interact/index.php/topic,131406.0.html
-
28.0.92 is available now: https://yabb.jriver.com/interact/index.php/topic,131406.0.html
Cool, thanks :) Installed! Testing is planned to start tomorrow! Just briefly browsed through the options and started a DVD to check it's working (and it is).
@Hendrik:
Is there a way to reset the statistics in the JRVR overlay (CTRL+J), like in madVR (I think it was CTRL+R that did the reset)? I forgot to test that before switching off the machine, but will look into that tomorrow too.
Everything else will be posted in the JRVR testing thread of course.
-
When using JRVR, the Color Controls are disabled - is this expected behaviour?
If I switch to Standard or HQ, I can use the controls the usual way.
-
Wondering when playback of rotated videos will be included in JRVR.
Thanks.
-
I have updated the JRVR changes in the second post in this thread with all changes from MC29, to provide a full list of changes specifically for JRVR. Since the release of MC29 we've been focused on polishing and fixing reported glitches, but new features are on their way. The next topic we plan to address is calibration with ICC profiles and/or 3DLUTs.
To answer the last few posts in this thread:
- Ctrl-R is now supported to reset statistics
- Rotated videos are now supported
- Color Controls are not currently supported, but we'll look into adding those in a future update
-
The next topic we plan to address is calibration with ICC profiles and/or 3DLUTs.
Excellent! ;D
-
Are there any plans to tonemap/re-encode DV videos for remotes to get correct colors also over MCWS?
-
In the next JRVR update, output settings are moving to a per-display basis, as that makes a lot more sense when you are configuring settings that reflect the properties of a screen, and not performance or quality.
In that process, I ended up with an empty title screen above the possible outputs, and a thought was to include some rough hints on the most major output settings.
(https://i.imgur.com/F3hRP90.jpg)
Let me know what you think, or if I should change some of the text in some manner. Explaining something you know by heart in a short sequence is always tricky.
Are there any plans to tonemap/re-encode DV videos for remotes to get correct colors also over MCWS?
Perhaps in the future, there are quite some challenges there, but thats not a JRVR topic.
-
Nice work. I think it is pretty clear.
Is it possible to make "Enable OS HDR Support when playing HDR10" a link to a wiki page or even an outside page? A nice guide on how to do it might reduce questions and confusion. A link to a good Youtube video might be the best.
-
Work on improving/simplifying the options dialog continues, here is the new "General" page, as well as the re-done Output page (with advanced mode disabled)
(https://i.imgur.com/CorcuYS.jpg)
(https://i.imgur.com/2FHKZHD.jpg)
Generally, I tried to hide options that are not required for basic usage, leaving only those important enough for most people to touch.
Advanced Mode will generally show those options which existed before that are currently hidden, as well as possibly convert some options for more control - eg. the brightness slider will turn into a textbox.
I debated with myself to hide Calibration entirely under advanced, however I would like ICC profiles to be applied by default, and if that is unexpected for someone, having the option right there to disable it seems important.
PS:
The Presets on the General page will be implemented in a follow-up build, but I wanted to get the options in to give that page its full design.
PPS:
The brightness slider currently goes from 80 to 400, which seemed like a good default brightness range for HDR to SDR tonemapping to me. Feel free to comment if the range should be increased - but also remember that in advanced mode its a textbox like before.
-
WOW - that looks terrific! Not only nicely laid out but is so much more accessible. Also a good description of the functions.
I love how you have automatically determined if the screen is both HDR capable and if it is already in HDR Mode, a couple of suggestions
- if the screen is NOT HDR capable, should the two HDR options below it be greyed out?
- if Use the display's HDR capability for HDR videos is Unchecked, should the "Automatically switch to HDR mode..." be greyed out.
Also like the look of Quality Presents as this will cover most cases yet still have advanced for twiddling.
Keeping ICC profiles outside advanced makes sense.
That range for the SDR brightness slider should be OK... there might be some PJ's under 80, but I doubt there are many (if any) SDR screens hitting 400. I presume under advanced, you can type in any value.
-
I love how you have automatically determined if the screen is both HDR capable and if it is already in HDR Mode, a couple of suggestions
- if the screen is NOT HDR capable, should the two HDR options below it be greyed out?
- if Use the display's HDR capability for HDR videos is Unchecked, should the "Automatically switch to HDR mode..." be greyed out.
1) No, I don't want to entirely rely on the detection to lock out the option
2) Yes, I think thats how it works right now as well
-
I think a number of older PJs would be under 80, perhaps take it down to 40 or 50?
-
1) No, I don't want to entirely rely on the detection to lock out the option
2) Yes, I think thats how it works right now as well
1) OK, Makes sense
2) In the screen shot, "Use the display's HDR capability for HDR videos" is Unchecked but "Automatically switch to HDR mode..." is not greyed out (and is checked)? Should it not be greyed out?
-
I think a number of older PJs would be under 80, perhaps take it down to 40 or 50?
That's correct. My epson Laser pj has only 55 nits. So this would be good if the scale would begin at around 50 nits.
-
I changed the scale to start at 60. You probably don't want to actually set it that low even on a low-brightness projector, as it really starts crushing even normal bright details to limit the brightness range, instead leave it a bit higher and give up shadow details.
Advanced Mode lets you input an actual number though, down to 10, at which the image looks really broken.
-
As the initially planned list of features is near completion, here is your chance to talk about what features you would like to see next.
Major points that have been discussed before:
- Profiles are still a consideration, although with the simplified options and general efficiency, it feels like its less mandatory. Happy to take opinions and use-cases on that to influence the design of the solution here.
- Projector-specific improvements? I'm not a projector owner, so if you are one of those, some detailed requirements would be nice.
- Anything we entirely missed so far?
Let us know, so we can plan ahead for the next bigger features we work on.
Please note, this is specifically about JRVR, that is video rendering only. General playback issues should be adressed in their own threads.
-
As the initially planned list of features is near completion, here is your chance to talk about what features you would like to see next.
Major points that have been discussed before:
- Profiles are still a consideration, although with the simplified options and general efficiency, it feels like its less mandatory. Happy to take opinions and use-cases on that to influence the design of the solution here.
- Projector-specific improvements? I'm not a projector owner, so if you are one of those, some detailed requirements would be nice.
- Anything we entirely missed so far?
Let us know, so we can plan ahead for the next bigger features we work on.
I am a projector owner JVC NX9 with a 150" curved scope screen. I really think it would be nice to see some enhancement options like madvr has. When you have a really large screen to be able to add some enhancements to sharpen slightly really helps... Of course on a 55" Oled or similar one just doesn’t need enhancements probably.
-
Split Blu-ray related questions here:
https://yabb.jriver.com/interact/index.php/topic,133027.0.html
Lets keep this topic to JRVR specific topics, that is video rendering only. Separate threads can be used for other video playback questions or requests. :)
-
When you have a really large screen to be able to add some enhancements to sharpen slightly really helps...
Those who have a projector but above all a large screen, in addition to better sharpness, would also like frame interpolation because in scenes with horizontal panning the image is sometimes annoying.
My Epson, as known, has frame interpolation only up to 1080p and not for 4K so it would be nice if there was this possibility with JRVR.
I already know that you have said several times that it is not in the programs at the moment, but if it was possible, I think many will thank you :)
-
I'd be interested in what JRVR could do with SDR --> HDR tonemapping for those with HDR on all the time in Windows 11 (I presume JRVR would be better than Windows 11)
-
Profiles: I was using madVR profiles on my mid range 1660Ti to split the Upscaling algo's based on FPS ( eg Higher Settings < 31fps > Lower Settings) to prevent dropped frames on higher FPS material. In my testing the same applies on the JRVR in that I can use FSRCNNX16 with 23.976/24/29.97 but only FSRCNNX8 with 48/50/59.94fps material. If such an option existed in JRVR, I'd use it..... but I also have no complaints on running FSRCNNX8 and this is to a 125" PJ (but more is "better" right!!!)
-
For projector use I still use madvr as it has settings that JRVR doesnt have, I would like to see enhancements and profiles, this is an example.
-
I'd be interested in what JRVR could do with SDR --> HDR tonemapping for those with HDR on all the time in Windows 11 (I presume JRVR would be better than Windows 11)
That would be very interesting!
-
As the initially planned list of features is near completion, here is your chance to talk about what features you would like to see next.
Major points that have been discussed before:
- Profiles are still a consideration, although with the simplified options and general efficiency, it feels like its less mandatory. Happy to take opinions and use-cases on that to influence the design of the solution here.
- Projector-specific improvements? I'm not a projector owner, so if you are one of those, some detailed requirements would be nice.
- Anything we entirely missed so far?
Let us know, so we can plan ahead for the next bigger features we work on.
Please note, this is specifically about JRVR, that is video rendering only. General playback issues should be adressed in their own threads.
Since I use bitstreaming for all of my 4k videos which most have Atmos in them, I can't use JRVR at this point because I get dropped frames, which I think is due to not being able to use Video Clock when bitstreaming. In madvr I don't get any noticeable dropped frames because you can custom tune the refresh rate to the monitor and it works with bitstreaming. So maybe that is something that JRVR can work on in the future.
-
Tuning your refresh rate is independent of which renderer you use. You can do it with a few external tools or eg. the Nvidia control panel.
-
@datdude, as Hendrik says, there should be no difference in the refresh rate behaviour between madVR and JRVR in regards to dropped frame caused by bitstreaming drift. One of the big benefits from my testing with JRVR is that, as it is more efficient, you can run stronger scaling algos. The first thing to work out is if your dropped frames are from the GPU hitting its performance limit (in while case you have to ease up on the algos) or if it is the occasional ones from bitstreaming drift.
-
I watched it intently for several hours over several different MC 28 and 29 versions and the performance metrics were always low. Can’t remember what they were but they were lower than madvr. And yet I would notice a slight visual stutter and then check the stats and sure enough there were dropped frames. I tried using the lowest possible settings which of course helped the performance numbers, but it still dropped frames. I tried non-bitstreaming and never had any issues. Madvr basically never drops frames and I never notice it. Maybe it is because I’m on an AMD, who knows.
Open to any other suggestions though.
-
I don't have any experience with AMD :(.
- If you are seeing 1 drop or repeat every XX Minutes when bitstreaming (and none with decoding when using Video Clock) that is the auto clock drift and should be the same on any Video Renderer. The only way of fixing that when bitstreaming is to play with custom timings.
- If you are seeing a bunch of drops and at more random times then it could be GPU slipping into and out of Low Power Mode. I see this on my 1660Ti and the only way was to either add more load (eg better, more intense algos) or in the GPU Control Panel select what ever the AMD equivalent of preferring "Max Performance".
-
I don't have any experience with AMD :(.
- If you are seeing 1 drop or repeat every XX Minutes when bitstreaming (and none with decoding when using Video Clock) that is the auto clock drift and should be the same on any Video Renderer. The only way of fixing that when bitstreaming is to play with custom timings.
- If you are seeing a bunch of drops and at more random times then it could be GPU slipping into and out of Low Power Mode. I see this on my 1660Ti and the only way was to either add more load (eg better, more intense algos) or in the GPU Control Panel select what ever the AMD equivalent of preferring "Max Performance".
Where do you set the custom timings? In madvr there is a tool for that not but not in JRVR. That’s what I was wondering if JRVR was going to add in. I think that is why I don’t get dropped frames in madvr.
-
Custom timing are system wide (eg not just madVR), and are created by the GPU SW or 3rd parties like CRU, madVR etc. Once applied all applications are then using the new timings. So if you have one created in madVR then they are also the set of timings all apps (including JRVR) will be using.
-
Interesting ok. Then something else is going on.
-
Post a pic of the Ctrl+J stats in case it is something obvious. Are the stutters, all the time, single drops/repeats at set intervals, a bunch of drops/repeats and various intervals, all the time?
-
I haven’t tried it in a while with bitstreaming. I’ll give it a go again soon.
-
Here's a quick test on the latest version of MC 28. I tried MC 29 a few months ago and still had the same results, so decided to not upgrade yet.
Performance numbers look good to me, but I got couple of drops after a few minutes into playback (started up with 29 then jumped to 31) which is typical for JRVR when I bitstream.
I would say it is one or two drops every 5-10 minutes.
-
Currently I rely on MadVR to handle the HDR -> SDR BT.2020 for movies using my JVC projector - ~ 100 nits on High lamp. I got curious about JRVR, and reading this topic I saw that it offers DV support, which is not the case with MadVR. Now I am even more curious!
Question: Should I expect JRVR to take advantage of the DV dynamic tonemapping metadata and on top of it handle a 2nd tone map to deliver a final SDR BT.2020 image to my projector? Or will the DV metadata be ignored in this case?
(this is all assuming I am using a MKV file with DV data).
Thanks!
-
Question: Should I expect JRVR to take advantage of the DV dynamic tonemapping metadata and on top of it handle a 2nd tone map to deliver a final SDR BT.2020 image to my projector? Or will the DV metadata be ignored in this case?
(this is all assuming I am using a MKV file with DV data).
If i try to play any DV profile file with dynamic metadata, the MEL/RPU is just ignored and the test-scenes never change. At best JRVR is using the static metadata and does the color-conversion of the special DV P5 colorspace.
So on real DV content, most scenes are too dark, compared to native DV playback.
-
Thanks! I will wait until the dynamic tone mapping is supported.
Daniel.
-
I upgraded to MC 29 but am still getting dropped frames that I am not seeing in Madvr. I was able to replicate one that happens precisely at 11:09 in the American Made UHD movie. It happens at the exact same time every time, but does not happen in Madvr. I dropped all of the performance features to reduce the load, but it did not help.
-
After more extensive testing it appears that checking the box for "Hardware accelerate video decoding when possible" fixes the issues with certain frames/scenes causing dropped frames, the drops even occur in madvr without checking Hardware acceleration. However, in JRVR every few minutes or so, I'd say at most 5 min or less, a frame is dropped no matter what when this feature is checked. I can rewind a bit, reset the stats, and then try to play that same scene again and there are no dropped frames. It appears to be timed based, so maybe checking that box is messing with the clock in JRVR somehow.... In madvr, with this box checked, I have never seen any dropped frames, or at least not ones that are on a regular time frame. It probably has to do with me being in AMD. I’m going to have to stick with madvr at this point.
-
Apart from turning on HW Acceleration, you may want to turn on Video Clock (if you are not bitstreaming) and this should sort out the time based drops (which is caused by the drift between the Audio Clock and presentation of the Video Frames). Another option to use is turning on "Display Settings automatic change mode".
-
Yeah I have a ton of UHDs so I bitstream for the Atmos data. I do use the automatic display change feature as well.
-
I too have tons of UHD and bitstream on the 7.2.4 setup but decode on the 5.1 setups. I'm all nvidia / intel so can't help on the AMD side but FWIW I typically get one drop/repeat on the bitstreaming setup ever hour or so. I don't get any when decoding with video clock.
-
I too have tons of UHD and bitstream on the 7.2.4 setup but decode on the 5.1 setups. I'm all nvidia / intel so can't help on the AMD side but FWIW I typically get one drop/repeat on the bitstreaming setup ever hour or so. I don't get any when decoding with video clock.
Good to know. My drops seems to be every 5 mins or so.
-
I would recommend to make a frame time log, in JRVR Settings -> Advanced -> Debugging, it would tell us if drops are based on clock drift to keep audio in sync (which you might be able to fix with a custom resolution), or other issues.
It'll create a JRVRFrameLog.csv in "%APPDATA%\J River\Media Center 29"
In the past there have been some reports of rendering not being entirely stable on AMD graphics cards, and we plan to work on that, but its a big change that'll come a bit later.
-
Here you go Hendrik. Thank you for the help!
Understood on the AMD issue. I can't see that being a huge priority given that most people are on Wintel.
-
I can only see a single drop after startup in that log, but that was from a rendering glitch, instead of a timing issue. Those might be fixed in the future as mentioned above.
-
As soon as I got that single drop I stopped playing. If I had kept playing, several minutes later I’d get another single random drop. I do not get these in madvr, or at least I don’t see them when testing with the performance numbers up on screen.
Glad that this is something on your radar for the future!
-
I don't know if anyone has brought this up or if it is even possible, but I would love if there was a way to do a per file profile application.Z
If the capability already exists, feel free to point me to the documentation and I will RTFM, no problem.
For some content, certain upscaling looks better, then for other content, a different method looks better.
After spending time trying to figure out why one of my interlaced Anime DVDs looked like poop in JRVR but fine in VLC, when I KNOW JRiver is better, I spent an hour tweaking settings to dial in the type of upscaling.
Turns out Jinc was causing the interlaced frame stair step effect to be VERY pronounced, so dialing it down to Bicubic, no super sampling, cleaned it up, made it lack the stair step (or no more pronounced than VLC) and had a better overall image than VLC (which is expected).
But I like Jinc on some of my live action DVD content.
If I had to modify a file name, like you could with interlace settings on MadVR (deint=film or something), would be cool do do JRVR=profilenamehere
-
Hendrik has said the profiles are coming, and (I'm guessing) that they will be driven by Meta Data in the library. If so, no need to rename file titles etc, just use existing Library Fields.... or you could create your own for per file tagging.
-
Hendrik has said the profiles are coming, and (I'm guessing) that they will be driven by Meta Data in the library. If so, no need to rename file titles etc, just use existing Library Fields.... or you could create your own for per file tagging.
Awesome!
Thanks for the info! Glad to know it's coming. Don't NEED it but changing JRVR per file can be tedious.
-
As the initially planned list of features is near completion, here is your chance to talk about what features you would like to see next.
Major points that have been discussed before:
- Profiles are still a consideration, although with the simplified options and general efficiency, it feels like its less mandatory. Happy to take opinions and use-cases on that to influence the design of the solution here.
- Projector-specific improvements? I'm not a projector owner, so if you are one of those, some detailed requirements would be nice.
- Anything we entirely missed so far?
Let us know, so we can plan ahead for the next bigger features we work on.
Please note, this is specifically about JRVR, that is video rendering only. General playback issues should be adressed in their own threads.
Hi,
Still voting for cropping/automatic shift of the image to upper/lower screen area. I often switch to ROHQ because Manual shifting sucks from time to time…
Sorry, don‘t understand why this essential feature is not on prio list.
-
Hi,
Still voting for cropping/automatic shift of the image to upper/lower screen area. I often switch to ROHQ because Manual shifting sucks from time to time…
Sorry, don‘t understand why this essential feature is not on prio list.
I'm not sure what you mean with shift to upper/lower screen area? I assume you mean detecting black bars and cropping them off so the image can expand naturally? I wouldn't call that shifting, but anyway, lets go with that.
I've talked about this feature before, and that we will not do real-time black bar detection, because it costs way too much performance and is incompatible with hardware decoding.
Instead, what is strictly speaking already possible today, a potential "video analysis" might pre-fill the data that applies cropping. We don't have that video analysis process yet, but jmone's SoT tool can do black bar cropping detection, I don't think it writes it into the right field in the right format to automatically apply cropping during video playback though, but maybe you can convince him to look into that.
Its likely that we'll have such a process ourselves eventually, but it won't be very soon.
Otherwise, the feature is only "essential" for a very narrow and specific kind of setup. The vast majority of video playback setups are natively 16:9, and those won't benefit from this.
Since I asked for opinions on upcoming features, and specifically also projector-specific improvements from someone that actually runs one and can tell me what they are missing, this is the first time it has come up, as well.
In general, I do not have a projector, therefor no experience running one to really draw from when it comes to these features. So please actually describe the feature you are looking for, as some keywords may explain it to you, but don't necessarily give me the right information to what you are looking for. When we started JRVR development, some projector owners roughly mentioned some features like anamorphic lenses, but those requests seem to have disappeared now that we are further in the development where we could actually work on those, and I put out the question here again to give me the details of what you want/need it to do.
-
I am a projector user and I have mentioned Enhancement options like madvr has. I use an Anamorphic lens (Isco IIIL) on a Cineslide which moves the lens out for 4:3, 16:9 and 1:85, so anamorphic stretch would be nice. Also Anamorphic corection like on the big Envy, if that was available JRVR would be the only "other" video renderer in the world that could do that.
There are a few other things that would be nice but I dont want to push my luck ;)
-
We don't have that video analysis process yet, but jmone's SoT tool can do black bar cropping detection, I don't think it writes it into the right field in the right format to automatically apply cropping during video playback though, but maybe you can convince him to look into that.
I'm all ears! If you let me know what field / format you want I'll happily change SoT to assist.
Edit: Can we take the request to the SOT thread so not to pollute this one? https://yabb.jriver.com/interact/index.php/topic,106802.0.html
-
Otherwise, the feature is only "essential" for a very narrow and specific kind of setup. The vast majority of video playback setups are natively 16:9, and those won't benefit from this.
Since I asked for opinions on upcoming features, and specifically also projector-specific improvements from someone that actually runs one and can tell me what they are missing, this is the first time it has come up, as well.
In general, I do not have a projector, therefor no experience running one to really draw from when it comes to these features. So please actually describe the feature you are looking for, as some keywords may explain it to you, but don't necessarily give me the right information to what you are looking for. When we started JRVR development, some projector owners roughly mentioned some features like anamorphic lenses, but those requests seem to have disappeared now that we are further in the development where we could actually work on those, and I put out the question here again to give me the details of what you want/need it to do.
I thought I had posted what (I thought) was required earlier -> https://yabb.jriver.com/interact/index.php/topic,131214.msg909817.html#msg909817
Aren't we talking about the same thing here? There was also a performance problem I found during that testing, has that been fixed now? comments around that (repeatable) performance problem are in the other thread nearby https://yabb.jriver.com/interact/index.php/topic,130905.msg911868.html#msg911868
I didn't realise I needed to repost this to ask for it again so are the requirements (for anamorphic lens users) clear now or not?
-
I thought I had posted what (I thought) was required earlier -> https://yabb.jriver.com/interact/index.php/topic,131214.msg909817.html#msg909817
The discussion basically ended with the image being as you needed it, right? So all we need to do is add a way to apply that automatically based on the video aspect ratio and your lens factor?
Can you link me to the tech specs of such a lense or something similar so I can see how to best integrate it so it matches what the lens specification says?
Aren't we talking about the same thing here? There was also a performance problem I found during that testing, has that been fixed now? comments around that (repeatable) performance problem are in the other thread nearby https://yabb.jriver.com/interact/index.php/topic,130905.msg911868.html#msg911868
I can't really confirm or deny that, its been 6 months, lots has changed, and since the issue occured on your system. But performance changing based on tabbing in and out sounds like some weird graphics driver glitch, so it might well have been fixed with all the cleanup going on.
-
I can't really confirm or deny that, since the issue occured on your system. But performance changing based on tabbing in and out sounds like some weird graphics driver glitch, so it might as well have been fixed with all the cleanup going on.
Do you mean you couldn't reproduce this? I will retest with the latest build anyway
-
Can you link me to the tech specs of such a lense or something similar so I can see how to best integrate it so it matches what the lens specification says?
I use a lens like this https://www.prweb.com/releases/2009/05/prweb2449484.htm
It is a 1.33x horizontal expansion lens
The other main type used is a vertical compression lens such as https://www.panamorph.com/ which, if I remember correctly, are a 0.75x lens
-
Horizontal Expansion and Vertical Compression should have the same outcome, shouldn't they? Both would take a picture in the native aspect ratio of the projector (16:9, eg), and make it "wider". The way they do it is different, but that doesn't change the properties for JRVR as I understand it.
Correct me if i'm wrong, but for most content this would only really offer the full benefits if we also have black-bar-detection, so you can actually benefit from using more screen space?
Of course even without that, you might want to use it, because you have the lens installed and it would be the wrong ratio otherwise, except you would end up getting pillarboxing in this case, unless you override the scaling mode to Crop.
-
Actually, starting to look into how we do aspect ratio handling, it seems we already support anamorphic displays, it is just not named very well for this purpose, and hidden a bit.
Options -> Video -> Advanced -> Aspect ratio correction
Below you'll find the scale factors available right now, which we can easily extend if needed
No change: 1.0
1.33 to 1.78: 1.333..
1.33 to 1.60: 1.20
1.78 to 2.35: 1.321875
1.78 to 2.40: 1.350
The actual aspect ratios and factors it lists are just descriptive, it all turns into this one scale factor. So if your lens is setup to scale 16:9 (1.78) to cinemascope 2.40, there is an option ready to use there.
Combine that with the "Aspect ratio mode" option right below and you have a lot of control already (eg. setting it to Crop would let it fill the screen). Let me know if this works?
Ideally these should be per-screen settings in JRVR, but the entire aspect ratio/zoom handling is generic MC stuff that predates it, so that might be a change for later. But most people with dedicated projector setups likely don't mix and match much, or could use zones to deal with it.
-
Yes they both convert to scope in the end, I will give it another test tonight using jrvr and the various options mentioned.
-
If these settings do the job I can reword and move them for better visibility, and maybe even add a custom mode where you can enter a custom ratio, because it helpfully already stores the actual ratio rather then just an index into the option.
And time saved I can allocate for other features, like moving some form of black bar detection further up the stack.
I think subtitles might not scale properly with this setting, as it assumes square pixel, but thats something I can fix. Need to do some testing with it.
-
I think it all works as expected but I'm quite confused by how some of the options are meant to be used and/or how they intersect
I can see 2 working setups though
1) Set Aspect Ratio Correction in advanced options + set Window > Crop in the right click menu during playback
2) Don't see any advanced options, use the Window menu only with Stretch + Crop Black Bars > Video within Black Bars is 2.35
The confusing part are the Crop/Stretch options at the top of the right click > Window menu, they seem to behave like they apply to black bars but there is a separate menu item below which is called Crop Black Bars so I'm not sure what that top option does.
Is there a reason why one of these options is better than the other (with respect to PQ)?
From a usability perspective, apart from there appearing to be n ways to do the same thing + some not obvious menu items, I think I can restate a few aspects as I see it as the user
1) some users (e.g. me) have the lens on a slide so it's only in use when required, this means AR/crop changes have to be applied on a per title basis
2) a lens is (obviously) a physical device which is present in a single location so this config has to be able to vary on a per client basis
3) pushing this config into zones would be fairly terrible because it would mean zones are used for 2 things that can vary independently (DSP, video config) which is gets ugly to manage (unless zones get smarter and let you combine different pieces of configuration in reaction to different rules, e.g. something like { if AR > 2.2 apply video zone 1, if channels < 6 apply audio zone 2 } )
-
But performance changing based on tabbing in and out sounds like some weird graphics driver glitch, so it might well have been fixed with all the cleanup going on.
fwiw I can no longer reproduce this
-
1) Set Aspect Ratio Correction in advanced options + set Window > Crop in the right click menu during playback
The Advanced option Aspect Ratio Correction gives you the ability to have a global always-on option to influence the image aspect ratio in a certain manner, eg. exactly compensate for your lens ratio - and in a safer manner too, independent of the videos actual content or aspect ratio.
It was originally designed for older anamorphic screens, but those exhibit the same properties as using a lens.
Overall this would be the best option to use - of course that falls apart when you are talking about per-video usage, more below.
2) Don't see any advanced options, use the Window menu only with Stretch + Crop Black Bars > Video within Black Bars is 2.35
"Stretch" is a bit of an aggressive solution and only works right if the video happens to have the right size - which in this case you ensure by using Crop Black Bars, which will always create an image with the specified aspect ratio.
Stretch has no logic to check for any size or aspect ratio, it'll simply fill the entire screen with the image you have. It can work, but beware those caveats, as it can also screw up if used incorrectly.
The confusing part are the Crop/Stretch options at the top of the right click > Window menu, they seem to behave like they apply to black bars but there is a separate menu item below which is called Crop Black Bars so I'm not sure what that top option does.
Thats mostly coincedental. They would impact JRVR-generated black bars of course, because both Crop and Stretch are designed to not generate any and rather fill the screen instead. But they would not usually impact video-encoded black bars, unless you use the Crop Black Bars option ("Crop" can impact encoded black bars, depending on your actual screen layout and the video properties, but it would only do so if your screen aspect ratio is wider then the video aspect ratio - I should make some explanatory images how crop and stretch impact the image)
Is there a reason why one of these options is better than the other (with respect to PQ)?
PQ is the same, as long as you arrive at the same target video rectangle. All these just calculate source and target rectangles that the renderer uses.
1) some users (e.g. me) have the lens on a slide so it's only in use when required, this means AR/crop changes have to be applied on a per title basis
Do you actually modify the lens settings manually, or did you use madVRs automation for that? I'm not sure if we would re-create something like that anytime soon.
2) a lens is (obviously) a physical device which is present in a single location so this config has to be able to vary on a per client basis
I don't think video playback settings are synced across devices, but i'm not 100% right now.
3) pushing this config into zones would be fairly terrible because it would mean zones are used for 2 things that can vary independently (DSP, video config) which is gets ugly to manage (unless zones get smarter and let you combine different pieces of configuration in reaction to different rules, e.g. something like { if AR > 2.2 apply video zone 1, if channels < 6 apply audio zone 2 } )
Maybe we can move something of this into JRVR profiles once those become a thing, which would also be nice as to have it in a per-monitor section in JRVR, although right now its independent of JRVR, so i'll have to think about how to best do that.
Ideally what I think would work is if we have the ability for JRVR to control the Aspect Ratio Correction based on its per-device config, as well as JRVR profiles. Combine that with a future feature to automatically find and crop black bars, and we should be all there. That'll require quite some shuffling of features though as the Aspect Ratio Correction needs to move some of its logic around.
Per-device solves any concerns of using different screens, and profiles would let you do it on a per-file basis.
Guess I'm back to working on profiles as the next thing, and we can make use of those later for all these things. The conflict of zones with audio settings is why I want to do JRVR profiles independent of zones in the first place, because zones are rather rigid and should probably mostly remain relegated to audio or high-level settings outside of JRVR's domain.
-
thanks for the detailed explanation, a few comments on specific points
The Advanced option Aspect Ratio Correction gives you the ability to have a global always-on option to influence the image aspect ratio in a certain manner, eg. exactly compensate for your lens ratio - and in a safer manner too, independent of the videos actual content or aspect ratio.
It was originally designed for older anamorphic screens, but those exhibit the same properties as using a lens.
Overall this would be the best option to use - of course that falls apart when you are talking about per-video usage, more below.
OK I see, so this would be a good option for someone who uses a lens fixed in place (no sled)
Do you actually modify the lens settings manually, or did you use madVRs automation for that? I'm not sure if we would re-create something like that anytime soon.
I use a madvr profile
if (AR > 2.2) "ana"
else "normal"
which applies a 4/3 stretch factor + automated black bar detection to eliminate the bars. This works well (except for films with multiple aspect ratios which I find hard to find a good balance of settings for)
The lens is moved into place via a change to the installation mode on the projector which signals the sled via a 12v trigger. This could be automated but I do it manually atm.
Guess I'm back to working on profiles as the next thing, and we can make use of those later for all these things. The conflict of zones with audio settings is why I want to do JRVR profiles independent of zones in the first place, because zones are rather rigid and should probably mostly remain relegated to audio or high-level settings outside of JRVR's domain.
do you think it's worth asking jmone to make changes to SOT now to populate the playback info field or is it best left til after this work is done to see how things settle?
-
I use a madvr profile
if (AR > 2.2) "ana"
else "normal"
which applies a 4/3 stretch factor + automated black bar detection to eliminate the bars. This works well (except for films with multiple aspect ratios which I find hard to find a good balance of settings for)
The lens is moved into place via a change to the installation mode on the projector which signals the sled via a 12v trigger. This could be automated but I do it manually atm.
The settings profile we'll be able to have as well. I was more interested in the change to the lens itself, which madVR can theoretically automate in some fashion, but we might not easily get that.
do you think it's worth asking jmone to make changes to SOT now to populate the playback info field or is it best left til after this work is done to see how things settle?
Long term I would probably write the black bar detection information into a separate field, and then optionally apply it during playback with an option. But if you want to get ahead of that development, writing the right cropping info into the Playback Info field would certainly work and get you going relatively quickly.
-
I was more interested in the change to the lens itself, which madVR can theoretically automate in some fashion, but we might not easily get that.
madvr does have support for activating a lens memory on profile change but I don't use it, partly because I have to have ability to change the mode without using madvr (for streaming sources) so i think it's simpler for other people in the house to change the lens mode in the same way for all content rather than have it automated in some cases but not others.
-
JRVR is great!! The image quality performance is comparable to MadVR but rendering performance is definitely better.
My request at the moment is a film grain filter. Film grain tends to be one of the first things that video compression averages out to increase ratios, and I find that without grain the image just doesn't look right. Being able to add film grain back in with MadVR was one of my favorite features.
Ok actually two requests. Displaying the video frame rate in the OSD would be helpful to be confident the refresh rate has been matched up correctly.
-
Actually, starting to look into how we do aspect ratio handling, it seems we already support anamorphic displays, it is just not named very well for this purpose, and hidden a bit.
Options -> Video -> Advanced -> Aspect ratio correction
Below you'll find the scale factors available right now, which we can easily extend if needed
No change: 1.0
1.33 to 1.78: 1.333..
1.33 to 1.60: 1.20
1.78 to 2.35: 1.321875
1.78 to 2.40: 1.350
The actual aspect ratios and factors it lists are just descriptive, it all turns into this one scale factor. So if your lens is setup to scale 16:9 (1.78) to cinemascope 2.40, there is an option ready to use there.
Combine that with the "Aspect ratio mode" option right below and you have a lot of control already (eg. setting it to Crop would let it fill the screen). Let me know if this works?
Ideally these should be per-screen settings in JRVR, but the entire aspect ratio/zoom handling is generic MC stuff that predates it, so that might be a change for later. But most people with dedicated projector setups likely don't mix and match much, or could use zones to deal with it.
I tried this the other night and for me it, aside from it one or 2 glitches where it just didnt work (needed to quit and replay the file), it works very well. I have my anamorphic lens (ISCO IIIL) in place 100% of the time on a scoped screen, so now it looks okay for 16:9 content and works best for 2:35 aspect ratios.
-
Split: JRVR Configuration Profiles (https://yabb.jriver.com/interact/index.php/topic,133480.0.html)
-
One of the reasons I use madVR is that it can detect and remove black bars. Those are especially annoying if they are grey and if the border to the video is not sharp.
So if you are searching for possible features to implement in JRVR, than that would be a great possibility.
-
I'm also in for the black bar detection (if you mean the feature to "blow up" the video to the complete screen). Great awesome feature.
-
I too initially gave a lot of importance to madvr black bar detection, having a 21: 9 screen, and I was also thinking about buying a more powerful cpu as the one I have is not good for black bar detection for 4k but only for 2k.
But I can get the same result, in the case of films with AR 2.35, with a couple of clicks on the remote control (Aspect ratio> crop black bars 2.35) and having previously selected Fit Windows.
-
Any new news on getting MC to work with copy-once protected DRM channels/cablecard?
-
Any new news on getting MC to work with copy-once protected DRM channels/cablecard?
Thats more of a TV topic, best to ask in the Television board.