Vero 4K support #573
Comments
|
I'm bumping this and adding more logs: https://gist.github.com/antsu/b426d72a35e7b32fbad64f05552225ba Hope that someone will look into this sooner or later ;) |
|
Can you try specifying the target audio device manually? If that fails, try building with PulseAudio to see if the PA backend works. |
|
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:
Hope this gives some clues! |
|
What exact parameters are you passing to stream? What GPU is in your PC? You might try adding I implemented a workaround in moonlight-common-c for the most recent GFE version, which supports specifying the number of reference frames. moonlight-stream/moonlight-common-c@f6ae7fc |
|
The last time I simply ran I merged the recent commits, I'll compile, test using your suggestions and report back tonight. Thanks! |
|
Unfortunately specifying the h264 codec didn't change much, i got less errors in console but the screen is still black. |
|
OSMC and Vero 4k were updated to Stretch. Unfortunately the black screen issue still remains. |
|
Can you try run strace and see if it gives us anything useful? |
|
Yup, here's the log: https://paste.osmc.tv/isavozohoz |
|
Hello, I belibe this is a kodi and amlogic problem and not with moonlight. Please take a look here: try to set /sys/class/video/disable_video to 0 before starting moonlight |
|
Good find @danielfmo . Let us know how it goes @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.. |
|
@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. |
|
I won't be at home till Saturday, so I'll test it once I get back. |
|
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 <[email protected]<mailto:[email protected]>> 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 GitHub<#573 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AA47LK2y_Y3-UkVwr9nQbD2SpG3w338Kks5tUzQ4gaJpZM4PxdcC>.
|
|
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. |
|
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: |
|
Hopefully you're feeling better now. Thanks for giving this a go.
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? |
|
Hi Sam, thanks. I have indeed installed vero3-libamcodec-dev-osmc. I modified the 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:
|
|
Here's the output from moonlight from today's test @ 1920x1080: http://paste.osmc.tv/poqayipobo.vbs And the dmesg: |
|
Yes -- that's one way to get the compile to use the OSMC versions of libamcodec.
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. |
|
@cgutman @danielfmo might have some more ideas. I'll see if I can get access to an NVIDIA system to test this out with. |
|
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. |
|
@TheHacker66 Have you had any luck? |
|
We're happy to get hardware out to resolve this. |
|
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 |
|
Nothing yet unfortunately. 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. |
|
Anything on this yet? |
|
Unfortunately nothing has moved this forward yet. |
|
Hi
I am back from my travel now.
I think everything’s been covered here but if I can help or if there’s anything that needs looking in to me do let me know
Many thanks,
Sam
From: EvgeniySpinov ***@***.***>
Reply to: moonlight-stream/moonlight-embedded ***@***.***>
Date: Tuesday, 18 April 2023 at 08:21
To: moonlight-stream/moonlight-embedded ***@***.***>
Cc: Sam Nazarko ***@***.***>, Mention ***@***.***>
Subject: Re: [moonlight-stream/moonlight-embedded] Vero 4K support (#573)
Thank you for detailed explanation. Probably I'm missing something, but to my knowledge software encoding could be multi-threaded (Sunshine has this setting as well), and overhead is coming from sync of frames provided by multiple streams, which is reduced by optimizations made within x264 encoder, used by ffmpeg library, which Sunshine utilizes. Am I getting it wrong? Or there are some specifics within Sunshine on output pipeline?
From my personal experience, I see no difference in latency between NVENC (x264) and Software encoder (x264). In both cases it's noticable at ***@***.***/s comparing to native display. Reducing bitrate and/or resultion reduces latency for both of them. I'm using Ryzen 3600 - not a most advanced CPU. As well as 2 to 3 encoding threads (still have to find a sweet spot). CPU utilization is around 50-70% during game session, depending on game/scene/etc. More capable CPUs should reduce latency and utilization even further.
To summarize, from my experience, so far, it seems that increasing 20-50% on load for encoder (this is average computational effort increase to encode 10bit HDR frame, even though the size of frame is 1.25 times bigger compared to 8bit SDR frame), should still keep software econding as a viable option. This is in theory, and numbers though are a bit different (in a way of reduction) than you've provided. If you can share more details on why it's 2 times the frame size and what latency it might introduce, even in theory, let's say in ***@***.***@40Mbit stream - that would be great.
As for libswscale, it seems that you're right. There is workaround though, through using zscale filter from z.lib, which supports high bit-depth and wide color gamut conversions, including conversions involving FP16 and Rec. 2100 PQ. Not sure how hard it would be to incorporate into Sunshine though.
—
Reply to this email directly, view it on GitHub<#573 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLE42KSOCK6ZISJSVEDXBY6GJANCNFSM4D6F24BA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Ok, seems like I've found 1 more issue:
Unable to start streaming: Changing client codec to h265 or auto works without issues. I assume the issue is with those lines on Vero 4K+: i.e. seems that something wrong with codec setup on Vero 4K side, as stream is not even starting from server perspective. Config on the client side: UPD: Looks like issue is with resolution higher than 1080p. With 1080p h.264 works fine. Likely codec initialization fails on those lines: moonlight-embedded/src/video/aml.c Lines 96 to 99 in 5bb47ce According to xbmc/xbmc#10944 some devices (like with Amlogic S905X) should use VFORMAT_H264 codec for 4K streams, instead of VFORMAT_H264_4K2K. I'll prepare PR. |
|
Short update on H264 decoding:
If anyone can help with this - would be great. |
|
Hi, I'm resuming the thread because I tried compiling from source but I still cannot see the video. I assumed all the needed fixes were merged in master? |
|
Any update on this? I also tried compiling from source and I cannot see the video. I tried I'm on the Vero V. |
|
@samnazarko anything special we need for Vero V? #884 logs see to show the codec is not consuming input quickly (at all?) - lots of |
|
What codec is being used? |
|
I tried h264, h265 and av1. Same issue for all. |
|
OK, thanks for the feedback. |
|
I made some tiny bit of progress. Hope this helps. |
|
@cgutman: I continued my investigation and it seems you stumbled on both of these issues in the past that I'm currently facing. The first one is that I only see the first frame (similar to what happened to you in this comment). I don't know what those statuses mean, but I only see those (1, 5 and 53) in this case. Also, when using h264, I got the same issue that you got in this comment. Here's what I see in This time, I have a few questions for you:
Thanks for your help! |
|
Ok, I was finally able to stream some video! I had to remove this line in In order to write a proper patch, I would need to know why this was added back in c2036ac#diff-95d130942a7b36a52939da0fea295a6587be8b1249c5b7d2ac9e7018b77f561bR81. Thanks for your help. |
|
Hey everyone. Thank you very much. After a few years, I tried again to stream games to the Vero4k in 4k resolution and it works great now :) Versions: Moonlight Embedded v2.7.0 (self built I had to manually preload the aml.so for some reason. Also I have to manually set the output resolution. |
|
@maxanier curious where do you put this start script? |
|
I just put it in the home folder. I am stopping Kodi before streaming because I experienced lag/stuttering/issues when Kodi is running in the background. |
|
Hi. I also tried again now and after uncommenting the line mentioned by
@antoyo streaming works fine @ 1080p. I get some lag @ 4k but it might be
my lan speed or something else.
I have to stop Kodi as soon as I reboot otherwise I get no video at all.
This is great news! I'm also testing from a Vero V and others in the osmc
team tested with a Vero 4k. I use Nvidia while others had to add this to
aml.c to make video work with Intel cards:
static int framecount = 0;
If (++framecount % 60 == 0) {
return DR_NEED_IDR;
}
Just before the return at the end of the function aml_submit_decode_unit()
Thanks to everyone for testing and keeping this issue alive! And of course
thanks to moonlight devs!
Il ven 28 giu 2024, 14:46 Max Becker ***@***.***> ha scritto:
… I just put it in the home folder.
When I want to play, I have to connect via SSH and start the script.
Not ideal, but works for now. I have to start sunshine on my PC anyway.
I am stopping Kodi before streaming because I experienced
lag/stuttering/issues when Kodi is running in the background.
The start command is just there so it automatically relaunches
mediacenter after moonlight has finished (so only after streaming has
stopped).
—
Reply to this email directly, view it on GitHub
<#573 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE4Q5E56JE3MTI7IRLQYQ3ZJVLJXAVCNFSM4D6F24BKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJZGY4DEOBQG4YA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi, I'm also tinkering with my Vero V to get Moonlight to work. Thanks to this thread I was able to get it working by removing the line mentioned in #573 (comment) and building moonlight-embedded myself. Moonlight Embedded 274d3db (self built) I'm still struggling with the optimal settings though. Setting I found a recommendation to enable performance stats with Ctrl+Alt+Shift+S, but apparently this doesn't work in moonlight-embedded (someone mentioned this in Discord). This makes it a bit more challenging to find the optimal settings. Otherwise this looks promising! |
|
I continued testing Moonlight with my Vero V and it works fine, except when a black screen happens. This is resolved by rebooting the Vero. At first this seemed random, but then I noticed a pattern that every time I watched a video on OSMC, the black screen happened again. Maybe the video player does something with the frame buffer that stops Moonlight from being able to use it? I was able to capture the logs for both situations. There are some noticable differences, but I'm afraid I'm not knowledgable to make any sense of it. With video: Without video: |
|
I noticed as well that playing a video in OSMC changes some settings. This might help you: I run moonlight-embedded from Luna (I believe I use this add-on) and I modified the Perhaps you need to run some of these commands before running moonlight. Edit: @agboom: I saw you made a PR to Luna. If you want, I could send you the changes I made to Luna: I didn't make a PR because I figured I spent enough time to make this working. |
|
Hi @antoyo, thanks for replying! Indeed, I use Luna as well and shared some possible improvements. Thanks for your suggestion, I'll try it as soon as I have the time. If you have more changes you want to share, I'm certainly interested. It would be nice to have a plug-and-play experience with Moonlight for Kodi/Vero and Luna seems like the way to go right now. I have some more ideas for the long term, like app shortcuts in the main menu and automatic wake-on-lan. |
|
@antoyo Your solution works, thanks! Interestingly, the first line looks like it does the same as the (removed) line from write_bool("/sys/class/graphics/fb1/blank", true);Do the commands after resolve something maybe? The vfm map seems to be accessible from MBE so maybe we can add these lines to One issue solved, another pops up 🙈: I have a moonlight log from the session the delay occurs: https://paste.osmc.tv/elogetokay.coffee |
This is setting fb1 while the command in the script sets fb0. I guess it might work to change moonlight-embedded to use fb0, I don't know.
Is this caused by the commands I posted? I believe you'll find other people that had delays in this thread: perhaps they also posted the solution? [Moonlight]
address = myhostname
width = 1920
height = 1080
fps = 30
bitrate = 20000
packetsize = 1392
sops = false
remote = auto
localaudio = false
debug = false
audio = sysdefault
codec = h265
nounsupported = false
nomouseemulation = true |
Ah, good point, I missed that.
You're right, this has been mentioned before. I have |
|
From TheHacker666:
We put this together, since I had the same problem, but on steroids, 30 secs streaming,15 sec frozen video with streaming audio. Just then then rinse and repeat. the issue was that for each "blackout", they became longer and longer. With the help of another dev. at OSMC. We xperimented with clearing the buffer at intervals.. Why I probably had it worse then most, is my old desktop, Just Intel HD4600, first gen with some sort of quicksync. I'm guessing it's giving of a much "dirtier" streamthen modern nVidia does. Due to having a harder time keeping up with the system. The thought was force "clearing" Veros buffer, in order to reduce the build-up causing lag. Tjhe "modula 60" was to have it as a starting point. I was going to experiment with it, but I've gotten tied up in other projects. So, as long as you modulate is evenly dividable by the frame rate, it "should be good". Hope this helps someone. |
|
@zjoasan Thanks for your suggestion. I managed to add this patch. Sadly for me it doesn't help with the increasing latency. I probably need to find the right modulo value. I set it to 60 while keeping the fps at 60 too. Another side effect of this patch is that there's some kind of artifact pulsing about every second. If I change the modulo to 10 it pulsates faster (looks like about 6 per second), but the latency still increases over time. I tried to record a video of it, I hope this gives an idea: vid.mp4 |
|
After removing the
The behavior seems to be the same as described here: #662 |
|
This is completely unrelated to #662. In the case of #662, the Pi 2 was not rated for 1080p60, so it could not keep up without overclocking. The issue here is the same accumulation of frames due to mismatching between the rate of display and the rate of incoming frames problem I reported a long time ago: #573 (comment) We're reporting PTS values for every frame we submit, so I don't know what else we're supposed to do. We need some way of asking for overdue frames in the pipeline to be dropped or to at least limit the number of buffered frames. I'm not sure if there's a way to do that. TBH though, I think the answer is for the Amlogic software stack to leave this poorly-documented vendor-specific API and ancient kernel version in the past and start supporting standard V4L2, so you can use a modern client like moonlight-qt. Moonlight-Embedded is a legacy client from the dark ages of the 2010s when every SoC vendor invented their own bespoke video decoding and rendering APIs. Fortunately we're (mostly) past that era, and Moonlight-Qt's embedded packages already work great using standard V4L2+DRM+GL APIs on plenty of platforms like RK3288, RK3399, JH-7110, BCM2711, BCM2712, and probably more. |
|
I totally agree with @cgutman , there are better solutions, but as we are tied to this platform for now. I'm still trying to get it as good as it can get. With my old hardware, a modulo of 20 eliminate build up, at least for 20-ish minutes (60 fps). There is side effects, but hard to describe. Thanks for the info about PTS, will take it back to OSMC-devs and see if we can come up with more elegant solution. |
|
I agree, I didn't mean to imply that the issue was related, just that the behavior was the same. But yeah, RPI is a completely different thing. Having a working moonlight-qt would be awesome. I did try it out, but got no further than the main screen, no streaming. That makes sense now based on what you explained. I gathered at some point it had something to do with DRM and KMS, or lack thereof, and a newer kernel version would help, but my knowledge is very limited in that area. It's also out of scope of this issue, so I'll stop talking about it here. I have a thread over at OSMC Discourse about Moonlight dependencies if you'd like to weigh in, I certainly would like to learn! Anyway, regarding MBE, I've settled on 30fps for daily use. I'll try some more modulo values later. If I can help by testing anything, please let me know. |
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
-verboseof Moonlight Embedded: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
The text was updated successfully, but these errors were encountered: