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

From: Peilin YANG <[email-masked]>
Date: Mon, 22 Mar 2010 18:51:25 +0200

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.

Peilin Yang

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Mar 2010 12:55:04 -0400

> 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 h…
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 22 Mar 2010 12:03:22 -0500

There is no question that it could be made to work either way. The
question before us is "which way is better?". The most efficient, less
complex, more scalable solution is preferable.

As a general rule for processing Audio/Video flows, best practices
dictate that stream-specific functions occur "upstream" and device
specific functions occur "downstream". There are very good reasons for
this, some of which are discussed in the previous emails. Let's discuss
it in detail and come up with the right answer.

Perhaps we should walk through a use case in which a channel change
occurs on a simulcrypt system between channels using different CAS
systems? This is a fairly common use case, and highlights the
differences between the proposals.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peilin YANG
Sent: Monday, March 22, 2010 9:51 AM
To: [email-masked]
Subject: [AVT] MPEG2-TS preamble - client customization

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.

Peilin Yang

---

From: Roni Even <[email-masked]>
Date: Mon, 22 Mar 2010 19:14:05 +0200

Bill,
I am sorry but I do not understand your meaning and how it implies to the
message from Peilin.
Roni Even
As individual

> Bill Ver Steeg (versteb)
> Sent: Monday, March 22, 2010 7:03 PM
> To: Peilin YANG; [email-masked]
> Subject: Re: [AVT] MPEG2-TS preamble - client customization
>

---

From: Roni Even <[email-masked]>
Date: Mon, 22 Mar 2010 19:22:37 +0200

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

> David R Oran
> Sent: Monday, March 22, 2010 6:55 PM
> To: Peilin YANG
> Cc: [email-masked]
> > I would like to try and clarify my meaning on client customization
> since it looks like there are some misunderstanding.
> > 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
> 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
> >

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Mar 2010 13:39:20 -0400

> the data format and not about the post processing if it is needed.
Sorry, that's not how I read it...if that's all Peilin was trying to say that may be true, and I have no objection of course, but I don't see how it's germane to the issue that we're trying to resolve.

That issue is whether there is any inherent advantage to an MPEG2TS encoding of the preamble because you might be able to jam it straight into the decoder without pulling it all apart and changing the ordering /timing. There seems to be evidence that in at least one case (i.e. the one Huawei is shipping) this works, and a number of instances (e.g.  the multiple Cisco deployments) that it doesn't.

What I don't have a good handle on is whether using MPEG2TS makes things harder than TOLV if you are going to rip things apart anyway. 
I have code for one, but not the other...

DaveO.

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 22 Mar 2010 12:48:38 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Monday, March 22, 2010 10:23 AM
To: Dave Oran (oran); 'Peilin YANG'
Cc: [email-masked]
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

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Mar 2010 15:10:33 -0400

On Mar 22, 2010, at 2:04 PM, Peilin YANG wrote:

> Dear David,
> 
> Please see inline,
> 
> Peilin
> 
> ----- 原邮件 -----
> 发件人: David R Oran <[email-masked]>
> 日期: 星期二, 三月 23日, 2010 上午1:39
> 主题: Re: [AVT] MPEG2-TS preamble - client customization
> 收件人: Roni Even <[email-masked]>
> 抄送: 'Peilin YANG' <[email-masked]>, [email-masked]
> 
> Peilin: I also don't see how Begen draft avoids jam after RR generates a sequence of MPEG2 TS packets from TOLV.
We don't do that. See the code. We do use MPEG2TS since that's the data format the decoder demux parses, but carefully construct the order and the timing based on direct API interaction with the decoder. That way we can be certain that the PCRs will be acceptable (since they are actually sync'ed already to the receiver's clock, and also make sure in the case of ECMs that they are only handed to the decoder when it is ready for them. In some cases this is actually done via an up-call from the vendor-specific code that the CAS vendor supplies (which may in fact be a different library from the standard STB library.

> For huawei deployments our solution works well. I also think Let market decide is a good choice.
As long as one is mandatory to implement, I could live with two schemes. If neither is mandatory to implement, then we have created a situation where we have conformance without interoperability and that is exactly why the IETF doesn't work according to conformance as the compliance basis of its standards.

---

From: Roni Even <[email-masked]>
Date: Mon, 22 Mar 2010 23:31:15 +0200

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

> From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
> Sent: Monday, March 22, 2010 7:49 PM
> To: Roni Even; Dave Oran (oran); Peilin YANG
> Cc: [email-masked]
> Subject: RE: [AVT] MPEG2-TS preamble - client customization
> 
> Roni-
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Mar 2010 14:43:15 -0700

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

Roni Even
> Sent: Monday, March 22, 2010 2:31 PM
> To: Bill Ver Steeg (versteb); Dave Oran (oran); 'Peilin YANG'
> Cc: [email-masked]
> > Once again, I want to be sure we get the best algorithm, and I
welcome
> > a

---

From: Roni Even <[email-masked]>
Date: Mon, 22 Mar 2010 23:43:10 +0200

David,
I am not sure I understand the distinction between the solutions

"We don't do that. See the code. We do use MPEG2TS since that's the data
format the decoder demux parses, but carefully construct the order and the
timing based on direct API interaction with the decoder. That way we can be
certain that the PCRs will be acceptable (since they are actually sync'ed
already to the receiver's clock, and also make sure in the case of ECMs that
they are only handed to the decoder when it is ready for them. In some cases
this is actually done via an up-call from the vendor-specific code that the
CAS vendor supplies (which may in fact be a different library from the
standard STB library."

This process happens after the Receiver receives a preamble stream from the
RS. So this step takes the preamble data and reconstructs it differently. I
believe that this same process is applicable for both ways of sending the
preamble over the wire.

As for having the two solution I think this will require from the Receiver
to support both.

The process at the receiver will be to get the preamble information as
RFC2250/MPEG2-TS or TOLV stream and if needed do the step you described
above
Roni Even
As individual

> From: David R Oran [mailto:[email-masked]]
> Sent: Monday, March 22, 2010 9:11 PM
> To: Peilin YANG
> Cc: Roni Even; [email-masked]
> > Sorry, that's not how I read it...if that's all Peilin was trying to
> say that may be true, and I have no objection of course, but I don't
> see how it's germane to the issue that we're trying to resolve.
> >
> > That issue is whether there is any inherent advantage to an MPEG2TS
> encoding of the preamble because you might be able to jam it straight
> into the decoder without pulling it all apart and changing the ordering
> /timing. There seems to be evidence that in at least one case (i.e. the
> one Huawei is shipping) this works, and a number of instances (e.g.
> the multiple Cisco deployments) that it doesn't.
> >
> > Peilin: I also don't see how Begen draft avoids jam after RR
> generates a sequence of MPEG2 TS packets from TOLV.
> We don't do that. See the code. We do use MPEG2TS since that's the data
> format the decoder demux parses, but carefully construct the order and
> the timing based on direct API interaction with the decoder. That way
> we can be certain that the PCRs will be acceptable (since they are
> actually sync'ed already to the receiver's clock, and also make sure in
> the case of ECMs that they are only handed to the decoder when it is
> ready for them. In some cases this is actually done via an up-call from
> the vendor-specific code that the CAS vendor supplies (which may in
> fact be a different library from the standard STB library.
> 
> As long as one is mandatory to implement, I could live with two
> schemes. If neither is mandatory to implement, then we have created a
> situation where we have conformance without interoperability and that
> is exactly why the IETF doesn't work according to conformance as the
> compliance basis of its standards.
> 
> >
> >
> > What I don't have a good handle on is whether using MPEG2TS makes
> things harder than TOLV if you are going to rip things apart anyway.

---

From: Peilin YANG <[email-masked]>
Date: Tue, 23 Mar 2010 06:28:52 +0800

Dear Ali,

It is undoubted that the preamble information is needed to demultiplex/decode correctly for receivers. 
In your solution you use TOLV; Xia draft uses raw TS packets.
There is one thing until now I am not exactly clear that if the TOLV format should be converted to TS packet before being fed to demultiplexer/decoder. According to the understanding of a general reader, it should. 
If the TOLV format should be converted to TS packet before being fed to demultiplex/decode, how is it faster decoding and shorter zapping times than Xia draft? Because Xia draft doesn't need the converting steps and directly feed it to demultiplexer/decoder.

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 三月 23日, 2010 上午5:43
主题: RE: [AVT] MPEG2-TS preamble - client customization
收件人: Roni Even <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, Peilin YANG <[email-masked]>
抄送: [email-masked]

-acbegen

Roni Even
welcome

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Mar 2010 15:57:41 -0700

> From: Peilin YANG [mailto:[email-masked]]
> Sent: Monday, March 22, 2010 3:29 PM
> To: Ali C. Begen (abegen)
> Cc: Roni Even; Bill Ver Steeg (versteb); Dave Oran (oran);
[email-masked]
> It is undoubted that the preamble information is needed to
demultiplex/decode correctly for receivers.
> There is one thing until now I am not exactly clear that if the TOLV
format should be converted to TS
> packet before being fed to demultiplexer/decoder. According to the
understanding of a general reader,
> it should.

It is not a should, it is a must. And if this has been unclear until
now, I must have done a pretty bad job in explaining our stuff. We
cannot change the demuxes or decoder chipsets, etc. Whatever we do, it
happens on the RTP layer. 

We don't use raw TS packets because it is more difficult on the receiver
side to parse the TS stream and then customize the preamble. Using raw
TS packets also increases the number of packets needed to carry the
preamble in our experience. Rather, we encode the preamble data
efficiently in the form of a new payload (tlv elements) and let the
receiver create new TS packets according to its needs. Those TS packets
are also perfectly clock'ed so transitioning from the preamble to the
primary SSM stream does not create glitches in the demux.

> If the TOLV format should be converted to TS packet before being fed
to demultiplex/decode, how is it
> faster decoding and shorter zapping times than Xia draft? Because Xia
draft doesn't need the
> converting steps and directly feed it to demultiplexer/decoder.

Parsing the TLV elements and creating new TS packets may take 1x
additional delay but the resulting customized preamble may potentially
provide >> 1x reduction in channel change times. 

-acbegen

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Mar 2010 16:19:33 -0700

I may be missing something, but it seems to come down to this: the only 
difference between the two methods is the pre-packaging the Begen solution 
proposes. I assume the argument is that the RR has less processing power than 
the RS, so it pays to shift some of the parsing effort to the RS. Do I 
understand correctly?

---

From: Roni Even <[email-masked]>
Date: Tue, 23 Mar 2010 01:44:54 +0200

Hi Tom,

The packaging of the information in the xia draft is simpler than the begen
draft. The xia draft just look at the primary stream and extract the
relevant PSI packets without any processing while the begen draft covert
these packets to TOLVs which requires more processing on the RS. 

The other processing requirement is if you need to do some post processing
before feeding the data to the demultiplexer on the RTP_Rx and I am not sure
the starting from TOLV or from MPEG2-TS is much difference that it will
benefit from converting  to TOLV on the RS. 
Roni 

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, March 23, 2010 1:20 AM
> Cc: Peilin YANG; Dave Oran (oran); Bill Ver Steeg (versteb); Roni Even;
> [email-masked]

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Mar 2010 19:48:29 -0400

On Mar 22, 2010, at 7:19 PM, Tom Taylor wrote:

> I may be missing something, but it seems to come down to this: the only difference between the two methods is the pre-packaging the Begen solution proposes. I assume the argument is that the RR has less processing power than the RS, so it pays to shift some of the parsing effort to the RS. Do I understand correctly?
> 
Sort of. I don't think anybody is claiming you can't make things work with either encoding. I also think that the processing overhead differences are a second order effect once you in fact write all the code to make it work in a multivendor (especially RAMS receivers from multiple vendors) environment. We have such code for TOLV. The MPEG2TS folks clearly think you don't need this code since they have a deployment that works without it.

What I think the TOLV advocates argue is that the stated advantage of using raw MPEG2TS for the preamble is a mirage, because you are in fact not gaining anything significant in either implementation simplicity, or processing load, or specification simplicity to use it. The reasons have been stated many times and we are likely at an impasse where I don't think one side's arguments are going to sway the other. 

The reason we chose the TOLV design was because it made it very clear and straightforward for the RAMS receiver to interact with the local decoder in its own API, timing domain, and startup constraints. 

The MPEG2TS encoding design has a set of tradeoffs that make it look simpler, but the TOLV advocates argue actually make things harder, because:
- the receiver may have to re-order things that have an inherent order in the TS rather than just create the right order
- the receiver may have to re-time the PCRs rather than construct them directly from the decoder's local clock
- the receiver may have to insert or remove null frames to get proper separation among things in non-video PIDs that can't be given to the decoder back-to-back (ECMs are the poster-child example of elements that need special handling in all known implementations with encryption).
- the sender has to construct a "legal" MPEG2TS but since this isn't likely to be the one the receiver wants anyway, it is likely to be suboptimal both in terms of size and convenience for the receiver.

In closing, let me reiterate; either can be made to work. My personal view remains that the TOLV method is superior. It looks more complicated on paper, but winds up simpler in code if you in fact need to it work interoperably for a large variety of receiver/decoder combinations, *especially* when encrypted streams are involved.

Cheers, DaveO.

>> happens on the RTP layer. We don't use raw TS packets because it is more difficult on the receiver
>> provide >> 1x reduction in channel change times. -acbegen
>> 
>>> Peilin

---

From: Peilin YANG <[email-masked]>
Date: Tue, 23 Mar 2010 09:40:06 +0800

Dear Ali,

Please see inline.

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 三月 23日, 2010 上午6:58
主题: RE: [AVT] MPEG2-TS preamble - client customization
收件人: Peilin YANG <[email-masked]>
抄送: Roni Even <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>, "Dave Oran (oran)" <[email-masked]>, [email-masked]

[email-masked]

We don't use raw TS packets because it is more difficult on the receiver
side to parse the TS stream and then customize the preamble. 
Peilin: I don't know what and how is the difficulty? I think it is the same.

Using raw TS packets also increases the number of packets needed to carry the
preamble in our experience. Rather, we encode the preamble data
efficiently in the form of a new payload (tlv elements) and let the
receiver create new TS packets according to its needs. Those TS packets
are also perfectly clock'ed so transitioning from the preamble to the
primary SSM stream does not create glitches in the demux.
Peilin: In most cases, the one RTP packet is enough to transmit the preamble information. I don't think 600 bytes in one RTP packet is more effecient than 1000 bytes in one RTP packet. If ECM/EMM has several TS packets, in our solution it will use two or more RTP packets, in your solution it is the same. 
The most important thing is that our solution is independent on the application layer information(codec and MPEG2-TS). Our solution has good extensibility and flexibility because it doesn't need to extend.Please the following comment that I cited from the previous email. 
"In which sense the Begen draft adds extensibility and flexibility? I would have thought the contrary, since potential future additions in Mpeg2TS will likely require an update of the payload format used in Begen draft, and not on the payload format adopted by the Xia draft." 

draft doesn't need the

Peilin: Since in your solution it must convert TOLV format to TS packets before feeding to demultiplexer and decoer, in our solution it is complete TS packets. I don't know what cannot do in our solution.

-acbegen

---

From: "Allison, Art" <[email-masked]>
Date: Tue, 23 Mar 2010 10:58:32 -0400

I reached the conclusion some time back, and have seen no basis to
change that based on subsequent exchanges, that the Bergen alternative
is more likely to result in more implementations that actually work and
therefore should be the one adopted. 
Further, the Xia approach does not require that the ISO 13818-1 TS
provisions be respected, alters the payload layer to perform this
special function and appears to explicitly require violation of its (ISO
13181-1) terms (as written).  

Also, not withstanding my opinion on the technical merits; if one has
two choices that are judged about the same, picking the one that avoids
(conflict with)/(violation of) other international standards seems
appropriate.

Art
Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981

www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Tom Taylor
|Sent: Monday, March 22, 2010 7:20 PM
|To: Ali C. Begen (abegen)
|Cc: Dave Oran (oran); Roni Even; Bill Ver Steeg (versteb); [email-masked]
|Subject: Re: [AVT] MPEG2-TS preamble - client customization
|
|I may be missing something, but it seems to come down to this: 
|the only difference between the two methods is the 
|pre-packaging the Begen solution proposes. I assume the 
|argument is that the RR has less processing power than the RS, 
|so it pays to shift some of the parsing effort to the RS. Do I 
|understand correctly?
|
|Ali C. Begen (abegen) wrote:
|> 
|>> -----Original Message-----
|>> From: Peilin YANG [mailto:[email-masked]]
|>> Sent: Monday, March 22, 2010 3:29 PM
|>> To: Ali C. Begen (abegen)
|>> Cc: Roni Even; Bill Ver Steeg (versteb); Dave Oran (oran);
|> [email-masked]
|>> Subject: RE: [AVT] MPEG2-TS preamble - client customization
|>>
|>> Dear Ali,
|>>
|>> It is undoubted that the preamble information is needed to
|> demultiplex/decode correctly for receivers.
|>> In your solution you use TOLV; Xia draft uses raw TS packets.
|>> There is one thing until now I am not exactly clear that if the TOLV
|> format should be converted to TS
|>> packet before being fed to demultiplexer/decoder. According to the
|> understanding of a general reader,
|>> it should.
|> 
|> It is not a should, it is a must. And if this has been unclear until 
|> now, I must have done a pretty bad job in explaining our stuff. We 
|> cannot change the demuxes or decoder chipsets, etc. Whatever 
|we do, it 
|> happens on the RTP layer.
|> 
|> We don't use raw TS packets because it is more difficult on the 
|> receiver side to parse the TS stream and then customize the 
|preamble. 
|> Using raw TS packets also increases the number of packets needed to 
|> carry the preamble in our experience. Rather, we encode the preamble 
|> data efficiently in the form of a new payload (tlv elements) and let 
|> the receiver create new TS packets according to its needs. Those TS 
|> packets are also perfectly clock'ed so transitioning from 
|the preamble 
|> to the primary SSM stream does not create glitches in the demux.
|> 
|>> If the TOLV format should be converted to TS packet before being fed
|> to demultiplex/decode, how is it
|>> faster decoding and shorter zapping times than Xia draft? 
|Because Xia
|> draft doesn't need the
|>> converting steps and directly feed it to demultiplexer/decoder.
|> 
|> Parsing the TLV elements and creating new TS packets may take 1x 
|> additional delay but the resulting customized preamble may 
|potentially 
|> provide >> 1x reduction in channel change times.
|> 
|> -acbegen
|>  
|>> Peilin
|> 
|> _______________________________________________
|> Audio/Video Transport Working Group
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/avt
|> 
|> 
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: "Allison, Art" <[email-masked]>
Date: Tue, 23 Mar 2010 13:16:42 -0400

This has been discussed on list. In short,  please carefully examine threads covering continuity count values and PCR time stamps, which unless I missed an update, are not mandated to be adjusted before transmission.  
So if a receiver were to extract all the packets when received (which is the expected  behavior per Xia), the extracted TS packets, when inserted into the flow of the next arriving regular TS packets (after disembedding then from the next RTP packet) can be discontinuous in the continuity count values and the PCR time stamps (per PID value). Also it is not clear if that any of the preamble packets can be duplicates of later arriving (or by remote chance just arrived) 'normal' TS packets - but if so that also must be signaled as per 13818-1 or nonconformance exists. The Xia approach could require the packets be constructed so as to be conformant, but that does not seem to be mandatory (and I do not opine on that complexity).   

And in another branch it was asked (by Zong):

2) I didn't understand why you say Xia's approach alters the payload layer and appears to require violation of standards. In my understanding (and repeated for many times in mailing discussion), Ali's approach extract the preamble values from TS stream and Xia's approach extract raw TS packets. I am confused by saying one approach alter the payload layer and another not.

The Ali approach provides the data as a separate structure and the implementation has a special process to use it. 
A receiver can use this in various ways. Local creation of TS packets is one that has been described; but that is not in the RFC, rather local receiver implementation option.   The Xia approach sends the packets, and they are on the wire as defined, purporting to be TS packets that can be used. The benefit that has been touted was then these (Xia) sent packets are simply passed to the next layer as is.... rather than used as input for custom processing. If they were inputs for custom processing and not simply passed unaltered, then the receiver would have the burden of the special handling to avoid parameter errors. To be conformant the sender would need to be required to so insure based on the timing of the preamble transmission and the current regular TS packets being sent.
..
Final words fwiw:
I do not challenge the assertions that either can be made to work.
I see no significant variability potential with the Ali implementations, and a small variability exposure with Xia implementations. 

Art Allison

www.nab.org

|-----Original Message-----
|From: Peilin YANG [mailto:[email-masked]] 
|Sent: Tuesday, March 23, 2010 12:34 PM
|To: Allison, Art
|Cc: [email-masked]
|Subject: Re: [AVT] MPEG2-TS preamble - client customization
|
|Dear Art,
|
|Welcome your comments. Please help us to explain how Xia 
|approach alters the payload layer to perform this special 
|function and appears to explicitly require violation of its 
|(ISO13181-1) terms (as written)?
|
|Thanks,
|
|Peilin
|
|----- 原邮件 -----
|发件人: "Allison, Art" <[email-masked]>
|日期: 星期二, 三月 23日, 2010 下午10:59
|主题: Re: [AVT] MPEG2-TS preamble - client customization
|收件人: [email-masked]
|
|I reached the conclusion some time back, and have seen no 
|basis to change that based on subsequent exchanges, that the 
|Bergen alternative is more likely to result in more 
|implementations that actually work and therefore should be the 
|one adopted. 
|Further, the Xia approach does not require that the ISO 
|13818-1 TS provisions be respected, alters the payload layer 
|to perform this special function and appears to explicitly 
|require violation of its (ISO
|13181-1) terms (as written).  
|
|Also, not withstanding my opinion on the technical merits; if 
|one has two choices that are judged about the same, picking 
|the one that avoids (conflict with)/(violation of) other 
|international standards seems appropriate.
|
|Art
|Art Allison
|
|Senior Director Advanced Engineering, Science and Technology
|

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 23 Mar 2010 18:30:31 -0500

Peilin

I would like to see this MPEG2TS compliant bitstream. Can you send a
wireshark capture of such a bitstream to the list?

Bill VerSteeg

-----Original Message-----

Hi,

Peilin Yang

---

From: Frank Xia <[email-masked]>
Date: Wed, 24 Mar 2010 11:59:52 -0500

Dear David,

I personally think you analysize neutrally two solutions on the other side
of ground that we are likely at an impasse, one side's arguments cannot sway
the other. Like you, I personal view is that the Xia Draft is superior
because it is simple and completely complies MPEG2TS bitstream.

Best regards,

Peilin & Frank

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期二, 三月 23日, 2010 上午7:48
主题: Re: [AVT] MPEG2-TS preamble - client customization
收件人: Tom Taylor <[email-masked]>
抄送: "Ali C. Begen (abegen)" <[email-masked]>, Peilin YANG
<[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>,
Roni Even <[email-masked]>, [email-masked]

difference between the two methods is the pre-packaging the Begen solution
proposes. I assume the argument is that the RR has less processing power
than the RS, so it pays to shift some of the parsing effort to the RS. Do I
understand correctly?
Sort of. I don't think anybody is claiming you can't make things work with
either encoding. I also think that the processing overhead differences are a
second order effect once you in fact write all the code to make it work in a
multivendor (especially RAMS receivers from multiple vendors) environment.
We have such code for TOLV. The MPEG2TS folks clearly think you don't need
this code since they have a deployment that works without it.

What I think the TOLV advocates argue is that the stated advantage of using
raw MPEG2TS for the preamble is a mirage, because you are in fact not
gaining anything significant in either implementation simplicity, or
processing load, or specification simplicity to use it. The reasons have
been stated many times and we are likely at an impasse where I don't think
one side's arguments are going to sway the other. 

The reason we chose the TOLV design was because it made it very clear and
straightforward for the RAMS receiver to interact with the local decoder in
its own API, timing domain, and startup constraints. 

The MPEG2TS encoding design has a set of tradeoffs that make it look
simpler, but the TOLV advocates argue actually make things harder, because:
- the receiver may have to re-order things that have an inherent order in
the TS rather than just create the right order
- the receiver may have to re-time the PCRs rather than construct them
directly from the decoder's local clock
- the receiver may have to insert or remove null frames to get proper
separation among things in non-video PIDs that can't be given to the decoder
back-to-back (ECMs are the poster-child example of elements that need
special handling in all known implementations with encryption).
- the sender has to construct a "legal" MPEG2TS but since this isn't likely
to be the one the receiver wants anyway, it is likely to be suboptimal both
in terms of size and convenience for the receiver.

In closing, let me reiterate; either can be made to work. My personal view
remains that the TOLV method is superior. It looks more complicated on
paper, but winds up simpler in code if you in fact need to it work
interoperably for a large variety of receiver/decoder combinations,
*especially* when encrypted streams are involved.

Cheers, DaveO.