Subject: [payload] Open issue #4 // RE: I-D Action: draft-ietf-payload-rtp-h265-03.txt

From: "Wang, Ye-Kui" <[email-masked]>
Date: Tue, 6 May 2014 18:43:39 +0000

Let's try to resolve one more open issue, the 4th, through this thread.

The 4th open issue listed below is relatively minor, which is on using a different parameter category for level-id in Table 1 in Section 7.2.2. I have some reservations to do that because of the following reasons:
- Level down-grade has been mentioned already five times in this section, including once right after the table. Thus, the intention is pretty clear already.
- Using a different category would increase the size of the table, which is pretty big (more than one page) already.
- As a result of the discussion on other threads on profile-id and profile-compatibility-indicator, we are likely to allow to some extent asymmetric use of these two as well, e.g. depends on the direction attribute. A better way to express this I think would still be use the 'C' category but clearly spell out what is allowed.

Magnus, with the above reasons in mind, please let me know you do still have a strong opinion to use a different parameter category for level-id or you can live with using the 'C' category.

BR, YK

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Wang, Ye-Kui
Sent: Wednesday, April 30, 2014 11:29 AM
To: [email-masked]
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

Dear All,

Compare to -02, we have addressed most of the numerous comments and tickets, from Magnus, Jonathan, Jonatan, Bernard, ..., as well as the following changes:
- Addition of sprop-sei, as suggested by Stephan on Apr. 23 to the reflector, agreed by most of the authors, no objection from anyone.
- Addition of an informative, brief description of the display orientation SEI message, which is among one of those new SEI messages that have some systems usage.
- Addition of a definition of NAL-unit-like structure. The term was used but not defined earlier.
- Addition of descriptions for use of the PLI and SLI messages (specified in RFC 4585) and the FIR message (specified in RFC 5104) with HEVC, in addition to the RFC 4585 RPSI message for which the use description was already included, as agreed during the presentation at the previous IETF meeting

Remaining open issues:
- On profile-compatibility-indicator and interop-constraints (raised by Magnus, being discussed among Magnus, myself and Yago, no conclusion yet)
- On recv-sub-layer-id and using of sprop-vps for session negotiation (raised by Magnus, still being discussed among the authors and Magnus)
- On source-specific sprop parameter sets (raised by Magnus, still being discussed among the authors and Jonathan for exact text changes)
- On using a different parameter category for level-id (raised by Magnus, discussed between Magnus and myself, no conclusion yet)
- I just noticed that the definition of "packet stream" itself needs to be changed back to "RTP stream"

We will try to address the above open issues as soon as possible. At the same time, further review and comments are welcome.

BR, YK

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 30, 2014 10:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF.

        Title           : RTP Payload Format for High Efficiency Video Coding
        Authors         : Ye-Kui Wang
                          Yago Sanchez
                          Thomas Schierl
                          Stephan Wenger
                          Miska M. Hannuksela
	Filename        : draft-ietf-payload-rtp-h265-03.txt
	Pages           : 92
	Date            : 2014-04-30

Abstract:
   This memo describes an RTP payload format for the video coding
   standard ITU-T Recommendation H.265 and ISO/IEC International
   Standard 23008-2, both also known as High Efficiency Video Coding
   (HEVC) [HEVC] and developed by the Joint Collaborative Team on Video
   Coding (JCT-VC).  The RTP payload format allows for packetization of
   one or more Network Abstraction Layer (NAL) units in each RTP packet
   payload, as well as fragmentation of a NAL unit into multiple RTP
   packets.  Furthermore, it supports transmission of an HEVC bitstream
   over a single as well as multiple RTP streams.  The payload format
   has wide applicability in videoconferencing, Internet video
   streaming, and high bit-rate entertainment-quality video, among
   others.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-03

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 May 2014 16:36:25 +0200

On 2014-05-06 20:43, Wang, Ye-Kui wrote:
> The 4th open issue listed below is relatively minor, which is on
> using a different parameter category for level-id in Table 1 in
> Section 7.2.2. I have some reservations to do that because of the
> following reasons:

> - Level down-grade has been mentioned already five times in this
> section, including once right after the table. Thus, the intention is
> pretty clear already.

> - Using a different category would increase the size of the table,
> which is pretty big (more than one page) already.

Sorry, I don't understand why changing C into D for the relevant places
for the level-id would expand the table.

D: Downgradable Configuration, as C except possible to answer also with
a lesser value.

> - As a result of the discussion on other threads on profile-id and
> profile-compatibility-indicator, we are likely to allow to some
> extent asymmetric use of these two as well, e.g. depends on the
> direction attribute. A better way to express this I think would still
> be use the 'C' category but clearly spell out what is allowed.
> 
> Magnus, with the above reasons in mind, please let me know you do
> still have a strong opinion to use a different parameter category for
> level-id or you can live with using the 'C' category.>
> BR, YK
> 

I think you might have misunderstood the extent of my proposal to fix
this, please see above to see if you think this is acceptable.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Tue, 13 May 2014 16:37:06 +0000

By expanding the table I meant exactly that one more notation of the new category, e.g. the same as you did, would need to be added.

However, if you do have a strong opinion here, then let's do what you suggested. I do not have a strong opinion here.

BR, YK

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, May 13, 2014 7:36 AM
To: Wang, Ye-Kui; [email-masked]
Subject: Re: Open issue #4 // RE: [payload] I-D Action: draft-ietf-payload-rtp-h265-03.txt

On 2014-05-06 20:43, Wang, Ye-Kui wrote:
> The 4th open issue listed below is relatively minor, which is on using 
> a different parameter category for level-id in Table 1 in Section 
> 7.2.2. I have some reservations to do that because of the following 
> reasons:

> which is pretty big (more than one page) already.

Sorry, I don't understand why changing C into D for the relevant places for the level-id would expand the table.

D: Downgradable Configuration, as C except possible to answer also with a lesser value.

> profile-compatibility-indicator, we are likely to allow to some extent 
> asymmetric use of these two as well, e.g. depends on the direction 
> attribute. A better way to express this I think would still be use the 
> 'C' category but clearly spell out what is allowed.
> 
> level-id or you can live with using the 'C' category.> BR, YK
> 

I think you might have misunderstood the extent of my proposal to fix this, please see above to see if you think this is acceptable.

Cheers

Magnus Westerlund