Subject: Re: [avtext] comments on draft-xia-avtext-splicing-for-rtp-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Apr 2011 13:57:06 +0200

Hi,

Sorry for the delay in answering. Please see discussion where there
still open issues/discussion.

Jinwei Xia skrev 2011-03-28 18:32:
> ----- Original Message ----- From: "Magnus Westerlund"
> <[email-masked]> To: <[email-masked]>; "Jinwei Xia"
> <[email-masked]> Sent: Monday, March 28, 2011 5:01 PM Subject:
> comments on draft-xia-avtext-splicing-for-rtp-00
> 
>> 
>> 2. I am also missing a discussion on the RTP timestamp handling
>> issues. That clearly also needs to be covered to ensure that the
>> receiver gets a consistent stream.
>> 
> 
> Very good question, the timestamp of main stream RTP packet is keep
> intact, the timestamp of substitutive RTP packet is calculated by
> Translator based on how many substitutive packets are outputted to
> user during specific time. I will add related description in next
> version.

Well, number of packets doesn't matter. It is the relative timestamp
difference that needs to be handled. Plus that correct steps between
last video frame and the first spliced needs to have a reasonable and
consistent step. This is easier for more continuous media like audio
where the next timestamp value can be used.

> 
>> 3. I also see a clear issue for a translator to deal with the RTCP 
>> translations towards the main source. My understanding is that the 
>> splicer will need to translate any RTCP Report blocks coming from
>> down stream to the splicer, even when the substitute content is
>> being forwarded by the splicer. I can see how this can be made to
>> work if there are no media adaptation happening. But if the media
>> streams are being adapted then this becomes problematic. This as
>> any feedback relates to the stream actually being sent. So the
>> translated RTCP needs to report to the main stream how the main
>> stream would fair down stream of the splicer, without actually
>> having sent it. I don't see how this can be done in a reasonable
>> and robust way.
>> 
>> For example if the substitute stream is higher bandwidth than the
>> main stream and that stream is being reported as causing
>> congestion. Then what does one report to the main stream sender?
>> Because one can't know if that stream would cause congestion. Can
>> someone please explain how to support this case.
> 
> When detecting the ECN notification message during splicing period,
> translator intercepts them, discards the feedback messages or remove
> XR parts in RR because it knows the congestion is caused by
> substitutive content rather than main content. how does the
> translator execute media adaptation is inner implementation.
> 
> Discarding ECN feedback message indeed is a additional requirement
> for translator. Can translator execute above approach? Is the
> approach reasonable and robust?

Per discussion in the other thread I think forwarding feedback to the
one that sourced the data is the right decision here. And the other
source if over RTP gets the feedback for the path to the splicer.

> 
>> REQ-2: The RTP packets whose payloads are replaced by substitutive 
>> content are required to keep their RTP header information to be 
>> consistent with those of main RTP packets whose payloads are 
>> unaltered.
>> 
>> I think "Keep" is the wrong word here. I think resulting in a
>> consistent stream.
> 
> how about:  " The current RTP stream received by user may contain
> main content or substitutive content, but user can not find which
> kind of content the RTP stream convey from current RTP header
> information."

I don't think that is a working requirement either. Because if you are
forced to switch payload type you break the above requirement. And that
has less to do with the solution, and more to do with what additional
requirements you can put on the encoding of the content.

> 
>> 
>> REQ-2:  "The value of SSRC field in RTP header MUST be same as the
>> value of corresponding field in main content RTP header, while the 
>> value of payload type field SHOULD be same as the value of 
>> corresponding field in main content RTP header.  Note that in some
>> cases, it may be necessary to transcode the substitutive content to
>> ensure the payload type is the same, and that this may be
>> prohibitively expensive, so it might be acceptable to leave the
>> payload untranscoded."
>> 
>> First, I think this isn't requirements, they are how one should 
>> implement it.  I also think, one could clarify that if one has
>> signalled the different RTP payload types then one can actually
>> switch between them. IF that is supported by client depends on the
>> usage.
>> 
> 
> OK, so how about to delete the content "Note that~~~~"? the deleted
> content will be remove to section 5 with the description about
> reaction of user on different codec.

Can we perhaps change the requirement from the RTP details to what the
real intention is here?

Is the intention that the switch over should be undetectable on the
encoding, or that things are consistent.

> 
>> 
>> REQ-4: Splicer MUST be backward compatible with basic
>> characteristics of [RFC3550], e.g., SSRC identifier collision
>> resolution and loop detection.
>> 
>> Shouldn't this also include certain RTP extensions also?
>> 
> 
> how about:   "Splicer MUST be backward compatible with RTP/RTCP
> protocols with its associated profiles, and extensions to those
> protocols"

Yes, and I in addition I think there is a point of trying to create a
list of what extensions that we see being used together with a splicer
so that we needs to discuss them?

> 
>> Section 6. "Even if no new substitutive content will be inserted, 
>> the Translator still needs to modify the main RTP packets, and to 
>> recalculate the UDP/IP checksum until the main RTP session ends.
>> If Translator serves multiple main RTP streams simultaneously, this
>> may lead to large overhead on the Translator."
>> 
>> I don't think this translation is any form of extreme case of
>> burden. Yes, you will need to update both some RTP header fields.
>> Well, you anyway would need to update the address fields and that
>> is part of the pseudo header anyway. So you can't do relaying
>> without paying this cost. And there are hardware off-loading for
>> UDP checksums.
> 
> OK, we just need to mention implentation consideration that
> translator needs to process the lower layers.
> 
> how about:  "When Translator is used to handle RTP splicing, RTP
> receiver does not need any RTP/RTCP extension for splicing.  As a
> trade-off, Translator must process RTP and lower layers compared to
> just forwarding the main RTP stream, since Translator must coordinate
> the switch between main content and substitutive content, and
> generate its own RTCP reports.  Even if no new substitutive content
> will be inserted, the Translator still needs to modify the main RTP
> packets, and to recalculate the UDP/IP checksum until the main RTP
> session ends."

Yes, but I think this will become obvious as you expand into more detail
on the handling of each field in RTP and RTCP.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------