Vero 2 Playback/Stop glitch with some videos

[quote=“sam_nazarko, post:5, topic:13418, full:true”]
Do you mean green kind of lines when you stop?[/quote]

No, it’s more like the frame buffer containing random data, which results in it looking like a few frames of static noise (as seen at the video I mentioned above, http://sendvid.com/u11xj59c)

Just a small addition - I’ve noticed that if I have ‘Adjust display rate to match video’ set to ‘OFF’, then this static appears for a longer time at the start of the video - almost like the it’s there until it’s buffered/decoded a full frame - I think that if ‘Adjust display rate to match video’ is set to one of the other settings (always etc), then this state isn’t visible for as long (as it’s hidden by the TV blanking output during the refresh rate change).

I’ve never seen that before.

I’ll check your PM’d video and see if I can replicate that.

Sam

Additional testing this evening shows the observed static-like output I described as appearing when starting & stopping some videos, also appears when skipping forward and back within an affected video (including the sample provided via PM).

I’ve tested the sample you sent by PM and I see absolutely no static during stopping or starting the video.

Like you I recorded my TV in slow motion mode on my iPhone just to be sure - when I select the video the screen goes momentarily black then the video appears. To make sure it was not masked by a refresh rate switch I left adjust display refresh rate to match video turned off - so the black screen was actually due to the Vero2 sending a black image, not due to the TV blanking the screen during a mode change.

So whatever the problem is seems to be specific to your setup and I’m not able to reproduce it. A few thoughts:

  • What skin are you using ? It’s possible that some skins may cause an issue. (Although I have not seen this before) I tested with Confluence.

  • How long is the HDMI cable and have you tried a different/shorter HDMI cable just in case the HDMI drive level is marginal for your TV ?

  • Have you tried plugging it into a different TV ?

  • What resolution and refresh rate do you have Kodi set to ?

  • Have you tried putting all Kodi settings back to defaults ?

To do so, stop Kodi with:

sudo systemctl stop mediacenter

Then rename guisettings.xml in /home/osmc/.kodi/userdata/ then restart Kodi with:

sudo systemctl start mediacenter

Can’t think of anything else off hand, especially when I don’t see the same issue on the same file and have never seen an issue that looks like this before on Kodi or OSMC.

Hi DBMandrake,

Thanks for trying to reproduce the issue at your end. I’ve been through the additional steps that you’ve suggested, and have the following results:

  • I’m using Confluence as my skin. Changing to OSMC doesn’t seem to affect it.

  • The HDMI cable I’m using is 1 meter in length. I’ve tried 4 different HDMI cables I have (including the one shipped in the Vero 2 box), and no change is observed.

  • Unfortunately I don’t have any other TV to test with.

  • I have the Kodi UI set to 1920x1080/60Hz. Changing this has no effect (e.g.: to the default setting of 1280x720/60Hz).

  • I’ve reset all settings to defaults as per your instructions above, and found it did not affect the issue that I’m seeing here.

I have found two things that seem to eliminate the issue at hand though

First, is that if I change the "Allow hardware acceleration - amcodec’ setting in Videos/Settings such that it’s disabled, then the issue goes away.

Second, is that if I plug Vero 2 directly into my TV, then again, the issue isn’t observed.

I don’t know how (or if) the amcodec stuff interacts with HDMI output on this - my background is more related to console OS/driver development - but taking these two observations at face value it almost seems like use of amcodec is affecting HDMI output (timing related? handshake related?) in a way that means my AV receiver (a Denon AVR-1912) gets confused. I guess I could grab the code and have a look if I have time. As I mentioned in my thread over in the General Discussion forum, I’m seeing some minor issues with respect to audio on HDMI during boot - I do wonder if this is symptomatic of some HDMI timing issue or similar.

I don’t see this issue at all with a Vero 1 plugged through the same AV receiver with the same cable(s), and the same media.

Cheers,
Dean

Interesting - I don’t have an AVR so all my devices are plugged directly into a Samsung TV, so that probably explains why I can’t reproduce the problem.

Which code are you referring to - the Amlogic kernel ? @sam_nazarko knows a lot more about this than I do, but my understanding is that most of the amcodec video decoding is either done in the kernel in a binary blob or in the gpu firmware. (which will also be a binary blob, like the RPi) In this regard Kodi is just a wrapper that pipes the video stream directly from the container file to the kernel device driver which then returns decoded frames that can be sent to the framebuffer. Very little work is done in Kodi itself.

Possibly, but I don’t think so. What you reported in the other thread is probably due to the mode switch that occurs early during boot.

The bootloader does not currently auto detect or set the reported native mode of the display device via EDID, and always passes hdmimode=1080i on the kernel command line regardless of what your monitor might support. If you check /proc/cmdline you should see this. This overrides any native mode detection in the kernel so this causes the device to always initially start in 1920x1080i60.

As an interim solution while we work on the bootloader and kernel we manually check the reported native resolution and set the current display mode in the initramfs:

Regardless of automatic mode detection we still have to pass a mode to /sys/class/display/mode as before that is done HDMI is running with valid timings (albeit 1920x1080i60) but no frame buffer is active. Unlike most devices the framebuffer is not activated automatically in the kernel so we have to do it in the initramfs.

This additional mode switch during early boot is not ideal (some devices will report an incompatible mode during the first few seconds) but we are working on fixing this properly.

Hi,

Yeah, I was hoping elements of the Amlogic kernel would be open - but as you say it’s all binary blobs.

It’s clearly not a critical issue (as in, it doesn’t prevent me from enjoying watching media on my Vero 2 - as the glitches are only when starting/skipping/stopping) - but if there is anything I can do to narrow down a cause, then do let me know.

I guess that without being able to trace HDMI control signals being passed to the AVR (which I assume would require instrumentation in the Amlogic blobs, or a dedicated HDMI analyser) then it’s difficult to know what’s causing the problem. Would be interested to know if anyone else is seeing a similar effect when routing Vero 2 through a receiver too.

Understood about the boot/HDMI stuff you describe - appreciate the detail, and look forward to improvements in this area in future.

Thanks again,
Dean

It’s not completely ‘blobby’, so we have some hope there.

Most control of HDMI is done via /sys in userspace, so it’s possible for us to strace kodi.bin and see what sequence and commands are being sent to the kernel.

Can you take a photo (crude I know) of video and audio settings? Then I will see the exact sysfs interaction between Kodi and playback for your settings and can probably narrow it down a bit.

Sam

Of course… I can do this when I get home. Although after this weekend’s testing (above) I can confirm that I’m seeing this with the install defaults (ie: ‘Adjust display rate’ set to off, default 1280x720x60hz UI etc). :slightly_smiling:

Thanks,
Dean

Okay – I’ll try that out with your video.

I see the black screen when I press play, even without Adjust refresh rate. Going to take a look at that shortly.

Sam

Okay, I have an idea for the black screen, but wasn’t able to replicate the static.

I’ll work on this tonight. Would you be happy to try a test build when I have something?

Sam

Of course… Anything I can do to help. One thing I’ve noticed is that if I have my AVR OSD up while starting/skipping/stopping the videos in question, that’s also affected by whatever state results in this HDMI issue…

Anyway, yes. Feel free to send details on test builds over PM.

Dean

Hi.

Just seen the post about the initial March update, specifically how it should address the issue of artefacts/static output at points (the 2nd frame buffer initialisation thing?).

Sounds promising. Am away from my Vero 2 for the next few days, but will test on my return and post up results here.

Thanks again for the awesome work on Vero 2 / OSMC!

Dean

Hi Dean

Let me know how you get on. There are also a couple of other things I’d like to address which will reduce the incidence of small glitches. I took a stab at hard coding the PLL setup for all video modes we support, instead of relying on AmLogic’s frame rate automation.

The current scheme doesn’t work well for all video modes, as some AV receivers and TVs have different levels of tolerance for drift. The new scheme is done, but didn’t make this update as it is yet to be tested

1 Like

Hi Sam,

Just back after a few days away, and updated to latest - unfortunately I’m not seeing any change with regards to the static/glitch I’ve discussed earlier in this thread. :cry:

Seems strange that I see this when the video skips/stops, but not during pause/resume. Does advancing/rewinding video result in any mode change?

Anyway, it’s not a major issue - so I’ll keep tracking it as releases appear - especially those with fixes for CEC or other HDMI issues. If you do have any future work to allow for tracing of HDMI control as you’d described earlier, then I’d be delighted to give it a try and report back results.

In short, if there’s anything I can do to help just let me know.

Cheers,
Dean

I appreciate your patience and will follow up in detail on this shortly.

Hi Sam,

My Vero 2 had a pending update on Friday when I got back from work, so I installed and found that the static/glitching that I’ve reported in this thread has gone. Was there anything in this update targeting this issue, or is it just a happy byproduct of other fixes?

I was only able to perform quick tests, and am unable to do more tests until 21st when I’m back home, but I thought I’d report this change of status right away.

Cheers,
Dean

Hi Dean

There were a few patches to both kernel and Kodi. Hopefully the issues are gone for you now. Friday’s update however was just a quick fix to a hang caused by the WiFi driver, so if you hadn’t updated for a little while it’s hard to pinpoint the exact issue.

Sam

Hi Sam,

Now back and can confirm the glitches I reported are a thing of the past - agree that it’s unlikely the fixes you describe regarding wifi are responsible for the resolution, but it is possible that the a prior update did so - I can’t be sure that I had all patches prior to that.

Anyway, am super happy that it’s working well now, so thanks again for your help!

Cheers,
Dean

1 Like

Thanks for reporting back. Good stuff.