[06:09:03] --- tomkri has joined [06:09:21] --- tomkri has left [10:49:19] --- tomkri has joined [11:44:37] --- tomkri has left [12:10:43] --- tomkri has joined [12:16:38] --- suzukisn has joined [12:17:56] --- Loki has joined [12:19:36] --- TomTaylor has joined [12:19:45] --- petithug has joined [12:21:28] --- tomkri has left: Replaced by new connection [12:21:28] --- tomkri has joined [12:21:38] --- tomkri has left: Replaced by new connection [12:21:39] --- tomkri has joined [12:25:33] --- csp has joined [12:27:06] Hi, folks. I'm going to try to take my meeting notes in the Jabber room, if that seems OK to you [12:27:27] Starting [12:27:33] More than OK :-) [12:28:17] --- suzukisn has left [12:28:58] Status: looking for note taker ... got one [12:29:04] --- alfredh has joined [12:29:07] --- suzukisn has joined [12:29:34] Two sessions. See status charts for agenda today [12:30:29] Now Thursday. Interesting presentations on RTCP [12:30:36] Note well -- IPR [12:30:58] Document status per charts [12:31:12] --- magnus has joined [12:31:14] --- tomkri has left [12:31:15] Number of RFCs published [12:31:49] --- tomkri has joined [12:31:53] One draft waiting [12:32:50] hdrext: AD agrees there is consensus. Will be passing back to the IESG with a new request for publication [12:33:28] authors will be submitting a minor update [12:34:22] Other docs --- continuing on charts [12:36:06] --- isudo has joined [12:36:07] ATRACS passed WGLC with minor comments -- authors will submit update, people can review for a week, then will send to IESG [12:36:12] --- Dan York has joined [12:36:55] SVC -- Tom Schierl presenting [12:37:06] (Thomas) [12:37:39] Charts -- presenting changes [12:37:55] Now mailing list comments [12:38:58] Next slide - decoding order recovery [12:39:28] Had meeting this am -- 3 hours discussion, no conclusion yet, let's do it now [12:39:31] --- ysuzuki has joined [12:40:20] CL-DON chart [12:40:43] (Thomas continuing to present) [12:41:40] Still unclear in this am's discussion whether mode 0 could be supported by CL-DON [12:42:03] Next chart - classical RTP mechanisms for order recovery [12:44:36] Possible solutions chart -- based on this morning's discussions [12:44:36] --- ysuzuki has left [12:44:57] Stillno consensus [12:45:45] Roni: had design team working since last meeting. Not a closed group -- announced on mailing list. Design team will continue until open issues resolved [12:45:56] Open issues chart [12:46:47] Open issues next chart [12:48:18] Open issues third chart [12:49:16] Open issues fourth chart [12:49:45] Asking if need generic draft -- Roni no comment [12:50:28] Something more than RFC 4566 a=quality:, presumably? [12:51:50] --- ysuzuki has joined [12:52:08] Roni speaking. I'll pass on Colin's remark in a moment. Roni: thanks to Mike Nilsson (not here) as well as all the other participants. [12:52:20] wasn't important enough to pass on [12:52:42] Just did it [12:53:21] At mike: [12:53:28] Summarizing proposals [12:54:12] Thomas Wiegand [12:54:38] Looking for views on the floor -- too much back-and-forth in discussions [12:55:05] Other SDOs have deadlines -- DVD-B, others [12:55:40] Wants ability to avooid using stuff they don't want [12:56:14] Roni -- matter for AD -- have to have rough consensus, but can consult with AD [12:56:50] Dave Oran introduces himself as ex-AD. How long has this been going on? [12:57:17] Stephan Wenger: at least a year agop he made a presentation on the order recovery problem [12:58:21] Stephan: gave two choices then -- put in some info, a Nokia patented technology, or fairly complex and hard-to-understnad specificaTION PROCESS [12:58:37] aNSWER HE GOT THEN WAS GO AHEAD WITH WHAT HE THOUGHT BEST [13:00:20] We've have been here before. [13:00:52] Stephan is summarizing proposals -- add redundant info or not [13:01:20] Nokia not convinced other system would actually work under the constarints they face [13:01:46] They already have a pile of patents -- this is not important in the whole picture [13:02:22] Dave Oran: if there is an even split in the WG, we have no process for dealing with it. [13:02:56] https://datatracker.ietf.org/ipr/736 [13:03:03] https://datatracker.ietf.org/ipr/852 [13:03:09] https://datatracker.ietf.org/ipr/832 [13:03:16] https://datatracker.ietf.org/ipr/910/ [13:03:24] Asks: assumes there is IPR disclosures filed. (Yes, fort both) Dave: differences in terms of disclosures something to be considered by WG [13:03:49] Thomas Wiegand: [13:04:48] Wants to tie the techniques to the modes -- classical for modes 0 and 1, CL-DOn to mode 2 [13:05:01] Send text, then ask if there is consensus to accept it. [13:05:35] Stephan: packetization mode 2 related to high-delay applications [13:06:04] Need to buffer severaL PICTURES before doing meaningful decoding [13:06:21] Also IPR-encumbered, but not is the point [13:07:00] This is not the right dividing point [13:07:14] Timing reqts are definitely an issue [13:07:42] Not stalling draft, as Thomas implied [13:08:00] Simply not convinced it would work well without CL-DON [13:08:08] Roni asks for timeline reqts [13:08:42] Thomas: need RFC no. for SVC payload -- December [13:08:56] Follows that we need a WGLC by summer [13:09:10] WG last call can happen between meetings, of course. [13:10:52] Roni: hoping that based on work today we can achieve a full consensus. [13:11:07] (Was hoping) [13:11:54] Need to have a good description about what each of the methods means in terms of delay, ... [13:12:34] Thomas Wiegand: Why doesn't RTP provide a method already to do this synchronization [13:12:43] Roni -- does -- timestamp [13:13:03] Thomas why add unnecessary IPR [13:14:31] Stephan: RTP allows correct reconstruction of transmission order (Roni differentiates from playback) [13:16:11] There is a difference between this and problem here -- have to sequence parts of packets [13:16:27] Thomas Schierl -- problem arises with mode 2, not mode 1 [13:17:10] Back-and forth on difficulty [13:17:47] Stephan: trying to make case that there is more complexity than classical RTP mechanism was designed for [13:18:03] Roni: agreed -- otherwise thewre would be no discussion [13:18:11] --- dumdidum has joined [13:19:31] Ye-Kui: two differences. First different sessions sent to different decoders in classical model. Trying in this case to restore order set by coding specification. [13:20:01] ??: Startup time an issue [13:20:08] randell jessup [13:20:31] Ye-Kui: agreed, important point [13:21:20] Thursday -- Magnus will be presenting on RTCOP extensibility on Thur. This is a good time to discuss start-up time [13:22:09] Discussion between Thomas W and Roni on whatr Nokia is saying [13:23:55] Thomas W: if agreed that RTP method works, why not use it? [13:24:07] RTP synchronisation says nothing about the decoding order of the media. This is the point Stephan Wenger seemed to be trying to make earlier. [13:24:54] --- magnus has left [13:25:26] Line cutoff after Joerg, who remarked that our time is being wasted [13:25:47] Next presnetation: Ye-Kui on RFC 3984bis [13:26:18] Charts: outline [13:26:30] Changes: [13:26:38] http://www.ietf.org/proceedings/08mar/slides/avt-1.pdf [13:27:21] Technical change 1 [13:28:16] Tech change 2 [13:28:27] Tech change 3 [13:29:01] Tech change 4 [13:29:10] Tech change 5 [13:29:36] --- magnus has joined [13:30:53] "Thursday -- Magnus will be presenting on RTCOP extensibility on Thur. This is a good time to discuss start-up time" I hope this was corrected to say Joerg. [13:31:27] Roni: clarifying the need for this change [13:31:27] You could swap presentations? :-0 [13:31:45] Tech change 6 [13:31:50] Open issues [13:32:02] Probably not a bigger problem, but I think I prefer to talk about why SRTP isn't mandatory. [13:34:12] Open issues continued [13:35:27] Next chart -- issues 5 on [13:35:37] (5-6) [13:37:04] Roni on 6: [13:37:14] Point is that you want it to beconsistent [13:37:58] Ye-Kui: pointed out the text [13:37:59] --- yjs has joined [13:38:05] Roni: repeated his point [13:38:42] Stephan: discussed this one a while ago in a WG meetoing --- marked as an issue over a year ago [13:38:51] Issue 7 [13:40:44] Randell Jessup at the mike: trying to change the level without having the right parameter set is problematic. May have to renegotiate. Sender could send every parameter set for every level he could be downgraded to -- doesn't seem good. [13:41:15] Randell is really open to suggestions -- thinks it unlikely you can just modify parameter sets on the fly [13:41:52] Roni: problem is when you specify new level, and you want to use different parmeters [13:42:11] First point with H.264 is that decoder should be able scale to anything [13:42:45] In H.323 send parameter sets inside -- had this point before -- video switch [13:43:28] StephaN: YES, HAD THIS DISCUssion, sees no one has better idea than proposal [13:44:18] Roni: should be clear that what you ask for is full information incl parameter set [13:44:28] Stephan: not same in H.264 [13:45:00] Basically (Roni) need way to ask for new parameter set [13:45:18] Stephan: OK, need to choose something [13:45:38] Roni and Stephan: present options to the list [13:46:05] Randell: do we need to continue support for out-of band parameters sets? [13:46:22] Do we need to support in-band parameter sets? [13:46:39] If you are not downgrading level problem is much simpler [13:47:01] Randell: one other issue -- what do we allow to be downgraded? [13:47:22] Talking 1B [13:47:39] Roni: H.241 says something [13:48:05] Roni: if not part of the hierarchy, 1B should be treated separately [13:48:13] Maybe an idea to include level 1b to this bis-draft [13:49:35] Randell: downgrade a real issue [13:49:53] Other issues (Randell) [13:50:11] External meanings out of scope) Roni: OK [13:50:44] Issue 3: different payload types have different packetizations [13:51:08] Can't say a property of a payload stream is a property of a payload type [13:52:06] Thomas Wiegand: are we talking about a new profile here? [13:52:34] Roni: may have new SDP parameters. Should be approved in a separate draft. [13:52:57] When we have an update to the main spec, we include the parameters in that document [13:53:17] Final chart: should this be a WG item? [13:53:49] Several hands in favour, none against. Will be WG item. Will merge with H.264 stuff [13:54:06] Next presentation Ye-Kui on MVC [13:55:04] Charts showing multiview application principles (as in last meeting) [13:55:57] ... ddown to MVC vs. SVC chart [13:56:27] Status of MVC standardization [13:56:41] Summary of draft [13:57:54] Changes since -00 [13:58:17] Question to WG: WG item? [13:58:45] Thomas Wiegand question: are we going to repeat all the SVC stuff here? [13:58:49] It would be desirable to have a single mechanism for cross-layer synchronisation for all H.264 extensions, rather than a different one for each extension. [13:59:44] (Colin's remark repeated to meeting) [14:00:29] Stephan: believes he asked for a sense of direction before [14:01:07] Should MVC be a delta on SVC -- end up having to read a whole cascade of documents [14:02:07] --- csperkins has joined [14:02:07] --- Loki has left: Lost connection [14:02:07] --- Dan York has left: Lost connection [14:02:07] --- isudo has left: Lost connection [14:02:07] --- petithug has left: Lost connection [14:02:07] --- ysuzuki has left: Lost connection [14:02:07] --- TomTaylor has left: Lost connection [14:02:07] --- csp has left: Lost connection [14:02:07] --- dumdidum has left: Lost connection [14:02:07] --- suzukisn has left: Lost connection [14:02:07] --- alfredh has left: Lost connection [14:03:14] jabber.org died [14:04:42] Ah - jabber.no survived :-) [14:05:16] http://www.ietf.org/proceedings/08mar/slides/avt-4.pdf [14:07:37] --- petithug has joined [14:14:13] --- TomTaylor has joined [14:14:15] --- ysuzuki has joined [14:14:22] --- csperkins has left [14:14:47] Want my notes? Nothing really happened [14:14:49] --- csp has joined [14:15:15] Audio has been working all along. [14:15:15] Alan Clark currently going over changes [14:16:03] Next steps chart [14:16:35] Other SDOs interested in HR [14:17:10] Roni: Colin sent note to list -- need to address organization of measurements (architecture) [14:17:21] Suggests Alan correspond with Colin [14:17:30] Alan said it himself - this is very application specific. We saw with RTCP XR that application specific metrics don't work well. [14:17:48] Roni asks for other comments -- none [14:17:52] Define general metric, which can then be used for particular applications. [14:18:07] Joerg's draft a guide [14:18:14] --- yjs has left [14:18:15] This is all for today [14:18:29] --- ysuzuki has left [14:18:38] Tom - Thanks for scribing! [14:19:00] Now to verify I can retrieve my logs. [14:19:17] I'm about to dump some missing notes here to complete the record [14:19:29] I have the log saved, if not. [14:19:35] Stephan: thinks we agreed on stand-alone. We can work on delta, then do necessary copy-paste Roni: don't have to worry for WG items New topic: non-compound RTCP (Johansson) Chart 1 Chart 2: what is non-compound RTCP? Modification of bandwidth algorithm AVPF immediate mode Enforcing compound RTCP Encryption/ authentication Next steps Jonathan Lennox: ques for clarification. Re definition. Randell: no problem with either definition RTCPHR - Alan Clark [14:20:19] --- csp has left [14:20:43] --- petithug has left [14:25:46] --- tomkri has left [14:33:26] --- magnus has left [14:33:26] --- TomTaylor has left: Lost connection [14:39:02] --- yjs has joined [14:41:05] --- yjs has left