# Meeting 2014-01-07
Mumble: mf4.xiph.org:64738
# Agenda
- review policy changes
- review tool emails
- tim day
- pvq projects
- 16x16 support
- activity masking
- convert to fixed point
- Interns!
- Det1 training ( http://people.xiph.org/~greg/daala.det1.training.20140107/ )
- Work week
# Attending
gmaxwell, xiphmont, jmspeex, unlord, jack, td-linux,
# review policy
- jack: reviews due in a week. in this meeting we'll go through quickly and assign and those should get done by end of the week.
- jmspeex: i would also auggest we review only important things.
assigning reviews
# pvq projects
- jack: jean-marc wants these three projects done by someone other than him. volunteers?
- xiphmont: me me me
- jm: here are the projects:
1) Implementing PVQ for 16x16
2) Activity masking
3) Fixed-point conversion
- jm: these are sequential and easiest to hardest
- greg: why is activity masking not two lines of code?
- jm: it's not a lot of code, but it's trying to figure out what's going on. there's a bunch of constants that would influence the results that are implicitly 1.
- xiphmont: there's some amount of wanking with constants I imagine.
- jack: can greg do activity masking in parallel with monty doing 16x16?
- jm: yes
- greg: sounds good
- jm: for 16x16 we don't predict anything so pvq is not that useful.
- unlord: i've landed the TF predictors
- jm: are we predicting something useful?
- unlord: perhaps. we're not feeding the 16x16 blocks directional data. when we do block size splitting we take all the directional blocks and making them 8x8 or 4x4.
- jm: not sure i'm following
- unlord: the training is done on all blocks in an image.
- jm: but you are at least training something and you predict in HF?
- unlord: yes.
- jm: the other thing is det1 stuff at least when doing pvq with interframes.
# interns
- jack: email people. recruit!
# det1
- g: on http://people.xiph.org/~greg/daala.det1.training.20140107/fastssim.png the blue line is git. the green line is the results from training. this was the best settings for prediction gain. i freaked out because this wasn't the results i got back when we first tried this. so i redid the training for the det1 coeffs and then having nothing else left to check i changed the training tool settings back to the defaults. then i got the red line. i think i have it sorted out now. it is odd that the changes in the training settings make such a big different. if you look at http://people.xiph.org/~greg/daala.det1.training.20140107/training.png you can see
- d, u: what is the difference between the settings on the fastssim graph?
- g: the green and reds are the same on both those images. the green line the training is set to use weighting and the bits metric. when i was working on this back in december, i noticed setting weight and bits in the training tool are setting higher prediction gain numbers.
- jm: is this on still images or videos?
- g: still images. the det1 stuff didn't hurt the performance at the last coding party when we first tested this. in any case, i'm happy with the results i have now. at least it's not worse anymore.
- u: using no weights and no bits is giving you best performance?
- g: on the images, yes.
- x: what are the axis labels on the last graph?
- g: that's iteration steps vs. actual coding gain from intraprediction.
- u: are you testing against subset 2 in your rd curves?
- g: the rd curves are testing against subset1 and i'm training against subset3.
- jm: it would be interesting to see these curves for pvq as well.
- g: sure.
- jm: it's worth investigating. at some poitn we need to commit to pvq or scalar or whatever, and assuming we use pvq, i realized it will have impacts on everything. similar to how the lapped transform changed the rest of the codec. at least it would change the metrics all over the place.
- g: ok. i have it running right now. i just started that data collection. i have the det1 patch ready to review. there's little to review.
- d: do you know what settings the stuff in git was trained with?
- g: i was going to ask if we should change the training tools to write out the settings in the header files.
- u: it's no weights and no bits.
- g: do you know what subsets it was trained on?
- u: do you know hte sizes?
- g: 4x4
- u: i think it's just subset3. it might have been subset1. i didn't modify those.
- g: that may be a reason i'm struggling against subset1.
- u: this is why i've moved to only testing on subset2. i remember that no weights and no bits got us the best results. i think i was graphing the prediction gain not the overall gain.
- g: that shouldn't make any difference.
- jm: what's weights vs. bits again?
- u: actuallly it might make a difference because we classify them based on prediction gain right?
- g: yes. jm, the weights vs. bits is where we weight them as the best over next best???
- g: there didn't appear to be any signs of overfitting. none of the weights were really high or zero, and i trained on subset3 which is a lot of images.
- u: i'd wnat to see this graph on prediction gain instead of overall gain.
- jm: it seems like it doesn't have to be all or nothing. reduce weights or bits, etc.
- g: not just that. part of the problem is that i don't know what to look at. here we have prediction gain telling us it's a lot better, but it's not so much better in the codec.
- jm: if you have something that seems to be working it's time to check it in. pvq will change the cost function anyway.
- d: based on these graphs i think we can check it in.
- u: we want to change the prediction metric for pvq?
- jm: we definitely want to change the selection metric. among the changes you'd want to consider individual bands and looking at the selection metric in the encoder, if any particular band is completely wrong or slightly wrong it's the same. if the prediction is 0 or way wrong, it doesn't change anything for the pvq code.
- g: as far as more changes to training tools. beyond changing for pvq, the thing we should be looking at is doing some L1 optimization, but this is probably a good intern projects.