IETF
codec@jabber.ietf.org
Thursday, 28 July 2011< ^ >
gmaxwell has set the subject to: Codec WG meeting IETF-80 | http://tools.ietf.org/wg/codec/agenda?item=agenda80.html | http://ietf80streaming.dnsalias.net/ietf/ietf808.m3u | Say MIC: to have your comments spoken in the room
Room Configuration

GMT+0
[04:24:59] tterribe leaves the room
[05:05:33] <irc-> * joined: ron__
[05:07:49] <irc-> * quit: ron_ (Ping timeout: 258 seconds)
[06:45:31] gmaxwell leaves the room
[09:10:56] <irc-> * nick: ron__ is now ron_
[09:57:34] <irc-> [ph3-der-loewe] ron_: haha, nice BTS ping pong ;)
[11:59:33] tterribe joins the room
[12:57:31] gmaxwell joins the room
[13:30:03] tterribe leaves the room
[13:49:45] tterribe joins the room
[14:25:04] tterribe leaves the room
[15:01:24] tterribe joins the room
[15:01:34] tterribe leaves the room
[15:02:25] tterribe joins the room
[15:02:34] tterribe leaves the room
[15:03:46] tterribe joins the room
[15:04:04] tterribe leaves the room
[15:05:27] tterribe joins the room
[16:23:34] gmaxwell leaves the room
[16:31:03] gmaxwell joins the room
[16:31:30] gmaxwell leaves the room
[17:06:54] giles leaves the room
[17:21:05] tterribe leaves the room
[17:32:33] gmaxwell joins the room
[17:34:38] gmaxwell has set the subject to: Codec WG meeting IETF-81 | http://tools.ietf.org/wg/codec/agenda?item=agenda81.html | http://ietf81streaming.dnsalias.net/ietf/ietf804.m3u | Say MIC: to have your comments spoken in the room
[18:20:50] pcgod joins the room
[18:23:50] Aleksej joins the room
[18:34:34] <Aleksej> Hello. There is a typo at http://opus-codec.org/contact/ : imformation
[18:37:59] giles joins the room
[18:41:53] <giles> Aleksej: thanks, fixed!
[18:43:20] tterribe joins the room
[18:43:35] tterribe leaves the room
[18:43:50] <Aleksej> no problem
[18:44:06] tterribe joins the room
[18:44:10] <Aleksej> What does the "Some rights reserved." refer to?
[18:44:35] tterribe leaves the room
[18:44:43] <Aleksej> “Some of the content is not All rights reserved”?
[18:45:05] <giles> "Some rights reserved" usually means CC copyright license
[18:45:09] tterribe joins the room
[18:45:12] <giles> although there doesn't appear to be one of the page
[18:45:35] tterribe leaves the room
[18:45:58] <Aleksej> At least it's not "Creative Commons Some rights reserved" without details whatsoever.
[18:46:01] tterribe joins the room
[18:46:05] tterribe leaves the room
[18:46:13] <giles> It's just trying to be more friendly
[18:46:27] <Aleksej> If it means “Some of the content is not All rights reserved”, I like it.
[18:46:50] <gmaxwell> I'm not sure where that arose from, though “Some of the content is not All rights reserved” is factually correct.
[18:47:20] <giles> the IETF drafts, for example
[18:47:24] tterribe joins the room
[18:47:27] <gmaxwell> And the code.
[18:47:35] tterribe leaves the room
[18:49:20] tterribe joins the room
[18:49:35] tterribe leaves the room
[18:52:01] tterribe joins the room
[18:52:05] tterribe leaves the room
[18:54:53] <irc-> * joined: jmspeex
[18:57:31] <Aleksej> I usually temporarily read it as something like "by-nc-nd"…
[18:58:13] <Aleksej> But it's not good enough to guess.
[18:59:20] <Aleksej> I mean when there is a reference to CC.
[19:00:04] <giles> yes, I agree that would be...sloppy
[19:00:05] gmaxwell leaves the room
[20:32:44] gmaxwell joins the room
[20:35:43] Aleksej leaves the room: leaving
[20:52:23] <irc-> * joined: mindspillage
[20:55:06] giles leaves the room
[20:58:46] <irc-> * quit: rillian (Ping timeout: 260 seconds)
[21:03:21] <irc-> * joined: rillian
[21:03:39] giles joins the room
[21:22:06] gmaxwell leaves the room
[21:29:58] bens@mit.edu joins the room
[21:30:45] gmaxwell joins the room
[21:30:52] <irc-> * quit: mindspillage (Ping timeout: 260 seconds)
[21:31:18] jmspeex joins the room
[21:31:36] gmaxwell leaves the room
[21:31:37] gmaxwell joins the room
[21:33:52] <irc-> * joined: gnafu
[21:34:27] <irc-> * joined: mindspillage
[21:37:03] <irc-> * joined: basilgohar
[21:37:23] <irc-> [basilgohar] Lots of familiar names...:)
[21:38:02] <irc-> * joined: anonymouz666
[21:38:06] <irc-> * joined: nightrid3r
[21:38:55] <giles> is there a stream yet? I don't see a listing on meetecho.
[21:39:06] <irc-> * joined: haxar
[21:39:25] <irc-> * joined: slicer
[21:39:33] kpfleming joins the room
[21:40:46] janskoglund joins the room
[21:43:06] gmaxwell leaves the room
[21:43:30] Cullen Jennings joins the room
[21:43:44] gmaxwell joins the room
[21:44:28] <giles> http://ietf81streaming.dnsalias.net/ietf/ietf804.m3u for live(ish) audio
[21:44:41] <kpfleming> jmspeex: David Vossel: ah, cool. the only thing that wasn't obvious to me in the opus.h file was that the opus_decode() function returned the output sample number.... In opus.h it says it returns the CELT error code, which is weird.... After being confused by that i just looked at the test_opus.c file in the src directory and used that as my documentation
[21:45:13] <jmspeex> Oops, will fix
[21:45:20] <gmaxwell> For the record, another 13 in IRC.
[21:46:26] <kpfleming> gmaxwell: what is the IRC channel?
[21:46:38] <giles> kpfleming: #codec-wg at irc.freenode.net
[21:46:39] <irc-> [gnafu] codec-wg: #codec-wg
[21:46:47] <irc-> * joined: kpfleming
[21:46:55] <kpfleming> oh, it's linked
[21:47:00] <irc-> * left: kpfleming
[21:47:04] <giles> indeed
[21:47:30] <kpfleming> is the audio feed working?
[21:47:39] <giles> I can hear the mp3 audio stream
[21:47:46] <bens@mit.edu> worksforme
[21:47:53] <irc-> *** gnafu can't hear the Opus stream.
[21:48:49] <gmaxwell> Hopefully in a few more IETFs it'll be an Opus stream. :)
[21:49:47] <kpfleming> jmspeex: David Vossel: Oh, one other thing. opus_decode when FEC is in use. it appears that if FEC isn't used by the encoder, enabling that feature on the decoder will result in no audio.... I'm surprised by this since FEC is just redundant information
[21:52:47] michel.daggelinckx joins the room
[21:53:02] Jonathan Lennox joins the room
[21:53:11] Jonathan Lennox leaves the room
[21:53:16] Jonathan Lennox joins the room
[21:54:52] <kpfleming> Greg Maxwell speaking now
[21:55:26] <giles> very hard to hear
[21:55:48] <kpfleming> better?
[21:56:03] michel.daggelinckx leaves the room
[21:56:07] <irc-> * left: nightrid3r
[21:56:22] <giles> yes! thanks
[21:56:26] <giles> still very quiet though
[21:56:32] <kpfleming> he speaks quietly
[21:56:36] katwalsh joins the room
[22:04:05] RjS joins the room
[22:08:12] <kpfleming> Jean-Marc Valin at the mic
[22:12:06] <kpfleming> Christian Hoene presenting now
[22:13:12] <kpfleming> waiting to update to the correct slices
[22:13:15] <kpfleming> sorry... slides
[22:19:55] <gmaxwell> Here has been some bit error rate testing: http://lists.xiph.org/pipermail/celt-dev/2010-June/000380.html the graph is now at http://people.xiph.org/~greg/celt/error.sweep3.png .. there hadn't been any obvious interest on the codec list previously so I hadn't posted about it there, I guess (I thought I had!)
[22:20:14] <gmaxwell> I've got some additional examples that I'll post to the list.
[22:21:11] <gmaxwell> I think I (or JM) posted audio files for seamless bitrate and mode switching on the lists, IIRC and Jean-marc tried to play a mode/bitrate sweep in the last meeting but the meeting ran out of time.
[22:21:35] <gmaxwell> I also posted an example with 50% loss, though its an old one.
[22:21:35] <bens@mit.edu> well do it this time!
[22:23:33] <katwalsh> 1000 years is a great number to be able to cite.
[22:24:52] <gmaxwell> 1000 years of fuzz testing is conservative.. it's basically one of my standard testing runs.
[22:25:20] <gmaxwell> I certainly don't want to discourage people from doing their own tests!
[22:25:42] <janskoglund> and have you listened through the material for artifacts
[22:25:56] <bens@mit.edu> rough consensus and running codecs
[22:26:25] <gmaxwell> Not 1000 years of it! haha. But no, for bulk tests I use PEAQ (and objective test metric, supercharged SNR if you will) and listen to the outliers.
[22:27:18] <janskoglund> fair enough:)
[22:29:00] <gmaxwell> Someone might want to speak to the difficulty of implementing given the reference and "dropping in over the weekend…"
[22:32:24] <gmaxwell> Obviously tandeming has been tested— in the real life usage, but I don't know that anyone was keeping track of coverage…
[22:33:05] <kpfleming> gmaxwell: not sure that's true, actually. most real life usage of SILK doesn't end up with tandeming in the way it is being talked about here.
[22:35:53] <gmaxwell> Worth asking them. The I suppose other point is that by design it shouldn't be an issue. One thing we've tested in depth is tandeming with itself.
[22:36:59] <kpfleming> personally i don't care about tandeming being a blocker... i'm sure it's going to 'fail to degrade' any audio that arrived over a lower-bandwidth codec
[22:39:11] <gmaxwell> I was actually really worried about tandeming with itself.
[22:39:43] <gmaxwell> "Is 2.5ms low enough for you?"
[22:40:02] <bens@mit.edu> 5 ms...
[22:41:58] <kpfleming> i fail to understand that... if a G.711 ulaw stream is packetized in 20ms packets, that results in a 20ms delay for that stream, no?
[22:42:48] <giles> I think he was saying Opus (in the default mode) is 5 ms encoder delay + 20 ms packetization
[22:42:54] <kpfleming> right
[22:43:07] <giles> one could use 10 ms packetization and come under 20 ms total delay
[22:43:09] <bens@mit.edu> Someone should explain the situation to him
[22:43:09] <gmaxwell> Yes. We have some additional delay beyond that (5ms) as does virtually any codec that does anything more complicated than G.711.
[22:43:13] <bens@mit.edu> we can't do it here though
[22:43:22] <kpfleming> so if a carrier can handle the 20ms packetization using G.711 ulaw, i don't see how adding 5ms would break any networks
[22:43:42] <kpfleming> i may talk to him after the meeting to understand what he means
[22:46:13] <gmaxwell> I'm sad that no one seems to have seen the objective testing results fro the prior IETF: http://tools.ietf.org/agenda/80/slides/codec-4.pdf slide 24.
[22:46:21] <gmaxwell> and on.
[22:47:46] <giles> do we know the language distribution of the skype and mumble users Greg mentioned?
[22:48:45] <kpfleming> personally, i would only consider the skype and mumble users as anecdotal evidence. they weren't actually testing Opus, and while Opus was derived from SILK and CELT, it does have differences, including of course the hybrid mode.
[22:49:24] <bens@mit.edu> kpfleming: Opus is essentially a perfect superset of SILK and CELT, so quality of SILK and CELT forms a lower bound on quality of Opus
[22:50:26] <kpfleming> bens@mit.edu: sure... but in this case, it's much safer to convince people when the *actual* running code was tested, not something similar.
[22:51:29] <bens@mit.edu> Japanese is quasi-tonal; it has a "pitch accent" system that is valuable for intelligibility but not as crucial as Mandarin (which is in turn not as sensitive as Cantonese)
[22:52:09] <gmaxwell> beyond the field tests, I believe that spanish, german, finnish, and english have been in the listening tests already out there. I guess that would be another thing to add to that informational draft: which langauges were tested in each test.
[22:52:43] <kpfleming> gmaxwell: yes, that would be extremely valuable. however, i believe that anisse's point is that no single test at this point has been done against two languages.
[22:52:44] <bens@mit.edu> I hope that Christian Hoene and the Google developers can get together to decide what tests they would like to perform, if they would like to perform paired tests at two sites.
[22:52:55] <gmaxwell> That isn't true.
[22:53:22] <kpfleming> i may have been assuming too much then.
[22:53:45] <gmaxwell> Well, it seems that no one is on the same page about what has already been done. Thats okay, thats why the informational draft was created.
[22:54:27] <kpfleming> it may just be that some of this is a matter of how the data is presented
[22:55:04] <gmaxwell> A majority of my messages to the list go without any comment. People pay attention to the arguments. There hasn't been an argument on these details before!
[22:55:16] <kpfleming> indeed
[22:55:29] <kpfleming> very few reponses to *anything* on the list except patent related discussions
[22:56:14] <gmaxwell> At (xiph) we have some licensed collections which may be useful here— we need to check the licenses.
[22:56:38] <gmaxwell> It's kind of depressing to spend 6 hours writing a technical update and only get comments from the IRC regulars on IRC. :)
[22:57:16] <gmaxwell> (not that all the IRC regulars are excellent :) )
[22:58:10] <gmaxwell> er!
[22:58:17] <gmaxwell> not that that are not excellent!
[22:58:23] <giles> speak for yourself :)
[22:59:55] <bens@mit.edu> I am concerned that acquiring the source code for USAC to this group will create serious IPR contamination issues.
[23:00:11] <bens@mit.edu> I would strongly prefer that the codec working group have no contact with USAC
[23:01:20] <kpfleming> +1
[23:01:27] <janskoglund> interesting, why's that?
[23:01:47] <bens@mit.edu> There is no real legal problem, but the appearance of independent development is valuable.
[23:01:53] <kpfleming> yes
[23:02:13] <kpfleming> there is nothing to defend if you never had access to it in the first place :-)
[23:02:33] <bens@mit.edu> The last thing I want is any possible rumor that Opus copied anything from USAC. Better as it is, that we don't even know how it works.
[23:02:51] <gmaxwell> Sure, but they can encode and decode stuff... if they're feeling helpful.. Or just give us their originals and decoded stuff.
[23:03:01] <kpfleming> s/USAC/anything except what was contributed to the WG/
[23:03:24] <gmaxwell> At least most of the Opus design came too early to be based on USAC. This whole process has taken a long time. :-/
[23:04:07] <gmaxwell> FWIW, USAC isn't much in terms of competition — it doesn't do low latency at all. It's kinda scary that we may be remotely competitive with a code with >10x the delay.
[23:09:17] <bens@mit.edu> "final characterization" is really nonsense. People are still characterizing G.711
[23:11:48] <giles> I guess testing is going to take the whole discussion window
[23:11:49] <bens@mit.edu> "Why you should use Opus in your product"
[23:12:02] <gmaxwell> The room said "so we have to have consensus on the lies?" "Yes."
[23:12:12] <giles> haha
[23:12:47] <bens@mit.edu> "Is Opus any good?"
[23:13:26] <kpfleming> actually, the question right now is "do we think it's good enough to publish as a proposed standard and find out if it really *is* good?"
[23:14:09] <giles> mp3 stream died
[23:14:22] <bens@mit.edu> MIC: Current encoder performance always represents a lower bound.
[23:14:28] <bens@mit.edu> giles: worksforme
[23:14:40] <kpfleming> bens@mit.edu: your name is?
[23:14:47] <bens@mit.edu> Ben Schwartz
[23:15:16] <bens@mit.edu> Also maybe mention that the encoder is in a public repo...
[23:15:21] <giles> back
[23:16:51] <bens@mit.edu> I don't think a hum is required.
[23:17:23] <kpfleming> only one opposed, it appears
[23:17:25] <bens@mit.edu> Why do we need to adopt this as a deliverable? If people want to produce this thing, they can do so
[23:17:52] <kpfleming> because then it gets to go through WGLC, and get WG consensus that it is valuable
[23:18:01] <bens@mit.edu> well, ok. I don't get it.
[23:18:50] <gmaxwell> Yea, it's not some single crazyman's summary. And that the WG thinks this is an accurate list / summary of tests the WG thought was useful.
[23:19:02] <bens@mit.edu> then the WG can approve it when it's done
[23:19:06] <bens@mit.edu> or not approve it
[23:19:10] <bens@mit.edu> why approve it in advance?
[23:19:36] <bens@mit.edu> anyway, afaict this has no effect, so whatever
[23:19:41] <gmaxwell> Or abandon it.
[23:20:22] <kpfleming> it's not being approved in advance. the WG is stating that it is willing to accept it as a WG work item, with a deliverable date and planned reviews.
[23:20:33] <gmaxwell> Can people hear JM?
[23:20:36] <gmaxwell> (on the mp3)
[23:20:43] <bens@mit.edu> gmaxwell: too much latency. No JM yet.
[23:20:43] <janskoglund> yes
[23:20:57] <gmaxwell> okay, I couldn't hear him over the speaker…
[23:21:23] <kpfleming> the document will continue to be expanded and test results come in, until the WG decides there is an 'adequate' amount of test results and that the document is ready to review for publication
[23:21:30] <kpfleming> s/and/as/
[23:21:39] <bens@mit.edu> kpfleming: I understand.
[23:22:44] <bens@mit.edu> I agree with JM's position on padding.
[23:24:28] <giles> the draft says the padding SHOULD be zero
[23:24:56] <kpfleming> giles: the draft should say MUST... someone should post that on the list
[23:25:36] gmaxwell leaves the room
[23:26:20] <giles> kpfleming: draft-ietf-codec-draft-07?
[23:26:22] <giles> "he additional padding bytes appear at the end of the packet, and SHOULD be set to zero by the encoder, however the decoder MUST accept any value for the padding bytes."
[23:26:47] <kpfleming> giles: draft-ietf-codec-opus-07, i believe
[23:27:20] <giles> er, yeah, draft-ietf-codec-opus-07 was what I was quoting. sorry.
[23:27:23] <giles> where did you see a MUST?
[23:27:35] <kpfleming> i was suggesting it should be changed to MUST
[23:27:41] <giles> ah, ok
[23:27:46] <kpfleming> if there is a security concern with non-zero values, then MUST is better
[23:36:54] RjS leaves the room
[23:37:03] gmaxwell joins the room
[23:37:14] RjS joins the room
[23:37:26] RjS leaves the room
[23:38:59] <bens@mit.edu> No, this does not change the SDP
[23:39:39] <kpfleming> not for current requirements, correct
[23:41:36] gmaxwell leaves the room
[23:42:23] gmaxwell joins the room
[23:44:33] <kpfleming> meeting adjourned
[23:44:59] <giles> whew
[23:45:22] <kpfleming> good results all around
[23:45:24] kpfleming leaves the room
[23:45:45] <gmaxwell> Thanks everyone who joined via IRC. I'm shutting down the gateway now.
[23:46:02] irc- leaves the room
[23:46:56] Cullen Jennings leaves the room
[23:46:59] janskoglund leaves the room
[23:47:05] bens@mit.edu leaves the room
[23:47:07] katwalsh leaves the room
[23:48:18] RjS joins the room
[23:49:55] pcgod leaves the room
[23:52:04] RjS leaves the room
[23:52:05] RjS joins the room
[23:53:30] RjS leaves the room
[23:53:38] giles leaves the room
[23:58:07] gmaxwell leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!