Has anybody seen this effect?

Has anybody seen this effect?

It's dynamic, shortlived, non-repeatable and happens when an I-frames are ignored and subsequent B & P-frame data is applied to the last good I-frame so you get a pixelated smearing effect for maybe a second or two.

(Those with any NLE experience will know it as datamoshing)

A negative response is just as useful as a positive response

 

I'm sure I've seen this occasionally but have ignored it as it's a momentary thing. As I use a variety of 'sources' for my files I put it down to a bad rip.

 

As a random occurrence, that's not due to corrupted file? Maybe 3 or 4 times in the space of 12 months. Always as a very brief, once-off glitch. Never as a problem that would persist over the space of minutes.

 

That's what I thought originally and made the same assumption as @blenky above, but now I don't believe it's the file because any subsequent replaying around the timecode never replicates the effect however much I try.

I was just lucky to catch it this time and press pause to grab a photo.

 

I've never expected a bad file as I run BTRFS that checksums all data and metadata on the server, so any bitrot would have been caught. Similarly, network issues would get caught with checksums too.

Must be some kind of buffer corruption or even a dropped buffer on the Zidoo itself. Possibly a locking issue / race condition, but given how rare it is, it would be hard to find.

However...

Since most modern hardware decoders have error concealment, where they just hold the previous picture, seeing such obvious corruption is rare. What may not be rare is this happening and error concealment kicking in, thus creating the perception of <drumroll please> stuttering!

 

Could be a deblocking error? - I believe it is set to medium on these boxes?

 

Nope. As @Markswift2003 pointed out, it's a missing i-frame, where the b and p frames are being applied to the incorrect base data. when you get corruption like this, it usually lasts for a GOP.

 

Yeah, understood.

 

I know you have a huge amount of experience in this area but I don't think stuttering is related to error concealment - I've just posted some comments on stuttering here:

If you have VIDEO STUTTER please check THESE SETTINGS (updated)

This is a bit of an anecdotal comment, which I generally try to steer clear of, but I've only noticed this phenomenon since the latter part of last year. And equally anecdotally, this loosely coincides with the release of v1.2.42.

 

So can I take it you've never seen this?

 

I saw it a couple of times very briefly then understood as source remuxing error.
By the way, the images belong to Tulsa King S03, isn't it?

 

I've seen it maybe twice, and it lasted for a split second'ish, so just put it down to bad encodes at the time.

 

Nope - Superman (2025).

 

Confused, sorry!!

 

I have also encountered such artifacts.. I've even written about it several times in firmware threads. I called it "pixel splatter." It's rare. I've seen it on DV P7, WEB-DL 2160p, and 1080p h265. It occurred with varying frequency on different firmware versions. But I haven't seen it on the latest firmware yet (I had very little free time to test the latest firmware)

 

I'm usually just a silent reader here; this is my first time posting in this forum. I own a Zidoo 3000 and still have firmware v1.2.40 installed. I've now observed these "pixel splatter" artifacts three times in different MKV files, but I've never been able to reproduce them. When rewinding, the same sequence was fine. I thought it might be the HDMI cable or the file itself.

 

I have had this as well and opened a topic about it here when I watched Nosferatu. I got the same splotchiness but when I rewound it and played it again it was fine.

 

So September last year - probably on v1.2.40 also?

 

Yes sir!

 

Roger that, thank you!