Vero 2 Playback/Stop glitch with some videos

Help and Support Vero 2
1

I’ve spun this off from my general ‘Vero 2 Initial Feedback’ thread, but with Vero 2 I’m finding that some video files display a static noise image for a small number of frames at the when playback starts, and when playback ends (i.e.: pressing stop on the Vero 2 remote).

I’ve uploaded logs for a test to http://paste.osmc.io/ucufumigim.coffee

In this case, I’ve tested with the following - ‘WORKING’ indicates that no visual glitch was apparent on startup/stop of the video in question. ‘GLITCH’… well, that’s obvious, hopefully. After each filename is the video information from ffmpeg contained within the provided log.

(WORKING) ‘bb_sunflower_1080p_30fps_normal.mp4’ (from Kodi test files)
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 2998 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)

(WORKING) ‘big_buck_bunny_480p_surround-fix.avi’ (from Kodi test files)
Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 854x480 [SAR 1:1 DAR 427:240], 2500 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc

(GLITCH) ‘test_hevc.mkv’
Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709), 1280x640 [SAR 1:1 DAR 2:1], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

(GLITCH) ‘test_sic.mkv’
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709), 1280x528, SAR 1:1 DAR 80:33, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

(WORKING) ‘test_j.avi’
Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 720x304 [SAR 1:1 DAR 45:19], 1228 kb/s, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc

I’ve created a small video of the effect on stopping the ‘test_sic.mv’ video above, which is available at http://sendvid.com/u11xj59c. This was created on an iPhone using slow motion video recording, hence the fragment of video looking particularly slow. I felt it would be more useful for analysis… notice how the frame buffer does not completely contain the ‘static’/‘glitched’ data I’m reporting - it takes a few more frames for the entire frame buffer to be filled with this type of data. Then, the screen goes black and (not pictured) it transitions back to the OSMC UI. Note that in real terms, this sequence (with the static data) lasts only a small fraction of a second - the black->OSMC UI transition takes approximately 1 second with the video being tested.

I didn’t experience this visual artefact on Vero 1 (on the ‘test_sic’/‘test_sj’ data, or on other files in my possession). I am seeing this on the bulk of the H264 videos I have tested that are in HD (720p/1080p) (in MKV containers).

I hope this is useful in some way. If you need further information, please let me know.

Dean

2

The two that glitch for you, are they short test clips that you could upload somewhere so we could get hold of the exact files for local testing ? If you don’t want to post the link publicly then PM it to me and @sam_nazarko

I’ve tried a large percentage of my Movie/TV Show collection on the Vero2 and have not seen any “static” during stopping or starting as you show in your video.

A copy of a small sample file that exhibits the issue would be very helpful.

Also, do you have “Adjust display refresh rate to match video” enabled, so that your TV switches to the frame rate of the video played ? And if so does your TV’s info screen confirm that the refresh rate is switching on start/stop ?

3

I’ll try to locate a freely available file that exhibits the same problem - the files I have here are ‘from usenet’ and therefore have a somewhat shady origin.

If I can’t, I’ll see if I can edit a smaller portion that’s less hokey (with Handbrake or similar)…

I do have ‘Adjust display rate to match video’ enabled. This effect occurs with/without it set, but I can confirm that when enabled, 24fps (or 23.98fps) content does result in my TV switching to a 24hz display mode.

4

I’ve managed to get a smaller sample file - I’ll PM you a link so you can grab it.

Many thanks for looking at this!

Dean

5

Got the PM – thanks

Do you mean green kind of lines when you stop?

If so, already aware of this and hoping to get a fix done in a couple of days.

Sam

6

[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).

7

I’ve never seen that before.

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

Sam

8

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).

9

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.

10

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

11

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.

12

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

13

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

14

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

15

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

16

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

17

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

18

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

19

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
20

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