Subject: [AVT] MPEG2TS preamble - where next

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Jul 2010 19:39:27 +0200

(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.

In terms of choosing one solution over the other, to be honest I am not convinced that we have significantly advanced this discussion since the end of the Hiroshima meeting, and certainly none since the Anaheim meeting. The goal of any further discussion needs to be in aid of convincing the working group of which direction they want to go. At the moment I am unconvinced that further material is going to appear. In the absence of further input, I believe we just need to call the question, and if people end up deciding because they prefer the red coloured one to the blue coloured one, then so be it.

So, if I allow discussion in this direction to continue, then I want to see clear proposals on how that discussion should be structured, and the purpose to be achieved by that conversation. I would like to see this input rapidly - think about doing this before the session starts tomorrow.

At the moment I am not convinced that a formal assessment process (e.g. as proposed by Stefan at the last meeting and in the ad-hoc) is going to come up with a set of assessments that are doable in some independent test bench, nor am I convinced that such a set of tests will tell us anything about performance or scaling, which I currently believe we need to address. If you believe this is viable, then please also send me some mail on it, with some persuasive words.

I am concerned also that further delay may just automatically assume there are two solutions in the market place, and therefore if there is a service we should be doing to the IETF community, then we will not have done it.

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Jul 2010 21:13:49 +0300

Hi Keith, 
What I fear is missing in both document is the part that describes the
pre-processing and post-processing that is required according to the face to
face and mailing list discussion with reference to document defining this
when specified. Section 7 of the begen draft and section 6 of the xia draft
are very simple and both document do not describe the whole process and
issues. 
I am trying my best to understand the issues based on both drafts text and
looking at the suggested reference documents and since I am not involved in
the coding of any of the proposal I can not voice a full technical opinion. 

My current observation is that saying we tried this method and it did not
work, trust me, against we tried it and it works is not providing any real
input.

I am trying my best to get all the input from both side even though I am not
an impartial party, yet I want to see a good technical solution if we want
to have one basecd on understanding the advantage and disadvantages of the
proposals

Roni Even
As Individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Thursday, July 29, 2010 8:39 PM
> To: [email-masked]
> 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.
> 
> In terms of choosing one solution over the other, to be honest I am not
> convinced that we have significantly advanced this discussion since the
> end of the Hiroshima meeting, and certainly none since the Anaheim
> meeting. The goal of any further discussion needs to be in aid of
> convincing the working group of which direction they want to go. At the
> moment I am unconvinced that further material is going to appear. In
> the absence of further input, I believe we just need to call the
> question, and if people end up deciding because they prefer the red
> coloured one to the blue coloured one, then so be it.
> 
> So, if I allow discussion in this direction to continue, then I want to
> see clear proposals on how that discussion should be structured, and
> the purpose to be achieved by that conversation. I would like to see
> this input rapidly - think about doing this before the session starts
> tomorrow.
> 
> At the moment I am not convinced that a formal assessment process (e.g.
> as proposed by Stefan at the last meeting and in the ad-hoc) is going
> to come up with a set of assessments that are doable in some
> independent test bench, nor am I convinced that such a set of tests
> will tell us anything about performance or scaling, which I currently
> believe we need to address. If you believe this is viable, then please
> also send me some mail on it, with some persuasive words.
> 
> I am concerned also that further delay may just automatically assume
> there are two solutions in the market place, and therefore if there is
> a service we should be doing to the IETF community, then we will not
> have done it.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 29 Jul 2010 12:35:57 -0700

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 regardless 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

> RFC or two alternate RFCs. There does seem to be support in the WG that
 
[Sandy] ...snip...

---

From: Peilin YANG <[email-masked]>
Date: Fri, 30 Jul 2010 04:36:01 +0800

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" <[email-masked]>
日期: 星期五, 七月 30日, 2010 上午3:35
主题: Re: [AVT] MPEG2TS preamble - where next
收件人: "[email-masked]" <[email-masked]>

> 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
> 
> 
> > 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...
> 
> > own technical decision and informing the working group of your 
> opinion.> 
> > regards
> > 
> > Keith

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 29 Jul 2010 14:43:01 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peilin YANG
> Sent: Thursday, July 29, 2010 10:36 PM
> To: Sandy (Alexander) MacInnis
> Cc: [email-masked]
> Subject: Re: [AVT] MPEG2TS preamble - where next
> 
> 
> Dear Sandy,
> 
> 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
> 
> 
> ----- 原邮件 -----

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 29 Jul 2010 14:47:09 -0700

Thanks, Peilin, this is also a good topic to discuss.
I've seen this point brought up before in this forum.

In my understanding, if some new PSI and/or CODEC format becomes a requirement in the future - something that we could not and did predict now - then all receivers that are supposed to receive this new format need to have at least some new software. (I say "at least" because they might have to be replaced.) This is true regardless of what kind of preamble is used, or even whether there is any preamble at all in use.

Do you agree? If not, how do the receivers process formats that were not known and not predictable at the time the receivers were designed and programmed?

So I don't see a difference between the two proposed preamble formats regarding receiving future multicast PSI and/or CODEC formats. It would be nice not to have to update the preamble spec itself, but that does not appear to make a difference to whether the receivers would need to be updated when new multicast formats need to be supported. Whether one or the other preamble format choice would result in more or less work to update receivers in the future, I can't predict, since by definition we can't predict what the future PSI or CODEC changes might be.

--Sandy

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 1:36 PM
To: Sandy (Alexander) MacInnis
Cc: [email-masked]
Subject: Re: [AVT] MPEG2TS preamble - where next

Dear Sandy,

Best regards,

Peilin

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 29 Jul 2010 18:06:39 -0400

I see one flaw that applies to both approaches. If the MPEG-2 TS buffering
parameters are optimal, meaning that adding a bit more data may result in
buffer overflow, then the buffering parameters would need to be changed
regardless of which of the two approaches is in use. If the TS based
approach is in use, the TS stream after addition of the preamble packets
would be non-conforming to the buffering parameters anymore. If the TLV
based approach is in use, after the so-called post-processing, the TS stream
seen by the TS receiver is non-conforming to the buffering parameters
anymore. 

One way to solve this problem is that the server changes the buffering
parameters such that the TS stream is conforming to the signalled buffereing
parameters. Of course, this would not be a trivial thing to do by the
server. In this case, I think the TS based approach is clearly better, as
there is then no post-processing needed at all. Another way to solve the
problem is that the receiver changes the buffering parameters. This is more
difficult than server changing the parameters as the receiver cannot access
the entire stream before the entrie stream is received. I am not sure
whether this is the so-called post-processing mentioned in eartlier
discussions. If the post-processing does not invovles changing of the
buffering parameters then I believe it cannot work for all cases anyway. 

If the original video buffereing parameters are optimal and the preamble
includes additional data to be fed to the video decoder, then the video
buffering parameters also need to be changed, similarly as above.

Please corrrect me if the above understanding is incorrect. However, if
correct, I think both drafts need to clearly describe the problem and the
solution, to make both approaches complete and to enable the group to make a
decision. 

BR, YK 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sandy (Alexander) MacInnis
> Sent: Thursday, July 29, 2010 5:47 PM
> To: Peilin YANG
> Cc: [email-masked]
> In my understanding, if some new PSI and/or CODEC format 
> becomes a requirement in the future - something that we could 
> not and did predict now - then all receivers that are 
> supposed to receive this new format need to have at least 
> some new software. (I say "at least" because they might have 
> to be replaced.) This is true regardless of what kind of 
> preamble is used, or even whether there is any preamble at all in use.
> 
> Do you agree? If not, how do the receivers process formats 
> that were not known and not predictable at the time the 
> receivers were designed and programmed?
> 
> So I don't see a difference between the two proposed preamble 
> formats regarding receiving future multicast PSI and/or CODEC 
> formats. It would be nice not to have to update the preamble 
> spec itself, but that does not appear to make a difference to 
> whether the receivers would need to be updated when new 
> multicast formats need to be supported. Whether one or the 
> other preamble format choice would result in more or less 
> work to update receivers in the future, I can't predict, 
> since by definition we can't predict what the future PSI or 
> CODEC changes might be.
> 
> --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.
> 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 
> 
> 
> ----- 原邮件 -----

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 29 Jul 2010 15:43:17 -0700

Ye-Kui, thanks for bringing this up. MPEG-TS STD(*) buffering is obviously very important, and it is often overlooked.

One significant difference in understanding is in how the receiver would process the incoming preamble.

The preferred way to process the preamble, at least in my view, is to parse the preamble and keep the relevant variables in software, and have software set up the transport processing to prepare it to receive the start of the video. That's how I'd do it. If the preamble spec were TLV based, I would not convert it to TS packets! If the preamble were in TS packets, I'd parse them and extract the relevant fields, and then perform the initialization processing in software. Of course, there are other ways to do it, if someone so chooses. If the receiver does, for some reason, choose to convert a TLV preamble into TS packets and then feed those TS packets to a transport processor, that's a private choice of the designers of that receiver. Such a receiver would have no right to complain that the result does not conform to the STD buffer model of the MPEG-TS standard if it chose to do that.

On the other hand, if the preamble comes in the form of TS packets, and if the resulting combination of preamble and multicast, all consisting of TS packets, is claimed to conform to the MPEG-TS standard, then there would be an issue with STD conformance, and it could potentially be severe.

We can speculate that a RS that supports the MPEG-TS based preamble might be able to modify the transport stream that it is processing and sending to the receivers, such that the STD constraints are met by the combination of the multicast stream and each case of preamble sent to any RR. However that would appear to be very difficult to do. The RS cannot just change the STD parameters to make the stream conform - those parameters are in the standard. Changing the relative positions of TS packets that carry video, audio, and systems data in the multicast, and also the temporal positions of the TS packets that carry the preamble, such that the STD constraints are met, would appear to be very difficult to do, even if the operation were defined. I doubt that it's defined at all, since the preamble is separate from the multicast stream, so how would an STD conformance test test for conformance of the combination of the multicast stream and the preamble? The way the MPEG-TS standard is written, the combination would have to be one transport stream in order to able to say whether it conformed to the standard or not.

So, from the perspective of MPEG-TS STD conformance, the TLV approach has no effect at all, and the MPEG-TS approach either has no effect or else it would appear to be very difficult to make it conform.

Please correct me if I misunderstand something about RAMS and the proposed preamble specs.

I agree that the preamble specs should be clear about how they relate to the MPEG-TS standard, including any effect, or lack of effect, on STD conformance.

--Sandy

P.S. (*) - STD == System Target Decoder

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]]
Sent: Thursday, July 29, 2010 3:07 PM
To: Sandy (Alexander) MacInnis; 'Peilin YANG'
Cc: [email-masked]
Subject: RE: [AVT] MPEG2TS preamble - where next

BR, YK

> > Behalf Of

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 29 Jul 2010 20:01:12 -0400

Hi Sandy,

Very good to learn your way of utilizing the preamble information for the
TLV based approach. Indeed, that way the MPEG-2 STD conformance would be
kept. This is, by the way, the only way I can see now that would work well
(provided that servers do not need to do anything), hence it should be
clearly described in the draft. 

Question to authors of the TLV draft: is this the way in the open-sourced
implementation?

With the above way of utilizing the preamble information, there are still
two issues I would like to understand how to resolve. The first one is that
the MPEG-2 transport processor implementation would need to changed to be
able to receive those variables derived from the preamble and combine those
variables into right context, i.e. existing MPEG-2 transport processor
implementations cannot be used as such. The second one on video buffering
parameters (e.g. H.264/AVC Hypothetical Reference Decoder - HRD parameters)
when any preamble includes additional data to be fed to the video decoder
(e.g. parameter sets NAL units). If the "variables based" way is used, then
also existing video decoder implementations cannot be used as such, which to
me is a  big problem.

BR, YK

> From: Sandy (Alexander) MacInnis [mailto:[email-masked]] 
> Sent: Thursday, July 29, 2010 6:43 PM
> To: Ye-Kui Wang; 'Peilin YANG'
> Cc: [email-masked]
> Ye-Kui, thanks for bringing this up. MPEG-TS STD(*) buffering 
> is obviously very important, and it is often overlooked.
> 
> One significant difference in understanding is in how the 
> receiver would process the incoming preamble.
> 
> The preferred way to process the preamble, at least in my 
> view, is to parse the preamble and keep the relevant 
> variables in software, and have software set up the transport 
> processing to prepare it to receive the start of the video. 
> That's how I'd do it. If the preamble spec were TLV based, I 
> would not convert it to TS packets! If the preamble were in 
> TS packets, I'd parse them and extract the relevant fields, 
> and then perform the initialization processing in software. 
> Of course, there are other ways to do it, if someone so 
> chooses. If the receiver does, for some reason, choose to 
> convert a TLV preamble into TS packets and then feed those TS 
> packets to a transport processor, that's a private choice of 
> the designers of that receiver. Such a receiver would have no 
> right to complain that the result does not conform to the STD 
> buffer model of the MPEG-TS standard if it chose to do that.
> 
> On the other hand, if the preamble comes in the form of TS 
> packets, and if the resulting combination of preamble and 
> multicast, all consisting of TS packets, is claimed to 
> conform to the MPEG-TS standard, then there would be an issue 
> with STD conformance, and it could potentially be severe.
> 
> We can speculate that a RS that supports the MPEG-TS based 
> preamble might be able to modify the transport stream that it 
> is processing and sending to the receivers, such that the STD 
> constraints are met by the combination of the multicast 
> stream and each case of preamble sent to any RR. However that 
> would appear to be very difficult to do. The RS cannot just 
> change the STD parameters to make the stream conform - those 
> parameters are in the standard. Changing the relative 
> positions of TS packets that carry video, audio, and systems 
> data in the multicast, and also the temporal positions of the 
> TS packets that carry the preamble, such that the STD 
> constraints are met, would appear to be very difficult to do, 
> even if the operation were defined. I doubt that it's defined 
> at all, since the preamble is separate from the multicast 
> stream, so how would an STD conformance test test for 
> conformance of the combination of the multicast stream and 
> the preamble? The way the MPEG-TS standard is written, the 
> combination would have to be one transport stream in order to 
> able to say whether it conformed to the standard or not.
> 
> So, from the perspective of MPEG-TS STD conformance, the TLV 
> approach has no effect at all, and the MPEG-TS approach 
> either has no effect or else it would appear to be very 
> difficult to make it conform.
> 
> I agree that the preamble specs should be clear about how 
> they relate to the MPEG-TS standard, including any effect, or 
> lack of effect, on STD conformance.
> 
> --Sandy
> 
> I see one flaw that applies to both approaches. If the MPEG-2 
> TS buffering parameters are optimal, meaning that adding a 
> bit more data may result in buffer overflow, then the 
> buffering parameters would need to be changed regardless of 
> which of the two approaches is in use. If the TS based 
> approach is in use, the TS stream after addition of the 
> preamble packets would be non-conforming to the buffering 
> parameters anymore. If the TLV based approach is in use, 
> after the so-called post-processing, the TS stream seen by 
> the TS receiver is non-conforming to the buffering parameters anymore.
> 
> One way to solve this problem is that the server changes the 
> buffering parameters such that the TS stream is conforming to 
> the signalled buffereing parameters. Of course, this would 
> not be a trivial thing to do by the server. In this case, I 
> think the TS based approach is clearly better, as there is 
> then no post-processing needed at all. Another way to solve 
> the problem is that the receiver changes the buffering 
> parameters. This is more difficult than server changing the 
> parameters as the receiver cannot access the entire stream 
> before the entrie stream is received. I am not sure whether 
> this is the so-called post-processing mentioned in eartlier 
> discussions. If the post-processing does not invovles 
> changing of the buffering parameters then I believe it cannot 
> work for all cases anyway.
> 
> If the original video buffereing parameters are optimal and 
> the preamble includes additional data to be fed to the video 
> decoder, then the video buffering parameters also need to be 
> changed, similarly as above.
> 
> Please corrrect me if the above understanding is incorrect. 
> However, if correct, I think both drafts need to clearly 
> describe the problem and the solution, to make both 
> approaches complete and to enable the group to make a decision.
> 
> BR, YK
> 
> > Sandy (Alexander) MacInnis
> > In my understanding, if some new PSI and/or CODEC format becomes a 
> > requirement in the future - something that we could not and did 
> > predict now - then all receivers that are supposed to 
> receive this new 
> > format need to have at least some new software. (I say "at least" 
> > because they might have to be replaced.) This is true regardless of 
> > what kind of preamble is used, or even whether there is any 
> preamble 
> > at all in use.
> >
> that were 
> > not known and not predictable at the time the receivers 
> were designed 
> > and programmed?
> >
> > So I don't see a difference between the two proposed 
> preamble formats 
> > regarding receiving future multicast PSI and/or CODEC formats. It 
> > would be nice not to have to update the preamble spec 
> itself, but that 
> > does not appear to make a difference to whether the receivers would 
> > need to be updated when new multicast formats need to be supported. 
> > Whether one or the other preamble format choice would 
> result in more 
> > or less work to update receivers in the future, I can't 
> predict, since 
> > by definition we can't predict what the future PSI or CODEC changes 
> > might be.
> >
> > --Sandy
> >
> >
> evaluate your 
> > comments. But I am completly sure that our current deployment is no 
> > problem for that.
> 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
> >
> >
> > ----- 原邮件 -----
> > > 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 
> > > 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.
> > >
> > > 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.
> > > 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 
> > > 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.
> > >
> > > 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
> > >
> > >
> > > > Audio/Video Transport Working Group [email-masked]

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Thu, 29 Jul 2010 17:22:38 -0700

Ye-Kui, please see my replies in-line.

--Sandy

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 5:01 PM
To: Sandy (Alexander) MacInnis; 'Peilin YANG'
Cc: [email-masked]
Subject: RE: [AVT] MPEG2TS preamble - where next

Hi Sandy,

[Sandy] IMO, the same applies to both drafts. No matter how the preamble is packaged for transmission to the receiver, the receiver needs to parse the elements and manage the timing of processing each element in turn. The timing of operations in the receiver is critically important if we expect to get any benefit from the preamble.

implementations cannot be used as such. 

[Sandy] You made the statement that the MPEG transport processor needs to be changed. I don't agree, at least not for our MPEG transport processors; I can't speak for everyone else's. In many, if not most or even all, transport processors, there is significant software involvement, and they are not completely hard-wired. And if they were completely hard-wired, I doubt that either approach would work for robust systems. I strongly disagree with the assertion that existing implementations cannot be used. 

The second one on video buffering
parameters (e.g. H.264/AVC Hypothetical Reference Decoder - HRD parameters)
when any preamble includes additional data to be fed to the video decoder
(e.g. parameter sets NAL units). 
 
[Sandy] What is the question?

If the "variables based" way is used, then
also existing video decoder implementations cannot be used as such, which to
me is a big problem.

[Sandy] Sorry, I don't understand this at all. What "variables based" way are you referring to? Why do you say existing video decoders cannot be used? I disagree.

[Sandy] Video decoders have some amount of physical buffering capability. The designers of those decoders should design them to work with streams that conform to the applicable standard. Presumably the assumption here is that the video streams that are part of the multicast conform to the applicable video standard, and that fact is not changed by the introduction of a preamble. 

What problem are you thinking of?

--Sandy

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 29 Jul 2010 21:24:42 -0400

Sandy,

Please see inline.,  

> [Sandy] IMO, the same applies to both drafts. No matter how 
> the preamble is packaged for transmission to the receiver, 
> the receiver needs to parse the elements and manage the 
> timing of processing each element in turn. The timing of 
> operations in the receiver is critically important if we 
> expect to get any benefit from the preamble.
> 

I don't think your way of utilizing the preample information can be applied
to the TS based approach. Your method needs to first of all know which
packets contain the additional preamble information (and which don't) and
then process them using a separate software module as part of the receiver.
How can this method be applied to the TS based approach, wherein the
receiver makes no distinction on which are preamble packets (and which are
not)?

> [Sandy] You made the statement that the MPEG transport 
> processor needs to be changed. I don't agree, at least not 
> for our MPEG transport processors; I can't speak for everyone 
> else's. In many, if not most or even all, transport 
> processors, there is significant software involvement, and 
> they are not completely hard-wired. And if they were 
> completely hard-wired, I doubt that either approach would 
> work for robust systems. I strongly disagree with the 
> assertion that existing implementations cannot be used. 
> 

Straightforwardly, an MPEG-2 transport processor takes as input a conforming
MPEG-2 TS packet stream. In your method of utilizing the preamble
information, the processor needs to take also input from the software module
that processes the preamble information, in addition to the conforming
MPEG-2 TS packet stream. Maybe your implementation has been designed in the
way you described, which I don't see a good reason for this peculiar
feature, I doubt others will do the same. Note also that existing
implementations do not mean just hardware implementations. Even you need to
make a small change to a software piece of the processor, it is a change. 

> [Sandy] What is the question?

This is so similar to the T-STD buffereing problem thus I did not try to
elaborate it in detail. But let me try now. Each conforming video bitstream
is assoicated with a set of buffering parameters, which can be signalled as
part of the bitstream. When additional data, e.g. parameter set NAL units as
part of the preamble information, is injected to the video bitstream, the
buffering parameters may be violated. Assuming that an existing
standard-compliant video decoder is integrated as part of the receiver, the
input video bitstream must be a conforming bitstream. However, when the
preamble contains data to be fed to the decoder,  e.g. parameter set NAL
units for an H.264/AVC bitstream, insertion of the data to the video
bitstream may violate the buffering parameters (hence the HRD conformance in
terms of H.264/AVC terminology). One potential way of solving this problem
is to use the way you described for processing the preamble information from
the transport level, i.e. not adding the data to the bitstream, but rather
the separate software module parses the information and derives relevant
varaibles and passes the variables to the video decoder. This way, the
existing video decoder needs to be changed by taking as input also these
derived variables in addition the bitstream. Thus existing video decoder
implementations would need to be modified to be applicable. 

> 
> If the "variables based" way is used, the
> [Sandy] Sorry, I don't understand this at all. What 
> "variables based" way are you referring to? Why do you say 
> existing video decoders cannot be used? I disagree.
> 

See above. 

> [Sandy] Video decoders have some amount of physical buffering 
> capability. The designers of those decoders should design 
> them to work with streams that conform to the applicable 
> standard. Presumably the assumption here is that the video 
> streams that are part of the multicast conform to the 
> applicable video standard, and that fact is not changed by 
> the introduction of a preamble. 
> 

See above. It seems that in your understanding that the premable information
would not contain any data that would be needed by the video decoder. That
is not true, at least for H.264/AVC, for which parameter sets may be
included as part of premable information. 

> What problem are you thinking of?

See above.

BR, YK

> Sent: Thursday, July 29, 2010 8:23 PM
> [Sandy] IMO, the same applies to both drafts. No matter how 
> the preamble is packaged for transmission to the receiver, 
> the receiver needs to parse the elements and manage the 
> timing of processing each element in turn. The timing of 
> operations in the receiver is critically important if we 
> expect to get any benefit from the preamble.
> 
> [Sandy] You made the statement that the MPEG transport 
> processor needs to be changed. I don't agree, at least not 
> for our MPEG transport processors; I can't speak for everyone 
> else's. In many, if not most or even all, transport 
> processors, there is significant software involvement, and 
> they are not completely hard-wired. And if they were 
> completely hard-wired, I doubt that either approach would 
> work for robust systems. I strongly disagree with the 
> assertion that existing implementations cannot be used. 
> 
> [Sandy] Sorry, I don't understand this at all. What 
> "variables based" way are you referring to? Why do you say 
> existing video decoders cannot be used? I disagree.
> 
> [Sandy] Video decoders have some amount of physical buffering 
> capability. The designers of those decoders should design 
> them to work with streams that conform to the applicable 
> standard. Presumably the assumption here is that the video 
> streams that are part of the multicast conform to the 
> applicable video standard, and that fact is not changed by 
> the introduction of a preamble. 
>

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 30 Jul 2010 08:34:44 +0200

Hi Keith,

It would have been helpful if your request for WG input would have been
circulated just a bit earlier than 19:39 the day before our session.

I agree that there is insufficient information, at least for me, to come to
a conclusion based on the technical information received so far.  Obviously,
something broke loose after yesterday's session; see the overnight emails
from Sandy and Ye-Kui.  Still, it's not enough.

As for a proposal for the way forward:

I continue to believe that the implementation/testing/deployment effort for
a solution requiring support of both technologies is only marginally bigger
than of a single solution, whichever of the two may be chosen.  That is,
because the amount of technology in the two proposals is only a small
fraction of the technologies of the environment that need to be considered.

Further, I believe that the different business strategies of the two
proponent companies obviously make both solutions viable, at least for their
respective business.  It should not be up to the IETF to endorse one
business strategy over the other, unless there is a clear technical
advantage.

Also, to me, there are enough uncertainties in the environment to call for
as much flexibility in the technology as possible--as long as
interoperability can be preserved, but independent from implementation
effort, as long as such effort stays within reason.

Finally, intense lobbying is going on, favors are called in, and so on.  I
hate seeing decisions being made based in such an environment, though I
certainly would agree that this is by no means the first time in the
IETF--or any other organization, for that matter :-)  In his case, the
situation is particularly bad and unbalanced, due to the personalities
involved.  That makes me rally to the defense of the party I perceive weaker
in this lobbying effort.

All this continues to lead me to the conclusion that a requirement for the
interoperable use of either solution would be best.  Proposals for this have
been made.

Therefore, here my suggestion for a decision tree:

Q.1: does AVT insist on a single solution involving only a single proposal?
If yes, go to Q.2; if no, go to Q.6.

Q.2: does AVT have enough info to make a decision now?  If yes, go to Q.3,
if no, go to Q.4 and Q.5

Q.3: Cisco or Huawei?

Q.4: Should the decision between proposals be limited to the two on the
table?

Q.5: Formal shootout, pseudo-random selection, or request for additional
info with the understanding that the subject could drag on for another
meeting cycle?

Q.6 One, two, or three documents?  (One: a single document, involving both
proposals and the decision mechanism between the two.  Two: both proposals
in their own RFC, each containing essentially the same information on the
decision mechanism between the two.  Three: both proposals in their own RFC.
Another RFC (probably authored by a third party) documenting the decision
mechanism.

Regards,
Stephan

P.s.: in the interest of full disclosure: I have no commercial ties to
either proposal or proponent company, have no, and do not plan to work on,
an MPEG-2 TS based system, have friends in both companies, and my main
interest would be to see MPEG-2 TS die the painful, but quick death it
deserves...  

On 7.29.2010 19:39 , "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> 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.
> 
> convinced that we have significantly advanced this discussion since the end of
> the Hiroshima meeting, and certainly none since the Anaheim meeting. The goal
> of any further discussion needs to be in aid of convincing the working group
> of which direction they want to go. At the moment I am unconvinced that
> further material is going to appear. In the absence of further input, I
> believe we just need to call the question, and if people end up deciding
> because they prefer the red coloured one to the blue coloured one, then so be
> it.
> 
> So, if I allow discussion in this direction to continue, then I want to see
> clear proposals on how that discussion should be structured, and the purpose
> to be achieved by that conversation. I would like to see this input rapidly -
> think about doing this before the session starts tomorrow.
> 
> At the moment I am not convinced that a formal assessment process (e.g. as
> proposed by Stefan at the last meeting and in the ad-hoc) is going to come up
> with a set of assessments that are doable in some independent test bench, nor
> am I convinced that such a set of tests will tell us anything about
> performance or scaling, which I currently believe we need to address. If you
> believe this is viable, then please also send me some mail on it, with some
> persuasive words.
> 
> I am concerned also that further delay may just automatically assume there are
> two solutions in the market place, and therefore if there is a service we
> should be doing to the IETF community, then we will not have done it.
> 
> 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

---

From: Roni Even <[email-masked]>
Date: Fri, 30 Jul 2010 09:35:22 +0300

Hi Sandy,
See inline
Roni

> 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.

You are right about one solution but only in some kind of world where there
is one manufacturer who decide. I think the English word for it is monopoly.
As for counting on servers - this is what standard is about, you have to
comply with the mandatory requirement. 

> 
> 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.

So you are talking about specific pre/post processing. Currently none of the
drafts discuss it. Both give only the simple case (section 7 of begen draft
and 6 of xia draft)

> 
> 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.

My understanding that both solutions can support it but none of them specify
it.

> 
> 4. For a general receiver solution, the receiver needs to parse and
> 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.

I would like to assume that what you are saying here is true for the regular
MPEG2-TS even without preamble since what you are saying is that the
receivers can not always process any MPEG2TS stream. My understanding that
both drafts authors acknowledged that post processing may be needed and in
my view this can be done but is not specified in the drafts. If you need
post processing for regular MPEG2TS stream so the receiver can do it in the
xia draft case.

> 
> 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.

The specific, not simple post processing is not specified and I am not sure
why you think that starting from TLV and not from TS packets is simpler. We
are talking about what I think is one RTP packet in most cases or maybe two
if the EMS is big.

> 
> 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.

I am not sure about it since in the case of the MPEG-TS the order is defined
and it is only a subset of the full MPEG-TS. I also mentioned earlier that I
would think that if post processing is required then it is required also for
non preamble case so the receiver need to address post processing on MPEG2TS
anyhow

> while either could be made to work.
See my comments above

> 
> 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
> 
> 
> opinion.

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 30 Jul 2010 01:43:36 -0500

I suggest that we focus on the technical merit of each solution. I, for
one, have not pulled in any favors - nor do I plan to do so.

There is a distinct difference in the proposals, and we should adhere to
the intent of the IETF and evaluate them on their technical merits
without regard for company affiliations. I am trying to keep an open
mind, and will continue to do so.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Friday, July 30, 2010 8:35 AM
To: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [AVT] MPEG2TS preamble - where next

Hi Keith,

I agree that there is insufficient information, at least for me, to come
to
a conclusion based on the technical information received so far.
Obviously,
something broke loose after yesterday's session; see the overnight
emails
from Sandy and Ye-Kui.  Still, it's not enough.

I continue to believe that the implementation/testing/deployment effort
for
a solution requiring support of both technologies is only marginally
bigger
than of a single solution, whichever of the two may be chosen.  That is,
because the amount of technology in the two proposals is only a small
fraction of the technologies of the environment that need to be
considered.

Further, I believe that the different business strategies of the two
proponent companies obviously make both solutions viable, at least for
their
respective business.  It should not be up to the IETF to endorse one
business strategy over the other, unless there is a clear technical
advantage.

Also, to me, there are enough uncertainties in the environment to call
for
as much flexibility in the technology as possible--as long as
interoperability can be preserved, but independent from implementation
effort, as long as such effort stays within reason.

Finally, intense lobbying is going on, favors are called in, and so on.
I
hate seeing decisions being made based in such an environment, though I
certainly would agree that this is by no means the first time in the
IETF--or any other organization, for that matter :-)  In his case, the
situation is particularly bad and unbalanced, due to the personalities
involved.  That makes me rally to the defense of the party I perceive
weaker
in this lobbying effort.

All this continues to lead me to the conclusion that a requirement for
the
interoperable use of either solution would be best.  Proposals for this
have
been made.

Q.1: does AVT insist on a single solution involving only a single
proposal?
If yes, go to Q.2; if no, go to Q.6.

Q.2: does AVT have enough info to make a decision now?  If yes, go to
Q.3,
if no, go to Q.4 and Q.5

Q.3: Cisco or Huawei?

Q.6 One, two, or three documents?  (One: a single document, involving
both
proposals and the decision mechanism between the two.  Two: both
proposals
in their own RFC, each containing essentially the same information on
the
decision mechanism between the two.  Three: both proposals in their own
RFC.
Another RFC (probably authored by a third party) documenting the
decision
mechanism.

Regards,
Stephan

P.s.: in the interest of full disclosure: I have no commercial ties to
either proposal or proponent company, have no, and do not plan to work
on,
an MPEG-2 TS based system, have friends in both companies, and my main
interest would be to see MPEG-2 TS die the painful, but quick death it
deserves...  

On 7.29.2010 19:39 , "DRAGE, Keith (Keith)"
<[email-masked]>

> concensus for documenting two solutions, whether that was in a single
RFC or
there are
> Outside of the two author groups, I am looking for members of the
working

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 30 Jul 2010 02:06:09 -0500

An approach in which the server makes client-specific changes to the pre-amble would only work (in a scalable manner) for systems with a very small number of receiver types and a very small number of stream types. 

However, an operator receives content from a wide variety of sources. The receiver population typically consists of a variety of devices, with a variety of chipsets. Each of the combination of stream/receiver may have its own set of timing and buffer size constraints. If the server is burdened with making device-specific pre-ambles for every permutation of stream type and receiver type, the problem space quickly becomes very complex.

A simpler approach is to have the server send the required data to the client, and have the device-specific manipulations happen on the client. This is the intent of the TLV mechanism.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui Wang
Sent: Friday, July 30, 2010 12:07 AM
To: 'Sandy (Alexander) MacInnis'; 'Peilin YANG'
Cc: [email-masked]
Subject: Re: [AVT] MPEG2TS preamble - where next

BR, YK

---

From: Eric Friedrich <[email-masked]>
Date: Fri, 30 Jul 2010 08:44:55 -0400

> Question to authors of the TLV draft: is this the way in the open- 

Yes-
   The open source implementation provides two methods for accessing  
the preamble data. The first option is to decode into TS packets. The  
second option is to provide callback functions that are called upon  
decoding the PAT, PMT, etc.. These callbacks are passed the PSI data  
as an argument. It is the system integrator's decision of which  
approach to use. If you'd like to take a look, the relevant code is in  
the mp_tlv.h and mp_tlv_decode.h files

--Eric

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 30 Jul 2010 09:01:13 -0400

Strong humm to Sandy, especially 
"The preferred way to process the preamble, at least in my view, is to parse the preamble and keep the relevant variables in software, and have software set up the transport processing to prepare it to receive the start of the video. That's how I'd do it. If the preamble spec were TLV based, I would not convert it to TS packets! If the preamble were in TS packets, I'd parse them and extract the relevant fields, and then perform the initialization processing in software."

I would go further assert if folks think that making TS packets is what has to be done for TLV - perhaps that is a root misunderstanding.

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 Sandy (Alexander) MacInnis
Sent: Thursday, July 29, 2010 6:43 PM
To: Ye-Kui Wang; 'Peilin YANG'
Cc: [email-masked]
Subject: Re: [AVT] MPEG2TS preamble - where next

--Sandy

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]]
Sent: Thursday, July 29, 2010 3:07 PM
To: Sandy (Alexander) MacInnis; 'Peilin YANG'
Cc: [email-masked]
Subject: RE: [AVT] MPEG2TS preamble - where next

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 30 Jul 2010 10:07:59 -0400

> I would go further assert if folks think that making TS 
> packets is what has to be done for TLV - perhaps that is a 
> root misunderstanding.

Please note, as Eric said,  the open source implementation provides both methods, and making TS packets is the first one. The draft is silent about this (AFAIK). Also, your comment would be more valuable if you take into the entire context (herein the entire discussion so far between Andy and myself), rather than just jumping into one mid-point. 

BR, YK

> Behalf Of Allison, Art
> Sent: Friday, July 30, 2010 9:01 AM
> To: [email-masked]
> "The preferred way to process the preamble, at least in my 
> and then perform the initialization processing in software."
> 
> I would go further assert if folks think that making TS 
> packets is what has to be done for TLV - perhaps that is a 
> root misunderstanding.
> 
> Art
> Art Allison
> TS buffering
> preamble packets
> the preamble
> However, if

---

From: Eric Friedrich <[email-masked]>
Date: Fri, 30 Jul 2010 10:18:13 -0400

YK-
    I didn't mean to place any implicit ordering or preference on the  
options in my earlier email. Customers are presented with both choices  
when they perform the integration, it is up to them which to choose  
depending on their STB architecture. We've personally seen from our  
internal use that the callback (non-TS packet) method works better.  
The TS packet method requires some additional work to meet hardware  
timing requirements. Specifically, it takes some amount of time to  
program the demux hardware, during which some vital premable data may  
be missed. One possible solution in our open source implementation is  
to repeat and/or delay the preamble TS packets.

Thanks,
Eric

On Jul 30, 2010, at 10:07 AM, Ye-Kui Wang wrote:

> Please note, as Eric said,  the open source implementation provides  
> both methods, and making TS packets is the first one. The draft is  
> silent about this (AFAIK). Also, your comment would be more valuable  
> if you take into the entire context (herein the entire discussion so  
> far between Andy and myself), rather than just jumping into one mid- 
> point.
>
> BR, YK
>
>> buffering

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 30 Jul 2010 10:23:04 -0400

Mr. Wang,

I have found that when folks start suggesting how others should craft their contributions, little productive discourse occurs thereafter. 

Art Allison

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Friday, July 30, 2010 10:08 AM
To: Allison, Art; [email-masked]
Subject: RE: [AVT] MPEG2TS preamble - where next

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 30 Jul 2010 10:35:18 -0400

Eric,

OK. Thanks for the clarification.

BR, YK 

> From: Eric Friedrich [mailto:[email-masked]] 
> Sent: Friday, July 30, 2010 10:18 AM
> To: Ye-Kui Wang
> Cc: 'Allison, Art'; [email-masked]
>     I didn't mean to place any implicit ordering or 
> preference on the options in my earlier email. Customers are 
> presented with both choices when they perform the 
> integration, it is up to them which to choose depending on 
> their STB architecture. We've personally seen from our 
> The TS packet method requires some additional work to meet 
> hardware timing requirements. Specifically, it takes some 
> amount of time to program the demux hardware, during which 
> some vital premable data may be missed. One possible solution 
> in our open source implementation is to repeat and/or delay 
> the preamble TS packets.
> 
> Thanks,
> Eric
> 
> >> I would go further assert if folks think that making TS packets is 
> >> what has to be done for TLV - perhaps that is a root 
> >> misunderstanding.
> >
> >> Allison, Art
> view, is 
> >> to parse the preamble and keep the relevant variables in software, 
> >> and have software set up the transport processing to prepare it to 
> >> receive the start of the video.
> >> That's how I'd do it. If the preamble spec were TLV based, I would 
> >> not convert it to TS packets! If the preamble were in TS 
> packets, I'd 
> >> parse them and extract the relevant fields, and then perform the 
> >> initialization processing in software."
> >>
> >> I would go further assert if folks think that making TS packets is 
> >> what has to be done for TLV - perhaps that is a root 
> >> misunderstanding.
> >>
> >> 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
> >> Ye-Kui, thanks for bringing this up. MPEG-TS STD(*) buffering is 
> >> obviously very important, and it is often overlooked.
> >>
> view, is to 
> >> parse the preamble and keep the relevant variables in 
> software, and 
> >> have software set up the transport processing to prepare it to 
> >> receive the start of the video.
> >> That's how I'd do it. If the preamble spec were TLV based, I would 
> >> not convert it to TS packets! If the preamble were in TS 
> packets, I'd 
> >> parse them and extract the relevant fields, and then perform the 
> >> initialization processing in software.
> chooses. If 
> >> the receiver does, for some reason, choose to convert a 
> TLV preamble 
> >> into TS packets and then feed those TS packets to a transport 
> >> processor, that's a private choice of the designers of 
> that receiver. 
> >> Such a receiver would have no right to complain that the 
> result does 
> >> not conform to the STD buffer model of the MPEG-TS standard if it 
> >> chose to do that.
> >>
> packets, 
> >> and if the resulting combination of preamble and multicast, all 
> >> consisting of TS packets, is claimed to conform to the MPEG-TS 
> >> standard, then there would be an issue with STD 
> conformance, and it 
> >> could potentially be severe.
> >>
> >> might be able to modify the transport stream that it is processing 
> >> and sending to the receivers, such that the STD 
> constraints are met 
> >> by the combination of the multicast stream and each case 
> of preamble 
> >> sent to any RR. However that would appear to be very 
> difficult to do. 
> >> The RS cannot just change the STD parameters to make the stream 
> >> conform - those parameters are in the standard. Changing 
> the relative 
> >> positions of TS packets that carry video, audio, and 
> systems data in 
> >> the multicast, and also the temporal positions of the TS 
> packets that 
> >> carry the preamble, such that the STD constraints are met, would 
> >> appear to be very difficult to do, even if the operation were 
> >> defined. I doubt that it's defined at all, since the preamble is 
> >> separate from the multicast stream, so how would an STD 
> conformance 
> >> test test for conformance of the combination of the 
> multicast stream 
> >> and the preamble? The way the MPEG-TS standard is written, the 
> >> combination would have to be one transport stream in order 
> to able to 
> >> say whether it conformed to the standard or not.
> >>
> >> So, from the perspective of MPEG-TS STD conformance, the 
> TLV approach 
> >> has no effect at all, and the MPEG-TS approach either has 
> no effect 
> >> or else it would appear to be very difficult to make it conform.
> >>
> they relate 
> >> to the MPEG-TS standard, including any effect, or lack of 
> effect, on 
> >> STD conformance.
> >>
> >> --Sandy
> >>
> >> I see one flaw that applies to both approaches. If the MPEG-2 TS 
> >> buffering parameters are optimal, meaning that adding a 
> bit more data 
> >> may result in buffer overflow, then the buffering parameters would 
> >> need to be changed regardless of which of the two approaches is in 
> >> use. If the TS based approach is in use, the TS stream 
> after addition 
> >> of the preamble packets would be non-conforming to the buffering 
> >> parameters anymore.
> >> If the TLV
> >> based approach is in use, after the so-called 
> post-processing, the TS 
> >> stream seen by the TS receiver is non-conforming to the buffering 
> >> parameters anymore.
> >>
> >> buffering parameters such that the TS stream is conforming to the 
> >> signalled buffereing parameters. Of course, this would not be a 
> >> trivial thing to do by the server. In this case, I think 
> the TS based 
> >> approach is clearly better, as there is then no post-processing 
> >> needed at all. Another way to solve the problem is that 
> the receiver 
> >> changes the buffering parameters. This is more difficult 
> than server 
> >> changing the parameters as the receiver cannot access the entire 
> >> stream before the entrie stream is received. I am not sure whether 
> changing of the 
> >> If the original video buffereing parameters are optimal and the 
> >> preamble includes additional data to be fed to the video decoder, 
> >> then the video buffering parameters also need to be changed, 
> >> similarly as above.
> >>
> >> correct, I think both drafts need to clearly describe the 
> problem and 
> >> the solution, to make both approaches complete and to enable the 
> >> group to make a decision.
> >>
> >> BR, YK
> >>
> >>> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >>> Of Sandy (Alexander) MacInnis
> becomes a 
> receive this 
> >>> new format need to have at least some new software. (I say "at 
> >>> least" because they might have to be replaced.) This is true 
> >>> regardless of what kind of preamble is used, or even 
> whether there 
> >>> is any preamble at
> >> all in use.
> >>>
> >>> Do you agree? If not, how do the receivers process 
> formats that were 
> >>> not known and not predictable at the time the receivers were 
> >>> designed and programmed?
> >>>
> >>> formats. It would be nice not to have to update the preamble spec 
> >>> itself, but that does not appear to make a difference to 
> whether the 
> >>> receivers would need to be updated when new multicast 
> formats need 
> >>> to be supported. Whether one or the other preamble format choice 
> >>> would result in more or less work to update receivers in 
> the future, 
> >>> I can't predict, since by definition we can't predict what the 
> >>> future PSI or CODEC changes might be.
> >>>
> >>> --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.
> 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
> >>>
> >>>
> >>> ----- 原邮件 -----
> >>>> of them are. In addition to all of the external specs that have 
> >>>> been discussed recently, it's a good assumption that not all 
> >>>> there are all sorts of potential issues with ordering 
> and timing of 
> >>>> MPEG-TS packets in the streams the RS is processing, and these 
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>> ensure the receiver can process the preamble, and 
> benefit from it, 
> >>>> without any preamble-specific processing in the 
> receiver, then the 
> >>>> 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.
> >>>>

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 30 Jul 2010 10:38:54 -0400

Mr. Allison,

Simply saying "I like A over B" without any detail is the least productive thing I can see. I like those discussions like Sandy's even though we have different opinions. 

--
Ye-Kui Wang
Standards Manager - Multimedia
Core Network Research Department
Huawei Technologies (USA)
400 Somerset Corp Blvd, Suite 602
Bridgewater, NJ 08807, USA
Tel: 908-541-3518
Cell: 908-803-3888
Fax: 908-927-0698

> Sent: Friday, July 30, 2010 10:23 AM
> To: [email-masked]
> I have found that when folks start suggesting how others 
> should craft their contributions, little productive discourse 
> occurs thereafter. 
> 
> 
> Art Allison
> Please note, as Eric said,  the open source implementation 
> provides both methods, and making TS packets is the first 
> one. The draft is silent about this (AFAIK). Also, your 
> comment would be more valuable if you take into the entire 
> context (herein the entire discussion so far between Andy and 
> myself), rather than just jumping into one mid-point. 
> 
> BR, YK
> 
> > post-processing, the TS stream
> > problem and the
> point out