# Meeting 2014-01-14
Mumble: mf4.xiph.org:64738
# Agenda
- work week update ( https://daala.etherpad.mozilla.org/workweek-201402 )
- interns
- Anyone waiting on anyone else for reviews now?
unlord: I would still like a review of https://review.xiph.org/132/
jm: have two more to review, rest is still up
# Attending
jack, derf, unlord, jmspeex, gmaxwell, td-linux
xiphmont: will be asleep for tomorrow's meeting :-( I'll see you in my early morning and early evening.
# pvq
- jm: what's the plan for pvq now?
- derf: greg is doing activity masking and monty is going the 16x16
# det 1
- derf: how did that turn out?
- g: behavior is the same as i showed last week. i couldn't get anything better than that.
# next things
- nathan: we came up with two things for me. the first is an idea for better coding of the motion vectors.
- derf: i want him to look into the square polar stuff you were doing. the other one was my idea for having multiple predictors and partitioning the coding space that way.
- g: in terms of the MVs, there are a bunch of ways we can encode x and y. we can code them independently or we could code sums and differences between coordinates. there are two obvious projections that we could potentially use to get them into angle and magnitude form. one is sum an difference whicih gets you a diamond shape, and the other is coding one magnitude and a radius around that magnitude which gets you a square shape instead of a diamond shape. i did some stats on real MVs and you could make some guesses about which structure was better.
- derf: the other idea is multiple predictors. you code the decision but it's easy to code. most motion fields are piecewise continuous. the theory is that if you make one predictor the median of neighbors and the other the 0,0 vector. inside one piecewise continuous region you'd predict the median and at the boundary you'd use 0,0 instead. so the flags are only not what you'd expect along the boundary. even in the case where there's no advantage to having two predictors you aren't wasting any bits. the idea is that it will always give you a gain.
- jack: which one are you going to start on first?
- nathan: probably the polar one.
- derf: yes, the question that will come out of that work is what does closest mean?
- g: the easy definition of closest that makes it easy to prune depends on how you code the MVs.
- jm: i was thinking that i'd look at pvq from another angle. what should we change in the rest of the code to account for PVQ? and i've got some IETF stuff to do.
- derf: the stuff i tried was .... removing restriction that neighboring motion partitions only differ by one level ... ripping out CGI and changing out dynamic programming algorithm.
- g: how do you do OBMC windows in that case?
- d: for the largest block along an edge, you can only have two motion vectors on that edge. so i can split the MVs down on one side of that edge, but i can't add any MVs on the edge.
- g: you'll get weirdly shaped OBMC boundaries right?
- d: no. it works fine. since you can fold all those into one extra interpolation it requires no extra work per pixel.