Subject: [AVT] commenst on draft-ietf-avt-rtp-svc-12.txt

From: "Even, Roni" <[email-masked]>
Date: Mon, 7 Jul 2008 11:44:13 +0300

Hi,

I managed to read only up to section 7 and will try to finish later in
the week.

Some editorial comments

1.  Section 1 "this may result in each layer being carried in its own
RTP session, or in having multipe layers encapsulated within one RTP
session. ". change  multipe to multiple

2.  Section 1 last paragraph has also twice

3.  In section 4.1.1 VCL appears in dependency  representation but the
abbreviation is not defined before 

4.  Same for IDR change to Instantaneous Decoding Refresh (IDR)

5.  In 4.1.2 you have "in  output order" twice - change to decode or
display whichever is correct.

6.  In  4.1.2  base RTP session the last sentence says that it can carry
NAL unit types equal to 14 and 15, are these the only ones ?

7.  In 4.1.2 in CS-DON you have session-multiplex, the term should be
changed to MST

8.  In section 4.1.2 H.264/AVC compatible "biststream" to "bitstream"

9.  In 4.1.2 layer: A bistream to bitstream

10.Section 5.3  Second paragraph RFC2984 should be RFC3984 also PACSI
and NI-MTPA - abbreviation need to be defined before usage.

11.Table 1 type 31 is NI-MTAP

12.Section 5.3 the specification of F: bit is different from RFC 3984

13.Section 5.3 NRI definition - in RFC 3984 there is also transport
priority

14.In section 5.3 the language describing DID, QID and TID is different
even though have similar meaning, why not use the same.

15.In section  5.3 last paragraph "This specification extends the
semantics of F, NRI, I, PRID, DID, QID, TID, U, and D per [H.264] as
described in Section 6.4." I could not find these parameters in H.264 so
the mapping should be specified. Maybe just say in the definition of
each term that the name like use_ref_base_pic_flag for U is the H.264
name.

16.In table 6 type  31 is NI-MTAP

17.In 6.8 6th paragraph has 5.3 twice

18.In 6.8  "The A bit MUST be set to 1 if all the target NAL units
belong to anchor layer representations.  Otherwise, the A bit MUST be
set to 0.  The A bit SHOULD be identical for all the PACSI NAL units for
which the target NAL units belong to the same access unit." I had
problem understanding the last sentence

19.In 6.8 in the informative note after the previous paragraph you use
IBBP without specifying what it is.

20.In general in 6.8 the way to give values to the fields should be
specified, for example for the A bit it has some text in the informative
note but I assume that is normative text.

21.In 6.8 in the C bit description the last section is not clear.

22.In 6.8 you mention in a couple of places that the SEI messages may
not be present in the bitstream, why is that? And if they are not there
how do you put them in the PACSI, the PACSI is specified in the RTP
payload and the SEI are part of the encoded stream, if they are not in
the encoded stream how do you create them for the PACSI

23.In section 6.9 after reading it I am not clear how to map from figure
2 to figure 3, where is the hdr mentioned and also could not see the
distinction between the NI-MTAP fields and the encapsulated
information..

24.In section 6.10 second paragraph  "desribed" to "described"

Roni Even

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

---

From: Thomas Schierl <[email-masked]>
Date: Tue, 08 Jul 2008 14:27:14 +0200

Hi all,

While going through the SDP section of the SVC payload draft,
I found that it is hard for an endpoint to distinguish which would be 
the right media description (section between "m"-lines )and within the 
media description, what would be the right media format description 
(payload type number) to choose. Having the flexibility of SVC in mind, 
a scalable media stream may contain multiple operation points at 
different levels of frame rate, resolution, and/or visual quality. With 
the available parameters it is hard to describe, e.g., which maximum and 
minimum values of e.g. frame rate, bit rate and resolution are 
associated with the operation points of a particular SDP media format 
description in an SDP media description. Standard SDP parameters 
describing bit rate and frame rate are not sufficient and are only 
applicable to the whole media description. Instead of that, the 
additionally defined sprop-spatial-resolution parameter is applicable to 
the media format description within the media description. It would be 
desirable to have also parameters about bit rate and frame rate on the 
media format description (payload type number) level.

It would be really helpful for an endpoint to know about the values of 
parameters like bit rate, frame rate, and resolution of the highest and 
the lowest operation point.

I suggest:
to define
sprop-spatial-resolution-min-op
sprop-spatial-resolution-max-op
sprop-avg-framerate-min-op
sprop-avg-framerate-max-op
sprop-max-framerate-min-op
sprop-max-framerate-max-op
sprop-avg-bitrate-min-op
sprop-avg-bitrate-max-op
sprop-max-bitrate-min-op
sprop-max-bitrate-max-op
and
remove sprop-spatial-resolution.

For the above parameters, the "-min-op" and "-max-op" values of spatial 
resolution, average frame rate, maximum frame rate, average bit rate, 
and maximum bit rate represent the values of the lowest and the highest 
operation point of a media format description.
The values for the above parameters shall be the same as they would be 
indicated by the H.264 scalability SEI message.

In combination with the SVC parameter sprop-layer-range, the end point
would be able to create a sufficient picture of the operation points
associated with a media description and a payload type number.

Best regards,
Thomas

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 8 Jul 2008 15:32:59 +0300

Thomas,
My general observation here is that one of the design goals of H.264 was
not to go to the H.263 capability sets and multiple parameters. 

I assume that all these parameters are descriptive, not for negotiation
but the relation to the level parameter and the tables in annex A of
H.264 should be mentioned. 
Roni
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Schierl
> Sent: Tuesday, July 08, 2008 3:27 PM
> To: [email-masked]
> Cc: Stephan Wenger
> Subject: [AVT] media format description in draft-ietf-avt-rtp-svc-
> 12.txt
> 
> Hi all,
>

---

From: Thomas Schierl <[email-masked]>
Date: Tue, 08 Jul 2008 14:49:51 +0200

Roni,
You are right, the intended purpose of the parameters is description 
only. For negotiation sprop-parameter-sets, sprop-layer-range, 
scalability-information and scalable-layer-id are currently defined.
The problem is, that just the parameter-sets do not give any distinct 
information about the stream characteristics.

Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI