Daala Blog-Like Update: Bug or feature? [or, the law of Unintentionally Intentional Behaviors]

[xiphmont]

Codec development is often an exercise in tracking down examples of "that's funny... why is it doing that?" The usual hope is that unexpected behaviors spring from a simple bug, and finding bugs is like finding free performance. Fix the bug, and things usually work better.

Often, though, hunting down the 'bug' is a frustrating exercise in finding that the code is not misbehaving at all; it's functioning exactly as designed. Then the question becomes a thornier issue of determining if the design is broken, and if so, how to fix it. If it's fixable. And the fix is worth it.

[continue reading at Xiph.Org....]

Comments

Reverse order?

[stefan brüns (from livejournal.com)]

Would it be possible to change the order of the DC update and the motion compensation?
This might not solve the problem completely, as the value of the DC update will be dictated by the pixels in the majority region (assuming there is some uncovering ongoing here) and stripes will appear one frame later, but the artifacts will be less blocky, because the blocks are moved after the DC update and the newly introduced borders are not aligned after the MC.

Can you provide the original frames (uncompressed or high quality lossy), so one can compare input and output?

Re: Reverse order?

[xiphmont.livejournal.com]

One can't reverse the order-- coding the block residue of motion compensation (in this case, just the DC) necessarily requires the motion compensation be done first.

The test clip is the y4m 1080p Sintel trailer on the front page of media.xiph.org. The input does not look much like the output :-) This is also a very dark frame from the initial fade-in from black. I can post it alone somewhere if you'd like.