DaalaMeeting20130911

# Meeting 2013-09-11

## Agenda

- logistical
- status updates
- brainstorm coding party agenda

## Attending

xiphmont, jack, jmspeex, gmaxwell, derf

## logistics

### meeting change

- jack: i suggest 9am pacific on tuesday

### #daala channel

- jack: I suggest we do daala talk in #daala.
- (not much argument)

### status updates

#### travel

- Monty: Daala coding party: Sept27-Oct1
            Disneyworld with family: Oct7-Oct14
- derf
12-17 Sep. IBC (Amsterdam)
1 Oct.: SF MusicTech XIV (probably not going, but someone maybe should?)
4-6 Oct.: Summit (MV)
9-11 Oct.: IEEE Broadcast Symposium (San Diego)
3-8 Nov.: IETF 88
11-15 Nov.: TPAC (not going to Shenzhen, defecting and going to Seattle)
17-18 Nov.: FOMS (San Francisco)
19-21 Nov.: WebRTC World West (Santa Clara... maybe not going)
8-11 Dec.: PCS 2013 (San Jose)
12-13 Dec.: Packet Video (San Jose)
- gmaxwell:
4-6 Oct.: Summit (MV)
3-8 Nov.: IETF 88
17-18 Nov.: FOMS (San Francisco)
8-11 Dec.: PCS 2013 (San Jose)
12-13 Dec.: Packet Video (San Jose)
- jmspeex:
   CCBE Sep 26-28
   Coding Party Sep 28-Oct 3
   Summit Oct 4-7
   AES Convention Oct 16-20
   IETF 88
- unlord:
  Daala coding party 9/26-10/7
  IETF 88
- jack:
  Coding Party 
  IETF 88
  Platform rendering work week (paris) oct 21-25
  Samsung (Seoul) Nov 14th-??
  Moz Summit 
  Strange Loop Sep 16-19
  LCA Jan ??
  
- xiphmont: I am shaving yaks. None of the mastroska tools can generate [completely] valid WebM. mkvmerge doesn't obey the profile.  mkclean doesn't reliably get timestamps in ascending order. Apparently this isn't Matroska but is in WebM and Chrome hangs if they timestamps aren't in order. And it's not deterministic. What you get out of mk clean dpeends on what you put into it.
This week I have RH legal stuff (re 2-stage TF). 
I'm still working on getting machine search of lapped transforms working. If we're going tform 4x4 to 8x8 we have to account for the lapping between the 4x4s. If we're splitting, then the second stage TF filter will need to simulate adding overlap between the two blocks that we split. I'm not optimizistic that we're goign to find anything, but I'm still looking.
This week: continue machine searching for lapping filters, lawyerness, and get started on next demo (ChromaFromLuma)
- jmspeex: "What lapping are you actually assuming we're going to use?"
- xiphmont: i'm assuming that our transforms are lapped with the matching lapping and that's what i'm trying to simulate. i think that's the right place to start. if we go to building 16x16 out of 4x4s then we lose some of the benefit of having the greater support.
-jmspeex: that is mostly useful for the larger blocksizes.
- xiphmont: this is all an approximation and i'm not sure it's good enough yet that that actually matters. I have bugs and have to find them. I got really lucky finding the first filter that I did.
- jm: lucky in what sense?
- xiphmont: I made a wild guess and the second stage TF popped up, but so far I've found nothing else.

### jmspeex

- jm: i've been working on getting Opus 1.1 out the door. Nothing really new on Daala.

### gmaxwell

- greg: I'm still hung up with 32x32 support. I went off on a tangent trying to search for lapping filters with the TF in place. So I have a modified coding gain tool that measure it. We prefer different prefilters when teh TF is in place.
- derf: what are you trying to optimize for with TF?
- greg: Basically I'm doing empirical coding gain using the variance on the image data.
- derf: what does that mean?
- greg: I'm TFing 16x16 up to 32x32 and then changing the lap params for the 16x32 prefilter.
- derf: ok
- unlord: this is just the part that's on the inside of hte block?
- greg: no, inside and outside. the reason i started messing around with this was to make sure that i was applying the TF correctly. So I broke that out and started measuring.
- unlord: this is sort of like the questions i've been having. should you do something different than the normal 16x16 if you're going to TF it together. this is sort of what finding a better filter on the inside looks like.

### unlord

- unlord: http://people.xiph.org/~unlord/subset3_16x32_modes.png
that's been running along. it doesn't look like it's ....
I can post the individual data too so you can see the coding and prediction gain output.
- greg: good. it's not totally busted anymore.
- unlord: before when i was doing the rollup that looked terrible. it was totally because of the overfitting moving everything to mode 0. this may be a reason to rerun all the 8x8 on subset3. i'll know more when i plot it bits / pg.
- jm: that figure is the prediction gain after full sparsification?
- unlord: no, we're at step 150 or so. this is after sparsifying 60% of the way. it has 40% of the coeffs.
- jm: you're trying to reduce it how far?
- unlord: 1/262. quite a bit. this doesn't mean anything except that before when looking at subset1 this graph was terrible. http://people.xiph.org/~unlord/subset1_16x32_modes.png
the other thing i've looked at is in the traiing tool. i modified the codec to only use 4x4 and 8x8 blocks, and then i ran the RD curve generation on subset1 with the second stage TF enabled and disabled. basically our current codec and the application of hte filters TF up and down. I thgouth maybe we are seeing an improvement on the smaller blocks. For low rates TF was slightly better and high rates was slightly worse. Greg brought up that doing it both ways, with TF and with TF + filter. So I'd have to run the experiment four times. My theory is that pairing these correctly should work.
- jm: there's two reaosns you can see it doens't imrpove. one is that it doesn't work well enough and the other is without it it works well enough.
- unlord: maybe this is being overwhelmed by compression loss somewhere else. is there a different suggestion for how to test that?
- jm: how to test whether the current one is good enough?
- unlord: yes
- jm: the only way i can think is to do this with 4x4 and 8x8 but lapping of 4 all the time and you can doa  losless TF for that. with that config you can do lossless TF between 4x4 and 8x8.
- xiph: that's worth playing with but i'm concerned about deploying it.
- jm: no, i was talking just measuring performance with that, and if it's not better compared to the stupid TF then it means you've squeezed the area and you aren't goign to get any better with the second stage, but if there's a gap then you can see where the second stage gets you within the gap.
- unlord: the predictors are horrible if you do that.
- jm: no you've trained the 4x4 on 4x4 and 8x8 on 8x8. if you do it lossless it means your predictors are optimal.
- unlord: the training was on 8x8 lapping
- jm: you'd have to retrain with 8x8 blocks and 4x4 lapping. doing lossless TF would give you the best case. running without monty's second stage gives you the wrost case and then you see if there's any meaningful difference that's worth trying to get back.
- unlord: ok. i can run that one.

### derf

- derf: i have been mostly focusing on opus 1.1. most of my daala work is dumping stuff into jack's brain.

## travel schedule

- everyone but monty headed to IETF in vancouver week of nov 4th.
- jm: i'm only going to one day at CCB in toronto before the coding party. and going to NYC for AES in october
- derf: What are people working on next week?
- xiphmont: TF, and then the next demo (chroma from luma)
- jmspeex: Continuing on PVQ (play around with theta quantizer and see if we can use prediction properly)
- gmaxwell: actually finish 32x32 support, put images up
- unlord: finish experiment with TF and intra prediciton
- derf: Coding party planning