Posts by johngalt

    Uploaded a new build (8.0.2-testing2) on the github releases page. This is a rather minor update to the testing1 release, and should be a show of stability.

    Changes:

    • Merged in upstream (kszaq) changes.
    • Merged in wrxtasy h265 dynamic_buf_margin (fixes some h265 picture corruption from improper dynamic_buf_margin), and modified vp9 dynamic_buf_margin to fix new corruption from wrxtasy's change.
    • Some minor hdmi driver fixes, with most important being properly
      setting AVI in case of colorspace correction bypass.

    Sorry for the delay...

    I finally had the time to test 12bit and look for the artifacts.

    Result:

    - 12bit does not change anything... Vertical lines are still there in 10bit videos.

    - I definitely see the weird artifacts in the "Sony Camp" video as well, it is 59.94 fps. At ~1.03min over the mountain (sky). It looks like heavy compression artifacts you get at low bitrates... Macroblocking... The video has a very high bitrate though and the artifacts are not there when I play via the TV's internal media player.

    It's still 10bit video at 12bit output, so that makes sense unfortunately. I'll check out that demo, ty.

    With a 2m cable is ok. So I think tha I have to buy another one 18gb 15m cable.

    May can you fix 420 OR 422 output?

    Manually setting 422 works, and fixing manual 420 is planned.

    That's interesting, especially because by default you shouldn't have hw accel enabled on it (sd). Thank you for the report.

    I tried again Testing 1 version,

    8 bit output all ok.

    10 bit output: 444 no video output.

    10 bit output: 422 only 24p output.

    10 bit output: 420 no video output.

    You have a different issue than the guys with the "standard" nougat output issue. Sorry, I'm not sure if you'll ever get 10bit output working on the hardware since you also had the issue on the early marshmallow test builds. Also, 4:2:0 set through attr won't work currently no matter the setup. For now, I recommend you stick with 8bit.

    What I can tell you johngalt is that today I did a short playback test of my samples on a devices that came with Android 7.1.1 - all playback issues we are experiencing with Nougat kernel were there, sometimes even worse than on LE. We're fixing Amlogic bugs...

    That's good to know :) . The PRs I put up for review revert some amports changes to avoid the h264 playback issues entirely. At this point, that seems to be a good base and just needs more testing by users who had the nougat output bug (one user reported it as fixed).

    What was the device? I ask because I'm curious if it used one of the full multi-instance decoders (defined in ucode). It's interesting: with copy/pasted functions, in one instance there were pts issues reintroduced in the "standard" h264 decoder, and fixed in the multi-instance decoder with those massive multi-instance decoding commits (with changes going far beyond multi-instance decoding). At this point, I'm very confused as to the type of development Amlogic review goes through.

    I will look for the artifacts in different framerate demos today.

    Apart from that, everything seems to be very good in "testing1". :)
    BT.2020 and HDR10 are properly passed and look right.

    You are right, the lines are barely visible at normal distances.
    However, I don't want to accept that nothing can be done about them. ;)

    I will try to force 12bit and see if they are still there...

    Once we have nougat-exp working, I can try to address some of this. For now, the changes in the state of "testing1" are sitting as pull requests for kszaq, so hopefully soon we can see official nougat builds.

    This is part of the reason why for some media I prefer 8bit output + dithering, and why I'm interested to play around on the S912 device I ordered. It has dolby registers for controlling stuff like noise, 10->12bit extending, then 12->10bit dithering. Those capabilities are only on the nougat-exp branch with the h264 pts (web-dl) issue, which is a big incentive for me to get it working properly before my S912 device arrives :)

    I definitely see vertical lines artifacts in 2160p / 10bit videos in the testing1 build.
    Also, there is some weird macroblocking and flickering, for instance in the Samsung Wonderland demo in some of the skies - look for the top middle of the screen. Those artifacts are gone when I use the TV internal media player.

    I think 1080p content is fine.


    My AVR does not like 4:2:2...
    Well, it would have been for testing only. In the end I need to think about another solution to get HD audio to the AVR.

    The vertical lines have been in all 10bit output I've had on s905x (android and LE), so I'm not sure what can be done about them. However, I don't notice them at normal viewing distances. I just ordered a s912 box, and will see if they're also on it.

    The artifacts I'm not sure of, but they could be related to chroma sampling. I'll work on manual 4:2:0 and see if they're still there.

    Edit: you could try a 25, 30, or 60fps video to see if they're still there.

    OK.

    Just a quick update:
    Cables are here - critical files play perfectly.
    No signal losses anymore. :)

    I can still retest the old cable if you wish, probably tomorrow.

    BTW, would "echo '420,10bit' > /sys/class/amhdmitx/amhdmitx0/attr" or "echo '420,8bit' > /sys/class/amhdmitx/amhdmitx0/attr" work on the testing1 build?
    I want to see if I can fool my AVR and passthrough at least a 2160p / 8bit / BT.709 / 23.976fps file...

    I know "420,10bit" won't work, but I'm not sure about "420,8bit". I think manually setting 4:2:0 at any depth will fail. However, you can run 422 instead of 444 if you wish. I think the artifacts I got from it on initial testing may have been from when dithering was globally enabled.

    johngalt you said that exp builds would not have the "vertical lines" artifacts?
    Unfortunately I missed downloading the build while it was still up...
    Is this version on the server right for testing?:
    8.0.2-exp2.tar.gz

    That was a mistake re: exp1. In that build I messed up 8bit output + dithering. There will be no change between exp2 and testing1 in terms of 10bit output quality. I don't recommend the "exp" builds until the h264 issues are fixed.

    The "testing1" build is in the same state as the PRs I just submitted to kszaq for merging :). To clarify, the main real world impact of the "exp" branches right now (aside from h264 bugs) are either HDR->SDR related or S912 specific.

    Update: I just deleted the "exp2" build from the release page. At this point, it seems the only issue with it are very bad frame skips on some h264 files.

    I'm now starting the work to merge the stable changes into upstream ( kszaq repos) and hopefully get more testing from users who had nougat output issues. The "exp" work can continue in parallel until ready for merge.

    Anyone else get Major frame skips playing this file with the latest build(exp2):

    open?id=0B3aL3ABBc7dMNWVxSVFHTUd5VjA

    I can confirm these frame skips and am working on it. They're also gone in "testing1" due to the amports reverts.

    So far, So good!:) Only problem is major frame skips on some media. Can't pinpoint the exact type but it looks like it's only on some 720p types. I'll do some more testing and see if i can isolate the specific type.

    ps. If I disable "Adjust display refresh rate" and playback at 60hz, then the problem is gone.

    On which build? "experimental," "testing," or both? Could you provide a test file? Perfect timing, just saw you uploaded a test file :)

    Any chance Kszaq's OpenSSL will port over to these builds?

    It definitely will, but I haven't debugged why I can't build with those changes (even clean). I'm sure I'll be able to figure it out without a chroot since I can build master without issues. However, these changes shouldn't stay in their own builds very long.

    I've been running a AML S912 / Kodi v18 Leia Alpha experimental - johngalt Kernel build over the weekend and getting nice results from a MINIX U9.

    I have not noticed any video banding, and watched 2 movies over the weekend and did not detect any frame skips at all, I can normally spot frame skips easily.

    I will have to do more testing with HDR10 output to my 10bit (non HDR) 4K TV before commenting further.

    Thank you. I just watched a full (high bitrate) h264 movie and checked the overlay toward the end and saw no skips :) . At this point, I think I can safely recommend the "nougat-exp" kernel branch for improved HDR -> SDR conversion. On S912, it should also now have full dolby vision decoding support (need to enable new config option). Can't recommend the branches due to playback issues on h264.

    You can also try setting /sys/module/am_vecm/parameters/panel_max_lumin to your display's luminescence in nits (e.g. echo 400 > /sys/module/am_vecm/parameters/panel_max_lumin). Just because you're watching HDR material in SDR, doesn't mean it should be graded for 100 nits on a 300 or 400 nit display. I think the only issue with this is that most have the brightness set lower to accomodate 100 nit graded sources, so without a "HDR mode", you'd be modifying brightness on the fly to accomodate both. But it's something to play with if you're feeling like it :)

    Quote
    Unfortunately the "testing1" build still has some lower grayscale flicker.

    I've yet to test, but native (4:2:2) or 4:2:0 output might be better. I need to test and fix setting 4:2:0 completely.