INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Bump - Support Request: Playback engine command 28038 cleanup / enhancements  (Read 3441 times)

Movieman

  • World Citizen
  • ***
  • Posts: 113

First my custom resource file:

Code: [Select]
<!--
Media Center Resource XML (Default / English)
-->

<MJRS version="1.0">

<!--
  MadVR Anamorphic lens correction = 13/9
-->

  <ACCELERATORS>

    <!-- Playback engine Zoom custom shortcuts (shared) -->
    <Entry Key="Alt;A" Command="28038" Param="100" />  <!-- 1.77:1 -->
    <Entry Key="Alt;S" Command="28038" Param="96" />   <!-- 1.85:1 -->
    <Entry Key="Alt;D" Command="28038" Param="86" />   <!-- 2.00:1 -->
    <Entry Key="Alt;G" Command="28038" Param="79" />   <!-- 2.20:1 -->
    <Entry Key="Alt;H" Command="28038" Param="74" />   <!-- 2.40:1 -->
    <Entry Key="Alt;J" Command="28038" Param="69" />   <!-- 2.55:1 -->
    <Entry Key="Alt;K" Command="28038" Param="64" />   <!-- 2.76:1 -->
    <Entry Key="Alt;L" Command="28038" Param="59" />   <!-- 2.85:1 -->
  </ACCELERATORS>

</MJRS>

Could you possibly consider enhancing the handling of the zoom preset parameter?

1. The Parameter actually decreases in value as the zoom increases and the value seems to have no relation to actual zoom percentage shown on the GUI when the i / o zoom option is used
2. The parameter is required to be an integer, which does not allow for sufficient granularity in the sizing of the image.
  In other words, using a parameter of 74 produces an excessive zoom amount for a 2.40:1 image cutting off part of the image area, while 75 leaves visible black bars
3. For some obscure reason, a value of 80 doesn't seem to give a valid zoom. (Not sure about this one as I haven't tested it recently.)

So, while the function is there, it certainly could do with some enhancements.

For now, I am certainly happy to have the capability, but I almost always have to use the i / o keys to fine tune the image size to establish the exact zoom amount to completely eliminate the black bars without eliminating an excessive amount of the image.

Thanks in advance for any consideration.
Logged

Movieman

  • World Citizen
  • ***
  • Posts: 113

I am using this as a reference for sizing, rather than depending on individual titles which may not be exact.
Logged

Movieman

  • World Citizen
  • ***
  • Posts: 113

Bump, please.

Am i  making an invalid assumption that the 28038 command for the video engine zoom is a part of JRiver Media Center?

If it is, I would appreciate an acknowledgement on whether or not anything can be done to improve this function per my above request.

Should I have posted it on a different section of the forum?

Thanks,  Vern
Logged

tij

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1563

That looks like MC command.

I recall you had some discussion about this, but I dont remember what it was about ... are you trying to use anamorphic lens? ... or is there another reason why you zooming in? (sorry I cannot truly remember your set up)
Logged
HTPC: Win11 Pro, MC: latest 31(64b), NV Driver: v425.31, CPU: i9-12900K, 32GB RAM, GeForce: 2080ti
Screen: LG 2016 E6
NAS: FreeNAS 11.1, SuperMicro SSG-5048R-E1CR36L, E5-1620v4, 64GB ECC RAM, 18xUltrastar He12-SAS3 drives, 2x240GB SSD (OS)

Movieman

  • World Citizen
  • ***
  • Posts: 113

Yes, anamorphic lens + Constant image height 2:65:1 screen.  Zoom is working for me and using MadVR to set the proper anamorphic lens correction is working fine.

The I/O keyboard function is working fine.  The problem comes when trying to assign a zoom value using, for example:

<Entry Key="Alt;H" Command="28038" Param="74" />   <!-- 2.40:1 -->

A value of 74 for the parameter results in too much zoom, a value of 75 results in too little zoom.  Since the parameter only accepts an integer, it is impossible to set zoom accurately using using the command. 

The 28038 parameter field would need to be changed to accept a decimal value like 73.67.

Using the I/O hot keys on the keyboard allows me to accurately zoom after the fact, but I really prefer that the presets deliver the same granularity as the I/O function does. 

Also, from a purely logical point of view, why does a decrease in the parameter from 100 at no zoom to 74 represent an increased zoom.  I can live with that, it just seems counter-intuitive.

Let me know if you need any more info.

Thanks....
Logged

tij

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1563

I am not expert on this at all ... but does not MadVR support this automatically by detecting blackbars (and removing them) ... I vaguely recall seeing this on one of the forums (from what i remember the setting for this was all over the place in MadVR)

EDIT: found that forum ... http://forum.doom9.org/showthread.php?t=173286
Logged
HTPC: Win11 Pro, MC: latest 31(64b), NV Driver: v425.31, CPU: i9-12900K, 32GB RAM, GeForce: 2080ti
Screen: LG 2016 E6
NAS: FreeNAS 11.1, SuperMicro SSG-5048R-E1CR36L, E5-1620v4, 64GB ECC RAM, 18xUltrastar He12-SAS3 drives, 2x240GB SSD (OS)

Movieman

  • World Citizen
  • ***
  • Posts: 113

Yes it will, but it does so with a delay.  It also doesn't handle situations like a 1.66:1 blu ray that it actually an open matte presentation of a film that was projected theatrically at 1.85:1.

Just for reference, JRiver is the only player I have used with this issue.

Other players (Zoom Player, MPC-BE, MPC-HC, and VLC) all allow zoom presets to be defined with 2 decimal place accuracy.
Logged

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 10969

We can't really change how these values work since anyone that uses them might otherwise suddenly have their values broken.

They are not meant to match the percentages shown in the UI, since the percentages depend on the video resolution and the window size or screen resolution. These values do not. This is the internal representation of the zoom value as we would also save it into the [Playback Info] field when changed manually - with the same precision, too. This is basically a two digit decimal value multiplied by 100 (so it has two digit decimal precision).

This internal representation may not be very intuitive, but you can change the zoom with the +/- keys during playback, stop playback, and read it out of the [Playback Info] field.

The 1% steps with the keys are definitely bigger then 1 pixel movements, so achieving a pixel accurate zoom at any arbitrary value is not quite the goal for any of these.

Logged
~ nevcairiel
~ Author of LAV Filters

Movieman

  • World Citizen
  • ***
  • Posts: 113

Here's what I see

First of all the I/O zoom steps are perfectly acceptable in terms of accuracy. So that piece of the puzzle is working fine.

However:

101% zoom  = 2.99
102% zoom  = 2.98
103% zoom  = 2.98

104% zoom  = 2.97
105% zoom  = 2.96

So, I still maintain the presets do not offer the same granularity as provided by the zoom in and out (I/O) keys as shown by both 102% and 103% zoom being represented by the 2.98 value.

Methinks that a gremlin exists somewhere in there relating to the precision of a variable.

Logged

Movieman

  • World Citizen
  • ***
  • Posts: 113

Quote
101% zoom  = 2.99
102% zoom  = 2.98
103% zoom  = 2.98

104% zoom  = 2.97
105% zoom  = 2.96

So lets take this one more step:
I play a video and set the the zoom to 103% using the I key.  The resulting value saved in the Playback Info field is 2.98.

Then a week later I play the same video, and the playback engine reads the 2.98 from the playback field.

Now how will it know how to translate the 2.98 to a 103% zoom when that same 2.98 also applies to a 102% zoom?  I suspect it won't and the resulting playback will be at an incorrect 102% zoom. 

This is exactly the same behavior that occurs when setting the 28038 parameter with a hot key.

This is clearly a bug in JRiver, although it is not actually with the 28038 parameter code, and it does need to be addressed.

Thanks again.
Logged

tij

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1563

so ... using "I" key works? ... maybe automate around that in combination with Playback Info field and command 28038 ... for example use 28038 to closest known good value then send predetermined number of "I" keystrokes to MC to fine tune.

I know its not an elegant solution but at least it might work

I suspect it won't and the resulting playback will be at an incorrect 102% zoom. 

also its always better to confirm a problem rather speculate over it. Speculation wont get much attention.
Logged
HTPC: Win11 Pro, MC: latest 31(64b), NV Driver: v425.31, CPU: i9-12900K, 32GB RAM, GeForce: 2080ti
Screen: LG 2016 E6
NAS: FreeNAS 11.1, SuperMicro SSG-5048R-E1CR36L, E5-1620v4, 64GB ECC RAM, 18xUltrastar He12-SAS3 drives, 2x240GB SSD (OS)

Movieman

  • World Citizen
  • ***
  • Posts: 113

Quote
I know its not an elegant solution but at least it might work

I'm not looking for something that "might work".  GIGO  (garbage in garbage out) means that you can't create a solution when the input data is possibly invalid.

I have been a JRiver user since version 19 and have always paid for my upgrades.

I'm looking for an acknowledgement that this is a bug in the zoom implementation, which it clearly is when at least two different zoom values 102% and 103% store the same value in the playback info data.

I'm sure this same behavior exists for many other zoom values as well, and is affecting the consistency of zoom when a title that has been played is replayed, since it depends on the playback info data which has been generated (incorrectly) previously.

It seems to me that I have invested a fair share of effort debugging this issue and providing data to explain why it's happening.  Since JRiver is a paid software product, it also seems reasonable to me that JRiver acknowledges that it is a bug and fixes it.   

Thanks in advance, hoping to see a fix soon . :(
Logged

Movieman

  • World Citizen
  • ***
  • Posts: 113

Now hoping for any response at all from the developers ?

Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same value in the playback info data?

It seems to me that this issue is affecting anyone who uses the zoom function I and O keys and expects JRiver to always use the exact same zoom percentage value for any subsequent viewing of the same media, not just those like myself who are depending on the accuracy of the zoom presets.
Logged

Awesome Donkey

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 7887
  • Long cold Winter...

Now hoping for any response at all from the developers ?

Hendrik, who is one of JRiver's developers, already responded above.
Logged
I don't work for JRiver... I help keep the forums safe from "male enhancements" and other sources of sketchy pharmaceuticals.

Windows 11 24H2 Update 64-bit + Ubuntu 24.10 Oracular Oriole 64-bit | Windows 11 24H2 Update 64-bit (Intel N305 Fanless NUC 16GB RAM/500GB M.2 NVMe SSD)
JRiver Media Center 33 (Windows + Linux) | iFi ZEN DAC 3 | JBL 306P MkII Studio Monitors | Audio-Technica ATH-M50x Headphones

Movieman

  • World Citizen
  • ***
  • Posts: 113

Hendrik, who is one of JRiver's developers, already responded above.
That's not actually a response to the latest discovery of what is actually broken.  It's a response to my earlier questions.

This: Has anyone actually looked at the code to see why at least two different zoom values (102% and 103%) actually do store the same internal representation value in the playback info data? is a flat out bug in the code.  Having two different zoom percentages create the same internal representation zoom value in the database playback info field is just flat out broken, and has nothing to do with what an existing user may have come to expect.

And it's not just 102% and 103% that exhibit this behavior, either.  It occurs throughout the zoom range.
Logged
Pages: [1]   Go Up