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

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

Hello Ali

Thank for you quick response, please check again.

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: Thursday, October 22, 2009 2:27 PM
Subject: RE: new draft on MPEG-TS preamble acquisition


Hi Frank, inline.


-----Original Message-----
From: Frank Xia [mailto:xiayangsong at huawei.com]
Sent: Thursday, October 22, 2009 3:03 PM
To: Ali C. Begen (abegen); avt at ietf.org
Subject: Re: new draft on MPEG-TS preamble acquisition

Hello Ali

Thank for your insightful comments.

Besides my inline response,  I would also like to
point out the methodology difference between
your document and our draft.

Your way is:
   1) RR identifies, extracts preamble information


Not RR but RS.
Frank=>My typo


   2) RR generates  summary packets


Again it is RS that generates the packets.
Frank=>My typo


   3) RS  transforms the summary packets into
      demux/decoder friendly stream in order to
      feed demux/decoder.


This should be RR.
Frank=>My typo too.



Our proposal skips step 2 and simlifies step 3.  That is,
let RR directly generates demux/decoder stream.


Yes, you skip the 2nd step but at a large cost IMO.
Frank=>Probably, I am just so focusing on our advantages
that I dont see the large cost yet.


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: Wednesday, October 21, 2009 1:25 PM
Subject: RE: new draft on MPEG-TS preamble acquisition


Frank,

I read the draft. It is good to know more people agree that this is a real
problem. However, I have several comments and questions. I'd like to
understand why you think this is a better solution than our existing
draft.
Frank=>Accuratly saying, I think we have some advantages
 from some perspectives.

- 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.
Preamble can also be regarded as a part of unicast RTP burst session.


- 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.
Setting the flag is also another alternative.


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?


- Using a TLV also identifies each preamble element explicitly. This
makes
it easier for the RR to selectively use portions of the preamble for
different tasks, e.g., priming system clock with PCR value. How do you
deal
with that?
Frank=>You mean how to deal with PCR or some thing else?
As for PCR issue for unicast RTP burst,
we do have a solution
http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00.txt.


The above draft does not address my question. And PCR was just an example.
Different TLVs are often needed for different things to speed up the
acquisition.
Frank=>Could you make it more specific?


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


- Section 4 says:

"Some other preamble information included in different TSes is also
identified and stored in the retransmission server."

This sounds pretty vague. Please explain.
Frank=>I meant NIT, CAT.

No details on the contents of the RTP PSI packets. Is only 1 PAT and 1 PMT
per program included? What order are they found in? Any repetition?  How
is
Conditional Access data included? What about constructs required by the
video codec (MPEG-2 sequence header, H.264 SPS/PPS/SEI)?
Frank=>I will elaborate them.  However, this is not the point of the
draft.
Our point is draft-ietf-avt-rapid-acquisition-for-rtp-03 can be directly
used for  preamble acquistion with limited extension.


I am not sure what you mean here. Of course, RAMS takes care most of the
stuff. Here we are addressing the specific reqs for the MPEG2TS content. If
we will only provide marginal benefit, I don't see much point in doing this
(we would just use RAMS). If we are here to do something, I think we should
decide on the best approach.
Frank=>We are talking about format of unicast RTP  burst which is 4588
compliant. I just want to justify our usage of 4588


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.


Also check 4588 about the use of timestamps. The way you set the timestamp
is not the way 4588 mandates.
Frank=>Let me think about it.

This is a short draft, but brings forward a lot of questions/issues with
it.
Frank=>Thank your comments. Our solution is  simple too :-)

-acbegen


-acbegen