More > JRiver Media Center 30 for Windows
NEW: JRVR Video Enhancements in Media Center 30
Desktop Videophile:
--- Quote from: Hendrik on August 24, 2022, 03:43:38 pm ---- (Maybe) Dolby Vision Enhancement Layer support (for UltraHD Blu-ray discs)
- More metadata in the library (HDR info, and more)
--- End quote ---
(1)Does the Dolby Vision Enhancement Layer support (for UltraHD Blu-ray discs) include support for UHD m2ts rips/remuxes from the UHDs as well(say using DVD-Fab UHD ripper)? I am specifically asking this because earlier there was mention for limited support for mkv rips only for some Dolby Vision capabilities of JRVR although container format should not make any difference.
(2)With more metadata in the library, can we take the indulgence to expect new HDR info field to be displayed in the Standard and Theater View(mentioning Dolby Vision/HDR10+/HDR10 ) just like FPS, Bitrate, Compression etc fields currently? Also, why can't we integrate SOT(Swag of Tools) relevant code/capability using mediainfo to add the Dolby Atmos/DTS-X info in MC itself instead of using the third party tool . As a humble suggestion, the HDR info and additional audio info should be accomodated in the current Compression field label itself justthe way like SOT tool does (for example:m2ts video(video: hevc hdr10+, audio:truehd + Dolby Atmos)
jmone:
--- Quote from: Rajesh Singh on September 09, 2022, 05:02:19 am ---(2)With more metadata in the library, can we take the indulgence to expect new HDR info field to be displayed in the Standard and Theater View(mentioning Dolby Vision/HDR10+/HDR10 ) just like FPS, Bitrate, Compression etc fields currently? Also, why can't we integrate SOT(Swag of Tools) relevant code/capability using mediainfo to add the Dolby Atmos/DTS-X info in MC itself instead of using the third party tool . As a humble suggestion, the HDR info and additional audio info should be accomodated in the current Compression field label itself justthe way like SOT tool does (for example:m2ts video(video: hevc hdr10+, audio:truehd + Dolby Atmos)
--- End quote ---
Hendrik has already said he plans to expand the MetaData collection for Video in MC30, so much of what my SOT collects may become redundant at some point. MC (as well as all other MediaPlayers) relies on FFMPEG (well the ffprobe subset), and hence, is limited to what by what it can report on. The code to detect if an Audio Stream has Meta Data Extensions (ATMOS, DTS-X etc) does not exist in ffprobe (hence SOT using MediaInfo for this). The "best" solution would be the addition of this capability in ffmpeg but that is well outside my expertise and unless someone is keen to add it..... it will not happen. I do note that MediaInfo is also open sourced so all the logic to do this is already in the public domain.
bogdanbz:
I vote for:
- Dolby Vision Enhancement Layer support (for UltraHD Blu-ray discs)
- scaler improvements
Regarding scaler improvements, I am using Jinc as the luma scaler and I find that it has more visible aliasing than madVR's Jinc scaler. This is most easy to notice on anime, where the black thin contours around characters have aliasing steps on oblique lines on JRVR but not on madVR.
bogdanbz:
There's another thing that might warrant some investigation regarding HDR.
- if I keep Windows HDR turned off, and use madVR to play HDR video with a nVidia graphic card, then madVR uses the NvAPI to switch the display into HDR10 mode, and to pass HDR static metadata to it
- if I keep Windows HDR turned on (as I have disabled the HDR auto-switch in JRVR) and use JRVR instead, then the same HDR10 video has different luminance and saturation than in the madVR case above
In this second case, I suspect metadata set on the swapchain with SetHDRMetaData is not sent to the display itself, but is used by the Windows DWM instead to perform a color space conversion of the video content. This CSC transform maybe converts the gamut to the one defined by the EDID data from the display, that usually does not have the same red, green, blue, white point chromacity coordinates as the BT2020 ones. The HDR luminance static metadata is also probably used at this point to tone map to a target of 1500 nits or something like that.
I suspect this is what happens because the VESA DisplayHDR utility, which VESA provides on Windows 10 & 11 systems to perform measurements of a HDR display for VESA HDR compliance, seems to use SetHDRMetaData to set as static metadata the values found in the EDID in order to avoid any processing by Windows itself. This can be seen in the Game.cpp file in the DisplayHDR source code, which is open source and available on GitHub.
Hendrik:
--- Quote from: bogdanbz on September 16, 2022, 11:14:47 am ---In this second case, I suspect metadata set on the swapchain with SetHDRMetaData is not sent to the display itself, but is used by the Windows DWM instead to perform a color space conversion of the video content.
--- End quote ---
I have tested the transmitted metadata with a HDMI analyzer sitting between the display and the PC, and can state with certainty that the above is not the case, at least not in any generic capacity. Of course I cannot comment on your systems behavior.
Note that HDR pass-through is only accurate in fullscreen, so testing for example windowed mode may exhibit different results.
Please note that bug reports or other topics warranting further discussion should have their own thread.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version