Re: [AVT] MPEG2TS preamble - where next

["Ali C. Begen (abegen)" <[e-mail]>]

I expressed this before several times. When the existing deployments will be upgraded with the RAMS code (which will be once the spec is frozen and becomes an RFC), the extra code we need for post processing will be put on the client as well. So, I do not understand why you are making a big deal out of this. You will have to upgrade your boxes' software, too, if you wanna run the RAMS as specified in the final spec.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Peilin YANG
> Sent: Thursday, July 29, 2010 10:36 PM
> To: Sandy (Alexander) MacInnis
> Cc: [e-mail]
> Subject: Re: [AVT] MPEG2TS preamble - where next
> 
> 
> Dear Sandy,
> 
> I am not an expert of codec chip, so I cannot carefully evaluate your comments. But I am completly sure that our current
> deployment is no problem for that.
> Perhaps from the viewpoint STB, i am not sure, TOLV is slightly simple.
> But I think you ignore somewhere, from the viewpoint of operation, if some unknown and unknowable PSI and codec
> information emerge, Begen's solution needs to upgrade STB's software code. Our solution doesn't. For example, in our
> implemention, we found in few video stream, occasionally, the first packet of I frame doesn't include PES header. Though this
> seldom happens, but at this time, PES Header is also a kind of MPEG2-TS preamble informat
> ion. I mean this is only an example. through this use case, our solution only needs to upgrade RS software code, we don't
> need to upgrade STB software code. But Begen's solution needs to upgrade both RS and STB software code. If it is necessary
> to upgrade software code of uncountable STBs, I think operators don't want to see it. IMHO, this is the advantage of our
> solution.
> 
> Best regards,
> 
> Peilin
> 
> 
> ----- 原邮件 -----
> 发件人: "Sandy (Alexander) MacInnis" <[e-mail]>
> 日期: 星期五, 七月 30日, 2010 上午3:35
> 主题: Re: [AVT] MPEG2TS preamble - where next
> 收件人: "[e-mail]" <[e-mail]>
> 
> > I want to try to help to break this deadlock. So let me point out
> > a few things. What I have to say here is purely technical. I am
> > not taking sides with or against any company here, and I am
> > intentionally ignoring any potential politics. I just want to get
> > this done right, so we can all benefit from the result.
> >
> > 1. We really want one solution, not two. If there are two,
> > presumably we and all companies involved would end up having to
> > support both solutions, each in a wide variety of usage scenarios,
> > even if the final spec says the RR can select between two. That
> > is, can we really trust that all servers will do a perfect job of
> > implementing both specs? Seems doubtful, and it seems that it
> > would not be beneficial to any server vendors. It would be best to
> > have one solid spec, soon.
> >
> > 2. Whatever solution we choose, it should be completely robust in
> > all relevant usage scenarios. It's hard to foresee exactly what
> > all of them are. In addition to all of the external specs that
> > have been discussed recently, it's a good assumption that not all
> > MPEG-TS sources exactly follow the rules they claim to follow. So
> > there are all sorts of potential issues with ordering and timing
> > of MPEG-TS packets in the streams the RS is processing, and these
> > issues will affect the receiver's operation, causing problems if
> > the receiver is not adaptable to the variations.
> >
> > 3. My understanding from the email thread is that the main
> > advantage claimed for the MPEG-TS preamble approach is that post-
> > processing in the receiver is not necessary. While that may be
> > true in certain limited cases, as far as I have been able to
> > determine, this is not true in general. Rather, preamble-specific
> > processing in the receiver is required in the general case if we
> > are to obtain the benefit of accelerated acquisition, rather than
> > making it worse.
> >
> > 4. For a general receiver solution, the receiver needs to parse
> > and process all the relevant fields, in the order and with the
> > timing required by the receiver. The time required may depend on
> > the data itself, especially where security keys are concerned.
> > It's easy to get the order and timing right if the receiver parses
> > and processes the fields in software. It's very difficult to do if
> > the receiver pretends the preamble is just a normal part of a
> > normal transport stream. Preventing the need for any preamble-
> > specific software processing in the receiver would require the RS
> > to predict exactly what the receiver needs, in terms of timing,
> > etc., and that would appear to be extremely difficult to specify
> > for the general case, as well as being difficult to implement. The
> > bottom line is that in practical, general, robust solutions, the
> > receiver needs to have software that understands the preamble spec
> > and that gets directly involved in processing the preamble, and
> > this is true regard
> > less of whether the preamble comes via TLV (TOLV) or MPEG-TS
> > packets. It's not hard to create the required software. I predict
> > that companies will do this once there is a solid spec. This could
> > be done by chip vendors, or box vendors, either one is possible.
> >
> > 5. I don't have much to say about the RS. If it were the case that
> > the server only had to copy and re-send TS packets, then that
> > would appear to be a little simpler than extracting the relevant
> > fields and putting them in TLVs, but if the server has to do
> > anything to ensure the receiver can process the preamble, and
> > benefit from it, without any preamble-specific processing in the
> > receiver, then the server probably would have a lot more work to
> > do (again, ordering and timing). TLV appears to be a robust
> > approach that does not require significantly more processing than
> > copying TS packets, and the working assumption in the TLV-based
> > draft is that the receiver handles the specifics of ordering and
> > timing of the fields, ensuring the server does not have to be
> > concerned with it.
> >
> > 6. Receiver software could be designed to handle either TLV or
> > MPEG-TS preambles. The TLV version is simpler to implement, since
> > the fields are directly accessible by software.
> >
> > 7. So, from the receiver's point of view, the TLV version is
> > preferred, while either could be made to work.
> >
> > 8. Bill Ver Steeg's description of the issue, in an email a few
> > hours ago, and in other emails over the last few months, appears
> > to be completely correct. Rather than re-stating the description,
> > I would refer members to his note.
> >
> > --Sandy
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of
> > > DRAGE, Keith (Keith)
> > > Sent: Thursday, July 29, 2010 8:39 PM
> > > To: [e-mail]
> > > Subject: [AVT] MPEG2TS preamble - where next
> > >
> > > (As WG chair)
> > >
> > > As far as I can see, we are still in a position where we would
> > not gain
> > > concensus for documenting two solutions, whether that was in a
> > single> RFC or two alternate RFCs. There does seem to be support
> > in the WG that
> > > work should continue.
> >
> > [Sandy] ...snip...
> >
> > > Outside of the two author groups, I am looking for members of the
> > > working group to tell me what their positions are (mails
> > welcome), and
> > > I may seek some indication of that in the AVT session tomorrow (but
> > > there will not be time for discussion as it is an otherwise crowded
> > > agenda). Remember the final decision (and responsibility) is the
> > > working groups, i.e. YOU; the result is not determined by a
> > fight to
> > > the death by the two author groups. Therefore you should be
> > making your
> > > own technical decision and informing the working group of your
> > opinion.>
> > > regards
> > >
> > > Keith
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> >
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt