Posts by chewitt

    I don't really see playback issues with 4K HEVC or VP9 media on S905X/S912 devices I have (other than seek). I hit play, occasionally see some garbage in the first few seconds but then it stabilises and plays to the end withouth issue. I am mostly playing self-ripped media though, and I rarely test PT audio because that involves fiddling with settings, and if you rotate through test installs as often as I do that's a chore to avoid. 4K SDR HEVC will work on an S905 box, but no HDR support in the chip (or tonemapping in software) and no VP9 on the chip. The decoders really do need adjust-refresh enabled so media plays at native rates. If you use a monitor that requires everything to be displayed at 60Hz or don't enable adjust refresh things don't run so well. I have no expectations of EGL rendering or any media with DRMPRIME disabled playing .. it's not how the image is intended to be used.

    If you want excellent hardware with average software; choose any RK or Allwinner chip we support. If you want something with average hardware and excellent software (hint, this is the better combo) get an RPi5. It lacks VP9, but will software decode up to 4K30 with online streams. Everything lacks AV1 right now. There is no such thing as future-proof.

    I've done some testing on a VIM2 board this morning. I can get DTS-core PT, but not DTS-HD MA PT, and my AVR is silent; unlike the N2+ that I tested which tried to fly my tweeters with noise. The fact S922X outputs noise and S912 does not is probably down to the different audio card drivers used, and the fact both are affected probably points to an issue in the common DRM layer; I'd guess the HDMI frame packing needs tweaking or some additional register poking to work, or something of that nature. S905X3 (SM1) is a minor evolution of S922X (G12B) hardware so will have the same issue. Comparisons with the legacy codebase are entertaining but have no technical merit as the kernel codebases are completely (100% of code) different.

    As a general rule H264 playback is solid and HEVC works 'okay' with adjust-refresh (start/stop) and PCM output. Don't expect HEVC seek to always work (the drivers aren't finished). Don't expect 3D and deinterlacing to work (not implmented) and poorly encoded media stolen from torrent networks will give poor results. The vendor codebase has a ton of hacks in ffmpeg to workaround media issues, and we don't replicate that. As per release notes, AMLGX works for a steadily increasing number of people, but it will not work for everyone.

    It should be using rtw89 which is a native kernel driver (not an external Realtek vendor driver). There isn't much we can do if the driver isn't performing well other than look at https://patchwork.kernel.org/project/linux-…e=&archive=both to see if there's anything we could backport that sounds/reads like a match; although usually the user report isn't technical enough and the patch descriptions are too deep-technical for an easy correlation of problems to patches.

    Please run "dmesg | paste" and "lspci -nnk | paste" and share the URLs so we can see if there's any specific errors and to confirm the exact hardware being used.

    I've made some progress in the last week or so with hardware decoding of 10-bit media and I now see a black screen when playing 10-bit HEVC content. That might not sound impressive, but not instantly crashing the SoC when opening the codec is a huge leap forwards since it allows meanginful further testing to be done; and I can now see there is a load of plumbing missing in ffmpeg that's related to V4L2 format modifiers that's needed to complete the puzzle.

    I've also replicated the DTS-HD MA issue in recent days. I'm not sure what the source of that issue is, but as the Kodi side of things works with multiple other SoC platforms it's almost certainly something specific to Amlogic chips and suspicion falls on the AXG audio driver and/or the HDMI related code in the DRM layer. I need to run tests with an older S905X or S912 device to see if the same issue is present on them or not?. If not, that probably narrows the issue to the AXG audio driver (as the DRM code is common; although there are different code paths in places) and if it also doesn't work on GXL/GXM boards it could be something missing in both AXG and AIU drivers, but more likely something in common DRM code. I'm a little fixated on the codec work at the moment though so might not get around to that test quickly, and even once it's done all I can really do is flag the issue to the upstream kernel maintainers. So for now .. DTS core is all that works.

    antonvier Kodi detects audio capabilities based on the EDID data on the HDMI connection. It's also odd that the kernel detects the audio hardware, but Kodi then fails to open the device(s) to check properties. The very limited list of resolutions shown here would normally suggest a problem in the display chain. That can result in failure to detect normal 1080p/4K modes etc. but doesn't explain the lack of audio hardware.

    Code
    dtoverlay=vc4-kms-v3d
    max_framebuffers=2
    hdmi_enable_4kp60=1

    Comment the above ^ out in config.txt. Disabling 4K60 (which 99% of users don't need, 4K30 is enough) also reduces the power draw which might help with an inadequate PSU issue. That's the only real red-flag that I can see; insufficient stable power (under-rated for current normally) will sometimes manifest all kinds of weird issues. RPi4 needs 5V/3A to be stable. Recycled phone chargers or using USB ports on a TV/monitor generally won't work. Check the PSU out. Also check cables/ports, and if you inflicted self-punishment with an Argon case, remove the board from the case before retesting.

    Any difference?

    FWIW, I can replicate the original issue report of no DTS-HD-MA audio. I've no idea what the problem is though, other than it's most likely to be an issue in the DRM layer, and right now (and since I only use PCM output in testing) I'm not motivated to look into the issue further. I am highly confident the issue is specific to Amlogic hardware so no need for you to find RPi threads and make "me too" posts there, it's only adding distraction to other people's (different) issues.

    I don't have any Dreambox hardware, and in the several years since I added upstream support for _emanuel_ nobody has ever bothered to explain (or, here's a crazy idea, add some content to the open wiki to document) that Dreambox devices require some wonky boot arrangement to run the AMLGX image. That only became clear about a week ago, and If I'd have known that before I probably wouldn't have bothered creating and sending the device-trees upstream. Ho hum.

    The latest Dreambox device(s) that _emanuel_ is now asking me to support are Android based, so that's been on my mind among other things. Yes of course the older stuff uses Yocto/OE to make something from the Android BSP from Amlogic. Regardless, the point still stands: If you want an OS where everything works, you need to run the vendor firmware image.

    The AMLGX image is generally curated to use the best (or newer hardware, least-worst) default settings. You can use 4K VP9 as that works, but you will not get far with 4K HEVC because hardware decode is intentionally disabled to prevent the SoC crashing instantly when the V4L2 codec is opened, and that caps HEVC to 1080p max in software. Forcing EGL rendering instead of Direct-to-Plane only loses the benefits of DRMPRIME and makes things worse; and hence I stopped reading the 'testing' .. it's obviously a user flailing around with random settings in the hope of finding a magic combination that beats the negative but clear description of current state provided in release notes. Good luck with that.

    Things moved forwards, but overall not much changed. Amlogic engineers recently submitted support for DRM (video output) and audio support on S4 devices (must-haves for an LE image) but all their patches are poor quality and require many iterations to adapt to upstream standards. They are also slow at iterating, so it will be a while before those changes get merged. I've made a note to ask Khadas for a VIM1S sample (S905Y4, so related to S905X4) to explore packaging.. but I have low expectations of doing much with the board for a while yet.