Difference between revisions of "DaalaMeeting20140603"

From XiphWiki
Jump to navigation Jump to search
(Created page with "<pre> # Meeting 2014-06-03 Mumble: mf4.xiph.org:64738 # Agenda - reviews - work week & code party - https://daala.etherpad.mozilla.org/workweek-201406 - https://daala.eth...")
m (Add word wrapping)
Line 1: Line 1:
<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word;">
# Meeting 2014-06-03
# Meeting 2014-06-03

Latest revision as of 16:03, 6 February 2015

# Meeting 2014-06-03

Mumble:  mf4.xiph.org:64738

# Agenda

- reviews
- work week & code party
  - https://daala.etherpad.mozilla.org/workweek-201406
  - https://daala.etherpad.mozilla.org/coding-party-201408
- Deringing filter (bkoc)

# Attending

derf, gmaxwell, bkoc, jmspeex, unlord, monty

- d: Bkoc needs a room for the coding party, he should nag jack
- d: Google asked us to present at the VP9 summit
- m: I have slides!
- d: We don't know how long a slot we're getting, around an hour or two. We need to decide who will present.
- m: I will. If it gets super technical you'll need to save me.
- d: If you don't have two hours of material let me know
- m: I don't er. I do. I'm pretty sure I can fill two hours at the drop of a hat.
- d: I will look at the schedule.
- d: I don't think there is anything new about the coding party.
- d: Jack and I did talk to MSFT yesterday about daala, and that call went okay.
- d: Bkoc to present some of the work on deringing filters.
- b: I spent a fair amount of time reviewing the lit on deringing filters and sent out some papers.
- b: This week I am trying to apply the same deringing filter used in Theora to Daala, and then try to improve it for daala.
- b: In the paper titled deringing filter for scalable video coding, they're applying a smoothing filter in a 3x3 boundary with a weighing function that depends on some edge classification. There is also work applying a bilateral filter, but its computationally expensive.
- d: But it could be approximated.
- jm: This may be hard in the face of activity masking, because we don't want to undo it.
- g: perhaps some of this makes it easier, since we can take the gains and blocksize decisions from the bitstream to control the deringing filter
- jm: seems hard because we're trying to preserve small details
- d: in areas where we have a smaller quantization threshold, e.g. from activity masking, it should be less aggressive. In any case, the first thing is to get some kind of filter in-loop that helps at all. Someone will then need to teach bkoc about it, I nominate jean-marc.
- d: Would you like to explain what the HEVC filter does?
- b: In the third page you can see that they're identifying categories and applying weight functions.
- d: So what it looks like (figure 2) that they're only running the filter along one of these four directions and signaling it as side information.
- jm: so if you have a diagonal edge do you want the filter orthogonal to the edge or parallel to the edge
- d: I don't know, parallel to the edge.
- b: This removed some of the artifacts but created some other ones, e.g. shiny pixels
- g: Did you implement only one support region?
- b: I implemented only the category 1/2. 
- b: This week I will try to implement the theora deringing filter in daala and if  I can get one working fine we can modify the parameters.  Perhaps I need to review the literature further but at first I'm trying to get something working.
- jm: In the longer term it would be good to have a way which is completely different from what everyone else is doing.
- d: One advantage of starting with what was in libtheora is that we know it helps there and its old enough to not have as many patent issues.

[sidebar on how patents work, recommending
http://endsoftpatents.org/2010/03/transcript-tridgell-patents/ as starting research]

- m: The blog post is done, minus the emscriptem parts and I believe those are working, save for the loading an image into a canvas.
- jm: it would be nice to be using the latest code... In particular the DC patch. <reviews update>
- u: In the unlapping I'm not liking the results that I'm getting, as the error is not very equally distributed.

We had a long discussion about intra-prediction at this point, both in including using further away pixels outside of the lapping. Tim has concerns both that this will work less well— citing that nathan's testing with the tf's down not using the interior 4x4s at all performing no better than just the edge ones... and also some potential IPR concerns. Greg pointed out that the sun OMS did a similar thing for intraprediction ('motion vectors' for intra).  We had some discussion about jointly selecting pre-filters for equal scaling, but tim believes with the det=1 stuff out that the scaling differences there are small enough to not matter.