When playing videos on my Vero 4K+ that don’t match my screen size, I get dim grey bars at top and bottom of the display. I’ve verified that these bars aren’t encoded in the videos.
But it seems that many other files in different resolutions and container formats have the same problem. It is possible that they’re all H264 (certainly this sintel clip is), this I’ve not investigated. I also don’t know for certain that all videos that don’t match cause the issue.
Normally I notice this when viewing content in 1080p that isn’t 16:9 (such as 1920x800), I’ve only picked this particular clip because it’s public domain and freely available.
This tiny excerpt of my logs shows the screen and video resolution.
2019-12-15 13:33:28.761 T:4071374848 DEBUG: CAMLCodec::SetVideoRect:display(0,0,1280,720)
2019-12-15 13:33:28.761 T:4071374848 DEBUG: CAMLCodec::SetVideoRect:gui(0,0,1280,720)
2019-12-15 13:33:28.761 T:4071374848 DEBUG: CAMLCodec::SetVideoRect:m_dst_rect(0,88,1280,544)
2019-12-15 13:33:28.761 T:4071374848 DEBUG: CAMLCodec::SetVideoRect:dst_rect(0,88,1280,544)
My display is 1080p native, but I have resolution switching enabled, the vero 4k+ sensibly chooses 1280x720 for this clip.
If simply having an offending file isn’t enough to assist in reproduction I can post logs, but a quick search through the logs indicates it contains unnecessary information (such as my samba password), so it will take some time to redact it.
I tried to create a screenshot, but the screenshot bares little resemblance to what’s actually on screen.
Full logs are always the best since they show what the kernel is doing, and how you have Kodi configured. If you follow safe password practices, your SMB password would be different than any other password that you use, so that password would be of no use to anyone, unless they have access to your home network.
This is a slightly edited log, but I don’t think I’ve removed anything related to playback. I do follow safe password practices - including never disclosing them.
There’s some unfortunate bonus garbage in the log as I’m currently having problems getting my harmony remote to talk to the vero 4k+, this explains any spurious display hotplug events and bluetooth reconnects, as I have to switch ‘activies’ on the remote to get it to re-attempt connection. or something. I haven’t investigated that problem thoroughly, and it’s likely a local problem. I felt if I tried to edit that out I might accidentally render the log meaningless.
If it’s too noisy I can pull the vero 4k+ out of its usual home and poke at it with a keyboard and mouse to try to get a better log.
That’s not really an acceptable workaround for this problem, though.
Content that fills the screen and has “burned in” black bars looks perfect.
Content that’s cropped/mismatched is “padded” out to full screen with a dim grey.
If I dim my display to hide the ugly bars then the movie will be crushed to black and unwatchably dark.
My assumption is that a video plane isn’t filling the display, so the compositor fills the unused pixels with a default pixel that isn’t black - or that a full screen video plane isn’t filled with content and is showing a default color that isn’t black.
Well, it can’t possibly fix the problem, but it may provide a useful data point to someone trying to debug it: whether the bars dim with the content or not.
Neat, the dim grey bars remain, at exactly the same brightness level, when I drop brightness and contrast right to 0, which makes the video itself very dark.
(For extra fun, it looks like the display’s rightmost pixel isn’t the right color, it’s too bright for the main image and it’s purple in the grey bars. but lets leave that particular red herring alone for now )
I doubt that it will help, but if you have a spare HDMI cable, give that a try.
Other than that I’m out of ideas to try, but your results are an interesting data point. I’ve pinged our video expert, so let’s wait until he has a chance to respond.
Thanks for the suggestions - it’s the HDMI cable that came with the vero, and it’s been ok for playing 4K content, so I’m pretty certain it’s not the failure point for this < 720P video.
(It’s also incredibly inconvenient to rewire any of that stuff, so I may just be making excuses to save the effort)
Interesting suggestion! I hadn’t thought to try that. My display is full range, so wouldn’t that just throw away dynamic range/contrast ratio?
I may be able to set my display to limited range, but I have other devices plugged in, including a gaming PC, and I don’t want to artificially reduce its color gamut (or have to mess around in menus every time I change inputs)
I’ll probably have some time to play with that later tonight… it’s someone else’s turn to watch video right now
All non HDR movies and TV shows are limited range. The default input for all regular televisions is to accept video as limited range. Most commonly a television will only be set to accept full range when in PC mode (sometimes game mode optionally). By setting the output to limited range you are not losing any colors as they are not there in the first place. I suspect that the reason why you are only seeing this when you switch to “odd” resolutions is because these are computer resolutions and your TV is switching to full range mode because it thinks it’s plugged into a computer and you disabled the limited range flag. That setting is for people who are plugged into a computer monitor, not people plugged into a TV set.
My display is a 1080p native but 4k capable (pixel shifting) projector, and I’ve got several range options: auto, standard (appears to be 16…235), enhanced (appears to be 0…255), and super white (who cares?) It’s capable of HDR - and HDR is really the driving reason behind buying the vero 4k+, because I had so much trouble getting windows to switch between SDR and HDR automatically.
“auto” seems to correctly get it to match the kodi “limited range” setting.
The video file might not be a TV resolution, but how could the projector possibly know what the video file’s resolution? It can only know the screen resolution, which is a TV standard (720p when playing the sintel file). I am not “switching to odd resolutions”.
If I switch the display to limited range (or auto) and enable “use limited color range”, the grey bars go away.
If I switch the display to enhanced (or auto) and disable “use limited color range”, I get grey bars. The blacks in the video are darker than the grey bars. I think this is proof that the display isn’t doing anything silly. It’s correctly using full range, but something is filling the empty space with grey (presumably 16?)
So it looks to me like there’s a problem when limited range is set to off.
Where this gets worse is that “limited range” setting still effects my display when HDR is enabled, but doesn’t appear to effect video rendering - so when limited range is on, blacks get crushed, whites saturate.
So, I can turn limited range on and get bad HDR, or I can leave limited range off and get grey bars on some video files.
The grey bars are the lesser evil, but it still seems like this shouldn’t be a choice I have to make.
Forget what I said about “odd resolutions” I skimmed through this thread very fast and misunderstood something that was written earlier.
Your source video resolution is 1280x544 and Kodi correctly switches to 1280x720 which is the closest supported resolution that matches the whitelist you have setup. This means that Kodi must add black bars to make the video match the output resolution. By having the limited range incorrectly set they are not the correct color. From what I understand this setting only affects 8 bit videos so what issues you have with HDR output are probably a different issue.
I don’t understand “By having the limited range incorrectly set” - the help text seems to indicate that this is to match the display’s capabilities/settings. If the correct setting depends on the video being played, why is there a setting at all?
I disable 4k because my projector’s e-shift mode makes a whine that drives me crazy. I sit far enough from the screen that I can’t really tell 4k from 1080p anyway, so I’d rather lose the awful noise.
There’s a nice explanation of video levels and colour spaces on the Kodi wiki. But to cut a long story short, in 99% of cases, watching commercial DVD, Bluray, 4K HDR or live TV you want limited colour range set in Kodi. If that doesn’t look right then there’s probably something amiss elsewhere in the video chain …
I’ve read similar but never that particular page - it’s a pretty good discussion of the problem space. Thanks.
What we’re seeing here is that with “full, full, full” color space selection, along with a video that does not fully fill the display, areas outside the display are filled with a color that isn’t super black/full black.
To be perfectly clear, when set for “full, full, full”:
The video is rendered correctly - blacks are black, whites are white.
The display is showing all colors correctly - blacks are blacks, whites are white.
The kodi box (in this case a Vero 4K+) is rendering grey bars outside the video content it’s displaying. It shouldn’t do that - the bars should be a black that matches the full range color space it’s rendering content for.
It seems that I should be able to reasonably expect that setting kodi to limited and my display to limited (this should be equivalent to limited, full, limited in that doc) should give very similar output (though perhaps not EXACTLY the same, as it changes what piece of hardware is stretching the color space to fit my screen’s range) as setting kodi to full and my display to full (full, full, full).
This holds true when the video file resolution matches the display resolution. However, In the full,full,full configuration, when the sizes do not match, the portion that falls outside the video file’s contents are rendered in a color that isn’t black.
I don’t have a high degree of familiarity with the amlogix S905D SoC (I think that’s what’s in the vero 4k+?), but on similar products I’ve developed for this problem would be fixed by properly setting the “background color” that the hardware compositor block uses for areas of the display that aren’t covered by video or graphics planes.
If the SoC has a bug/limitation that doesn’t allow setting a proper black “background” when using a full range colorspace, masking off the ugly grey bars with graphics planes which obviously can display proper blacks (as the GUI renders correctly) would be viable as well.
I’m having a hard time understanding why everyone is trying to explain to me that it makes sense for the device to render grey bars outside the video region - and they really are grey bars, as the device is configured in such a way that the blacks in the video are blacker than those bars.
Also, there appears to be a strong possibility that the device is sending the “limited range” flag in the hdmi info frames during > 8bit HDR playback, which causes my display to crush blacks when in “limited, full, limited” mode as well. The closest I can come to confirming this is switching my projector between “auto”, “enhanced”, and “standard” spaces while viewing video and noting that when kodi is “limited” auto looks like “standard”, and when kodi is full range, “auto” looks like “enhanced”.
So without changing settings between videos I either get ugly grey bars or crushed HDR.
If it would be an interesting data point, I can try to reproduce this on a 16:10 (full range only) PC display using “standard” 1080p video?
Let’s try this thought experiment:
Take a blu-ray 1080p video with 2.4:1 content, crop it down to to 1920x800.
Play the original video with the display and kodi set to “limited” range. Everything looks great.
Play the cropped video with the display and kodi set to “limited” range. Everything looks great.
Play the original video with the display and kodi set to “full” range. Everything looks great.
Play the cropped video with the display and kodi set to “full” range. The original video looks great, the cropped video is rendered with grey bars.
Every one of those scenarios should look the same - how is it not a bug that the cropped video is rendered with grey bars when kodi and the display are both set to use “full” range?
PS. If you made it this far, thank you for reading my wall of text!
)
