[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] new draft on MPEG-TS preamble acquisition
Hello David
Welcome to the discussion.
I believe we covered many parts of your concerns
through previous discussion. However,
it is my pleasure for me to highlight my points.
BR
Frank
----- Original Message -----
From: "David R Oran" <oran at cisco.com>
To: "Frank Xia" <xiayangsong at huawei.com>
Cc: "Ali C. Begen (abegen)" <abegen at cisco.com>; <avt at ietf.org>
Sent: Friday, October 23, 2009 1:44 PM
Subject: Re: [AVT] new draft on MPEG-TS preamble acquisition
Couple of quick comments - sorry to be jumping into the middle.
On Oct 23, 2009, at 8:37 AM, Frank Xia wrote:
Hi Ali
Thanks for your patience.
Please also check the inline response.
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 10:18 PM
Subject: RE: new draft on MPEG-TS preamble acquisition
Snipping off the redundant text.
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.
Sure they were. It's just that the RR wasn't listening!
Frank=>Just because the RR is in different session.
If there was no transmission to a RR, how does
come to the retransmission to the RR?
For this specific RR, there packets are not RETRANSMITTED.
The notion of "for this specific RR" is not well-defined when you are
mixing unicast and multicast as we are in RAMS. For example, check the
DVB specifications, which use multicast retransmission as well as
unicast.
Frank=> see my above comments.
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
You're glossing over the key/hardest part, which is how manage the
switchover from unicast to multicast. If all we cared about was unicast,
we would not be bothering with any of this. You'd just use VoD.
Frank=>I could not follow your idea. However, our topic seems
only be related to unicast retransmission session. Lets stick to the theme.
By the way, RS is designed for a RR to request a specific
SN of RTP packet because the packet is presumably lost.
right, which is why RAMS is slightly different in the control plane from
retransmission. The beauty of the overall approach we're taking is that
the data plane, once the decoder is primed, can be identical from RAMS
and regular transmission.
Frank=>This exactly my point which is RAMS stretch 4588 a little bit.
Probably, we can stretch more if it is within reasonable scope.
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?
As I mentioned earlier, some portions of the Preamble data may be used
more than once. TLV gives us that flexibility.
Frank=>Flexibility and Complexity.
The minute you have to "reach into" the MPEGTS data stream and parse/
extract stuff, the rest is easy by comparison. As Ali has said, the
advantage of TLV is that you don't have to mess with extracting taking a
subset of a TS, re-constructing a legal mux (including CC and the rest)
and sending as if it were RFC2550-compliant. I'd like to understand why
you think TLVs are more complex than all that stuff.
Frank=>Just I metioned, we skip summarization and post-possessing parts.
RR can do less work.
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.
Without arguing about whether moving the processing from the RR to the RS
is a good tradeoff, I would like to caution you to make sure what you are
doing will work with the current (and legacy) crop of STB data-
plane/decoder implementations - without getting into details we have
evidence from real boxes that there are problems.
Frank=>Our proposal is to let RS to do more on behalf of RR.
That means less requirements for STB.
Cheers, DaveO.
-acbegen
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt