From XiphWiki
Revision as of 08:55, 31 March 2015 by Jack (talk | contribs) (Created page with "<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"> # Meeting 2015-03-31 Mumble: mf4.x...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
# Meeting 2015-03-31

Mumble:  mf4.xiph.org:64738

# Agenda

- reviews
- quilting bug
- Screencasting encoding
- Screamcasting
- Icecreamcasting
- MC refinement strategies

# Attending

derf, jack, jmspeex, MrZeus, TD-Linux, xiphmont, unlord

# reviews

658: shouldn't be doing clamping in the metrics tools. can do this in the decoder instead.

# screencasting

(discussion continued from review discussion, and didn't get recorded)

# quilting bug

- x: it turns out that the quilting bug is more persistent than expected. Tests over the last few days show that quantization noise that you inject into things gets amplified. The variance keeps expanding. Any time you code an update to the block you might make all the noise worse. Your DC update can cause all HF noise to double in amplitude. Exhaustive search of all 4x4 filters does not find a solution, because it's not the filters, but the way we use them. I found a solution that will avoid amplification when DC-only updates, but any time you update HF you get noise amplification. Quantizing ref frames to 8bit is the source of the noise.
- d: Is this enough to solve the visual artifacts we can see?
- x: Maybe. I'm worried that if you add a single AC coeff, it still amplifies.
- d: I'm worried more about the actual video than constructed test cases. If the problem only exists at low rates where we only code DC, then we have fixed it.
- x: Those are tests I have no run, but I am pessimistic. If it does still pop up in rates we care about, I'm afraid we have to go to full precision reference. That's the only thing I can think of.
- jm: The impression I got was that the reason other codecs don't ge tthis is that they dont' run a prefilter and it gets blurred over and over.
- x: The mismatch is postfilter to prefilter, not the other way around.
- jm: What I'm saying is that postfilter blurs some amount of noise on block boundaries. In a normal codec it blurs things then you code an update and blurs again. So in our codec we unblur, and if there is noise, we don't beep bluring it, but retain it.
- x: The second half of this is that when we quantize (taking ref to 8bit) it injects more noise. Not only do we preserve the noise, but we inject more.
- jm: Exactly, the prefilter is not the cause, but makes sure we keep it around and don't blur it out. You said if you constrain DC you got rid of it, but in the case of AC, what did the quilting look like? Was it accumulation of noise or a pattern?
- x: In between. Those effects are a continuum not different things. There was no pos/neg bias but it is correlated horizontally and vertically.
- jm: So it's not just white noise.
- x: It is not just white noise.

# MC refinement

- d: Guillaume was doing experiments with enabling old MC refinement things. My plan was to turn those things off, but I may go back and add a speed level to the encoder today so that would turn these things on and off based on the setting.