Subject: Re: [AVT] SVC design team -July 1 meeting moved to Thursday the 3rd

From: Alex Eleftheriadis <[email-masked]>
Date: Sat, 5 Jul 2008 02:16:20 +0300

Thanks Mike, very thorough job as usual. Responses/comments inline.  
Some of the issues were clarified in the conference call earlier today.

(I took the liberty of cc-ing the AVT list.)

On Jul 3, 2008, at 4:53 PM, <[email-masked]>  
<[email-masked]> wrote:

> Sorry for the late comments – I have not had as much time to read  
> the document as I had hoped. The comments only apply up to section  
> 7.1.2.
>
> Overall I think this is much better than the earlier versions (10  
> and earlier). It reads much better from the beginning.
>
> The main comment I have is not knowing what “single-source  
> transmission.” really is, and whether this document actually  
> specifies it, or simply refers the reader to RFC3984.
>

Single-source transmission (to be called single-session transmission  
now)  is when you do not do session multiplexing (all layers in one  
RTP session, with the same SSRC). Now that we clarified that session  
multiplexig in a single RTP session is not allowed, we can use the  
terms "single-session" and "multi-session".

> --
>
> I am confused by the text in the introduction for SST. It seems to  
> be saying that all data is carried in a single RTP session with the  
> same SSRC; when an H.264/AVC compatible subset is transmitted, RFC  
> 3984 encapsulation should be used; and when SVC enhancement layers  
> are transmitted, they are encapsulated according to this memo. It  
> is possible to do all of this at the same time? And is that what is  
> intended?

No, you either use RFC 3984 or this memo. If any enhancement layer is  
included you have to use this memo. This does not mean that the  
stream does not work with an RFC 3984 receiver; it will just contain  
additional NAL units that will be ignored.

>
> In the definition of multi-source transmission: "This specifies  
> that the SVC bitstream is distributed across multiple RTP sessions,  
> with each stream having a distinct SSRC ...", should "stream" be  
> "RTP packet stream"?
>

Yes, and per our discussion today this will be aligned to RFC 3550 to  
use the same SSRC in all RTP sessions.

> There is no definition for single-source transmission. How about  
> the following? single-source transmission: This specifies that the  
> SVC bitstream is transmitted in a single RTP session, with a single  
> SSRC, and single timestamp and sequence number spaces.

Sounds good.

>
> Section 6.5.1. states that when using single-source transmission,  
> section 5.4 of RFC 3984 applies. Can PACSI and NI-MTAP be used in  
> SST mode?
>

For PACSI yes, but for the NI-MTAP I am not sure. Comments from others?

The text should reflect that the packetization rules of 3984 apply,  
with the possible addition of PACSI NAL units (and NI-MTAP if we so  
decide).

> In table 4 for NI-T mode, why is PASCI allowed in Non-Interleaved  
> mode, but not in Single NAL unit mode? In version 10, in table 3.3,  
> it was not allowed in either mode for NI-T. Why not allow it in  
> both modes?
>

Per our discussion earlier today, this will be fixed to be allowed in  
both modes.

> Section 6.8: "The field T MUST be equal to 0 if the aggregation  
> packet containing the PACSI NAL unit is not an STAP-A packet.".  
> What about an NI-MTAP packet?
>

It should read "... or a NI-MTAP packet". They don't have DONs so the  
PACSI must carry it. I will flag it for Y.-K. to double-check.

> Section 6.8: "The PACSI NAL unit SHALL include a subset (zero to  
> all) of the SEI NAL units associated with the access unit to which  
> the target NAL units belong ...". I think this is clear, but it  
> might be improved by changing SHALL to MAY.

Ok.

>
> Section 6.9: "The NI-MTAP consists of 16 bits of unsigned size  
> information ..." should be "The NI-MTAP aggregation unit consists  
> of 16 bits of unsigned size information ..."?
>

Ok.

> Section 6.10.1: "For non-PACSI NAL units carried in a session using  
> a non-interleaved session-specific packetization mode (NI-TC, NI- 
> C)". NI-TC and NI-C are not session-specific packetization modes  
> but simply packetization modes. I find it confusing that we have  
> the terms "session-specific packetization mode" meaning single NAL,  
> non-interleaved, or interleaved and "packetization mode" meaning NI- 
> T, NI-C etc.
>

I agree. I will look into fixing this.

> Section 6.10.1: Does this need to specify the case of PACSI in NI- 
> MTAP? Is this allowed?
>

I think it does, I will look into it more closely.

> Section 6.10.1: Are some packetisation rules needed? When using the  
> single NAL unit session-specific packetization mode, is it  
> necessary to transmit PACSI whenever ETS changes?

I believe the answer is yes.

> These rules do not say what to do when there is no previous PACSI  
> NAL unit with the same ETS. This is later specified in 7.1.2.  
> Perhaps a forward reference would be helpful.
>

Ack. In fact, maybe 6.10.1 (or a big portion of it) should move in  
7.1.2.

> Section 6.10.1: Repeated comment from 19 May. Not sure this was  
> ever addressed. Considering the case of PACSI in STAP-A being  
> followed by a single NAL unit packet. The text states that the  
> incremental method is used to determine CS-DON. Why not use the SN  
> difference method, modified to work relative to the last non-PACSI  
> NAL in the STAP-A. This would seem to simplify the CS-DON recovery  
> rules to using the incremental method within STAP-A and using SN  
> diff otherwise.
>

This was not in the list of pending issues I used so I did not  
consider it at all. However, the modified rule would still have to  
take into account the incremental method, in order to get from the CS- 
DON present in the PACSI to the CS-DON of the next NAL (by counting  
how many NAL's are inbetween, thus bringing in the increment).

A better presentation may be to define something like Last_CS-DON for  
a packet, which would be equal to the CS-DON for, say, a single PACSI  
NAL unit, or the last CS-DON for an STAP-A. Then references in the  
current NAL unit can always be to Last_CS-DON (i.e., (Last_CS-DON+1)  
% 65536). This would eliminate the - apparently confusing - if/elses.

> Section 7: "packetization mode" -> "session-specific packetization  
> mode", multiple times, horrible. Perhaps best to leave it as it is?
>

Per your earlier comment, I will make an effort to have different  
term than packetization mode for multi-session transmission modes  
(maybe "MST modes"), thus eliminating the need for the term "session- 
specific".

> Section 7.1.1: "When not using NI-TC mode and a PACSI NAL unit is  
> present, the T bit MUST be equal to 0" would be clearer if written  
> positively, otherwise the reader has to look back up the text to  
> find the scope. Hence suggest "When using NI-T mode ...".
>

Agreed.

> Section 7.1.2: "For each STAP-A packet, the first NAL unit in the  
> STAP-A packet, if present,  MUST be a PACSI NAL unit containing the  
> DONC field.". I think the "if present" is not needed as there is  
> always at least one aggregation unit in an STAP-A. Hence suggest:  
> "For each STAP-A packet, the first aggregation unit MUST contain a  
> PACSI NAL unit containing the DONC field.". Also suggest removing  
> "if present" from the next paragraph on FU-A.

Per my editoral comment in these two paragraphs I agree and will  
remove that text.

>
> Section 7.1.2: There are no rules for NI-MTAP.
>

! True. Thomas, can you provide text for this?

> Section 7.1.2: I find the rules a little difficult to follow, and  
> difficult to determine whether all cases are considered. It seems  
> like the rules ar saying that you can transmit a PACSI which must  
> have DONC any time you like, and you may need to transmit one to  
> avoid certain things happening, like consecutive single NAL units  
> with different ETS, and FU followed by FU or single NAL unit.  
> Perhaps the rules could be rewritten in this way?
>

I agree and will do so now that some dubious issues have been  
clarified in my mind (what's allowed and what's not).

Thanks for the great feedback. I will produce another version,  
hopefully by Wednesday. I expect to have an editors meeting soon  
after to go through the whole document once again, and also examine  
several cases of packetization to make sure everything is covered.

In the meantime, I also want to encourage people to review Section 9  
- it has not been reviewed as closely as the rest of the text (due to  
more pressing issues in other sections but also because it's at the  
end). As we've seen from 3984, this is equally important and needs  
careful review as well.

Finally, I find Section 13 (Application Examples) not particularly  
illuminating and, in fact, not necessary. I would like to hear some  
feedback about this as well. As I mention in the text, the  
application example of the only shipping SVC product I know of  
(Vidyo's) is not covered at all.

(All typos below will be taken care of as well.)

--Alex

>
> Typos
> -----
>
> Section 5.2: "unithas" -> "unit has".
>
> Table 1: "6.66.7" -> "6.6.7".
>
> "6.1Design Principles" -> "6.1 Design Principles" (add space after  
> 6.1). Similarly for 6.5.1.
>
> Section 6.4, "success delivery" -> "successful delivery".
>
> Section 6.8: "containedin" -> "contained in".
>
> Section 6.9: "memois" -> "memo is".
>
> Figure 3 caption: "labeled" -> "labelled".
>
> Section 6.10: "desribed" -> "described".
>
> Section 6.10.1: "It is similar to the DON concept in [H.264]" H264 - 
> > RFC3984.
>
> Section 7.1: "direcly" -> "directly".
>
>
>
> Best regards
>
> Mike
>
> Mike Nilsson
> Multimedia Analysis and Coding
> BT Group Chief Technology Office
> ___________________________
>
> Sirius House (B54-MH), Room 92
> Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK
> Tel:    +44 1473 645413
> Mobile: +44 7917 025433
> Fax:    +44 1908 862365
> Email:  [email-masked]
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no. 1800000
> This electronic message contains information from British  
> Telecommunications plc which may be privileged or confidential. The  
> information is intended to be for the use of the individual(s) or  
> entity named above. If you are not the intended recipient be aware  
> that any disclosure, copying, distribution or use of the contents  
> of this information is prohibited. If you have received this  
> electronic message in error, please notify us by telephone or email  
> (to the numbers or address above) immediately.
> Activity and use of the British Telecommunications plc email system  
> is monitored to secure its effective operation and for other lawful  
> business purposes. Communications using this system will also be  
> monitored and may be recorded to secure effective operation and for  
> other lawful business purposes.
> From: Even, Roni [mailto:[email-masked]]
> Sent: 01 July 2008 14:09
> To: Thomas Schierl; [email-masked]; [email-masked];  
> [email-masked]; Amon, Peter; Alex Eleftheriadis; ye- 
> [email-masked]; Nilsson,ME,Mike,CXR4 R; Thomas Wiegand;  
> [email-masked]
> Cc: [email-masked]; Ganesan Sam-W00184
> Subject: SVC design team -July 1 meeting moved to Thursday the 3rd
>
>
> Hi,
> The meeting today is canceled. We will hold the meeting on Thursday  
> July 3rd at the same time (Israel 17:00)
> Please read the draft and send your comments to the list.
>
> Dial in number: +1-678-7955235
>
>
>
> Regards
> Roni Even

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt