Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00

From: Bo Burman <[email-masked]>
Date: Tue, 11 Feb 2014 16:41:01 +0000

Hi Alex,

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Alex Eleftheriadis
> Sent: den 30 januari 2014 20:54
> To: [email-masked]
> Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00
> 
[snip]
> I did a quick read-through. Comments below; hope they are useful.
[BoB] Thank you, yes they were indeed useful!

> 
> ---
> 
> 2.1 Media Chain
> 
> I would take the first sentence of 2.1, Media Chain, and use it to define media: "a sequence of physical world stimulus
> represented in digital form"
[BoB] Agree. What about starting 2.1 with:
In the context of this memo, Media is a sequence of synthetic or Physical Stimulus (sound waves, photons, key-strokes), represented in digital form. Synthesized Media is typically generated directly in the digital domain.
This section contains the concepts that can be involved in taking Media at a sender side...

> It is not evident from the text, but it should be recognized that it is possible to have a a Media Source without a Physical
> Stimulus and associated Media Capture.  Computer-generated content would fall under this category.
[BoB] Agree. I added explicit mentioning of "synthetic" in the definition of Media above. I also suggest adding something like "A Raw Stream can also contain synthesized Media that may not require any explicit Media Capture, since it is already in an appropriate digital form" at the end of Raw Stream section, which I hope should take care of your comment. Do you believe it is important to explicitly mention "computer-generated", since there are other media-generating devices than "computers"?

> 2.1.1 Physical Stimulus
> 
> The definition does not need to use the receiver. Also, the word "capture" is ambiguous. You probably mean measured
> using an appropriate sensor/transducer and converted in digital form.
[BoB] Again, agree. I'll remove any mentioning of a receiver and replace "capture" with your proposed text.

> 2.1.2 Media Capture
> 
> Should not use "captured" in the definition itself (circular definition). I would use: "The process of transforming the
> Physical Stimulus into digital form using an appropriate sensor/transducer."
[BoB] Good proposal.

> 2.1.6 Media Encoder
> 
> In addition to hierarchical encoding, such as the one used in H.264 SVC, it is also possible to have what is called multiple
> description coding. In this case you have two independently encoded streams, each one complementing the other. One
> simple example would be taken the even and odd samples of an audio stream, and forming two independently encoded
> audio streams (each at half the sampling rate). If you receive either you can decode; if you receive both you can decode
> at full quality.
> 
> The section should also mention that for completeness. I am not aware of any commercially available encoder that uses
> MDC today.
[BoB] OK. I believe it could increase understanding of the concepts we try to describe.
What about adding:
" There are also other variants of encoders, like so-called Multiple Description Coding (MDC). Such Media Encoder produce multiple independent and thus individually decodable Encoded Streams that are possible to combine into a Received Source Stream that is somehow a better representation of the original Source Stream than using only a single Encoded Stream"?

> 2.1.9 Media Packetizer
> 
> The terms SST and MST were defined as Single Session Transmission and Multi-Session Transmission, respectively, in RFC
> 6190. I understand the arguments for switching session with stream, but I think re-defining them now only creates
> confusion (plus the new terms do not appear to be drop-in replacements for RFC 6190 anyway, since Multi-Session in
> Single-Stream was not anticipated in RFC 6190).
[BoB] We already have a separate section describing SST (3.2.1). What about keeping the Media Packetizer text simple, mentioning SST just as an example without describing it further and cross-referencing the section 3 text? I think we should then do the same for MST, which would require adding another short section in section 3 for that. In the SST and MST sections, their specific assumptions on use of RTP Sessions could be described and that complicating aspect could then be kept out of the text in Media Packetizer section. The 6190 "omission" of MST in a single RTP Session could then also be mentioned in section 3, maybe in one of the SST or MST sections.

> 2.1.20 Media Decoder
> 
> The way the system is presented, with 2.1.18 Media Depacketizer as an independent component, you do not foresee
> that the media decoder may perform concealment. There may be much tighter coupling between the components that
> suggested here (ILP concepts etc.).
[BoB] I believe this is already partly covered by the disclaimer early on in 2.1 "The below examples are basic ones and it is important to keep in mind that this conceptual model enables more complex usages", but it may be worth pointing that out again.
What about adding
"It should be noted that in practical implementations, the Media Decoder and the Media Depacketizer may be tightly coupled and share information to improve or optimize the overall decoding process in various ways. It is however not expected that there would be any benefit in defining a taxonomy for those detailed (and likely very implementation-dependent) steps"?
It would even be possible to add this text to both Media Depacketizer and Media Decoder sections.

> 4. Topologies and Communication Entities
> 
> I think here you should cite the new topologies update (http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-
> update-01), and mention that there are topologies that are not included in this brief summary. Otherwise it appears that
> the section tries to be exhaustive - and it clearly is not.
[BoB] Agree.

---

From: Alex Eleftheriadis <[email-masked]>
Date: Tue, 11 Feb 2014 18:07:32 +0000

Thanks Bo. All suggested changes are gerat. 

One possible solution for the SST/MST redefinition issue is to use the terms: single-port transmission and single-SSRC transmission, as well as the corresponding multi- variants. Acronyms: Sp / Ss - Mp / Ms. 

SST per RFC 6190 is single-port, single SSRC.

MST per RFC 6190 is multi-port, multi-SSRC.

What is being referred to as Single Stream Transmission here, is single-port covering both single-SSRC and multi-SSRC cases.

--Alex

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Feb 2014 08:45:01 +0100

On 2014-02-11 19:07, Alex Eleftheriadis wrote:
> One possible solution for the SST/MST redefinition issue is to use
> the terms: single-port transmission and single-SSRC transmission, as
> well as the corresponding multi- variants. Acronyms: Sp / Ss - Mp /
> Ms.
> 

I would protest the single port term here. Tough it is common to
determine what a single RTP session is by using a single listener port,
that is not always the truth. One can have a single RTP session using
multiple transport flows both incoming and outgoing from an endpoint.
Thus, please reference this as single RTP session.

> 
> What is being referred to as Single Stream Transmission here, is
> single-port covering both single-SSRC and multi-SSRC cases.
> 

In the context of RFC 6190 I don't think this is clear. Let me quote
form page 5 of RFC 6190:

   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions.  In
   SST, packetization is a straightforward extension of [RFC6184].

Using multi-SSRC for one SVC encoding in a single RTP session is not a
straightforward extension of RFC6184. This multi-SSRC usage has more to
do with MST mode than the SST mode for the SVC RTP payload format. Thus,
I think we are on the right track to define this as its own usage
requiring a special set of considerations. I would claim that the SVC
RTP payload format does not adequately define how to use the RTP payload
format in this mode. The reason is that it fails to make clear how you
would correctly associate the right set of SSRCs that are carrying the
encoded and dependent stream for a particular media source. Thus, for
endpoints that transmit multiple sources there exist a short coming in
this mode.

My suggestion would be to simple label this mode of operation with its
own label.

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]
----------------------------------------------------------------------