# Meeting 2014-11-25
Mumble: mf4.xiph.org:64738
# Agenda
- FOSDEM deadline is Dec 1
- reviews
- Doing non-intra work (when?)
- yushin
# Attending
unlord, derf, jack, jmspeex, td-linux
# FOSDEM
https://lists.fosdem.org/pipermail/fosdem/2014-October/002041.html
https://penta.fosdem.org/submission/FOSDEM15
- d: talk submission deadline is looming (Dec 1). Who is giving talks?
- u: I will. Jean-Marc and I were going to split it up.
- j: How are you going to split it up?
- jm: One is technical, and one is project overview.
- d: Technical one at FOMS (Friday before), project overview at FOSDEM. But it's kind of the wrong order.
- j: Can't be helped since the general one should be for the more general audience.
- d: Jean-Marc and Nathan, you two can coordinate that. Links are in these notes to do submissions.
# Reviews
- j: 312 has too many reviewers. Are all of them reviewing it?
- u: I was reviewing it. I can remove the others.
- td: That bitrotted, so I'll update it.
- j: Who's going to review 534?
- u: I'll do it.
# Non-intra stuff
- d: How is multiple reference frames coming?
- td: Not a lot to show for it yet. Coming soon.
- d: By portland?
- td: Sooner.
- j: Did we give up on getting Greg's code?
- td: Yeah. I haven't bothered. At this point it would be hard to put it in. I haven't done the motion search of two frames yet.
- d: I think that was the only piece he was working on.
- td: Ah, that may actually work then.
- d: Go harass him again.
- j: Tim, how is your non-intra stuff right?
- d: I'm still working on jm's paint-deringing stuff. I'm still trying to rethink how to speed up interpolation. I'm trying to move the logic from per pixel to decisions at a higher level. Unfortunately the way it is set up right now there is a bunch of stuff in the middle of rows and winds up being a mess. I'm not sure how to make it SIMDable which is a problem. That's what I'm trying to figure out.
- jm: I think we can get away with a table.
- d: Table of what?
- jm: Interpolation values.
- d: Of the whole block?
- jm: Yes.
- d: I was trying to avoid that.
- jm: The original code was trying to do 32x32 with 128 directions. The current one does 8x8 with 8 directions. Maybe 16 could be nice eventually, but right now it's 8. It wouldn't be that big.
- d: It would be a full k of ROM, but I'm worried about L1 cache impacts.
- jm: If you split it out by direction it's not necessarily that bad. You'll end up with one cache line per direction so if you're using two directions you haven't evicted anything.
- d: I was going to try to avoid the giant table and see how bad that is.
- jm: We can build a table and if people don't want the table at least we know it's reasonable to compute. Are there a bunch of symmetries?
- d: There's really only two. I don't want to do X-Y symmetries because transposing everything is expensive. Reading a column of weights is 8x as expensive as reading a row.
# Yushin
- d: What should we get Yushin working on?
- jm: When does he starts?
- j: He starts the 8th. We couldn't make the Portland WW work for him.
- jm: I'm pretty sure after he gets the gist of the codec, he's going to see things are stupid and want to fix them.
- u: Is rate control a thing?
- j: It's a low priority thing. It seems logical that we should put him on something non-intra.
- d: There's figuring out intra + inter. There's mechanical stuff like increasing maximum block size for motion compensation stuff.
- jm: It would be good to get familiar with PVQ since that is an uncommon piece. my thought is that when you join the project the first few weeks is the time you realize all the things that this project does weird, so we should take advantage of that.
# Jean-Marc's crazy idea # 2818238
- d: The problem with intrapaint is that there are only so many edges in the image, and intra-paint costs us everywhere. So I would go look at places where there are no edges and compare what you are proposing to a DCT.
- jm: So you seem to think that this will be nowhere near a DCT.
- d: Based on your description, yes.
- jm: The first step is pretty much like a wavelet transform. If you were to do an unaligned mode that predicts from different directions, you'd get the most basic bi-orthogonal wavelet on top of which you could do a DCT for each level. What kind of performance do you get if you run a low order wavelet transform and then run DCTs on the coeffs?
- d: I have absolutely no idea. I know people have tried this before.
- jm: Considering that nobody is using it, it's probably not that great.
- jm: I had a look at the filter coefficents from cisco. I don't remember what the coeffs from other codecs look like, but it struck me that the first half of hte freq response is really flat but the second half is not. I was wondering if there would be a reasonable way to do a multi-resolution prediction by predicting the low freq dct coeffs normally but for all of the top octave trying to find another reference that has full pel alignmnet with the current frame and copy the dct coeffs from these.
- d: I think you still get the phase wrong. If you've got some edge and the actual motion is at a half pel and you pull your HF from an adjacent full pel location, the phase information of hte HF coeffs will be wrong.
- jm: I mean trying to find one where it would be right. Imagine you have motion going from left to right and the motion is 1.5 pel per frame. So you would get the previous frame would give you good LF coeffs, but the HF would be attenuated with itself. But two frames back the LF aren't good, but the HF would line up perfectly.
- d: Somebody has done this. It will take me a little bit to find it. I'll find it and show it to you.
- jm: Did it work?
- d: I don't remember thinking it was that good an idea. But most certainly we can't use it, unless we can with PVQ.
- jm: Another problem that had my head exploding: Considering that we've got relatively little gain from intra, I was trying to think whether we could do what Frank Bossen was doing where he was iteratively requantizing blocks to get back some of the loss from bi-orthogonal filters.
- d: You you understand how that works?
- jm: No, that's why I'm asking.
- d: I'm not sure how to do it aside from making small changes and running it through the whole synthesis.
- jm: The noise is one block would affect neighboring blocks because it's bi-orthogonal not orthogonal. This was 4x4 no block switching or anything. Frank was saying he got significant improvements in quality from doing that.
- d: Who was he working for when he did this?
- j: Wasn't it LG? I looked it up it was DOCOMO probably.