Parts of video image seems smearing

Help and Support Vero 4K / Vero 4K +
1

English is not my native language so maybe I’m not using the right words but this is the issue with the new Vero4k:
Often some parts of the video image seems to move differently from the rest of the image. Like it’s dancing or so.
I call is a smearing effect but maybe it’s more a sticky effect? I don’t know.

Anyway I did some tests with OSMC running on my pi3 with the exact same video and scene and there it doesn’t happen.
So it has nothing to do with the video file itself or my tv.

Because image says more than words I recorded the same scene on both devices and you can clearly see the difference.
In this video: Produce on Vimeo you first see the scene on the OSMC/pi3 (with sound). Look at the 2 large area’s of the wall at the right side of Jake Gyllenhaal. It looks fine right?
Now wait for the black cut screen and then you see the same scene on the vero4k (without sound). Now look again closely to that wall area. You see it seems like parts of it are not moving together with the rest of the image?

Quite soon I noticed this in many movies/series I’m watching. It seems like it happens when the camera is slightly moving up/down/left/right. Like a shaky recording. In those scene and with larger area’s of the same colors I see this behaviour. After noticing it I now see it more often which is of course…not good :).

Settings are all the same as OSMC on the pi3.
I tried also with disabling the accelerator encoder and it seemed to make a slight difference but wasn’t gone.

What other information do you need to help troubleshoot and fix this?

2

I think this has also been reported.

As the update is now out, and the main issues are fixed, I can start looking at some of the smaller things like this.

Do you mean this?

Screenshot from 2017-03-22 22-15-28.png2160×1322 1.3 MB

That’s just noise from the encode.

The Raspberry Pi and Vero 4K have different video playback accelerators, you can expect picture quality to look a little different. Some people prefer the Vero (AML) picture quality. The Pi might be softening some of that noise.

But if disabling the hardware decoder doesn’t yield a difference, then I’m not sure what it could be. Just to clarify: did you try disabling the hardware acceleration (make sure it shows ffmpeg) on both Pi and Vero 4K?

3

No it’s not that. I know that’s noise and part of the quality of the file.
What I’m talking about can only be seen in a moving/playing video and in the example it’s in this area:

image.png883×514 313 KB

When you look closely to the second recorded part (which is of the vero4k) you’ll see that the left (darker) part of the wall is move differently than the right (lighter) part. It’s very strange and btw my wife sees it as well :wink:

(Sorry I assumed everyone would know who Jake Gyllenhaal is :))

“But if disabling the hardware decoder doesn’t yield a difference, then I’m not sure what it could be. Just to clarify: did you try disabling the hardware acceleration (make sure it shows ffmpeg) on both Pi and Vero 4K?”
I only disabled it on the vero because that’s where the issue is.

4

I see it now. Can you confirm that when you disabled the hardware acceleration you saw ffmpeg?

I’d like to know:

sudo cat /sys/class/amhdmitx/amhdmitx0/disp_mode

If you can send me a sample of this clip it will help a lot.

5

I disabled the hardware acceleration, I don’t know how else I can/should put it in ffmpeg mpeg mode.
result: VIC:16
However I took a bit more time to test with that disabled and I actually think the bad effect is then gone.
Maybe my mind was playing tricks with me after looking so often to this scene :).
I’ll keep it disabled and see how other series/movies go.

You want an actual sample clip? or another recording done with my phone?

Are there any disadvantages of having the accelerator turned off?

6

Yes.

7

Ok I tried to edit the movie to only have that scene and I retested this on the vero4k to make sure it’s not something to do with the encoding of the file itself (the edited clip is encoded differently than the original movie).
This edited file also shows the same bad effect so you can use that for testing.
https://www.wetransfer.com/downloads/f243732f65a275a1e6973262db41590020170327191235/e75684e315bd92f418b4c9f1ed79c8b720170327191235/270609

8

I think I’m also seeing the same kind of “smearing” artefact as reported by the original poster… While (relatively) subtle, it has the same visual effect as you’d expect if areas of the image were being subject to harsh motion compensation. When visible you can almost see a larger area of the decoded image moving as a static block, with it looking like it’s blended into the final display buffer.
I’ve seen it not only on lower bandwidth content (eg: a 250MB SD MP4), but also on high bandwidth content (5.5GB 1080p BD rips) too. Playing back the content on my desktop (Mac/VLC) doesn’t show any apparent motion issues…

I’ve not seen the same kind of artefacts with the same content on my Vero 2 (which I still have for the moment), although due to other commitments I’ve not been able to mess with the settings on my Vero 4 to turn off h/w acceleration - I might have time to try that at weekend.

9

I’ve grabbed the sample clip and I’ll try and take a look at it this weekend. I’ll also check with my AMLogic contact and see if there’s been any discussion re. this; as it’s been a while since we caught up.

10

Just to let you know this is both happening in x264 as well as x265 coded video’s.
Hope you will find a fix for it!

11

Hi

There’s a lot of upcoming video improvements

Stay tuned

Sam

2 Likes
12

Hi Sam, just curious if you already have a release date for this new version.

Thanks

13

We do not publish firm dates.

14

Not yet – there will be the April update first; then I’ll get some testing re. video improvements on the forum; and then we will plan to get it included in the May update. But as @actiona says these dates are not firm.

Sam

15

I have updated the H264 decoder for the next update which includes a variety of improvements.

I hope that this improves things here specifically and would appreciate some testing. To do so, you can run the following commands:

wget "https://www.dropbox.com/s/lq6efw1vpmjxokg/vero3-kernel-video-and-mux-improvements.deb?dl=1" -O kernel.deb
sudo dpkg -i kernel.deb
sudo reboot
16

I experience what seems to be the same issue. The patch seems to lessen the issue slightly, but it’s still there. The decoder seems to have difficulty with grainy footage or scenes with lots of small detail combined with motion.

I’ve uploaded a sample which shows it relatively clearly. Near the end, when the ship lands and the camera pans around, you can see circular trails/rings on the dirt which aren’t there with the ffmpeg decoder. Also the waves, when the craft flies over the shore, are being smeared out to some extend.

I’ve also noticed the grain doesn’t act like grain and stays in place for some time. (again, the patch has lessened, but not eradicated, the issue.)

17

Strange, I didn’t receive a notification of your new message.
Anyway I’ll do some testing soon!

18

Just want to say with the last update(s) you nailed it! The smearing is gone!

For me now only these issues are still open:

and occasionally, despite buffering being all ok, the sound continues but the video is in slomo. Then after a few seconds (can be like 10 seconds) it suddenly syncs again and runs fine.
In a important scene it’s not appreciated.

Something new since last update(s) is that occasionally there is suddenly a frame popup. Like in the movie Fight Club where Tyler added a single frame to the movie. That’s what I sometimes see. Like 1 in 3 movies/episodes it happens 1 time.

19

Glad to hear this.

You should notice that the last few seconds is now only one or two seconds. We’ve got a basic drain implementation but it needs more work.

I don’t believe this issue has been raised before.

Please post some logs and we can see what the issue is. If you can produce a clip that exhibits the problem, this will be perfect.

20

Ah yes indeed that period at the end is shorter than before :).

Regarding that slomo thing it will be very hard to capture. Is my default loglevel enough to capture what’s happening you think?
At least I’ll write down when it happens which file it is and will save the kodi log right after.