Vero 4K support

[TheHacker66]

NVidia Geforce Experience version: 3.9.0.97 Moonlight Embedded version: 2.4.3 Moonlight Embedded source: compiled from source Moonlight Embedded running on: Vero 4K Moonlight Embedded running on distribution: OSMC

Verbose output -verbose of Moonlight Embedded:

Searching for server... Connect to 192.168.178.20... No mapping available for meson-ir (19000000000000000000000000000000) on /dev/input/event2 No mapping available for gpio_keypad (10000000010000000100000000010000) on /dev/input/event0 No mapping available for cec_input (100000008e1b0000ec0c000001000000) on /dev/input/event1 Initializing platform...done Resolving host name...done Starting RTSP handshake...done Initializing control stream...done Initializing video stream...done Initializing audio stream...done Initializing input stream...done Starting control stream...done OPEN es DEVICE codec_init amstream version : 2.0 [codec_init 732]type =1 [codec_init 740] Starting video stream...done ALSA lib pcm_direct.c:896:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA lib pcm_dmix.c:1034:(snd_pcm_dmix_open) unable to initialize slave Starting audio stream...Alsa error code -22 Audio stream start failed: -1 Stopping video stream...ENet wait interrupted Control stream connection failed Loss Stats: Transaction failed: 11 [codec_close 851] [codec_close_cntl]video codec close return=0! done Stopping control stream...done Cleaning up input stream...done Cleaning up audio stream...done Cleaning up video stream...done Cleaning up control stream...done Cleaning up platform...done EVIOCGRAB failed with error 16 EVIOCGRAB failed with error 16

I have forked the repo and made the necessary changes for moonlight to compile. AMLogic support is already included in the Vero 4K.

Is someone willing to check what might be wrong? Thanks

[TheHacker66]

I'm bumping this and adding more logs:

https://gist.github.com/antsu/b426d72a35e7b32fbad64f05552225ba

Hope that someone will look into this sooner or later ;)

[cgutman]

Can you try specifying the target audio device manually?

If that fails, try building with PulseAudio to see if the PA backend works.

[TheHacker66]

Hi @cgutman!

Thanks for the suggestions, specifying the audio works (kinda), i can hear crackling sounds coming from the tv but the video is still black.

Something interesting coming from the verbose output:

[codec_init 732]type =1 [codec_init 740] Starting video stream...done Starting audio stream...done Starting input stream...done EVIOCGRAB failed with error 16 EVIOCGRAB failed with error 16 Alsa error from writei: -32 Returning RTP packet queued for too long Received OOS audio data (expected 28132, but got 28133)Waiting for IDR frame Alsa shortm write, write 48 frames Alsa shortm write, write 64 frames Alsa shortm write, write 192 frames Alsa shortm write, write 64 frames Alsa error from writei: -32 Unrecoverable frame 197: 16+2=18 received < 21 needed Network dropped an entire frame codec_write error: ffffffff [codec_close 851] [codec_close_cntl]video codec close return=0! OPEN es DEVICE [codec_init 732]type =1 [codec_init 740] [codec_reset:1199]ret=0 Requesting IDR frame on behalf of DR Waiting for IDR frame Waiting for IDR frame Alsa error from writei: -32 ...

Hope this gives some clues!

[cgutman]

What exact parameters are you passing to stream? What GPU is in your PC?

You might try adding -codec h264. I found that some Amlogic chips don't like the default h.265 stream that GeForce Experience produces.

I implemented a workaround in moonlight-common-c for the most recent GFE version, which supports specifying the number of reference frames. https://github.com/moonlight-stream/moonlight-common-c/commit/f6ae7fc2b4d2c0c5d2a8cb8ebc55f4157156c9f1

[TheHacker66]

The last time I simply ran moonlight stream -audio hw:0,0 -platform aml. I have a GTX 770.

I merged the recent commits, I'll compile, test using your suggestions and report back tonight. Thanks!

[TheHacker66]

Unfortunately specifying the h264 codec didn't change much, i got less errors in console but the screen is still black.

[TheHacker66]

OSMC and Vero 4k were updated to Stretch. Unfortunately the black screen issue still remains.

[samnazarko]

Can you try run strace and see if it gives us anything useful?

[TheHacker66]

Yup, here's the log: https://paste.osmc.tv/isavozohoz

[danielfmo]

Hello,

I belibe this is a kodi and amlogic problem and not with moonlight.

Please take a look here: https://forum.odroid.com/viewtopic.php?f=91&t=15456&p=171714&hilit=%2Fsys%2Fclass%2Fvideo%2Fdisable_video#p171714

try to set /sys/class/video/disable_video to 0 before starting moonlight

[samnazarko]

Good find @danielfmo . Let us know how it goes @TheHacker66 . I can patch Kodi to reset this on exit; or you can set it in a startup script in Moonlight.

[TheHacker66]

Well guys, unfortunately setting that flag before running moonlight didn't change anything. I can run another strace with the flag set to 0 if needed.

So close yet so far..

[samnazarko]

@TheHacker66 I've sent you a PM with a kernel with amlvideo debugging on. It may give us some clues if the decoder isn't happy.

[TheHacker66]

I won't be at home till Saturday, so I'll test it once I get back.

[samnazarko]

Cool. I found why HEVC wasn't tolerated by Moonlight (buf margin needs a bump). This also fixed a couple of playback issues.

Sent from a mobile device, so please excuse the brevity of this reply

On 14 Feb 2018, at 19:30, TheHacker66 notifications@github.com<mailto:notifications@github.com> wrote:

I won't be at home till Saturday, so I'll test it once I get back.

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/irtimmer/moonlight-embedded/issues/573#issuecomment-365718655, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA47LK2y_Y3-UkVwr9nQbD2SpG3w338Kks5tUzQ4gaJpZM4PxdcC.

[TheHacker66]

Hi, sorry for not replying earlier.

I installed the kernel and rebooted. Unfortunately there seems to be an incompatibility with the latest GFE version because moonlight complains about an udp port which is open in the firewall and that was working before. The version I have installed is 3.12.0.84

I tried uninstalling that and installing the version available on nvidia's site (3.12.0.79) to no avail. Deleting firewall rules (that were recreated after the install) didn't change anything.

I'll try to reinstall a even older version to see if the problem goes away.

[TheHacker66]

Ok, I reinstalled the version I had when I started this thread (3.9.0.97) and moonlight started working again.

Sorry, I forgot to run the modprobe command..

Here's the correct log:

https://paste.osmc.tv/monaxowoyo

I checked the disable_video flag and it was set to 2, is it normal?

EDIT: I don't see anything wrong in this new log, but I saw some errors in the previous log, so I'll leave it here: https://paste.osmc.tv/ezeludacig

[samnazarko]

Hopefully you're feeling better now.

Thanks for giving this a go.

[ +0.010327] codec:vdec1 video changed to 0 x 0 0 fps clk->200MHZ

I think this is the problem. The video decoder doesn't seem to be set up correctly.

I believe Moonlight uses libamcodec. Can you confirm if you compiled Moonlight using the libamcodec-dev-osmc package?

[TheHacker66]

Hi Sam, thanks.

I have indeed installed vero3-libamcodec-dev-osmc. I modified the cmake/FindAmlogic.cmake file to point to /usr/osmc/lib/ where libamcodec.so is located.

It is correct?

EDIT: That line you mentioned is right at the end just before i stopped the stream via Steam, so I think it's right. There's another one which seems correct:

[ +0.000048] codec:vdec1 video changed to 3840 x 2160 60 fps clk->667MHZ

[TheHacker66]

Here's the output from moonlight from today's test @ 1920x1080:

http://paste.osmc.tv/poqayipobo.vbs

And the dmesg:

https://paste.osmc.tv/azezuderow

[samnazarko]

Yes -- that's one way to get the compile to use the OSMC versions of libamcodec.

[ +0.007596] codec:vdec1 video changed to 0 x 0 0 fps clk->200MHZ

This still looks to be the problem. I'm not sure why the decoder is not getting hints properly; but I suspect something in Moonlight isn't setting up the amprivate structs properly.

[samnazarko]

@cgutman @danielfmo might have some more ideas.

I'll see if I can get access to an NVIDIA system to test this out with.

[TheHacker66]

You should still have remote access to my Vero 4k to fiddle with. I won't be at home tomorrow but I will be this weekend if you need me for tests.

[williamluke4]

@TheHacker66 Have you had any luck?

[TheHacker66]

Nope. I think we need @cgutman or @irtimmer help.

[samnazarko]

We're happy to get hardware out to resolve this.

[maxanier]

Currently considering buying a Vero 4k, but I would like to also use moonlight on it. So I was wondering if you had any success in the meantime? Thank you

[samnazarko]

Nothing yet unfortunately. I can't think of anything we have significantly diverged with that would cause such issues.

I'm happy to ship hardware to any developers. In the interim, I'm going to see if I can set up an NVIDIA system to look in to this myself. I am away for a few weeks however.

[ZacWolf]

Anything on this yet?

[samnazarko]

Unfortunately nothing has moved this forward yet.

[maxanier]

Finally got around testing it myself on my new Vero4k+, but I got the same issue: Black screen, but some crackling audio.

(@samnazarko ) I am using the OSMC August update with the vero4k+ video improvements installed.

I have compiled moonlight-embedded from the master branch, but adjusted cmake/FindAmlogic.cmake to include the /opt/vero3/include and /usr/osmc/lib paths (gist).

I tried 720,1080,4k as well as h264 and h265. Result is the same. Logs look similar to TheHacker66 ones: moonlight stream -platform aml -localaudio -codec h265 -1080 -verbose: MoonlightLog dmesg

I tried to do some debugging, but the only thing I could figure out so far is that the codec_write error: ffffffff log message is caused by the codec handle is temporarily unavailable (11 EAGAIN) in amcodec codec_write but this is probably normal behaviour. I do not really know where to continue looking since I can't really tell if the problem lies in moonlight (embedded/common-c) or in amcodec or somewhere else in the vero4k binaries. @irtimmer could the black screen be related to the missing IDR frame?

[samnazarko]

Glad to hear you've received the new device.

Did you stop Kodi first? sudo systemctl stop mediacenter

[maxanier]

Yes

[maxanier]

Would love to help in some way, but I don't really know where to start, because I don't really know where to start looking

[samnazarko]

I understand. We need some assistance from the Moonlight guys here. Hopefully there is an opportunity to do this.

[cgutman]

The IDR frame warnings are a symptom of the problem. When codec_write() fails, the error triggers the IDR frame request to resync with the host (since video data was lost).

Can you see whether it's failing on the first codec_write() call or a later one? The AML decoder may expect to receive an entire frame at a time, rather than split up as we are currently submitting them. Can you try modifying the code to submit the entire frame at once like the SDL backend does? https://github.com/irtimmer/moonlight-embedded/blob/master/src/video/sdl.c#L66

From this Kodi fork, it looks like they are explicitly checking for EAGAIN and continuing to retry until it clears. You could also try that with or without the above change too. https://gitlab.com/ember-dev/kodi/blob/46dc687ff8c2ea711021b4b98a562eb9ce21a4d8/xbmc/cores/dvdplayer/DVDCodecs/Video/AMLCodec.cpp#L679

[maxanier]

Thank you very much for your response.

I implemented your first suggestion and it seems to fix the codec_write errors. Moonlight stops complaining. However, the screen stays black. I still get the crackling (maybe slowed down) steam start sound (unless I use -localaudio).

Updated aml.c Moonlight Verbose Output Dmesg

I cannot tell much from it, but one thing that confuses me is a "init_decode_head_hw: (1920, 1088)", but I do not think this is related to our problem.

Just out of curiosity I logged the size of the frames passed to codec_write (output). The output looks reasonable to me, about 30 logs per second, and the size starts large and gets smaller, probably because the transmitted frames is not changing (Steam start screen). But that are just guesses.

I also tried playing around with /sys/class/video/disable_video and more, but it does not help.

@samnazarko maybe something in osmc is preventing the decoded stream from actually being displayed. After stopping kodi, it displays the console output (from my rc.local), but after starting/stopping moonlight everything stays black until I restart kodi.

[samnazarko]

See https://github.com/osmc/libamcodec/blob/2017.10/amplayer/player/player_av.c#L1572 for how to set up decoder.

I also tried playing around with /sys/class/video/disable_video and more, but it does not help.

You could try booting with Kodi disabled (systemctl disable mediacenter); in case Kodi or our watchdog are causing issues.

[maxanier]

Unfortunately, disabling kodi did not help.

I had a look at the code you linked, but could see anything interesting. I do not have any experience with video en/decoding, so I might have missed something relevant.

After that I had a look at https://github.com/osmc/libamcodec/blob/master/examples/esplayer.c which setups framebuffer and axis, but that did not help either.

Is there any way to get more debug log from the libs or kernel parts responsible for actually displaying what is passed to codec_write?

[samnazarko]

Sorry for the late reply on this.

I was able to modify the examples Makefile target and build simple_player. With Big Buck Bunny I can initialise the VPU and see frames being decoded; but I only get a black screen.

It's probably worth comparing the framebuffer state (sys/fb) when playing a video via Kodi vs trying to use Moonlight.

[maxanier]

Finally got around to try it again. I updated the Vero to the December update, pulled all the latest upstream changes of moonlight-embedded and rebuild. But the issue remains.

I tried comparing the state of /sys/class/graphics/fb0,1 /state,mode, ... as well as /sys/class/display/axis,mode. But since I couldn't find any helpful documentation on the dozens of things I am not smarter than before. The only thing I noticed is that /sys/class/graphics/axis and /sys/class/graphics/mode are not updated if I stop kodi and start moonlight. The values of the last video playback remain, even if moonlight runs on a different resolution.

I am also not sure if it has any effect to directly modify those (e.g. echo 2 > /sys/class/display/disable_video). The values are update, but I never manged to see any difference on screen.

[TheHacker66]

Hey everyone, I also updated my fork and tried to no avail. Saw that some aml libraries were added to the cmake and fixed the paths for osmc but it didn't make a change.

hope @irtimmer or @cgutman have some other clue.

[maxanier]

I decided to give up on this. It feels like we are close, but without some experience with the Linux display system it is rather difficult to get it to work. I am back to RPi3 for anything non 4k related, because neither moonlight nor hyperion work (well) on the vero.

[samnazarko]

Hyperion should work well in the next update. Unfortunately I'm not sure how to proceed with Moonlight.

[EvgeniySpinov]

I'd like to join the battle for the moonlight + vero, cause I do not want to deal with 1080 on raspberry pi.

@samnazarko Is there any way to emulate Vero 4K+? I have only 1 device and it's used in living room and family would not be happy if I would take it for experiments.

@maxanier Were you able to do super-verbose output by moonlight on connect (besides strace)? Is there such a mode? On your raspberry, you're also running OSMC? Upstream version and everything works? I also have Raspberry pi 3 where moonlight works without any hick ups. I have older version of the OSMC there though (Kodi 17.x).

[samnazarko]

Is there any way to emulate Vero 4K+?

Not really unfortunately.

[cgutman]

Does the Vero 4K support the standard V4L2 stateful/stateless decoding APIs? If so, that's probably way to go, but Moonlight Embedded doesn't have a standard V4L2 backend yet. V4L2 is the way forward to get out of the proprietary vendor-specific API hell that is currently the embedded world.

The V4L2 stateful API is supported in upstream FFmpeg (h264_v4l2m2m and hevc_v4l2m2m decoders), but the V4L2 stateless API requires out-of-tree patches (v4l2request hwaccel) while the kernel interface is still being completed. Which one you will need depends on how the Amlogic V4L2 kernel drivers are written.

If you want to test V4L2 on the Vero 4K, you can try building moonlight-qt with a V4L2-enabled FFmpeg build. Then you can test V4L2+EGL or V4L2+DRM rendering and see if performance is acceptable. Users on the RK3288/RK3399 with V4L2+EGL and V4L2+DRM on the Pi 4 for HEVC have reported good performance.

If V4L2 does work well, it shouldn't be too hard to drop in similar code in Moonlight Embedded to what Moonlight Qt does. Moonlight Embedded doesn't have overlay support or windowed support (on most devices), so it's probably sufficient to just implement the V4L2+DRM path and omit V4L2+EGL.

[samnazarko]

Does the Vero 4K support the standard V4L2 stateful/stateless decoding APIs? If so, that's probably way to go, but Moonlight Embedded doesn't have a standard V4L2 backend yet. V4L2 is the way forward to get out of the proprietary vendor-specific API hell that is currently the embedded world.

Currently the stable (supported) kernel is 4.9 and relies on the downstream AML V4L2 interface. So V4L2/M2M implementation isn't complete and effectively still a shim around amcodec.

[renatobellotti]

Has there been progress? :)

[samnazarko]

Unfortunately not.