[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] FW: Report of an SVC editors' meeting of July 22, 2008 and ad-hoc meeting for Dublin
Hi,
This is the summary of the current state of the work on SVC.
We intend to have an ad-hoc session in Dublin and you are invited to
join.
The ad-hoc will be on Wednesday (July 30) 15:00 - 17:00. Location will
be sent later.
We are asking for people to review the current draft and supply feedback
This is the summary made by Alex with Thomas comments.
The editors group included: Alex Eleftheriadis, Thomas Schierl, Even,
Roni, Ye-Kui Wang and Miska Hannuksela
had a meeting yesterday at the JVT meeting in Hannover, and resolved
open issues 6 and 7. There was also a
discussion on signaling, but did not reach a conclusion.
FYI, here is a summary of the resolutions from my meeting notes.
1. Open Issue #7: PACSI in NI-MTAPs/MTAPs
* PACSI allowed in MTAPs and NI-MTAPs
* First NAL unit in aggregation unit, or in a single NAL unit packet
* PACSI fields to be adapted for MTAP use. For example, A bit to
indFrom avt-bounces at ietf.org Wed Jul 23 03:06:55 2008
Return-Path: <avt-bounces at ietf.org>
X-Original-To: avt-archive at optimus.ietf.org
Delivered-To: ietfarch-avt-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4EB5C3A6853;
Wed, 23 Jul 2008 03:06:55 -0700 (PDT)
X-Original-To: avt at core3.amsl.com
Delivered-To: avt at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 897FD3A6853
for <avt at core3.amsl.com>; Wed, 23 Jul 2008 03:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.518
X-Spam-Level:
X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5
tests=[AWL=-0.072, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553,
J_CHICKENPOX_26=0.6]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lYZu5X-33WWP for <avt at core3.amsl.com>;
Wed, 23 Jul 2008 03:06:53 -0700 (PDT)
Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2])
by core3.amsl.com (Postfix) with ESMTP id 1D3D53A67A3
for <avt at ietf.org>; Wed, 23 Jul 2008 03:06:52 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
x-cr-hashedpuzzle: Ciya Cmqo Gxsq HqjQ KqtQ OVel Oi2n O7ZB PlIf RwXU SJke SU/K
VjZh ah+s c5c+ fgSV; 3;
YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBjAHMAcABAAGMAcwBwAGUAcgBrAGkAbgBzAC4AbwByAGcAOwB0AG8AbQAuAHQAYQB5AGwAbwByAEAAcgBvAGcAZQByAHMALgBjAG8AbQA=;
Sosha1_v1; 7; {EE390B0F-B30A-4BF8-89A6-36E0A631181E};
cgBvAG4AaQAuAGUAdgBlAG4AQABwAG8AbAB5AGMAbwBtAC4AYwBvAC4AaQBsAA==;
Wed, 23 Jul 2008 10:08:25 GMT;
RgBXADoAIABSAGUAcABvAHIAdAAgAG8AZgAgAGEAbgAgAFMAVgBDACAAZQBkAGkAdABvAHIAcwAnACAAbQBlAGUAdABpAG4AZwAgAG8AZgAgAEoAdQBsAHkAIAAyADIALAAgADIAMAAwADgAIABhAG4AZAAgAGEAZAAtAGgAbwBjACAAbQBlAGUAdABpAG4AZwAgAGYAbwByACAARAB1AGIAbABpAG4A
Content-class: urn:content-classes:message
x-cr-puzzleid: {EE390B0F-B30A-4BF8-89A6-36E0A631181E}
Date: Wed, 23 Jul 2008 13:08:25 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C05CBC1EC at IsrExch01.israel.polycom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Report of an SVC editors' meeting of July 22,
2008 and ad-hoc meeting for Dublin
Thread-Index: AcjsnXeS10iC6X4hT9iyJR5lrVbH0gADP0Jw
From: "Even, Roni" <roni.even at polycom.co.il>
To: <avt at ietf.org>
Cc: Colin Perkins <csp at csperkins.org>, tom.taylor at rogers.com
Subject: [AVT] FW: Report of an SVC editors' meeting of July 22,
2008 and ad-hoc meeting for Dublin
X-BeenThere: avt at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/avt>
List-Post: <mailto:avt at ietf.org>
List-Help: <mailto:avt-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces at ietf.org
Errors-To: avt-bounces at ietf.org
Hi,
This is the summary of the current state of the work on SVC.
We intend to have an ad-hoc session in Dublin and you are invited to
join.
The ad-hoc will be on Wednesday (July 30) 15:00 - 17:00. Location will
be sent later.
We are asking for people to review the current draft and supply feedback
This is the summary made by Alex with Thomas comments.
The editors group included: Alex Eleftheriadis, Thomas Schierl, Even,
Roni, Ye-Kui Wang and Miska Hannuksela
had a meeting yesterday at the JVT meeting in Hannover, and resolved
open issues 6 and 7. There was also a
discussion on signaling, but did not reach a conclusion.
FYI, here is a summary of the resolutions from my meeting notes.
1. Open Issue #7: PACSI in NI-MTAPs/MTAPs
* PACSI allowed in MTAPs and NI-MTAPs
* First NAL unit in aggregation unit, or in a single NAL unit packet
* PACSI fields to be adapted for MTAP use. For example, A bit to
indicate ificate if there at least one anchor layer representation in the
packet. All fields appear to be ok, except that Alex must see how to
extend the S/E bits and TL0PICIDX to cover MTAPs.
2. Open Issue #6: Calculation of CS-DON in NI-MTAPs in NI-TC mode
See redesign in next issue for how this is resolved.
- Re-design PACSI etc. to be extensible.
3. New design: Extending the number of available NAL units using NAL
unit type 31 adding a Subtype field 5 bits, plus 3 bits as free flags.
Subtypes: 0 reserved, 1 is empty NAL unit (used for NI-T decoding order
recovery), 2 is NI-MTAP.
For subtype 2, the last flag bit signals if the DON field is present.
Subtypes not recognized SHALL BE ignored.
In NI-TC mode, this bit is set, DON fields are set, used by NI-C
receivers, ignored by NI-T receivers. In NI-T mode this bit is not
set, DON fields are not present.
In NI-T mode the DON-present-flag shall be ignored, it is not read at
all.
PACSI keeps its own NAL unit type.
4. PACSI will be optional in general and text is something like "PACIS
MAY be present in single NAL unit and aggregation packets...". But, it
is mandatory for NI-C and NI-TC modes.
Text should be added on what PACSI is good for in the optional case.
5. We further discussed, if SDP parameters "scalability SEI" +
scalable-layer-id can be assumed to be understandable by an offer/answer
device. We further discussed if there is also a need for human readable
parameters in the SDP instead of the binary description of the
scalability SEI.
Thanks
Roni Even
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt
there at least one anchor layer representation in the
packet. All fields appear to be ok, except that Alex must see how to
extend the S/E bits and TL0PICIDX to cover MTAPs.
2. Open Issue #6: Calculation of CS-DON in NI-MTAPs in NI-TC mode
See redesign in next issue for how this is resolved.
- Re-design PACSI etc. to be extensible.
3. New design: Extending the number of available NAL units using NAL
unit type 31 adding a Subtype field 5 bits, plus 3 bits as free flags.
Subtypes: 0 reserved, 1 is empty NAL unit (used for NI-T decoding order
recovery), 2 is NI-MTAP.
For subtype 2, the last flag bit signals if the DON field is present.
Subtypes not recognized SHALL BE ignored.
In NI-TC mode, this bit is set, DON fields are set, used by NI-C
receivers, ignored by NI-T receivers. In NI-T mode this bit is not
set, DON fields are not present.
In NI-T mode the DON-present-flag shall be ignored, it is not read at
all.
PACSI keeps its own NAL unit type.
4. PACSI will be optional in general and text is something like "PACIS
MAY be present in single NAL unit and aggregation packets...". But, it
is mandatory for NI-C and NI-TC modes.
Text should be added on what PACSI is good for in the optional case.
5. We further discussed, if SDP parameters "scalability SEI" +
scalable-layer-id can be assumed to be understandable by an offer/answer
device. We further discussed if there is also a need for human readable
parameters in the SDP instead of the binary description of the
scalability SEI.
Thanks
Roni Even
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt