search

ericmckean / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

Deblock edges in chroma are missed for odd-multiples-of-8 widths #642

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When the frame width is an odd-multiple-of-8, it means that the chroma planes 
aren't a multiple of 8. In this case, the final 4 pixel columns in these planes 
appear to be inconsistently (incorrectly?) deblocked. Specifically, edges due 
to 4x4 transforms that are internal to an 8x8 MI region are skipped on the 
right edge of the picture. This results in artifacts along the right frame edge.

Original issue reported on code.google.com by pieter.k...@gmail.com on 11 Oct 2013 at 4:54

GoogleCodeExporter commented 9 years ago

Original comment by fgalli...@google.com on 17 Oct 2013 at 10:28

GoogleCodeExporter commented 9 years ago 
This is a confirmed bug in the VP9 loop filter code. But it is no longer the 
time to fix the bug that affects the bitstream.

Original comment by ya...@google.com on 17 Oct 2013 at 11:07

GoogleCodeExporter commented 9 years ago 
If I understand the issue correctly, the "usual" resolutions (320x240, 480x360, 
640x360, 1280x720, 1920x1080 - all with even-multiple-of-8 width) should be 
unaffected.

Given that there has been no official libvpx release with VP9 (few if any 
third-party encodes exist), YouTube resolutions most likely unaffected, 
third-party VP9 decoders perhaps not consistently replicating this bug 
(ffmpeg?), most decoders being deployed in Chrome (with a very nice update 
mechanism) and no hardware being deployed it seems a bit odd not to fix this. 
The real-life impact should be minimal as long as no official libvpx release 
happened.

Original comment by maikmer...@googlemail.com on 21 Oct 2013 at 7:30

GoogleCodeExporter commented 9 years ago 
I can promise you that companies are already working on hardware 
implementations. Depending on their architecture and progress, it may or may 
not be difficult to absorb the fix (or realize this bug). On the other hand, 
the fix doesn't require bitstream changes, so that may make it slightly easier.

Personally I'd like to see it fixed just because it's the "right thing", but 
there is a legitimate argument for keeping it as is.

Original comment by pieter.k...@gmail.com on 21 Oct 2013 at 7:37