Jack: Created page with "

 # Meeting 2014-12-23  Mumble:  mf4.x..."

2015-01-06T16:26:59Z

Created page with "<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-12-23 Mumble: mf4.x..."

New page

<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-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.
</pre>

DaalaMeeting20141223 - Revision history

Jack: Created page with "
# Meeting 2014-12-23 Mumble: mf4.x..."