In the Krypton it looks very bad on my tv (which is not HDR capable).
There are no black at all:
Set the TV's input RGB range to limited (HDMI black level / black level = low) and see if that fixes it.
Posts by jd17
-
-
I used test videos (actually same as off avs forum).
I'll grab some photos...
Please do that.
Quote...but I found out the behavior of full or limited black levels changed between nougat and marshmallow kernels which is where the difference lies: not whether the display is hdr capable. Mix in that many current displays have broken "auto" black level (like Samsung's entire lineup), this is why some of us have seen the black changes, and others haven't.
That theory might be true in some cases, but it is ultimately incorrect.
There is no change in RGB range between builds.Both Marshmallow and Nougat Frankenstein Kernels output limited YCbCr in video playback.
My TV is always fixed for limited input and I made sure to test both builds again.
When the MM kernel boots up, it looks like the build outputs the full RGB range (0-255), so changing the TV to full range fixes the issue for a second.
However, as soon as you start the first video, the output is back to limited YCbCr, as it should be. So if the TV was changed to full range before, everything will look washed out.Your theory still has some merit here, because TVs that have the range set to "auto" might read the signal as full range at boot up and stay at full range. The result would be washed out looking video.
So, users who complained about washed out colors with MM builds - please check your TV's RGB range setting and manually set it to limited (HDMI black level / black level = low in some devices).
To be honest, I always assumed this is a given and people have their devices set to limited by default... -
Last night i watch T2 Trainspotting and times to times have drop frames and the image its not fluid and to dark.
Mediainfo:
Code
Display MoreVideo ID : 1 Format : V_MPEGH/ISO/HEVC Duration : 1h 57mn Width : 1 920 pixels Height : 1 036 pixels Display aspect ratio : 1.85:1 Frame rate : 25.000 fps Writing library : Lavc57.89.100 libx265 Language : English Default : Yes Forced : No DURATION : 01:57:39.326000000There is just too much information missing.
Is this what MediaInfo is showing you?
However, the frame rate would be the first thing to perplex me.
That movie (like most) is filmed at 23.976 fps, not 25 fps.
A poor frame rate conversion might cause perceived frame drops or skips and non-fluid appearing pictures.
I highly doubt this looks any different on Frankenstein Nougat.
If it does, please log the dropped/skipped frames.
Normally, MediaInfo should provide more detailed information, for instance:Code
Display MoreVideo ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main 10@L4@Main Codec ID : V_MPEGH/ISO/HEVC Duration : 2 h 27 min Bit rate : 7 795 kb/s Width : 1 920 pixels Height : 804 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.211 Stream size : 8.04 GiB (78%) Writing library : x265 2.3:[Windows][GCC 5.3.1][64 bit] 10bit Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x804 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=5 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr Default : Yes Forced : No Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.70925 lines vs. 12 lines in your case...
Some things are not flagged, depending on the encode - but your info is just missing too many important lines. -
x265 get to mush frame skips and slush on MM Kernel.
Can you be more specific?
What kind of x265 files trigger frame skips?
Can you post sample, log and MediaInfo?
The 1080p / 10-Bit / BT.709 HEVC encodes I created seem to play perfectly fine. -
- There are black level changes between the kernels depending on display capabilities. On some displays, there are no black level changes on test images. On both my newer hdr capable displays, there are major changes in black levels that make me prefer the nougat kernel. It's worth noting I get the same test images for black level on the nougat kernel as on the marshmallow android build.
Could you describe these black level changes in detail and take comparison pictures?
I do have a HDR capable display from 2016 and while there is the obvious "dark after boot" phenomenon, I see no difference whatsoever in any video, at least not in regular AVC 1080p / 8-Bit / BT.709 stuff.
You do mention test images, not videos - are you maybe judging the Kodi image viewer, not the video player?
When you look at the "black clipping" pattern from the AVS HD 709 collection, do you see any difference?
AVS HD 709 - Blu-ray & MP4 Calibration - AVS Forum | Home Theater Discussions And Reviews -
I am sorry to simply bump this - I don't want to be annoying.
However, will anyone look into this if they find the time? -
Official bug report in the Kodi forum:
[BUG] Frame skips caused by forced subtitles -
New tricks are helping the Raspberry Pi's 2 and 3 play 1080p HEVC videos pretty well with the latest releases.
A moderate overclock will help as well.
Unfortunately this is limited to 8-Bit HEVC, which is utterly useless.
You cannot get AVC quality with HEVC if you are limited to 8-Bit encoding, at least not while maintaining a filesize advantage.
HEVC needs 10-Bit for proper picture quality.
And yes, that goes for 8-Bit sources too.
Even a very high quality x265-8 preset (like CRF17 / medium / tune grain) will introduce some ugly banding lines on smooth color gradations, whereas x264-8 would not only look better at CRF17 / medium / tune film - it would also result in a very similar filesize and encoding is much faster.
x265-10 however looks better than both and is smaller than both.
This is one of the reasons why proper 10-Bit output (or at least proper 10-Bit to 8-Bit conversion) is so important.
S905(X) have an obvious advantage over any RPi in that regard.
Also, RPi's are limited by SD cards as their only source for the OS.
Any S905(X) internal memory is much faster than the best SD card in a Pi (considering the RPi's USB2-based controller). -
Do you have hardware acceleration enabled?
That is required to reset the brightness...
If it's still darker, can you take a comparison picture and share? -
just loaded 8.0.1l-mm coming from 8.0.1l, TV Output is darker.
I cannot believe how this is such a big topic again...
The output always used to be darker with MM Kernel right after start, but perfectly fine after the first video was played.
kszaq always had that listed as a known issue too:QuoteKnown issues:
- If you use S905X device the screen will be darker than normal on boot. It goes back to normal after you start/stop a video.
-
I'd recommend to try to play this file (HDR 10-bit HEVC 25.000fps) first, for example, and after that the stuff that is too dark.
In my case paying back the file restores the contrast/saturation to normal.
Every regular AVC video restores the correct brightness too, it does not have to be a fancy HDR 10 Bit file.
For me, FN's better for S905x SoC.
I am sorry, but if you prefer Frankenstein Nougat based on a 10 Bit video (your screenshot), I cannot take you seriously.
10 Bit causes horrible banding in Frankenstein Nougat builds.
The menu screenshot looks like you took the MM-build picture before playing a video, i.e. before restoring the correct brightness. -
Since nobody else thinks it helps to support a claim with quantifiable evidence, I took some pictures.
1. 8.0.1l-mm (Marshmallow Kernel):
2. 8.0.1l (Nougat Frankenstein Kernel)
Apart from the minor (known) overscan on the left edge, there is no difference whatsoever. NADA!
Same camera, same TV. Same camera settings (apart from the human factor), same TV settings.
Both are fresh installs.(The minor difference in the purple vertical lines comes from the camera autofocus. There is no visible difference.)
QuoteOn MM I cannot lower my brightness below 50% without the display becoming "solarized" with almost a photo negative effect. Also, the contrast only seems to only effect the blue/red channels somehow.
I always leave contrast/color/brightness etc. untouched on source devices.
There might be a difference if those values are changed. But why change them?QuoteOn the nougat frankenstein these issues are gone, picture is much sharper, and with accurate color.
Please take comparison pictures to support this claim.
-
Have you gone beyond the initial startup brightness in the menus?
There should be no significant difference after you started the first video (with activated hardware acceleration). -
-
Shouldn't it give the same output?
No, definitely not.
If the input signal is not BT.2020, you are just oversaturating a BT.709 signal. -
In the "mm" build the colors are not consistent. Sometimes, on a given sample clip, they are normal, sometimes washed out and sometimes overly saturated.
I've played several HDR and non-HDR HEVC Kodi sample videos. Sony's HDR Camp clip, for example triggers the oversaturation on other (Patagonia) sample. If I play "The Life of Pi" or Astra's video — they restore the colors to normal.
Sometimes Sony's camp looks more realistic and sometimes too reddish, but the HDR effect always presents.
BT.2020 content is not there yet, no.
However, regular 1080p / BT.709 content is always fine in the MM-builds - reliably.
No matter the codec - AVC or HEVC. -
Well, they are definitely too dark in the menus before you started the first video (with enabled hardware acceleration).
That has been known forever... -
I know that HDR is not being output 1:1 as it should in 7.0.3.012j, but it looks fine to me. Not too different from the TV's internal media player to be honest.
I have to withdraw that statement (and my previous statements on the matter).
I chose another UHD HDR sample video to compare to the internal media player again...
My usual sample was too colorful and flashy, so I let myself be fooled.
Although HDR is triggered and seems to work fine, the colors are definitely off, so I assume BT.2020 is not being passed to the TV.
That goes for both 7.0.3.012j and 8.0.1l-mm.
Apart from that - UHD works fine with the MM build.
There are no more black screens / signal losses.
8.0.1l-mm causes frame skips, where 7.0.3.012j would pause and rebuffer.
I think both are network limitations however.
