Experiments with hw decoding

Help & Support Operating System
1

Hello CoreELEC developers.
I am trying to figure out how hardware decoding works on amlogic devices to try and fix some problems with moonlight-embedded.

So I found this project hello_video_cx example which shows basic usage of the vcodec. I’ve made basic adaptations for support for my test video which uses h265. The video can only be played if there is no container and its in raw bitstream format. But there are some problems. I am running latest nightly of coreelec-ng.

  1. the video, even though ffprobe reports its framerate is 60/1, plays at some unknown rate and slows down and speeds up randomly based on buffer size.
  2. after terminate signal is sent, there is a kernel error for trying to free bad address.
  3. playing the same raw bitstream file in Kodi (though I had to change the file format to something else, i chose .mkv) also wasn’t smooth. It also did not play at the correct frame rate.

This is my modification: testing amlogic decoder · GitHub
This is a sample folder: Dropbox - AMLOGIC TEST SAMPLES - Simplify your life
dmesg kernel errors: http://ix.io/3tR4

For testing, the sample has to be in the same folder named ‘test.h265’ and before executing echo 0 > /sys/class/video/disable_video.

Also, I’m guessing the non -ng version wouldn’t have this problem, because my project worked better there. I can’t test it though, my box doesn’t like switching between -ng and non-ng versions. That would mean there’s a bug in the -ng video kernel drivers?

I would be very thankful for your help and support.
Best regards.

2

I did some research while updating moonlight-embedded and compared the dmesg output of Kodi streaming H265 and moonlight streaming H265 content. The difference found is a different decoder used (VDEC_TYPE_FRAME_BLOCK).
This change occurs in one commit in Kodi, adding ‘multi_vdec’ parameter.
So I added the parameter in moonlight-embedded and no kernel error occured with Trying to vfree() bad address but the display was blank. Removing the multi_vdec returns back to the VDEC_TYPE_STREAM_PARSER which does different things and in the end throws the Trying to vfree() bad address while releasing the decoder.

A bit of googling and found this repo with some explaining of what’s happening and a solution with chroot that apparently fixes this issue. Everything else throws some kind of error or makes a blank screen.
Can someone explain what is happening here? Why is only CoreELEC kodi getting no error? Are there hardcoded values in the driver or OS or smth?

dmesg output with multi_vdec

[ 8124.200791@2] the demux clock on, ref cnt: 2002
[ 8124.200800@2] the parser_top clock on, ref cnt: 2002
[ 8124.200803@2] the vdec clock on, ref cnt: 2001
[ 8124.200862@2] vdec_create instance ffffff8012ca7000, total 1
[ 8124.201010@2] no drmmode
[ 8124.201064@2] The fw has been loaded.
[ 8124.201073@2] vdec_init, dev_name:ammvdec_h265, vdec_type=VDEC_TYPE_FRAME_BLOCK
[ 8124.201778@2] decoder_bmmu_box_alloc_box, tvp_flags = 0
[ 8124.202929@0] [0]dynamic_buf_num_margin=8
[ 8124.202938@0] [0]double_write_mode=2304
[ 8124.202948@0] [0]h265:pts_unstable=0
[ 8124.202952@0] [0]h265: ver (201602101,0) decinfo: 1920x1080 rate=1600
[ 8124.208562@1] [LOCAL], the fw (hevc_mmu_swap) will be loaded.
[ 8124.208662@1] [0]vh265 mmu ucode swap loaded 7665c000
[ 8124.208727@1] vfm map vdec-map-0 created
[ 8124.208751@1] ppmgr local_init
[ 8124.208761@1] di_receiver_event_fun: vframe provider reg ppmgr
[ 8124.209825@1] DI: reg f
[ 8124.209934@0] ppmgr local_init
[ 8124.209998@3] vdec_init, vf_provider_name = vdec.h265.00
[ 8124.210167@3] vdec->port_flag=0x102, port_flag=0x10b
[ 8124.210615@0] PPMGRVPP: info: task: quit
[ 8124.210693@1] ppmgr local_init
[ 8124.210704@1] DI: di_receiver_event_fun , is_bypass() 1 trick_mode 0 bypass_all 0
[ 8124.210706@1] DI: di_receiver_event_fun: unreg
[ 8124.210707@1] DI: provider name:(null)
[ 8124.210733@3] DI: di_unreg_process unreg start 1.
[ 8124.210737@1] di:no w
[ 8124.210744@3] video_vf_unreg_provider: vd1 used: false, vd2 used: false, keep_ret:0, black_out:1, cur_dispbuf: (null)
[ 8124.210751@3] keep frame skip, disable video again.
[ 8124.210755@3] VD1 AFBC 0x0.
[ 8124.210764@3] DI: di_unreg_process vf unreg cost 0 ms.
[ 8124.210765@3] DI: di_unreg_process unreg stop 1.
[ 8124.210799@3] di_unreg_process_irq disable di mirror image.
[ 8124.210802@3] DI: di_unreg_process_irq:cma release req time: 7824244 ms
[ 8124.210809@3] di:retry cnt=0
[ 8124.210819@3] di_cma_release:release 0 buffer use 0 ms(7824244~7824244)
[ 8124.211762@1] DI: unreg f
[ 8124.211796@1] vdec_disable_DMC input->target= 0x1
[ 8124.212141@3] vdec_release instance ffffff8012ca7000, total 1
[ 8124.212273@3] the vdec clock off, ref cnt: 2000
[ 8124.212277@3] the parser_top clock off, ref cnt: 2001
[ 8124.212280@3] the demux clock off, ref cnt: 2001

3

Kodi do send frames to the hardware decoder, not a stream.

Amlogic introduced the multi decoder to decode multiple streams parallel in hardware. Currently it’s possible to decode up to 9 different media streams simultaneous. This mean it’s possible to feed up to 9 different videos on one screen, all hardware decoded.

It was needed to limit it to one stream as Kodi is not designed to handle more than one stream:

4

I’ve noticed this patch so I’ve figured out that although hw supports it, you cannot decode more than one stream at once. But Kodi isn’t running when I’m testing this.

My problem is, why when I have add the multi_vdec parameter, the kernel error goes away and the screen doesn’t show anything. Because from what I’ve checked out in the media_modules repo, the flags assigned to the multi decoder are only responsible for different memory copying and different queues, but all seem to be going through the same decoding process: so if I provide the whole frame at once, it should display the frames. But the black screen problem seems like a flag that’s hiding it or vfm mapping is wrong (or if there’s any other clue, is Kodi doing anything else?).

Now the second thing that I don’t understand is why there were no problems when the guy from repo ran Kodi with chroot (and shouldn’t that root be the exact setup coreelec has…)?? When he wasn’t running Kodi in chroot he got the exact same problems (vfree errors and multi_vdec made blank screen). What the heck is happening here?

5

multi_vdec got fixed by vfm mapping, now it’s working as expected.
echo "rm default" > /sys/class/vfm/map
echo "add default vdec.h265.00 ppmgr amvideo" > /sys/class/vfm/map
Proposing this as solution, though I would like to get an explanation on why when multi_vdec isn’t there I get the kernel error.

6

I think when using multi_vdec the vfm map is set by the kernel. Before it was handled by kodi

7

This is interesting because for Kodi the kernel vfm map works just fine, but for my application it doesn’t. Then again I also removed some receivers so it might just be that I don’t handle one of them and it doesn’t work that way.

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.