Allwinner H6 HEVC?

Quote from offbeat

I'd say this VP9 fix patch should go to master, nice job!

Thanks for testing! This is just a quick hack and it uses more memory than necessary for 8-bit videos (unconditional buf_size *= 2;). I'll make proper patch series soon, hopefully over next weekend.

Quote from offbeat

10bit HDR plays with washed out colors, but thats probably expected, H6 HDMI hardware tonemapping most likely isn't implemented yet.

I suppose you're testing this on non-HDR capable screen? During writing 10-bit HDMI output support, I noticed that HW does proper downscale from 10-bit to 8-bit, but that is probably just averaging. There is HW for applying HDR tonemapping, but I have no idea how to use it nor how to integrate it in DRM framework.

Quote from offbeat

Typical 4K 8bit VP9 decodes at ~32 FPS, and 4K 10bit HDR is slower at ~24FPS. Probably ffmpeg decode path isn't 100% optimized yet.
Allwinner datasheet only promises "VP9 Profile 0/2 4K@30fps", so 4K@60 most likely isn't achievable on H6.

Yeah, ffmpeg is not optimized yet. As I said before, adopting RPi HEVC approach should yield more performance, but that probably won't happen soon.

Quote from offbeat

Tested this patch on both master(cma=1024M) and iommu branch.

Looking good, not a single error in logs!

We can't afford to set CMA so high, some boards only have 1 GiB of RAM. But I'm glad IOMMU doesn't report any issue. This means my quick patch is sound.

Quote from jernej

I suppose you're testing this on non-HDR capable screen? During writing 10-bit HDMI output support, I noticed that HW does proper downscale from 10-bit to 8-bit, but that is probably just averaging. There is HW for applying HDR tonemapping, but I have no idea how to use it nor how to integrate it in DRM framework.

Yes, my H6 box is connected to 12-year old 1080p SDR TV, used to be rather high-end. According to EDID it supports 10bit and 12bit colors, but its definitely way too ancient for HDR.

Can test on modern HDR capable monitor if needed, but guess not much point until H6 HDMI driver gains ability to send HDR metadata to display.

Quote from offbeat

Can test on modern HDR capable monitor if needed, but guess not much point until H6 HDMI driver gains ability to send HDR metadata to display.

That ability exists for some time now and it works for HEVC videos, didn't test VP9 yet (I heard HDR metadata is packed differently in VP9 streams). However, colours are still off - HDR is usually connected with 10-bit output, which isn't implemented yet.

EDIT: one IOMMU issue is probably fixed with https://www.spinics.net/lists/kernel/msg4055249.html

EDIT2: above patch indeed fixes kernel warning and H6 indeed sends HDR info to display when playing your Costa Rica VP9 10-bit HDR demo, I updated my iommu branch, if you're interested

Quote from jernej

I updated my iommu branch, if you're interested

Thank you, no more drm_gem errors!

Retested my NASA and F1 .ts HEVC samples. Interesting thing, all three samples fault IOMMU when fed through ffmpeg command line at max speed, but only F1 faults when played on normal speed through Kodi.

Will test HDR metadata tomorrow, when I get to monitor.

offbeat this patch http://ix.io/3QwZ should improve VP9 decoding speed and hopefully lower issues with Cedrus based decoding. It turns out that Android box is running VP9 core on much higher frequency and Cedrus on slightly lower. While at least in Cedrus case it doesn't seem much, it can be just enough to avoid issues. Let me know if this makes VP9 4k 30fps fast enough for you. I would also like to know if HDR works for you.

Quote from jernej

should improve VP9 decoding speed

ffmpeg VP9 decoding test shows some improvement, but not much, can't reach 30fps for 4K HDR sample.

ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i COSTA.RICA.vp9.2160p60.HDR.mkv  -f null -

frame= 1644 fps= 28 q=-0.0 Lsize=N/A time=00:00:27.46 bitrate=N/A speed=0.47x 

Maybe bottleneck is elsewhere, or VP9 decoder clocks aren't set to 576MHz.
I see 552MHz for both decoders in clk_summary, if it can be trusted.

/sys/kernel/debug/clk/clk_summary
    pll-ve                            0        1        0   552000000          0     0  50000         N
       vp9                            0        1        0   552000000          0     0  50000         N
       ve                             0        0        0   552000000          0     0  50000         N

Quote from jernej

hopefully lower issues with Cedrus based decoding

IOMMU still crashes on my HEVC .ts samples

ffmpeg -hide_banner -hwaccel drm -hwaccel_output_format drm_prime -i NASA.x265.2160p60.ts -f null -

[   60.534272] sun50i-iommu 30f0000.iommu: Page fault for 0x000000000001c000 (master 1, dir rd)
[   60.534309] IOMMU: Level 1 page error
[   62.557439] cedrus 1c0e000.video-codec: frame processing timed out!

Quote from jernej

I would also like to know if HDR works for you.

Yes, HDR output works, my monitor does switch modes!
Colors look very similar for both SDR and HDR versions of Costa.Rica VP9 sample.
But obviosly 8-bit output, heavy banding in gradients while playing HDR.

Here are photos of monitor OSD with some technical data.

HDR:

SDR:

Thanks for report. Can you check if switching rendering method from "Direct to plane" to "EGL" avoids iommu issues? It does for me, at least for some videos.

EDIT: Actually, if ffmpeg decoding with -f null - works, I think issue might be in display driver or misreporting actual buffer information, like size or stride.

Quote from jernej

Actually, if ffmpeg decoding with -f null - works, I think issue might be in display driver or misreporting actual buffer information, like size or stride.

ffmpeg -f null - doesn't work for these HEVC samples, not display output involved.

But tested with EGL rendering, just in case, iommu still faults.

offbeat I converted NASA.x265.2160p60.ts to mkv with following command:

ffmpeg -i NASA.x265.2160p60.ts -c:v copy -c:a copy NASA.x265.2160p60.mkv

I can confirm that TS file indeed produces iommu errors but mkv with same data does not.

I already observed issues with TS files in the past, usually because they start in the middle of the stream, with B or P frames. Converting it to matroska takes care that stream starts with a key frame.

So as far as I can tell, there are three issues:

1. slow decoding loop in ffmpeg

2. rendering issue, probably DRM driver needs some improvement, possibly around YUV scaler (workaround is to use EGL rendering)

3. Cedrus needs to be more resilient to stream errors (mostly missing references for B and P frames)

I guess I'll only PR frequency fixes and leave iommu branch for now. I think it's more important to finish 10-bit HDMI output support and after that, add proper 10-bit output from Cedrus and Hantro (for VP9). EDIT: and of course proper VP9 10-bit support.

Quote from jernej

3. Cedrus needs to be more resilient to stream errors (mostly missing references for B and P frames)

Oh yes, from my personal experience, SAT stream quality goes from 100% bit-perfect to unwatchable mess of pixels, even with all the DVB error correction algorithms. Thunderstorms, snowstorms... can't beat physics.

H264 and H265 decoders as well as TS container parser just has to be resilient as hell, able to consume pretty much garbage input without crashing. Drop frames and move on.

offbeat

jernej

allwinner h6 running libreelec 10.0.2 still stutters without dirtyregion. even with it, it stutters time to time. this happens more often when framerate matching is involved but I am not sure as my content are generally all 24p...

oh and I use subtitles which adds additional problems.

the issues generally disappear if I use EGL instead of direct to plane but when I use EGL, then the box loses HDR.

anyway, just noticed that libreelec for allwinner h6 also has this problem that I reported in rockchip forum. Rock64 / RK3328 fails to trigger correct colorspace - Rockchip - LibreELEC Forum

looks like no one has answer to this.... so... don't people have this problem? =x