DaalaMeeting20141223

From XiphWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
# Meeting 2014-12-23

Mumble:  mf4.xiph.org:64738

# Agenda

- reviews
- update1

# Attending

xiphmont, derf, unlord, jack, yushin, jmspeex

# reviews

- 548 and 547 are waiting on feedback

# update1

- x: It's ready to go up. I was going to put it on xiph.org and do the standard announcements. Does anyone want to do more than that or are there changes that need to be made?
- u: My recollection is that HEVC destroyed all the branches but not it looks ok.
- t: It still destroys them somewhat.
- x: It got better by about the same amount we got better since the last time we ran metrics.
- j: We should measure that against teh AWCY HEVC we currently test against.
- u: I didn't notice any particular change when I was eyeballing the graph.
- x: We both got better by a noticeable amount. We were consistently better than in July although not by a dramatic amount. It looked like from  July we held still and everyone else fell behind.
- u: Maybe I'm missing something but HEVC is doing an incredible job in crepuscular on the trees.
- x: It's still doing stuff, just less of it.
- jm: I think on crepuscular we are beating everyone else.
- x: I still think that end of show looks better. But I seem to be judging differently than everyone else. The reason we look better on end of show is that there is a lot more mid frequency content, and we seem to be the only codec that does well there. The other codecs seem to drop the center frequencies. It's a good hack.  If you're going to drop a lot of content then that is the place to do it. .In end of show, it's more obvious.
- jm: I'm wondering if there is a color conversion issue on end of show.
- t: Yeah, it's definitely there. I don't know what happened. Are you using the original PNG file?
- x: yes
- t: So that's 16bit PNG?
- x: I coverted them. I do not have a colorspace problem on mine. Who has color management turned on in Firefox? It's on by default now.
- u: How do I change the image in update1?
- x: Go to the larger test which is linked, which has a dropdown on the bottom.
- t: THe obvious solutoin here is to convert the original images to y4m and back again.
- x: I have gfx.colormanagementmode to 0, which is non-default. Let me flip that bit. Holy shit, I see it now with default settings.
- t: Also if you convert to y4m it will convert it to 420 instead of 444.
- x: I used abcompare, but not sure what it did. I'll have to go look. I bet the original have a colorspace declaration and the others got stripped out by mogrify. I'll figure out why.
update: it was the exact opposite in fact: mogrify was adding unwanted colorspace declarations
- j: Publishing this on moz research blog too?
- x: Not sure how, but I assumed both.
- j: I'll see if I can get it to work this afternoon.

# bpyramid

- t: MPEG2 doesn't seem to have bpyramid stuff. Is that true?
- d: Yes.
- t: Should we avoid this? Or should I have the bitstream support it but be turned off?
- d: I'd want to review stuff before deciding.