[BUG] S905X (maybe all AMLogic?) HEVC decoding is flawed: bad image quality

  • HEVC (x265 / H265) videos are not properly decoded on S905X, maybe all AMLogic devices (?).
    "Stained" double contours are visible.
    Both 8bit and 10bit HEVC videos are affected.

    Device type:
    S905X
    Build:
    All builds are affected. Jarvis, Krypton and Leia. Marshmallow and Nougat Kernel.
    Device:
    Mini M8S II 2GB/16GB

    How to reproduce:
    Compare linked x265 encodes to x264 encode.
    Compare x265 on AMLogic box to other players.


    Get close to the TV and look at the text edges, you can pause and look at a still frame too.

    The text edges are not clean on the x265 encodes, while they are perfectly clean on the x264 encode.

    The whole text should be pure yellow, as it is on the x264 encode, but the edges have a white-ish shimmer (or highlight) on the x265 encodes (left edge of letters).

    The x265 encodes look clean (all yellow letters) with other platforms and players:
    - Kodi Windows
    - VLC Windows
    - TV's internal media player

    Sample:
    I created short samples showing end credits with yellow text on black background:
    Uploadfiles.io - contour issue samples.7z


    Support logs:
    I don't think logs will help here.
    However, I can supply logs later if needed.

  • If you can pause the video with the stained letters, can you also get us a screendump?

    Attach a usb keyboard and press 'PrtScrn', the file will be in the screenshots folder.

    Or try kodi-send --action="TakeScreenshot"via SSH.

    The samples work okay for me so far, but that is on Nvidia graphics.

    I'll have a try later on a Wetek HUB s905 box.

  • Ohh noooo...
    Does "only fixed by AMLogic" not automatically mean it will never be fixed? ;(

    But why is there a disconnect between your statements?
    Is it possible this is OK in Android for S912 and NOK in Android for S905?
    Or did one of you two just not look close enough?

  • I also checked with Android and the issue is also present in Android. I'm afraid this means that it can only be fixed by Amlogic.

    But I don't have this issue in Android for S912, looks like this is some parameter in system

    Edited once, last by boot2k3 (August 15, 2017 at 1:15 PM).

  • If it really is OK on Android for S912 - maybe there is a way to port HEVC decoding parameters/settings etc. to S905 and LibreELEC for both?

  • If it really is OK on Android for S912 - maybe there is a way to port HEVC decoding parameters/settings etc. to S905 and LibreELEC for both?

    If somebody knows what parameter do we need than I can check their values in my Android

  • First of all you need to confirm that "Android Kodi" uses HW-accelerated decoding. You should also try the built-in Media Player app and not Kodi.

    Second thing is that Amlogic modifies their decoder from one kernel release to another and it's quite possible that the issue was not present at some point. "Android on S912" tells nothing if you don't know kernel revision it was built from. You can try using 8.0.x builds to check if the issue is present.

  • Yes, Kodi uses HW-accelerated decoding on my S912 Android, also in other players h265 picture looks good

    Android 6.0.1

    Kernel - 3.14.29

    I don't have the possibility to check 8.0.x versions right now, may be somebody else can do this

  • If you can pause the video with the stained letters, can you also get us a screendump?

    Attach a usb keyboard and press 'PrtScrn', the file will be in the screenshots folder.

    Or try kodi-send --action="TakeScreenshot"via SSH.

    Taking a screenshot works fine with x264, but I just get whatever was displayed in x264 before when I try to take a screenshot of the x265 video....


    I can also confirm that the issue is not present when hardware decoding is deactivated.
    That is however not an option for HEVC of course...


    I would really appreciate if fixing this issue could become a priority.
    HEVC hardware decoding is one of the biggest selling points of these boxes. It should work right.

    If the S912 Kernel 3.14.29 route does not work, is there a way to address this with AMLogic?