OK I was only trying to get you through today’s screening with a workaround which should not result in any loss of PQ. Unless your audience really can tell the difference between 422 and 444.
My problem with enabling 10/12 bit 444 is where does it stop? To code this up for all '000s of VESA modes is just not feasible with AML’s default approach (code every possible combination of wxhxHz individually). And I’ve got no evidence that 1920x1200 will be the only VESA mode needing this treatment. Plus I wasn’t going to start if we couldn’t get this working with YUV422 on your PJ.
It would have done before my latest patches. That last DTD would have been adopted for ‘1920x1200p24Hz’ and the 1000/1001 factor would have been applied twice.
I tried switching payback to 1920x1200@59.94 from 1920x1080@59.94 with 3:2 pulldown but I couldn’t make it. It still was 1920x1080. I need 1080p23.976, 1080p24 and 1080p25 whitelisted for now so I need to switch a 1800x1080/23.976p movie on the fly to1920x1200/59.94. I didn’t risk native 1200/23.976p mode on screening day.
The goal is get normal functioning without forcing anything. If you recently enabled deep color and 422 for default VESA resolutions, I can expect the new added rates (25,24 and 23.976) to work transparently.
It should work but seems to be fickle as we’ve both found. Note that 422 is not classed as ‘deep colour’. I did try excluding deep colour (ie 444 10 and 12 bit) here from my EDID but with no success. I’m sorry we couldn’t have had this conversation a few days ago. I can’t figure out why 60Hz works but other refreshrates don’t (reliably).
Note also my EDID does include range limits - I don’t think that’s the problem.
Update: although with that it wouldn’t boot to 1920x1200p24hz, I am able to change to and from that mode while playing a 1080p24hz video. Still some questions to answer though.
Please enable those refresh rates for at least 10-bit and YUV422, as the main VESA rate does since announced and checked recently. It’s all I ask for normal functioning. Limiting to 8-bit doesn’t help, we get inconsistency.
In order to facilitate programming the framerate values for the Vero V Amlogic driver on the kernel as you explained, I have set up a table for 8, 10, and 12 bits for our WXUGA modes:
The geometry parameters remain constant for all modes:
The changes to the kernel to support all the modes your PJ advertises and 10/12 bits for all VESA modes are now in our staging repo. Grateful if you could check if these work for you and are what you are expecting. As discussed in PM, full-range input is detected automatically but full-range output has to be set manually by turning off the option ‘Use limited colour range’ in Settings-System-Display.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
Run the following command to add the staging repository: echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
Go to My OSMC → Updater → Manual Controls → and select Check for Updates now. When prompted to do so on screen, please choose to install the update.
Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command: sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Thanks Graham and good job! I report that it all works with deep colour!
I uploaded your proposed EDID to the projector without the 23.976 DTD just in case, updated to staging and now custom 1920x1200 rates work, including 23.98, 24, 25. I also tried RGB output, with both full and limited range out, for both limited and full range videos. I noticed 8-bit files output in 10-bit, and 10-bit files output in 12-bit. Toggle Force RGB out doesn’t even apparently need to reboot, it works on the fly.
My intention is forcing RGB out and full range output to all content, regardless of the source being limited range and 1:1 pixel mapping, with the rationale that I’d like to benefit from S905X4-OSMC advanced video processing features such as bith depth upsampling, motion compensated noise reduction, de-contouring, de-ringing, scaling when needed.. Given that a minimum 4:2:0 to 4:4:4 chroma upsampling (scaling) is applied to output, I‘d prefer to convert from 4:2:0 straight to 4:4:4 RGB (if feasible) to benefit from the dedicated video processor and avoid additional YUV444 to RGB conversion and image processing by the display (it will eventually convert to RGB anyway).
I deactivated the staging repository after the update. Will it keep the patches when I sync to next stable update on stable channel?
Graham, would you be so kind to ascertain a bit about the video conversion pipeline workflow to choose the most convenient output setting?
I favour to choose full range and RGB output instead of limited range and YCC output for all content (limited and full), based on that we process at higher bit depth (10 bits?) so precision should not be lost when converting from a 8-bit source, and also saving a subsequent YCC to RGB conversion at the display.
I know that the 16-235 and YCC default makes sense for most limited range content to avoid range conversion and luminance mapping, and leave the RGB conversion to the display.
However, in my use case with full range and limited range videos, I’d like to set full range output by default: full luminance is output without conversion and limited would be converted but benefitted from processing.
Is video processing (range conversion, dithering, debanding, denoising) and RGB conversion done at 32-bit floating-point calculation and rounded to destination (10-bit or 8-bit depth)? I think that the Vero’s S905X4-OSMC video processor works in 10-bit internally. 12-bit output would be padding two zeroes from 10-bit, wouldn’t it?
You will appreciate that all video processing is done in hardware controlled by AML’s proprietary firmware so is somewhat opaque. I believe all conversions are done on a 16-bit or maybe 32-bit frame buffer but we do know the video is stored in a compressed format typical for ARM chips and I don’t know what the effect of that is.
I think I explained to you that conversion from YUV to RGB is done at the output and there’s no facility for passing full-range video through without conversion. As you acknowledge that makes sense for the domestic video market. I believe all processing such as dithering is done immediately after the decoder ie on the YUV signal. Conversion from YUV to RGB is done with a 14-bit matrix. There may be some smarts in that process but they are not documented or adjustable. Your Barco may perform that conversion better than Vero. Many users suppose that display manufacturers are better at conversions between resolutions than set-top box manufacturers and the same may apply to other conversions such as YUV-RGB and limited range to full-range. I would try both to see if there’s a visible difference.
IMHO, if “force 16-235 output” is disabled at OSMC GUI and I play a full-range video, there shouldn’t be any range conversion: the decoder reads the full-range tag from the file, decode full-range as is and be output full-range. This is what I intend. It makes no sense to do a conversion with full-range out and a full-range video. This is how I see other combinations:
In case of a limited-range video and “force 16-255 output” enabled, the video decodes as is, limited range, and outputs without conversion (the usual default).
In case of a limited-range video and full range output, the video should expand/convert to full-range, and benefit from dithering or bit-depth upsampling (if to 10-bit).
In case of a full-range video and “force 16-235” then it should compress to limited-range and dither or upsample as well.
I understand where you are coming from but I’m just telling you how it is.
I’ve already given you far more information than you could normally expect from an equipment supplier and made changes to suit your use-case that I don’t think you will find on any similar media players. I’ve also told you that it’s like that because that’s the way AMLogic sets it up (for the target domestic video market, not for semi-professionals) and that we might revisit the way it’s done in the future in the light of your comments but it’s not trivial and won’t be done on our present kernel.
I’m only speaking for myself as a volunteer dev who probably knows the most about this amongst ‘Team OSMC’. If @sam_nazarko or any others know any different they are free to contribute.
All I’m trying to discern is whether full-range input isn’t converted when full-range output is selected. I think you are confusing with RGB output conversion.
To be more specific about this post and avoid confusion:
Can I expect that decoded full-range content isn’t “converted” when selecting full-range YUV output in the GUI?
When ‘expanding’ 8-bit limited-range content to full-range and 10-bit YUV output, is the calculation rounded to 10-bit?
Same question but with 10-bit limited content and 12-bit YUV full-range output.
PS : I am not demanding support. I am only a video enthusiast discussing how OSMC works, in particular the final rounding to output.