[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Observations on MPEG2-TS preamble drafts
Hi Eric
Thank your comments.
Theoretically, both solutions works. All the information
received by RR is from RS. RS has enough information
(according to my understanding, you are questioning RR's
processing capability, e.g. CPU, memory).
However, from engineering perspective, there are some differences.
Your solution is RR-oriented and needs post-processing, while
ours is RS-oriented and needs some pre-processing.
Please also see my other inline response.
BR
Frank
----- Original Message -----
From: "Eric Friedrich" <efriedri at cisco.com>
To: "Frank Xia" <xiayangsong at huawei.com>
Cc: "Roni Even" <Even.roni at huawei.com>; <avt at ietf.org>
Sent: Monday, October 26, 2009 8:36 AM
Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts
Frank-
I appreciate the simplicity in your design to avoid post-processing of
the preamble. Unfortunately, different RR implementations require
different preamble structures. This is one reason Ali & I have concisely
specified the contents of the TLOVs- to show what may differ from one RR
to another. I would like to see a similar specification as to preamble
contents in your proposal as well.
Frank=>This is also one reason we try to screen the diversity of RR
implementations.
No matter what a RR is implemented, this RR should be able to processing
ISO13818-1 compliant TS. OK,We will elaborate our draft, but you already
got the main idea.
That said, I don't believe your proposal restricts you from customizing a
preamble to a certain type of RR, it just requires some additional work.
In our draft, the RR-specific code runs as part of the TLOV
post-processing. Since the main advantage behind your draft is no
post-processing, the RS would have to customize the preamble to each
specific RR. Customizing the preamble on the RS introduces the need for
the RS to know exactly what the RR expects in the preamble. This is not
impossible, but does introduce more complexity into your proposal.
Frank=>You are right. Our solution is never intented to preclude any
RR-specific post-processing. RR can do any optimization based on standard
TS. There is no any information loss for our solution.
However, I am not favoring to do any un-certain prediction.
I don't believe that preamble acquisition can or should be agnostic to
RR. The wide range of RR's (both legacy and future) requires that any
solution be flexible enough to serve the differing needs of each.
Frank=>For me, the preamble acquistion should be agnostic to RR
IF there is no obvious engineering obstacle. You don't know exactly
the needs of wide range of RR, why you assert your solution is better than
ours? :-).
I don't buy that your solution takes advantages just because
your solution has more "by-products".
Let's define the scope of this problem and focus on the core.
Thanks,
Eric
On Oct 25, 2009, at 9:47 PM, Frank Xia wrote:
Hi Roni
Thank for your review, and your summary is accurate.
We do recognize Avi's draft flexibility, at the same time,
I believe our draft also has some advantages which are
to try to avoid post-processing and to make preamble
acquistion be agnostic to RR.
BR
Frank
----- Original Message -----
From: Roni Even
To: avt at ietf.org
Sent: Sunday, October 25, 2009 4:51 PM
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 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.
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.
Frank=>
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 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 looks like
the RR will see an MPEG2 TS stream and will not need to support the TLOV
payload format.
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
Roni Even as an individual
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt