[00:58:01] Kosmiester joins the room [01:01:57] Kosmiester leaves the room: offline [01:31:11] * joined: Raymond [01:31:53] petithug joins the room [01:32:12] petithug leaves the room [01:35:42] Marc Petit-Huguenin joins the room [01:37:32] * quit: Raymond ("Page closed") [02:24:22] * joined: slicer [02:28:41] * joined: rillian [02:30:25] * joined: blizzard [02:30:30] * left: blizzard [02:32:43] * joined: blizzard [02:33:00] christopher.blizzard joins the room [02:33:24] [blizzard] hi [02:33:35] hi [02:33:52] hi [02:34:42] creepy listening to ambient noise in the room [02:34:47] over a crazy ogg relay [02:36:28] [slicer] Is the irc<->jabber gateway bidirectional? [02:37:16] gmaxwell joins the room [02:37:23] Probably, I do not know. [02:37:34] [blizzard] yes, it is [02:37:41] works from here or from there [02:37:46] Of course. [02:38:00] I wonder what the delay is on the sound [02:38:26] [blizzard] pop [02:38:32] !who [02:38:33] * members: blizzard, gmaxwell, rillian, slicer [02:38:41] From my previous experience, the sound delay is bad [02:38:54] bad is what, 5 seconds? 20? 30? [02:39:21] I'm going to vanish early - have to go to the airport [02:39:29] Not sure, but bad as in you ask a question for the previous slide... [02:39:53] heh [02:40:04] Perhaps it will be better this time. [02:40:17] I think it was something like 10 seconds. The ogg is somewhat behind the mp3 (about 1 second when I tested before) [02:40:31] (before meaning last night when I turned it back on) [02:40:31] yeah, and not sure how much buffer my browser stuck in there [02:40:34] probably a few seconds [02:40:44] [slicer] The audio feed really illustrates how important the work of this WG is :) [02:40:57] oh if you're listening in firefox— it might be adding quite a few seconds, unfortunately. [02:41:13] slicer: I'd suggested perhaps we have a mumble feed for a future meeting. ;) [02:41:25] (well, suggested to Jean-Marc) [02:41:31] [slicer] That would rocks. Could even be bidirectional ;) [02:41:50] Well, the problem is that it is streaming, when it should be real-time (VoIP). [02:42:08] It was not designed for interactivity [02:43:09] The other interactive part will be when they'll ask for a "hum" over jabber [02:43:33] It's …fun… when the delay means the jabber people can't figure out what they are humming for,. [02:43:50] * joined: Cyde [02:44:37] Thorvald joins the room [02:44:51] Well, I guess for this they take in account the delay. Thta's why it is the only interactive part of it... [02:49:45] * joined: richardus [02:50:27] Somebody knows what is the meeting currently in room 6? [02:50:34] on channel 6 [02:54:55] * joined: mindspillage [02:57:02] [slicer] ec480503f97ba77dc2d7252cbcbd97bac0ea0fe8 [02:58:09] [slicer] Oops, sorry, dropped the mouse on the floor :) [03:02:25] I just added links to the codec-bof slides to the little quick pointer page: http://people.xiph.org/~jm/hiroshima_bof.html [03:03:32] Handy. Thank you. [03:05:25] bnsmith joins the room [03:10:01] katwalsh joins the room [03:18:01] stpeter joins the room [03:19:16] stpeter has set the subject to: Codec BoF, IETF 76 | Audio Stream @ http://videolab.uoregon.edu/events/ietf/ietf766.m3u [03:39:53] stefan.sayer joins the room [03:41:06] gkanai@gmail.com joins the room [03:41:43] rtb joins the room [03:43:28] Ben Schwartz joins the room [03:46:48] * joined: derf [03:48:18] * joined: drowe67 [03:52:03] RjS joins the room [03:53:26] jgunn joins the room [03:54:07] kpfleming joins the room [03:54:15] HELIOPOLIS joins the room [03:54:25] HELIOPOLIS leaves the room [03:54:54] BAboba joins the room [03:55:08] jmspeex joins the room [03:55:21] jlcJohn joins the room [03:55:44] * joined: bkw_ [03:56:28] bkw_: have you seen the ericsson g.719 royalty free licensing announcement? [03:56:29] * joined: Math [03:56:40] [bkw_] yes [03:56:48] shamus joins the room [03:56:55] [bkw_] I emailed licensing [03:57:10] we did too... we'll see what happens [03:57:21] * joined: ron [03:57:26] [bkw_] I am waiting to see what exactly the terms are [03:57:31] [bkw_] but it'll be interesting none the less [03:58:16] [bkw_] I have already libtooled the floating versions of bv16 and bv32 and have it compiling on linux and my mac... so we'll see if we can get a codec module wiped up [04:00:54] !who [04:00:54] * members: bkw_, blizzard, Cyde, derf, drowe67, gmaxwell, Math, mindspillage, richardus, rillian, ron, slicer [04:01:02] Cullen Jennings joins the room [04:01:05] can someone add this url to the topic: http://people.xiph.org/~jm/hiroshima_bof.html - works from firefox w/ vorbis [04:01:06] bkw_: let me know when you have something running, i did the same yesrday for sems... [04:01:23] [bkw_] I'm sure the G719 code is not thread safe [04:01:30] the meeting has begun [04:01:42] haibin joins the room [04:01:57] kpfleming has set the subject to: Codec BoF, IETF 76 | Audio Stream @ http://videolab.uoregon.edu/events/ietf/ietf766.m3u === http://people.xiph.org/~jm/hiroshima_bof.html [04:02:00] roar.hagen joins the room [04:02:04] Pete St. Pierre joins the room [04:02:05] thank you [04:02:23] * joined: Raymond [04:02:27] [Math] bkw_: doesnt seem to use anything else except contextual structs [04:02:31] Joe Hildebrand joins the room [04:02:33] keep in mind the audio stream is about 10 seconds behind reality [04:02:34] paul.erkkila joins the room [04:02:37] * joined: kfish [04:02:59] [kfish] ã“ã‚“ã«ã¡ã¯ [04:03:32] [gmaxwell] kfish, it seems my jabber<->irc bridge is not UTF-8 clear! [04:03:43] dromasca joins the room [04:03:55] [derf] ã‚ˆã†ã“ã [04:03:56] csp joins the room [04:04:00] Are slides posted somewhere? [04:04:03] enrico joins the room [04:04:04] yes [04:04:19] slides at https://datatracker.ietf.org/meeting/76/materials.html#wg-codec [04:04:19] http://www.ietf.org/proceedings/09nov/slides/codec-0.pdf [04:04:26] jgunn: linked to from here (all of them) http://people.xiph.org/~jm/hiroshima_bof.html [04:04:42] page 7 [04:04:51] thanks [04:05:01] AdrianFarrel joins the room [04:05:31] slide 8 [04:05:39] wolfgang.beck01 joins the room [04:05:44] Anyone out there listening to the audio stream? [04:05:49] yes [04:05:54] [derf] Yes. [04:05:57] How is the codec behaving ;-) [04:06:02] theora is fine :) [04:06:26] suzukisn joins the room [04:06:42] slide 9 [04:06:47] different codecs for different use cases? [04:06:50] isn't theora a video codec? [04:07:01] I worry I'm many seconds behind [04:07:06] slide 10 [04:07:06] Is that legitimately a hot button? Or is that a concern advanced by just one or two people who are also entirely opposed to the creation of the WG? [04:07:06] blizzard means Firefox's general Ogg+Theora+Vorbis support. [04:07:19] ahh [04:07:22] err, yeah, s/theora/vorbis/ [04:07:22] duh [04:07:54] gmaxwell: are you referring to the question about one codec vs. many codecs? [04:08:01] Trying to build a secure crypto algorithm requires an infinite amount of math research. [04:08:41] Adam Roach joins the room [04:08:58] kpfleming: Yes. My impression from the list is that Roni has been advancing that concern, but that he has been largely alone in pushing it as material concern. (Others have asserted that the desire is to not create many but there was an unwillingness to limit to one) [04:09:33] remote users - when you want any of these read out loud let us know [04:09:53] i would agree with your impression. most people i have talked to are really intending for this to produce a single codec that meets the requirements, but that there may be a need for more than one if the requirements demand it [04:09:57] It's not as though the non-RF codecs are any less susceptible to IPR problems that are not yet known. [04:10:03] roar.hagen leaves the room [04:10:07] slide 8 is back on screen - btw [04:10:37] slide 10 [04:11:00] roar.hagen joins the room [04:11:00] roar.hagen leaves the room [04:11:23] kpfleming: I would go further to say that most people are not worried that the working group would be unable to navigate the decision about a split there… in any case. We should probably establish if there exists a clear consensus on this point, at some point. [04:11:35] probably so [04:11:49] lebobits joins the room [04:11:54] yusuke hiwasaki [04:11:56] roar.hagen joins the room [04:12:09] itu-t speech and audio coding [04:12:13] poor sucker [04:12:15] slide 2 [04:12:39] he was 'voluntold' for this duty, apparently [04:12:49] slide 3 [04:12:53] meknappe joins the room [04:13:04] https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr200803gls.html [04:13:21] slide 4 [04:13:34] "can't blame anyone else for what I might say" we got it [04:13:37] Randall Gellens joins the room [04:13:44] just glad he's here [04:13:54] indeed [04:14:43] Ben Schwartz leaves the room [04:15:08] bens joins the room [04:15:21] fyi, there are approximately 50 people in the room here [04:15:35] more than that, no? [04:15:46] naah, pretty empty rows behind you [04:15:47] I'd say closer to 75 - 100, no? [04:15:59] Who is speaking? [04:16:00] ok, flem, I want a count. NOT IT [04:16:01] yeah [04:16:04] I get about 80 [04:16:11] hold, I'll put in his name... [04:16:12] so i can't count [04:16:13] Yusuke Hiwasaki is speaking [04:16:20] also, the bluesheet has not made it to my side of the room [04:16:20] thx st [04:16:33] there are two blue sheets [04:16:44] haven't seen either one [04:17:09] which side of the room kevin? [04:17:20] spromano joins the room [04:17:22] dromasca leaves the room [04:17:29] it cam by the right hand side [04:17:30] came [04:17:30] flem's on left side [04:17:34] left side, looking to the front [04:17:43] well, depends on which way u r looking, eh? [04:17:48] stage left [04:17:52] ahh, i see it now [04:17:55] lebobits threw in "eh" for the Canadian [04:17:57] its on its way back [04:18:05] dromasca joins the room [04:18:07] i get ~60 [04:18:14] joe wins [04:18:25] that's pretty close to 50, so i win by proxy [04:18:34] slide 7 - sorry guys, i was thrown out of jabber [04:18:38] you get to edit a document on IPR of anything that may come out of a future wg, should one be formed. Lucky bugger [04:18:49] oh boy [04:18:54] lucky i'm married to an attorney [04:18:56] Alfred Heggestad joins the room [04:18:59] [04:19:17] prenup? [04:19:29] no, actually [04:19:33] LOL [04:19:45] [04:20:00] dromasca leaves the room [04:20:14] the J in Juniper is for 'joke' it seems :-) [04:20:16] martin.thomson joins the room [04:20:38] P for Party was already taken unfortunately [04:20:48] dromasca joins the room [04:21:00] slide 11 [04:21:09] for easier reading, the presentations are available online for (free) download: https://datatracker.ietf.org/meeting/76/materials.html#wg-codec [04:21:09] bens leaves the room [04:21:35] paul.erkkila leaves the room [04:21:54] bens joins the room [04:22:49] slide 12 [04:25:37] slide 13 [04:25:45] did he say anything about access to their work product? [04:25:50] so SG membership is not as horribly expensive as i expected, although there are many SGs [04:26:04] Joe Hildebrand: he did not [04:26:12] work product - reference code, or just the written spec? [04:26:16] was that per SG, or per ITU-T overall? [04:26:24] the cost for membership, that is [04:26:35] e.g. audio feeds of their meetings, their jabber chat rooms, etc [04:26:36] i think its overall [04:26:41] Stephan Wenger at the mic [04:26:57] Joe Hildebrand: there is not much access [04:27:26] documents of the meetings are closed [04:27:26] note: i'm in the room here, so don't need channeling, necessarily. [04:27:38] unless you want to know the answer yourself. :) [04:27:50] ok, so if anyone has a question to be asked at the mic, please make that clear in your question [04:28:02] Yes, please prefix with MIC: [04:28:17] yes, pls, tx [04:28:24] bens leaves the room [04:28:38] slide 15 [04:28:44] what was his clarification? Couldn't quite get it [04:28:49] bens joins the room [04:29:08] Emil Ivov joins the room [04:29:18] slide 16 [04:29:30] very helpful indeed. Many thx [04:29:48] jean-marc taking the mic to present [04:29:53] anyone on the "clarfication" from the man at the mic? [04:30:08] draft-valin-codec-guidelines [04:30:11] that was stephan wenger, right? [04:30:18] jean-marc [04:30:30] christopher.blizzard leaves the room [04:30:34] kpfleming: yes, that was [04:30:39] whois vs. whowas [04:30:48] The person speaking at mic in the cream color shirt was Stephan wenger [04:31:03] that clarification was that many Question documents (minutes, contributions, etc.) are available via anonymous FTP, even though they are not required to be [04:31:12] I was asking about the "clarification" from the asian man after Stephen [04:31:16] oh [04:31:20] kpfleming: that's an important clarification. [04:31:24] stephanwenger joins the room [04:32:10] yes. we've had a number of communications, and access to T.38 V4 drafts-in-process, in our SIP Forum FoIP working group, which is not at all affiliated with ITU-T SG16 [04:32:26] it's not terribly easy or convenient, but it's not completely closed. [04:32:35] it's important because it clarifies that the documents are NOT available, except by whim. [04:32:43] right [04:33:54] stephanwenger leaves the room [04:34:12] smack down [04:34:13] true, but access is MUCH better than it was ten years ago [04:34:15] I love it [04:34:17] mud match [04:35:24] go read the Tao. [04:35:37] even a newbie like me knows that stuff :-) [04:36:04] with respect to the question about ITU-T process, I think there was confusion about whether we were talking about work output (specification) vs. artifacts of the process (meeting minutes or whatever) [04:36:24] work output is generally available on itu.int nowadays [04:36:39] i have had no trouble download various G.x, T.x and V.x recommendations lately for free [04:36:44] This is why the existing proposed codecs are useful, because the qualify requirements by proving the minimum that is possible. [04:36:55] Glenn Parsons joins the room [04:37:26] bens leaves the room [04:37:31] er s/the qualify/they qualify/ [04:37:34] JANLINDEN-X301 joins the room [04:37:45] bens joins the room [04:38:34] many ITU recommendations (at least the Q.x series) still require payment for access though [04:38:43] when I was asking about work products, my intent was not just the final specification. quite often, the record of which decisions were made by whom for what reasons is really useful. [04:38:51] indeed [04:40:25] magnus joins the room [04:41:27] At random I just downloaded Q.32 for free. [04:41:37] ok, maybe it has improved then [04:41:58] Care to check first and speak later please - emotive area! [04:42:05] is the throat clearing semantic in nature? [04:42:07] :D [04:42:17] stephanwenger joins the room [04:42:42] Julien Meuric at the mic [04:43:26] Ingemar Johansson at the mic [04:43:49] thank the L for the RFID name thing, I would have NEVER gotten that guy's name from how he said it!! [04:43:50] Got dropped from the jabber. The organization of the documents in an ITU question outside of the ITU ftp server (which is closed) is up to the group. If a group were aiming for transparency, like JVT did, they can certainly do so. [04:44:30] @ sw: whose decision is that? Rapporteur? [04:44:40] ben@xmpp.estacado.net joins the room [04:44:47] nod. useful. [04:45:24] is this a clarifying question? [04:45:47] Joe Hildebrand: you mean jean-marc's throat clearing? he's had a cold since last week, and almost didn't come to the meeting [04:46:01] uggh sitting on the aisle here was a bad idea... [04:46:17] kpfleming: thank you. i just wanted to make sure we weren't ignoring someone. [04:46:19] more up and down than a junior high dance [04:46:29] AdrianFarrel: i had previously (last year) attempted to get copies of Q.913 and related documents and was unable... i should have checked before posting here, agreed. [04:47:16] Someone else can also test, it doesn't have to be tied to the contributor, of course. [04:47:34] gmaxwell: correct [04:47:42] Testing is an important contribution that anyone can make to the process… [04:47:54] even more valuable when it's not the contributor's own testing [04:48:16] Absolutely. "But it passed all my tests!" [04:48:41] which translates into 'It compiles!' [04:49:00] ben@xmpp.estacado.net leaves the room [04:49:16] bens leaves the room [04:49:27] he's a plant [04:49:29] rush him [04:49:32] !!!!!! [04:49:33] bens joins the room [04:49:37] [04:49:48] lebobits not meaning to stir the pot too much [04:50:11] haibin leaves the room: Computer went to sleep [04:50:21] folks, we can always ask yr question here in the jabber room [04:50:23] heh. up the baud rate to at least .5ekr. [04:50:24] bring it [04:50:41] OH THK YOU for invoking EKR, [04:50:45] kpfleming - no problem. ITU-T enabled free availability about 18 months (I think) ago. It was nominally an Experiment and was renewed, but I think it is now de facto permanent [04:50:45] he'll be soooooo plsd [04:51:43] Alexander.Chemeris joins the room [04:51:47] bit exact vs. bit compatible is a very important distinction in codec standardization [04:51:47] On which slide are we? [04:51:58] meknappe: indeed [04:51:58] compatible [04:52:04] the one named intellectual property [04:52:06] bens oops [04:52:15] ok, thanks [04:52:17] @meknappe: do elaborate [04:52:20] no numbering :-( [04:52:22] bens: canadian spelling [04:53:02] bit exact means the test vector inputs must result in an exact, expected output [04:53:18] well, i know of people who have highly optimized G.729 DSP implementations that don't deploy them because they do not produce bit-exact output from the encoder, even though the output is perceptually equivalent to the listener [04:53:47] Bit exact makes testing somewhat easier, and provides more consistent performance. But it prevents compatible quality improvements over time, and may significantly inhibit platform specific optimizations. [04:53:49] haibin joins the room [04:53:50] bit compatible means the bit fields are compatible, but test vectors may result in (usually) slightly different outputs [04:53:54] if there isn't bit exact, will the other side barf? [04:54:03] no, the output is still compatible [04:54:08] Simon Perreault joins the room [04:54:09] lebobits: No, this is "bit compatible". [04:54:10] i.e. what's the con/cost associated w/ bit exact? [04:54:12] G.729 vs G.729A is a good example of bit compatible [04:54:19] gmaxwell: IIUC, jm is saying non-bitexact decode, never mind encode. [04:54:33] ok [04:54:36] I'm not sure whether the side discussions ongoing here are helpful for anyone (be they on jabber or in the room) [04:54:39] bens: The optimization issue applies. [04:54:46] for example, imagine a G.729AB implementation that has a better voice activity detector than the one in the recommendation, and thus might produce SID frames at times when a bit-exact codec may not [04:54:48] you can decode G.729 output with a lower complexity G.729A decoder and vice versa [04:55:01] [derf] lebobits: For example, CELT has both a fixed-point and floating-point implementation. [04:55:04] G.729A is slightly lower quality but much less computationally complex [04:55:12] sw: u r welcome to disconnect from server. ;-) [04:55:13] [derf] Neither produces bit-exact results compared to the other. [04:55:30] derf: … and each is the fastest on the correct hardware. [04:55:35] [derf] Each one is significantly faster than the other on some hardware (e.g., depending on whether or not you have an FPU). [04:55:51] * joined: adiabatic [04:55:55] for example, G.711 mu-law and A-law ARE NOT bit compatible .... LOL [04:56:06] one of the features of the Jabber chat is that it allows us to ask "real" clarifying questions, i.e. ones we actually want the answer to, rather than ones we want in the minutes. [04:56:48] @ Joe: remember, the jabber archive lives forever [04:56:58] it's worse/better (?) than being in minutes [04:57:17] depending on your perspective, and how little you type b4 u think [04:57:19] understood. that's not the point. there are lots of questions that don't need to interrupt the IRL discussion, however. [04:57:29] EXACTLY [04:58:03] However, it makes it twice as hard to stay on top of both discussions, and I'm not smart enough to multitask ;-) [04:58:15] stephanwenger: practice! :) [04:58:29] Too old fo rthat [04:58:38] haibin leaves the room [04:59:18] yay [04:59:21] Of course codecs can be measured as well... And working groups determine modes of, .. yes. [04:59:22] thank you jon [05:00:18] bens leaves the room [05:00:34] (11:08:30 PM) Ben Schwartz: Trying to build a secure crypto algorithm requires an infinite amount of math research. < this is a good comment on that point. [05:01:45] there is a requirements doc. read it. [05:01:46] bens joins the room [05:02:09] will it deliver pizza and beer? that is the most important question clearly [05:02:26] kpfleming: that can be layered on top [05:02:32] [Math] only if you use it to call somewhere that delivers [05:02:47] ben joins the room [05:02:57] Running code in he\ [05:03:06] er in the IETF??? [05:03:33] stephanwenger leaves the room [05:03:35] code is documentation for codecs [05:03:54] Simon Perreault: feel free to say that at the mic [05:04:17] wolfgang.beck01 leaves the room [05:04:31] at least for G.722.1 and Annex C, the code is the normative reference for the codec [05:04:36] stpeter: too long line [05:05:30] wolfgangbeck01@chat.gizmoproject.com joins the room [05:05:30] if GIPS would have added iSAC (wideband version) to iLBC RFC, I think it would have been very very successful [05:05:31] ether Knappe's RFID is broken, or in his pic he's dressed as a ninja [05:05:44] his is broken, it was yesterday in AVT as well [05:05:49] definitely ninja [05:05:57] TLS is also defined in code-like syntax [05:06:00] it's a spectrum [05:06:09] another ninja [05:06:20] genuine article, this one [05:06:25] ninja [05:06:30] stpeter: is there an electronic bluesheet in this room? [05:06:36] there is [05:06:41] two, i think [05:06:45] MD5 (RFC 1321) is another example. [05:06:53] gkanai@gmail.com leaves the room [05:07:09] apparently this group fails at passing bluesheets successfully around the room :-) [05:07:32] as is SHA1 (RFC 3174) [05:07:33] BS [05:07:40] that's just NOT true [05:07:47] bens leaves the room [05:07:57] which, me? or stpeter speaking fast? [05:07:59] lebobits comment was wrt stpeter's ekr comment [05:08:02] cool. [05:08:15] stpeter is at about 0.8ekr atm [05:08:28] bens joins the room [05:08:34] dromasca leaves the room [05:08:34] That sound about right [05:09:08] wolfgangbeck01@chat.gizmoproject.com leaves the room [05:09:13] you should see him do one of his rapid-fire presos. he puts one word on each slide, and has ~150 slides. it's awesome. [05:09:18] Importantly: Most "high quality" codecs (esp in terms of music-grade performance) that people are familiar with are not low latency. [05:09:20] dromasca joins the room [05:09:30] that is correct [05:09:31] wolfgang.beck01 joins the room [05:09:36] slide 3 [05:09:45] but the goal here is for an interactive communication codec [05:09:56] but CELT for instance appears to be an exception [05:10:11] low latency AND good music quality [05:11:05] The more I read, RFC 3174 is a canonical example of something widely-deployed, widely-interoperable, defined as C code. [05:11:09] slide 4 [05:11:45] Joe Hildebrand: you have a secret weapon there. wait for the right moment to use it. ;) [05:11:53] nod. [05:11:56] * joined: Tester [05:15:08] stephanwenger joins the room [05:15:27] This is not intended to be a pass fail process. [05:15:34] It's intended to be development. [05:16:08] is it common that the requirements be already set for a WG to be formed? [05:16:23] stefan.sayer: it's common that there is a starting point [05:16:40] until there is working group consensus, it won't get an RFC number. [05:16:43] IETF WG's usually start with a statement of the problem and some proposed solutions from what I've seen from watching for a while… [05:17:05] kpfleming leaves the room: Replaced by new connection [05:19:53] I don't see "let's use TDM" as a technical goal... LOL [05:21:48] enrico leaves the room [05:22:09] enrico joins the room [05:23:52] kpfleming joins the room [05:24:20] ugh... the ietf jabber chat rooms don't give you history when you join. bummer. [05:24:44] tomkri joins the room [05:25:32] MIC: The working group is responsible for finding a generally acceptable balance the competing factors. Age and quality are just one example. [05:27:09] Why wouldn't *every* working group suffer the same problems? [05:27:18] You can say that about *any* piece of technology. [05:27:38] (that being 'how can you be sure that there will not be IPR') [05:27:46] every WG does face this - most are just much smaller minefields. [05:28:05] Well... sort of. There's no obligation in (US) patent law to police uses. But it's not reasonable to expect absolute certainty that no IPR concerns will arise. [05:28:14] we should not be afraid of innovation [05:28:38] bens: do you still want that at the mic? [05:29:01] kpfleming leaves the room: Replaced by new connection [05:29:08] Joe Hildebrand: I suspect someone else will say it eventually. [05:29:10] MIC: "Making the Internet Work Better" is a big mission.... adding another CODEC does not do harm if it is not adopted.... and if it is adopted, then it makes the Internet work better. [05:29:37] 'freedom" [05:30:15] Making the Internet accessible to FOSS developers MAKES the Internet better. [05:30:21] G722 has packet loss problems, FWIW. [05:30:27] Whi wrote the crappy code? [05:30:49] yes, G.722 is ADPCM based [05:30:50] MIC: In its determination, the IETF does not consider "turf"... but merely if we have the expertise and interest to complete the work. The IETF has TRILL WG, which some believe competes with IEEE 802.1... CAPWAP WG, which relates to aspects of IEEE 802.11... [05:30:58] and does do well with lost reference [05:31:01] does not [05:31:35] pee joins the room [05:32:31] note: the current lines are long. i'm going to stand up to channel all of your requests. be prepared to re-send right before it's my turn [05:33:03] I suspect person will say this but [05:33:34] dromasca leaves the room [05:33:37] BAboba >>the IETF does not consider "turf"<< That is a very "interesting" statement [05:33:45] We need to some to say that for many industries codecs major expense. There are a few companies, amply represented at the lines that make lots of money on codecs. They are very unviersally against "commoditing codecs" [05:34:03] but reducing cost of codecs would be good for very large part of internet [05:34:14] other than a tiny handfull of companies that currnely make money off them [05:34:23] I don't know - if you agree you can do that but [05:34:25] if not drop it [05:34:46] It's also inevitable. Hard to cry over business models which are doomed and depend on forestalling the public from cooperating to produce their own solutions… [05:35:26] "principle" or "philosophical" goals might be better than "business" goals... [05:35:28] _We_ are opening it up. [05:36:11] let's get out of this IPR rathole [05:37:19] i"m next [05:37:29] please re-send now [05:37:50] Who is at the mic? [05:37:55] dromasca joins the room [05:38:19] Hildebrand [05:38:21] Joe [05:38:30] (re: G.722) [05:38:30] roni_even joins the room [05:38:33] sorry, before joe. [05:39:24] wolfgang.beck01 leaves the room [05:39:41] shamus leaves the room [05:39:45] sorry, that was me. thought i said my name [05:39:47] CAPWAP - no competitio - it's a control plane for entities running 802.11 (among other) [05:40:00] Joe, audio lag, I was trying to ask about the person before you. [05:40:06] he's asking who was talking before joe ;) [05:40:14] someone spoke too fast to hear really [05:40:25] he's coming up to the mic again... [05:40:35] Stephan Wenger? [05:40:41] yes [05:41:25] there was a guy before me and after Stephan [05:41:35] [derf] Happy Fun Goals. [05:41:39] the one who said that the IETF should tell these people to go away [05:42:48] Thats the one I was asking about, yes. [05:43:24] KOen VOs on mic [05:43:36] i didn't catch his name, sorry [05:44:31] bens leaves the room [05:44:47] bens joins the room [05:47:46] [adiabatic] audio feed from within firefox died [05:47:47] gmaxwell leaves the room [05:48:02] magnus leaves the room [05:48:05] bens hums [05:48:09] [derf] Right, the Ogg stream now appears to be 404. [05:48:10] hum [05:48:23] [derf] What are we humming for? [05:48:23] [ron] hum [05:48:37]