Print

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

[jmone]

@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.

[datdude]

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.

[jmone]

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".

[datdude]

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.

[jmone]

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. 

[datdude]

Interesting ok. Then something else is going on.

[jmone]

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?

[datdude]

I haven’t tried it in a while with bitstreaming. I’ll give it a go again soon.

[datdude]

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.

[danbez]

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!

[Andy22]

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.

[danbez]

Thanks! I will wait until the dynamic tone mapping is supported.

Daniel.

[datdude]

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.

[datdude]

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.

[jmone]

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".

[datdude]

Yeah I have a ton of UHDs so I bitstream for the Atmos data. I do use the automatic display change feature as well.

[jmone]

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.

[datdude]

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.

[Hendrik]

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.

[datdude]

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.

[Hendrik]

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.

[datdude]

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!

[slerch666]

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

[jmone]

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.

[slerch666]

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.

[thorsten]

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.

[Hendrik]

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.

[murray]

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 

[jmone]

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

[mattkhan]

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?

[Hendrik]

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.

[mattkhan]

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

[mattkhan]

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

[Hendrik]

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.

[Hendrik]

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.

[mattkhan]

Yes they both convert to scope in the end, I will give it another test tonight using jrvr and the various options mentioned.

[Hendrik]

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.

[mattkhan]

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 } )

[mattkhan]

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

[Hendrik]

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.

[mattkhan]

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

Code: [Select]

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?

[Hendrik]

I use a madvr profile

Code: [Select]

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.

[mattkhan]

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.

[mykillk]

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.

[armyplace]

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.

[JimH]

Split:  JRVR Configuration Profiles

[Buldarged]

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.

[Smack]

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.

[lello]

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.

[CZ Eddie]

Any new news on getting MC to work with copy-once protected DRM channels/cablecard?