Re: [AVT] MPEG2-TS preamble - client customization

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

I truly believe that the first thing we should try to get an agreement
on whether a set of decoder-agnostic TS packets sent by the server
serves our purpose or not. Our purpose at least in our draft is to get
the best out of the preamble, which means faster decoding and shorter
zapping times compared to the scenarios where preamble is not used or
not optimized.

If anybody has a different goal or thinks our goal (as stated above) is
not the right goal, it would be a good idea to clarify it as well. Until
we get a consensus on this issue, discussing other items is pretty
pointless. 

Once we are done with this issue, we can then decide on the packaging of
the preamble (TLV encoding vs raw TS packets).

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Roni Even
> Sent: Monday, March 22, 2010 2:31 PM
> To: Bill Ver Steeg (versteb); Dave Oran (oran); 'Peilin YANG'
> Cc: [e-mail]
> Subject: Re: [AVT] MPEG2-TS preamble - client customization
> 
> Bill,
> I think that part of the disconnect is that what you describe as
option 1 is
> interesting but this is not what the Xai draft suggest to do. I am not
sure
> where the claim that the xia draft does server side adaption is coming
from.
> I did not see it in the draft nor heard such claim from the authors of
the
> draft.
> 
> Regards
> Roni Even
> As Individual
> 
> > -----Original Message-----
> > From: Bill Ver Steeg (versteb) [mailto:[e-mail]]
> > Sent: Monday, March 22, 2010 7:49 PM
> > To: Roni Even; Dave Oran (oran); Peilin YANG
> > Cc: [e-mail]
> > Subject: RE: [AVT] MPEG2-TS preamble - client customization
> >
> > Roni-
> >
> > Sorry I was not clear. There is a body of best practices in use in
the
> > digital video world, which I did not elaborate very well.
> >
> > Care must be taken to minimize CPU load, and particularly to
minimize
> > bursts of CPU load when channel change events cluster around
> > commercials
> > and event boundaries. So, we need to consider client complexity and
> > server complexity in this analysis. We need to be with resource
> > utilization, particularly peak CPU load. During channel change, the
> > client device's CPU is typically at the edge of its performance
> > envelope. During top-of-the-hour correlated channel change, the
server
> > also tends to be at the edge of its performance envelope. We need to
> > minimize real-time resource utilization.
> >
> > During the steady-state stream ingest process the server has to
parse
> > MPEG2TS and locally store the various data elements. It then has two
> > options in real time when it gets the channel change request -
> >
> > Option 1- The server can regenerate a compliant MPEG2TS bitstream
and
> > send it to the client, where it is re-parsed into its component
> > elements
> > and locally processed (along with the local keys and device specific
> > behavior). Note that the MPEG2TS regeneration process has to happen
> > when
> > the RAMS request comes in, and thus can cause severe resource spikes
> > during top-of-the hour events.
> >
> > Option 2- The server can send the parsed data in TLV format,
removing
> > the extra step of MPEG2TS generation on the server and subsequent
> > re-parsing on the client.
> >
> > The local key handling and device specific behavior are common to
both
> > cases. They are described here to highlight that the server can't
> > reduce
> > client load because there is significant client specific behavior.
> >
> > These are subtle points that drive significant scaling differences,
and
> > may be best handled by walking through an example. The most
demanding
> > (and thus most useful) case is when changing channels on a
simulcrypt
> > system between channels that use different CAS systems.
> >
> > Once again, I want to be sure we get the best algorithm, and I
welcome
> > a
> > detailed examination of the alternative solutions.
> > Bvs
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> > Roni Even
> > Sent: Monday, March 22, 2010 10:23 AM
> > To: Dave Oran (oran); 'Peilin YANG'
> > Cc: [e-mail]
> > Subject: Re: [AVT] MPEG2-TS preamble - client customization
> >
> > Hi Dave,
> > I think that what Peilin said has to do with the receiver
understanding
> > of
> > the data format and not about the post processing if it is needed.
> > Roni Even
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> > > David R Oran
> > > Sent: Monday, March 22, 2010 6:55 PM
> > > To: Peilin YANG
> > > Cc: [e-mail]
> > > Subject: Re: [AVT] MPEG2-TS preamble - client customization
> > >
> > >
> > > On Mar 22, 2010, at 12:51 PM, Peilin YANG wrote:
> > >
> > > > Hi,
> > > >
> > > > I would like to try and clarify my meaning on client
customization
> > > since it looks like there are some misunderstanding.
> > > > Our product solution does not require any customization on the
> > client
> > > side and we feed the MPEG2-TS stream directly to the MPEG2-TS
> > > demultiplexer /decoder.
> > > > Still the Xia preamble draft does not say that it is not allowed
to
> > > do client customization if needed. We think that this is is a post
> > > processing topic that is external to the transport of the preamble
> > > information.
> > > > From the discussion on the list we see that this post processing
> > may
> > > also be needed in regular MPEG2-TS receivers without even having
the
> > > RAMS support.
> > > > I think that this implies that these receivers know how to take
an
> > > MPEG2-TS stream and restructure it  before feeding it to the
> > > demultiplexer.  So this demonstrates that receivers can know how
to
> > > handle the RFC 2250 / MPEG2-TS structures in the post processing
and
> > > they will be able to support the preamble according to the Xia
draft
> > > easily if needed.
> > > Did you miss my analysis showing that the steady-state and startup
> > > behavior of decoders is known to be different? That is what
accounts
> > > for not needing to mess with the content/timing of the transport
> > stream
> > > in the absence of RAMS. So, I don't think the implication you
> > speculate
> > > about above holds.
> > >
> > > Cheers, DaveO.
> > >
> > >
> > >
> > > >
> > > > Peilin Yang
> > > >
> > > > _______________________________________________
> > > > 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
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt