Posts by jd17

Quote from jd17

I will test this on RPi2 if I have the time.

I finally had time to dig up the good old RPi2.
I can confirm that the skips occur on RPi2 as well (official LibreELEC 8.0.1).

This definitely makes this a global Krypton issue.

Videos encoded at 10 Bit color depth show horrible (hard) banding (lines) in Krypton.
Gradations look perfectly smooth in Jarvis and Windows, although the videos are only being displayed at 8 Bit color depth there as well.

Assumption:
Jarvis and Windows properly convert the color depth to 8 Bits.
Krypton just truncates the color depth.

I am aware that this has been known for a while, but I still thought it makes sense to have a proper bug report thread for this.
Maybe this can be forwarded to AMLogic somehow?

Device type:
S905X
Build:
Any Krypton build up to at least 8.0.1k
Device:
Mini M8S II 2GB/16GB

How to reproduce:
Play 10 Bit video and look out for gradation that is supposed to be smooth.

Sample:
view?usp=sharing

Specs from sample video:

Quote

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 19 min 59 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
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 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=15.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-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.709

Display More

Support logs:
I don't see how a log would help in this case.

I took pictures instead:

Jarvis:
zezNFby.jpg

Krypton:
9mtE5iI.jpg

(It only shows 4:47 on the Jarvis picture because of Unpause Jumpback, which I set to 4 seconds. It is not installed in Krypton yet.)

Movie has been playing via NFS for 1h 12min now, not a single skip!
Things are looking good!

Quote

I only changed late frame management. After my investigation I realized this procedure is trying skip frames already output from decoder. I relaxed criterion for late frames ( 0.98 -> 1.9). Too much relaxing this value can cause a/v out of sync. I also increased measurement window for VSyncOff (30 frames -> 120 frames) to attenuate value changed and eliminate frame skipping.

You did apply those changes between j and k?
So it makes sense that k performs better than j or is it just a coincidence?

After 1h 15min not a single skip played from USB with afl1's 8.0.1k-l, not even from opening PlayerDebug or overlay.

This makes me want to test this build via NFS again.
I only played the file via NFS on 8.0.1j-l (5 skips after 42 minutes).

afl1: were there any changes between 8.0.1j-l and 8.0.1k-l regarding frame skips or network performance?

I tested your build and played the movie via NFS, as usual.
It played for 28 minutes, in which 25 frameskips occurred.
I switched to another HDMI in the beginning and eventually back, this might have triggered a few of those skips.
However, the 25 skips are in the same ballpark as the regular 8.0.1k, so I think there is no significant improvement.
It is not close to the 7 skips I had via USB.

My next test will be afl1's latest build via USB.

Quote from jd17

I am using the advancedsettings for the 175ms delay now, it works flawlessly! Again, thank you so much.

I just removed the unnecessary parts from the code:

<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
<showexitbutton>false</showexitbutton>
<cputempcommand>cputemp</cputempcommand>
<gputempcommand>gputemp</gputempcommand>
<video>
<latency>
<delay>0</delay>
<refresh>
<min>23</min>
<max>24</max>
<delay>175</delay>
</refresh>
</latency>
</video>
<samba>
<clienttimeout>30</clienttimeout>
</samba>
</advancedsettings>

Display More

I know this is an old post, but I have recently been testing FLAC 16bit as an alternative to untouched DTS-HD MA tracks to save some space (it works great btw).

FLAC audio (or the decoding to PCM) introduces an additional delay for me.
The 175ms are perfect to me for bitstreaming DTS (HD) and Dolby Digital (+TrueHD) etc., but a FLAC track decoded to multichannel PCM apparently adds another 175ms (or at least something close to that).

Is it possible to add another exception to the advancedsetings for a specific audio track type?

Something like (pseudo

<video>
<latency>
<delay>0</delay>
    <audio codec>
<type>flac</type>
<delay>175</delay>
</refresh>
</latency>
</video>

Can somebody help me with this?

Also, the FLAC sometimes has weird distorted noise to it and a beep when it starts.
Is there a fix for that?
It's normally gone when I start a DD file and go back to the FLAC file...

Quote from RayW

You can always switch off the option to set the display rate to the video option of course as most of us used before in KODI 16, but then you are losign a lot of the better and smoother potential display benefits brought in with KODI 17.

What are you talking about?

7.0.3.012j displays fractional framerates perfectly.

Quote from koenkooi

Can you give this build a try? Here's the matching source code. That adds the missing chunksize patch and includes PR 12110, PR 12074 and partially LE PR 713.

I will, but it is based on kszaq's build, right?
So I would compare the performance to 8.0.1k over NFS (25 skips in 26 minutes)?

Can you apply those patches to afl1's build as well?
thread-2722.html

His 8.0.1j-l already performed quite well over NFS (only 5 skips in 42 minutes).

I just copied the movie to a USB3 flash drive to rule out LAN as a root cause.

Again, I started the movie and played it for 28 minutes (8.0.1k).
I had 7 skips in that time.

This is clearly less than over LAN, so my conclusion would be that NFS has am impact too.
[hr]

Quote from koenkooi

I backported the chunksize patches to 'krypton' here, and I have a matching build as well. That should improve throughput a bit, but I haven't tried to do proper comparisons yet. If you think networking is the bottleneck for you, can you give the above a try?

Can you apply this patch to afl1's build?
I had significantly less skips in that build, so your patch might just be the edge it needs?

An S905(X) is not powerful enough for 3D LUTs.
I assume it is therefore disabled by default for all AMLogic devices.

You need a powerful Intel CPU to use this feature.

I just tested 8.0.1k.
I don't know if you tried to adress this in the build or not - I'm just trying to support.

Anyhow, I had 25 skips within 26 minutes.
[hr]

Quote from koenkooi

I backported the chunksize patches to 'krypton' here, and I have a matching build as well. That should improve throughput a bit, but I haven't tried to do proper comparisons yet. If you think networking is the bottleneck for you, can you give the above a try?

I don't know if it's a bottleneck or not.
I did include a log in which a skip occurred, but I don't know what the root cause is.
Can you see that in the log?

Quote from DATS2LS

Those with S905x boxes, have u had any problems vp9 4k videos? Just downloaded my first one and video was stuttering... Checked network usage and no probs there, then saw CPU usage was peaking near constant 100 percent.

I just redownloaded a 1440p mp4 instead and perfect. Sorry if its already been mentioned but do we have support for vp9 files in these builds using a S905x box?

I think barely anyone tested VP9, since it is so uncommon and unpopular.
To me it feels like HEVC (H.265 / x265) already "won the race"...

The only two samples in the Kodi wiki are VP9 Profile 2 (HDR), this is probably not supported at all:
Samples - Official Kodi Wiki

If there is support for VP9, there probably is nobody maintaining it because there is no demand.

Quote from kszaq

jd17 can you please try running the latest build from afl1 from this thread: thread-2722.html

It's been playing since 18 minutes now, not a single "spontaneous" skip!
(Played via LAN, NFS.)
So kudos to afl1!
I have two skips, but the second was triggered by pressing OK (overlay) and the first one either at the beginning or by pressing either OK for the first time or PlayDebug for the first time.

...Now 24 minutes in, no additional skips!
[hr]
Update:
42 minutes in: 3 additional spontaneous skips.

But video caching should not result in skipped frames but rather pausing and buffering without any skipped frames, right?

Well, I considered network as a possible error before.
It is important to me that these files play perfectly over network, because they do so in Jarvis, which means it is not a hardware limitation.

I thought the log would show if the skip is decoder or network related?
Sorry I can't read code well enough...

The file in question has a combined max. bitrate of maybe 45 mbit/s.
If network limits, it is a software/overhead? issue, because that is not close to the bitrate where Jarvis would struggle.

Quote

jd17 can you please try running the latest build from afl1 from this thread: thread-2722.html

You can safely update from one of my builds and then go back, no data wipe needed.

I'll do that this afternoon.

It might be, I'm not sure.
I don't use x265 for encoding movies yet and those test videos like birds and jellyfish are just too short to be representative.

Quote from mmpp

...

Thank you for answering these questions!
It does look like our conditions are the same (if you noticed those changes on S905X as well).

Quote

I actually used the pattern v2 some days ago, and saw for the first time the "slightly darker" boxes in the clipping test area. It had bothered my before, as I could not see them properly in all the older versions of kodi on amlogic, even if I aggressively changed the settings of the projector. I did not compare the other areas explicitly.

Do you mean you could see squares in the clipping fields, but not all four squares - only the lighter, left ones?

Quote

You might still be right that I am victim of some placebo effect or an unrelated change. I might try to take pictures of my screen, but I have no high quality camera. If I find some time during the week, I setup a non-nougat-kernel version and compare the patterns in more detail. (I use this process:
Choosing a Color Space, 2nd Edition | Spears & Munsil)

Well I did not intend to imply you are a victim to placebo.
I am just as much trying to identify the difference on my side too.
You have both described the change as quite significant so I am confused that I can't see it.
If it were something subtle, I had just blamed my eyes.

I will try to compare the Spears&Munsil pattern on both versions again too.

On a side note:
Those clipping squares were never visible on any RPi build, but that still did not stop me from using the RPi2 every day.
The reason is that I never saw any negative impact in movies.

Generally speaking, the Pi's performance in this pattern is not good, but OK where it really counts in my opinion (upsampling and diagonals).
So I would call the changes between RPi and S905X subtle, although they are clearly reproducible with the pattern.

Quote from jd17

No, not yet.
I think I can still squeeze that in tonight.

I'll use the full Rogue One remux again and let you know how it goes.

I just tested it.
9 frame skips within the first 10 minutes of the movie.