Revision as of 09:57, 29 October 2013 by Jack (Created page with "<pre> # Meeting 2013-10-29 ## Agenda - gstreamer post mortem - IETF plans - research team staff meeting - roadmap ## Attending derf, jack, gmaxwell, jmspeex, unlord ## gstr...")
# Meeting 2013-10-29 ## Agenda - gstreamer post mortem - IETF plans - research team staff meeting - roadmap ## Attending derf, jack, gmaxwell, jmspeex, unlord ## gstreamer conference - g: The conference went pretty well. I made a couple of interesting contacts. I presented on Daala and Opus and I crammed a bit too much into the presentation. There were a lot of people itnerested and grabbing me after. It took me a half hour to leave the room. - j: How many people were there? - g: Roughly 200 fit in the room, but there was standing room only for the talk. We got a couple of people who hang out in IRC who came to the talk. I believe there will be coverage about it in the next LWN. - d: I was hoping either him or Corbett would show up. - g: They emailed me after and asked for the slides. - d: You were quote of the week in LWN: "Audio's boring since bandwidth is so cheap these days; just send everything uncompressed. Let's talk about video." - j: Seems like it was time wells pent. - g: I got some interesting feedback from people who wanted multi-channel in RTP. - jm: Why did they want that? - g: One person had a bid on multi-entertainment system in aircraft and they are going to provide 5.1 surround to the seats in aircraft. - d: Give everyone quadraphone earphones for people with four ears. ## IETF plans (some discussion of IETF plans) ## research team meeting - j & d: plan is to talk for 15 mins, then take questions as they come. ## roadmap - j: keep this stuff in mind and we'll sit down and write it all down in vancouver. ## PVQ review - jm: when can I expect a review? - j: so today? - d: not today. I can try for tomorrow. - jm: I'd like to have all three reviewers review it. - g: I need to do Nathan's reviews first. And the SAD patches. One thing that goes along with that is that we have some problem in the MC code. The two code paths disagree and I haven't tracked that down yet. - u: I'll get my review done this week. ## Chrome from Luma - u: I've got some tools for this. By comparing it to what happens if we use the mode from teh luma block and does freq domain intraprediction. It showed 1.5dB of prediction gain which I thought was good. My other test I want to do is to do something similar to an RD curve and look at how the prediction gain changes as we scale up the quantizer. I'm currently doing lossless but it might be interesting to see if the accuracy of chrom from luma falls off as the Q goes up. - jm: i've been thinking that there are going to be itneresting interactions between CfL and PVQ once we get PVQ hooked up. Because if you are looking not at DC but at AC then if we get the gain of the CfL wrong it won't affect PVQ all that much because PVQ would be able to encode a state of 0 and code a change in the gain that's required to get the actual chroma. To a point where if we're doing that we'd just want to predict the gain that we give to the PVQ; ie, not compute an actual prediction... - u: this is with partitioning? - jm: with or without partitioning. In both cases the only thign that changes is how to compute that particular gain. When you are using PVQ the actual normalized prediction is the same regardless of whatever the gain is. There's probably going to be cases where CfL fails for scalar quantizaiton but works pretty well for PVQ quantization. - u: I can definitely see that. The other question I had is the stuff Greg did creating the modes for the three neighbors based on the DC. Which filters was it using? - g: The filters that were in at the time. - u: The same weights for the modes at all block sizes? - g: Yeah. Just 4x8 filters. It was done before we had multiple block sizes. I would expect that the mode mapings might not be the same. It's easy enough to train values for those. i can post the littel tool I used to do it. - u: If you post that I can integrate it into the tools I have that use the actual filters so it will spit them out. The other question: the thouht that CfL has worse PSNR. Is that because it includes the cost to signal the mode? - d: Yes. It had somewhat lower rate and a good chunk lower PSNR. I didn't have good graphing tools then. We could do three things: CfL, intraprediction using Luma's mode, and we could also signal a mode. - g: We had some speculation that when CfL was making mistakes it might follow constrasts in the luma plain and this might mask things. What we really should have is some SSIM metric that combines all three planes and measures each of the planes against that. Everyone in the literature does all monochrome stuff. We could use the TID2008 database to check this out. They took a bunch of images and sent them through various distortions and then got lots of people to rate the quality of images. You can take your perceptual metric and have it rate the images and compare to see how much agreement there is with the TID database. This is one of the things that people used ot argue that metrics like SSIM are useful. The TID database shows they agree with humans. We could modify an SSIM tool and see if that agrees better with the TID database than monochrome SSIM does. It doesn't have to be a lot of work, but I haven't considered it terribly important.