View source for DaalaMeeting20131203

<pre>

# Meeting 2013-12-03

## Agenda

- CfL experiments (unlord)
- PVQ writeup (demo5, xiphmont)

## Attending

xiphmont, jmspeex, unlord, jack, gmaxwell, derf

## CfL experiments

- u: i did what jack suggest and did correlation between luma and chroma planes and between the chroma planes to see why we saw a smaller prediction gain in stats tool. what i'm looking at so far shows that there is some correlation between the correlation and the prediction gain. when i get it done completely i'll post the images. i haven't finished integrating the optimal linear regression yet since i got sidetracked landing lots of patches. it will show the optimal RD curve for the optimal linear predictor. will show us how much better we could be.
- d: optimal in regards to what?
- u: this is finding the very best linear fit in the encoder given that we know what hte chroma should be.
- g: this gives you the optimal alpha and beta
- u: i can print an RD curve so that if we had a magic oracle, this is the curve we could get. it should be showing up soon.
- g: in your performance results did you characterize it based on blocksize to see if it was blocksize related?
- u: the cfl stats tool?
- g: yeah
- u: i don't handle the 4x4 size correction. the tool doesn't work with luma 4x4. i tihink i have it pegged to 8x8 but it should work for 16x16.
- g: so you're not handling the hard case yet
- u: not really. that's interesting also. i haven't landed the patch for the tool yet although i did look at half the comments that monty provided. i'll finish addressing those with him and get it landed.
- jm: should we be trying to do chroma from luma and then the next chroma with chroma and the old chroma?
- g: we just the neighboring chroma
- jm: i mean using the other chroma plane
- d: it might be too expensive
- u: computationally?
- d: yeah
- g: no but using it some cheap way...
- d: that still has a parallelism cost.
- g: fair enough. what are you thinking with respect to parallelism now?
- d: well, parallelism is not the right word.. pipelining. all this stuff gets deeply pipelined.
- g: we could potentially do some things to interleave the code more tightly. the problem is that we serialize in the bitstream.
- d: i think those processes wind up being independent in hardware.
- g: ??
- x: i wanted to ask you more about them. let's talk about that offline.
- g: they are just simple regenerates of what you did before with the bugs fixed in the code.
- x: if we're going to have demos that are live documents, i might want to go back in and change the wording to make that clear. i've been posting these as archival documents. the only things that i'd like to change in the stuff i put up is typos; i haven't wanted to change the content. jm wanted to do this for the opus 1.1 demo as well. i think this will end up confusing and annoying people.
- d: the two cases are different. you've done updates before.
- x: that was the case where something was broken and the content didn't reflect the text. i want to put a little bit of thought into it.
- g: this case was a similar gaffe as the rotated blocks. the cfl stuff as i implemented it got broken during code review.
- x: i should replace it if it's broken data. sorry i misunderstood. i will go back and fix it. irc me the links again and i'll get it replaced right away.

## PVQ writeup

- x: reviews had been lagging so I have been doing that (by jack's request).
- d: thank you for that.
- x: i'll get back to pvq after i do the opus 1.1 addendum

## Travel

- d: greg and i are at the picture coding symposium next week. it's in san jose. we're not giving a talk. we're looking for potential interns and potential research grants.

## Resources

- g: i'm getting bottlenecked on cpu. i need a big machine.
- j: let's talk about that offline and try to figure out what's needed. maybe the whole research team could share some big 64-way machine.

## PVQ decoder

- jm: i started on this in vancouver, but haven't finished yet. it's next on my list.

</pre>