Incorrect MBs segment reset on key frames (VP8 DECODER)

[GoogleCodeExporter]

What is the expected behavior? What do you see instead?
MBs Segment Id is expected to be unconditionally reset to 0 on every key frame. 
Instead it is effectively propagating through key frames with disabled 
segmentation.

What version are you using? On what operating system?
"master", 0.9.7-p1; windows7

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?
vpxdec.exe --i420 888406015.ivf -o 888406015.ref 
Refer to the attached compressed test stream. On the third frame all MBs should 
have SegmentId==0, instead they are decoded with SegmentId==1 inherited from 
the first frame.

Please provide any additional information below.
This behavior was introduced after vp8_kfread_modes procedure removal and still 
present in the "master". Release 0.9.6.1 do not have this issue.
New behavior contradicts to the bitstream specification in which disabled 
segmentation update disables both update_map and update_data 
(decode_segmentation_header) This eventually triggers this->base.segment_id = 0 
on every key frame in vp8_dixie_modemv_process_row.
Apply this patch to fix the issue:
@@ -843,6 +843,9 @@ int vp8_decode_frame(VP8D_COMP *pbi)
                     xd->mb_segment_tree_probs[i] = (vp8_prob)vp8_read_literal(bc, 8);
             }
         }
+    } else {
+        xd->update_mb_segmentation_map = 0;
+        xd->update_mb_segmentation_data = 0;
     }

     /* Read the loop filter level and type */

Original issue reported on code.google.com by alexei.l...@gmail.com on 8 Dec 2011 at 3:30

Attachments:

• 888406015.ivf

[GoogleCodeExporter]

Original comment by iss...@webmproject.org on 8 Dec 2011 at 3:30

[GoogleCodeExporter]

Is there a way to escalate this bug? It's still in the latest Duclair (1.0.0.0) 
release and you need either to change the RFC spec or fix it!

Original comment by alexei.l...@gmail.com on 3 Feb 2012 at 9:59

[GoogleCodeExporter]

Sorry this sat in the queue so long.

https://gerrit.chromium.org/gerrit/16048

Original comment by jkoles...@google.com on 16 Feb 2012 at 7:24

• Changed state: Started
• Added labels: Mstone-10, Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 392 has been merged into this issue.

Original comment by albe...@google.com on 16 Feb 2012 at 9:17

[GoogleCodeExporter]

Re-tested issue 392 with the latest Git version, including this change:

    Change I9713c9f0: decoder: reset segmentation map on keyframes
    https://gerrit.chromium.org/gerrit/#change,16048 

The problem is exactly the same (try it yourself). The bug is NOT FIXED.

$ ./vp8_scalable_patterns.exe data/CREW_352x288_15_orig_01.yv12 data/20120301a
352 288 1 15 2 400 800 1200
Using WebM Project VP8 Encoder v1.0.0-84-gc34d91a
K...............................................................................
......................................................................
Processed 150 frames.

$ ./vpxdec.exe -o data/20120301a_pp_%wx%h.yv12 --yv12 --postproc data/20120301a
_2.ivf
$ ./vpxdec.exe -o data/20120301a_nopp_%wx%h.yv12 --yv12 data/20120301a_2.ivf

compare frame 124 with and without postproc

Are you sure it is the same issue?

Original comment by alt...@gmail.com on 1 Mar 2012 at 4:21

[GoogleCodeExporter]

I wasn't able to reproduce this. Can you post the version info printed when you 
run vpxdec without arguments? (the last line)

Also, can you post your data/20120301a_2.ivf file?

Original comment by jkoles...@google.com on 1 Mar 2012 at 9:54

• Changed state: NeedMoreInfo

[GoogleCodeExporter]

Thank you for your interest in this bug.

$ vpxdec.exe
    vp8    - WebM Project VP8 Decoder v1.0.0-84-gc34d91a

Original comment by alt...@gmail.com on 2 Mar 2012 at 9:56

Attachments:

• 20120301a_2.ivf
• 20120301a_2.ivf.md5
• CREW_352x288_15_orig_01.md5

[GoogleCodeExporter]

Original comment by albe...@google.com on 7 Mar 2012 at 11:32

• Changed state: Unconfirmed

[GoogleCodeExporter]

Original comment by albe...@google.com on 8 Mar 2012 at 12:02

• Added labels: Pri-0, Type-Bug
• Removed labels: Priority-Critical, Type-Defect

[GoogleCodeExporter]

Original comment by albe...@google.com on 15 Mar 2012 at 6:03

• Changed state: Assigned

[GoogleCodeExporter]

Are you able to reproduce this issue with the information from comment 7?

Original comment by alt...@gmail.com on 30 Mar 2012 at 7:45

[GoogleCodeExporter]

yes, unmerged and reopened issue 392.

Original comment by jkoles...@google.com on 30 Mar 2012 at 5:43

• Changed state: Fixed