[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Observations on MPEG2-TS preamble drafts
Hi Ali
See my inline comments.
Cheers
Frank
----- Original Message -----
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
To: "Roni Even" <Even.roni at huawei.com>; <avt at ietf.org>
Sent: Sunday, October 25, 2009 7:22 PM
Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts
Roni,
Your summary is pretty accurate except a few points I point out below.
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Roni Even
Sent: Sunday, October 25, 2009 5:51 PM
To: avt at ietf.org
Subject: [AVT] Observations on MPEG2-TS preamble drafts
Hi,
I read both drafts and I would like to present my view as an individual
trying to clarify
what I understand from both drafts and give my view on some of the issues
raised on the
mailing list.
I would like to start with an observation that RAMS is not a
retransmission solution as
specified in RFC 4588 "RTP retransmission is an effective packet loss
recovery technique
for real-time applications with relaxed delay bounds.". There is no
packet loss in this
This is open to interpretation. I view RAMS as the receiver has lost
everything so far (or for a long time) and subsequently lost its
"synchronization (or whatever we wanna call it)" with the primary mcast
stream and thus is asking the retransmission server to send whatever that
is necessary to put him back on track. This is what we said in our slides
since day one.
But, this is not that relevant to the current discussion.
case. It is using the same mechanism to convey information that will look
to the RR as a
retransmission stream using the RTP packet structure defined in section 4
of RFC 4588 and
the SDP description from RFC 4588. Yet the RR did not know that it was
missing any RTP
packet with specific sequence numbers since he was not expecting them in
the unicast
stream until they arrived and the OSN value is not that meaningful to it.
OSN is meaningful when it joins the mcast session. Now, it can put the
packets in the right order and the only relation between the
retransmission (burst) packets and the multicast source packets is the OSN
field.
Frank=>The RR has never meant to to receive the burst packet before.
IMHO, there is no such relationship in rapid acquistion (fast channel
change) case.
Now when talking about the preamble / PSI or information that the RR
needs which may have
been transmitted many packets ago I see in the two drafts two directions
to convey the
information
1. Specified in the Begen draft is to convey the information using
a new payload
format that will include the needed information as a set of TLOV elements
payload.
2. Specified in Xia draft that conveys the information looking like
a regular MPEG2
TS retransmission packet but since it is generated by the RS it may get
an OSN that is
before the OSN of the first RAMS unicast stream.
In both drafts, the preamble packets are created by the server. We differ
in what we put in the packets. In Frank's draft, I am still missing how
one can set the OSN field. I also asked Frank to demonstrate how he
generated the preamble packets.
I will give a "very" simple example here. Suppose each RTP packet is
carrying 7 TS packets and the server is receiving all the RTP packets sent
in the multicast session (numbers below denote the RTP seqnums).
... RTP_(N+2) RTP_(N+1) RTP_(N) RTP_(N-1) ...
Assume that the current preamble (recall that preamble data varies over
time) data is a combination of the information carried in the second TS
packet in RTP_(N-1) and the third TS packet in RTP_(N+1).
In our approach, we extract this information and create the necessary TLOV
elements, generate a new RTP packet and send it to the RTP receiver
requesting RAMS for this multicast stream.
Now, what does Frank's draft do here? I see two possible answers:
i) Extract those two TS packets and put them in a new RTP packet and send
it. If this is the case, what payload format is used? Is it 4588? If so,
how is the OSN field set? If not, which format is used?
ii) Retransmit the two RTP packets (i.e., N-1 and N+1) intact. In this
case, 4588 can be used similar to RAMS. But, this introduces new problems.
Frank=>Sorry for not making things clearer in our draft. Let me have
another shot.
1)RS identifies necessary TSes
2)RS creates new RTP packets in the format of 4588.
a) Let's say there are two RTP packets to convey preamble,
b) and given the SN of the first unicast burst RTP is N.
c) The OSNs of the two preamble RTP packets are N-2, N-1 respectively.
First, in this example the amount of info we needed was equal to or
(likely) smaller than 2 TS packets, but we transmitted two full RTP
packets. This is not only inefficient but also increases the chances of
loss for the preamble data. Our approach squeezes all the preamble data
out of several TS packets and often generates a single RTP packet. If that
packet makes it, we are done. However, if the other approach will be
transmitting k RTP packets (because k different RTP packets carried
partial preamble data), the failure probability will go from p to k*p.
This is no good.
Frank=>I tried to give you a calculation, and you can calcuate again.
The size preamble information is small. If you talk about the failure
probability,
you should also take into account of unicast burst.
In a word, either efficiency or failure probablity is not a issue just
because
the traffic volume of preamble information is small comparing to
unicast burst.
If (i) is used instead of (ii), due to padding and other redundant info in
TS packets, it is still likely that the server will generate more RTP
packets than the TLOV-based approach. So, failure chances will almost
always be higher.
Frank=>see my above comments
I cannot say which one is better. My personal analysis is that in both
cases the RS will
need to cache this information and will need to create the right packet
structure which is
the TLOV in the first case and an MPEG2 TS PSI packet in the second case.
The RR will need
Yes, the server needs to do some processing one way or another. Generating
the TLOV elements is not a concern at the server since the server is
already dealing with lots of TLV elements in RAMS transactions anyway.
More importantly, the number of TLOV elements that the server needs to
create is proportional to the number of MPEG2-TS streams in the system.
OTOH, the number of TLV elements the server needs to create for RAMS is
proportional to the number of RAMS requests, which is proportional to both
the number of receivers and the number of MPEG2-TS streams in the system.
If you consider that number of receivers is in the order of tens of
thousands per server in a typical system whereas the number of streams is
in the order of hundreds, it is quite clear that TLOV encoding of the
preamble data is not a concern for the server.
Frank=>TLOV is feaible, however, RR agnostic method is probably simpler.
to support this payload format in the first case while I assume that in
the second case it
will look like a regular MPEG2 TS stream.
Other points that I see is that in the first case the packet may be
smaller in size and
the extensibility can allow the RS to provide additional information that
was not part of
the original stream (I am not sure if that was the meaning here). In the
second case it
Yes, in addition it also gives us the flexibility of using the preamble
data in the best way for the specific decoder. Not every MPEG2-TS stream
produced by even standard-compliant encoders will be RAMS-friendly. Often
the preamble data will dispersed over a large time frame, across multiple
packets with different repetition intervals. And even the
standard-compliant decoders will be showing a different behavior based on
how the preamble data is placed in the stream. So, to produce the best
results, different decoders will often need the preamble data in slightly
different ways. The server cannot know that and should not bother with it.
Frank=>Extracting preamble information is a common step between your
solution and ours.
The server is trying to do some basic work which works with all RR, and
IMHO preamble
acquisition is one of these work.
Our post processing at the client enables us to address the specific
requirements of each decoder. We do the heavy lifting at the server, but
also need some receiver-side processing to get the best result.
looks like the RR will see an MPEG2 TS stream and will not need to
support the TLOV
payload format.
Frank's draft attempts to simplify the receiver-side implementation by
avoiding the "post processing" stage that our draft needs. Any receiver
implementing RAMS must already support TLV encoding/decoding and I don't
see how avoiding the post processing of TLOV elements (which is really not
different at all than TLV elements) will simplify the receiver
implementation.
Frank=>You assume all RR MUST implement RAMS. What if there is some other
alternative?
e.g Network-based Rapid Acquisition of Multicast RTP Sessions in
http://tools.ietf.org/id/draft-xia-avt-proxy-rapid-acquisition-00.txt.
Our solution works in both scenarios.
I do not have any view about what is the right way and I was only trying
to see if I
understand both proposals.
Thanks for the summary. I hope I've made some points clearer.
Cheers, acbegen.
Thanks
Roni Even as an individual
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt