Subject: [AVT] MPEG2 preamble - are there other solutions out there

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Mar 2010 17:52:29 +0100

(As WG co-chair)

This is just a catch all set of questions (to which in general I will assume the answer is a definitive NO to all of these unless I see a practical response).

1)	We have two solutions on the table. Given that we have had six months with a known issue to solve, and noone has come up with a third solution, I am assuming that there is not a third solution someone thinks is better than the other two already proposed. If you know different, then please make clear on list what you think that solution should be (you are too late to write an i-d). Is there a third solution waiting in the wings?

2)	I am currently assuming that the two solutions are mutually exclusive, i.e. that there is no compromise of taking the best of each solution and making a third solution. If you know better then also let us know. Are there any compromise solutions out there?

3)	I am assuming that if we endorsed both solutions, it will essentially mean that we have failed to come to come a consensus and are letting the market decide. Are there any technical advantages of documenting both solutions to the market place?

regards

Keith

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 16 Mar 2010 13:41:10 -0500

Keith-

I am not aware of a third solution, or a good way to combine the
existing proposals into a common solution. However, I am open to such
approaches. 

Currently, the two solutions are quite distinct. IMHO we would be doing
the community a large dis-service if we did not specify a single
solution. 

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Tuesday, March 16, 2010 12:52 PM
To: [email-masked]
Subject: [AVT] MPEG2 preamble - are there other solutions out there

(As WG co-chair)

This is just a catch all set of questions (to which in general I will
assume the answer is a definitive NO to all of these unless I see a
practical response).

1)	We have two solutions on the table. Given that we have had six
months with a known issue to solve, and noone has come up with a third
solution, I am assuming that there is not a third solution someone
thinks is better than the other two already proposed. If you know
different, then please make clear on list what you think that solution
should be (you are too late to write an i-d). Is there a third solution
waiting in the wings?

2)	I am currently assuming that the two solutions are mutually
exclusive, i.e. that there is no compromise of taking the best of each
solution and making a third solution. If you know better then also let
us know. Are there any compromise solutions out there?

3)	I am assuming that if we endorsed both solutions, it will
essentially mean that we have failed to come to come a consensus and are
letting the market decide. Are there any technical advantages of
documenting both solutions to the market place?

regards

Keith
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Mar 2010 06:07:50 -0700

Hi Keith,

1) I have not seen another proposal.
2) Two current solutions are fundamentally different. Not easy to make
both work in a single solution. The first issue to get a consensus on is
whether dumping the preamble to the demux reliably works or not in
practice.
3) I'd prefer AVT produced a single solution.

-acbegen

> Sent: Tuesday, March 16, 2010 9:52 AM
> To: [email-masked]
> essentially mean that we have failed to come to come a consensus and
> are letting the market decide. Are there any technical advantages of

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 17:48:45 +0200

Keith,
My input as individual

1. Did not see any other proposal.
2. The difference is in the packaging
3. I think that if we cannot reach an agreement between the two proposal it
will require us to do decide if the RS or receiver need to support both. If
the RS supports both the Receiver can ask one way in the RAMS-R if the
receiver supports both the RS can use either.

Roni Even

> Sent: Tuesday, March 16, 2010 6:52 PM
> To: [email-masked]

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Mar 2010 17:48:45 +0200

Hi Ali,
Inline
Roni Even
As Individual

> Ali C. Begen (abegen)
> Sent: Wednesday, March 17, 2010 3:08 PM
> To: DRAGE, Keith (Keith); [email-masked]
> Subject: Re: [AVT] MPEG2 preamble - are there other solutions out there
> 
> Hi Keith,
> 
Yes
> whether dumping the preamble to the demux reliably works or not in

I think that the first issue is if we are designing a solution for a
conforming codec and not for what was done in specific implementation. The
issue of non conforming implementations is not related only to preamble it
is a general problem of MPEG2TS construction.

---

From: David R Oran <[email-masked]>
Date: Wed, 17 Mar 2010 12:01:05 -0400

> is a general problem of MPEG2TS construction.
As I mentioned in my email earlier today, I think the situation is a bit more subtle than "conforming". Since this is the IETF and not ISO or ITU, interoperability and real-world applicability trumps conformance in my book.

Cheers, DaveO.

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 17 Mar 2010 17:03:54 +0100

See below
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE Keith
Sent: dinsdag 16 maart 2010 17:52
To: [email-masked]
Subject: [AVT] MPEG2 preamble - are there other solutions out there

(As WG co-chair)

Tom: IMO, there is a third solution, but not one that is more efficient
than the two solutions on the table : just send whatever MPEG2 TS
preamble info that is deemed useful as part of the RAMS burst, i.e.
equipped with RTP retransmission payload headers. Note that these
packets must be transmitted "as is" (but with the retransmission
headers) from the SSM. This hence makes it less efficient compared to
the solutions on the table, but there is no need to specify anything
here. ..Difficult to tell how much less efficient : both premable drafts
suggest that a few RTP packets are needed at most. This may be easily 7
times more with this approach (taking into account that an RTP packet
typically contains 7 TS packets).

Tom: as the two solutions do exactly the same (specify how to transport
efficiently MPEG2 TS preamble information) , and there is even a third
non-optimised solution, it is really not a favour to the community to
specify both! 

regards

Keith

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 17 Mar 2010 14:39:50 -0400

FWIW, my two cents:

Re 1: I'm not aware of a third solution to the problem stated.

Re 2: It would, IMHO, be possible to create a merged proposal that required
clients to accept and interpret both methods.  Serves can do whatever they
want.  Be conservative what you send, and liberal what you accept.

Re 3: I would advocate a merged solution to be begin with, in the above
sense.  If that's not acceptable, yes, I believe that there is a value in
documenting both solutions.

Let me elaborate: Both proponent companies have stated that they have at
least initial operational experience with their respective technologies.
Both companies appear to go ahead full steam with deployment.  Both
proposals appear to have advantages and disadvantages over each other, and
both appear to be better for the consumer than doing nothing.  That all
suggests that the world will see two different technical solutions anyway.
In such a situation, I don't think it should be the IETF's business to
endorse one solution, and dismiss the other.  Especially not considering
constellation of the 800 pound IETF-gorilla and the 15 pound IETF-macaque
that are involved here.

Stephan 

On 3.16.2010 09:52 , "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> (As WG co-chair)
> 
> This is just a catch all set of questions (to which in general I will assume
> the answer is a definitive NO to all of these unless I see a practical
> response).
> 
> 1) We have two solutions on the table. Given that we have had six months with
> a known issue to solve, and noone has come up with a third solution, I am
> assuming that there is not a third solution someone thinks is better than the
> other two already proposed. If you know different, then please make clear on
> list what you think that solution should be (you are too late to write an
> i-d). Is there a third solution waiting in the wings?
> 
> 2) I am currently assuming that the two solutions are mutually exclusive, i.e.
> that there is no compromise of taking the best of each solution and making a
> third solution. If you know better then also let us know. Are there any
> compromise solutions out there?
> 
> 3) I am assuming that if we endorsed both solutions, it will essentially mean
> that we have failed to come to come a consensus and are letting the market
> decide. Are there any technical advantages of documenting both solutions to
> the market place?
> 
> regards
> 
> Keith

---

From: stephen botzko <[email-masked]>
Date: Mon, 22 Mar 2010 15:16:53 -0700

+1

Stephen Botzko

On Wed, Mar 17, 2010 at 11:39 AM, Stephan Wenger <[email-masked]> wrote:

> assume