[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] new draft on MPEG-TS preamble acquisition

Hi Ali

Please check my reply...

BR
Frank
----- Original Message ----- From: "Ali C. Begen (abegen)" <abegen at cisco.com> 
To: "Frank Xia" <xiayangsong at huawei.com>; <avt at ietf.org>
Sent: Friday, October 23, 2009 11:00 AM
Subject: RE: new draft on MPEG-TS preamble acquisition



Snipping off the redundant text.

> > - First of all, is this an RTP payload format draft or not? The draft
> > seems
> > to be defining that, yet, title does not say so, and the draft does > > not 
> > have
> > the sections needed for defining a new payload format. See the
> > guidelines
> > document.
> > Frank=>This draft did not define a new payload format.
> > This is negotiatable if RFC4588 can't be used directly.
> > Some further  related response see below.
>
> You are carrying something in RTP, so one way or another, you are > defining 
> a
> new payload format. As I mentioned earlier, usage of 4588 does not seem > to 
> be correct here.
> Frank=>Good point. However, I  still believe it is make sense  to reuse
> 4588.
> draft-ietf-avt-rapid-acquisition-for-rtp uses 4588 for unicast RTP burst
> which are not RETRANSMISSION packets as to the RR.

I believe you are confused here. Burst packets are "retransmission"
packets - totally in accordance with RFC 4588. They are retransmissions of
earlier RTP packets sent in the primary multicast stream. And the receiver
considers them as retransmission packets.
Frank=>They are not retransmission packets.
In rapid acquistion (e.g fast channel change),
these packets are never sent to the RR before.
From RR's viewpoint, this does not matter (whether the packets were sent but they were lost or they were never sent - receiver cannot know the difference). The important thing here, the burst packets are the exact replicas of the original RTP packets encapsulated in 4588 format. But, the way you describe sending the raw TS packets does modify the source packets, which means 4588 should not be used.Hi 
Frank=>Copies of the original RTP packets are  not retransmission packets.
I just want to say that "rapid acquistion" document also stretches a little bit 
of  4588.
Using raw TS packets or whole RTF packet is not the point of our debate.
We prototyped both.  If you feel more comfortable with the latter, we can
do some minor change with the document.


For this specific RR, there packets are not RETRANSMITTED.
Here is a brief procedure of fast channel change to faciliate discussion.
1)A RR requests a new channel
2)A RS  sends bufferred packets related to the channel to the RR
3)The RR receives the packets

By the way,  RS is designed for a RR to request a specific
SN of RTP packet because the packet is presumably lost.


In NACKs yes. In RAMS-R, no.
Frank=> RAMS-R is defined in rapid acquistion document.
Just becuase of your newly defining RAMS-R, you change
the orginal meaning of RS.


> Preamble can also be regarded as a part of unicast RTP burst session.

They are part of the retransmission session, but as I said they are not
formatted according to 4588 because they are not retransmission of anything. 

> > - Not surprisingly, there are similarities with our draft on the
> > subject.
> > The motivation for your draft seems to be using the raw TS packets as
> > Preamble, rather than generating a "summary" packet consisting of TLV
> > elements. Do you need post processing on the packets you sent before
> > feeding
> > them to the demux? I suspect you do since you will be sending raw TS
> > packets
> > in an order that will likely upset the demux (i.e., CC discontinuity
> > will
> > likely to occur).
> > Frank=>We don't need post processing. I am not sure what issue you > > are 
> > specifically referring to.  However, CC continuity can be obtained .
>
> How? The raw TS packets you need will not necessarily be consecutive. If
> you
> will have to keep redundant TS packets to keep the continuity, it will > be 
> far less efficient. You can set the discontinuity flag but there are
> limits
> on it.
> Frank=>According to my understanding, it is only necessary to keep CC
> continuity
> for a given PID.   RS can easily chain the TSes with CC continuity.

I am not sure how you do this w/o getting RS to process the stream.
Frank=>All I want to say is RS can do this work on behalf of  RR.
RS has enough information and processing capability.
I thought the reason you used raw packets instead of summary packets was to simplify the server. At the end, post processing is not a big deal. 
Frank=>No, to simplify receivers, that is , RR.
The perfect goal is to let RR be agnostic to the extra effort.
However, nothing is perfect :-)



> Setting the flag is also another alternative.

In some cases, yes, in other cases, no.

> > From my perspective, we just move your post processing from RS to RR.
> >
> > Moreover, TLV encoding is way more efficient from a bandwidth
> > perspective.
> > Most of the space in TS packets goes to padding because of the fixed
> > 188-byte TS packet size anyway. So, to me TLV encoding is the way to > > go 
> > here.
> > Frank=>Honestly, I don't bandwidth is issue. Preamble is small size > > in 
> > volume
> > comparing to vedieo traffic.  Compressing preamble does not make
> > perceivable
> > difference.
>
> Preamble is small, correct. But the size of all TS packets making up the
> Preamble is not.
> Frank=>Just make a simple calculation. let's say preamble consists of 20
> TSes which
> has 20*188*8 bits.  Assume unicast RTP burst last 3 seconds with 2M
> bandwith
> which is 3*2M bits in total. Preamble occupies around 0.5% of total
> unicast.
> Am  I right?
If the burst is taking 3 seconds even with the preamble, something seems to 
be wrong here.
Frank=>Could you give me a right simple calculation?
I'd rather consider much shorter burst durations. But, this is rather a minor point. 


> > - In our experience, we have seen with several settops that some
> > manipulation of the preamble is either required or strongly > > beneficial. 
> > Consider repeating PATs/PMTs until the demux is initialized with them,
> > or
> > delaying sending the ECM into the decoder for some time. W/o post
> > processing
> > and TLV encoding, this is hard to do.
> > Frank=>The more specific is more understandable. Our solution works > > in 
> > our
> > experiment.
> > Could you give us more information?
>
> For example, you might feed the TS packets with the PAT/PMT/etc to the
> demux
> but once they are gone, they are gone. In certain cases, having that > info 
> readily available and using more than once may greatly help. In our
> post-processing, we can do it. But, if you don't have post-processing, I
> suspect you cannot do it or is at least more difficult.
> Frank=>Our solution does not exclude any possible optimization in RR.
> You can say your solution has such by-products.  However, these
> by-products
> are not the goal of the topic itself.
?? These "by-products" are possible because of the post processing we do at 
the receiver. And it is certainly within the scope of this problem.
Frank=>IMO, the scope is how the RR gets preamble.
"How to organize received preamble in RR for further processing"
is not within the scope.
I beg to differ. I already gave a few examples. We can discuss this further in the meeting. 
Frank=>Yes, I read your examples.  However,  I am inclined to
making the draft more focused on our goal, not a panacea.



If you believe it is in the scope, please define them  for further
discussion.
For me, the benefit of these by-products seems to be vague.

[snip]
> > Any way,  identifying and analyzing preamble  is common processing
> > for your and our solution.
> >
> > - Why do you use 4588 format for the Preamble packets? They are not
> > retransmissions of earlier unmodified RTP packets, are they? Section > > 4.2 
> > says PSI RTP packets are newly generated. Thus they cannot be
> > retransmissions of previous packets. How do you set the OSN fields?
> > Frank=>We do treat Preamble packets as unicast burst.  In fact,
> > draft-ietf-avt-rapid-acquisition-for-rtp-03 is using RETRANSMISSION
> > server
> > for
> > rapid acquisition.
>
> The preamble packets are sent in the same retransmission session with > the 
> burst packets. But, that does not mean that they are 4588-formatted
> packets.
> Actually they cannot be since they are not the retransmissions of other
> RTP
> packets. In a typical RTP packet, there are 7 TS packets. I cannot get a
> few
> of those TS packets and send them as retransmission packets since the
> resulting RTP packet is a different packet now.
> Frank=>On the contrary, I believe we can get a few of those TS packets
> and send them to the new joining RR. This is a part of rapid > acquistion 
> processing.    The new joining RR can't tell any difference.
>
> Either you are misusing 4588 or sending every whole RTP packet that
> carries
> a TS packet needed for your preamble (which might be OK from 4588
> viewpoint
> but as I said will be pretty inefficient). Or, I am totally missing how
> you
> are doing it.
> Frank=>Your understanding is accurate.  We implemented both and
> selectively
> proposed the former because we believe the two are similar.  As for
> efficiency,
> I gave you a brief calculation, and you can check.
If you are doing the former (i.e., sending only the necessary TS packets in 
4588 format after ripping off the redundant ones), it is misusing the RFC
4588 because you are modifying the source packets. I don't know why you do
it or need it.
If you were doing the latter, the calculation given above would be incorrect 
anyway (you need to take the whole RTP packet sizes into account).

The bottom line is one way or another the Retransmission Server needs to
continuously parse and extract the required "Preamble" data in the incoming primary multicast stream(s). Once it does that, putting the Preamble in the 
format we defined by using the TLV elements is not a big deal (not more
difficult than keeping the raw TS packets and trying to put them in the
right order). But, doing that provides a lot of benefits.
Frank=>I never question the advantages of your solution.  Our
motivation is just to keep RR simple. In fact, there are no big difference 
between yours and ours.  All what we do is offloading some processing from
RR to RS.
Post-processing is not a heavy-weight operation. But, of course, that depends on the implementation. 
Frank=>Probably, we can make the simple simpler.

-acbegen


-acbegen