Subject: [AVT] meog2-ts preamble - question about begen draft

From: Roni Even <[email-masked]>
Date: Wed, 24 Mar 2010 21:26:35 +0200

Hi guys,

I am curious if on the server side the MPEG2-TS preamble information is to
TOLV when it is extracted from the primary multicast stream continuously
even when no need to send it as a burst or is it cached as MPEG2-TS packets
and converted to TOLV only when there is a need to send a burst.

Roni Even

As individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 24 Mar 2010 12:43:53 -0700

I guess this is up to the implementation. For popular channels, it could
be prepared beforehand, for less popular ones, it could be prepared upon
receiving the first request, and cached for the later requests.

-acbegen 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
> Sent: Wednesday, March 24, 2010 12:27 PM
> To: [email-masked]
> Subject: [AVT] meog2-ts preamble - question about begen draft
> 
> Hi guys,
> 
> I am curious if on the server side the MPEG2-TS preamble information
is to TOLV when it is extracted
> from the primary multicast stream continuously even when no need to
send it as a burst or is it cached
> as MPEG2-TS packets and converted to TOLV only when there is a need to
send a burst.

---

From: Eric Friedrich <[email-masked]>
Date: Wed, 24 Mar 2010 15:56:52 -0400

Roni-
    We actually do it both ways for a given preamble. Some subset of  
all TOLVs is created is the stream is parsed, while some others are  
created only in response to a RAMS request (and even cached for  
repeated use). This is pretty implementation specific and our method  
maximizes performance for our particular implementation.

--Eric

On Mar 24, 2010, at 3:43 PM, Ali C. Begen (abegen) wrote:

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

---

From: Roni Even <[email-masked]>
Date: Wed, 24 Mar 2010 22:45:27 +0200

Hi,
So can I understand that the effort to convert from Mpeg2-TS to TOLV is not
an issue
Roni

> From: Eric Friedrich [mailto:[email-masked]]
> Sent: Wednesday, March 24, 2010 9:57 PM
> To: Ali C. Begen (abegen)
> Cc: Roni Even; [email-masked]
> Subject: Re: [AVT] meog2-ts preamble - question about begen draft
> 
> Roni-

---

From: David R Oran <[email-masked]>
Date: Wed, 24 Mar 2010 16:56:14 -0400

> So can I understand that the effort to convert from Mpeg2-TS to TOLV is not
I'd be careful here - there's "MPEG2" and then there's "TS" It is true that the basic data encoding is MPEG2 188byte cells, and some of them are SI, some are ECM, etc. BUT what our server implementation does is extract the underlying data (essentially particular pieces from the relevant elementary streams) from the incoming multiplex and stash them away, along with a bunch of other meta-data concerned with cache window boundaries and how they align with GOPs, etc. So, by the time the code is done doing the parse of the incoming stream, the stuff we axtract doesn't look much like an MPEG2TS.

So, we'd have to actually *construct* a transport stream multiplex from scratch, and do so in a way that stitches back into the TS that will carry the burst on the unicast session.

What *STILL* doesn't seem to be sinkng in is that from our point of view it is not useful to try to mess with the incoming MPEG2TS, pull stuff out of it, adjust various pieces of it (e.g. PCRs) and then send it out in a way that abuts properly with the GOP that starts the burst.

So, yes, it IS an issue since what we do is nothing like "convert from Mpeg2-TS to TOLV".

Cheers, DaveO.

---

From: Roni Even <[email-masked]>
Date: Wed, 24 Mar 2010 23:28:24 +0200

David,
None of the proposal is doing what you described. 
So the begen solution is to take the PSI packets on the Server convert to
TOLVs and use the TOLVs on the receiver to build an MPEG2-TS stream that
take into account the specific demultiplxer/decoder on the client. The
overhead is not critical so it does not care whether to do it on all PSI
preamble information or only when needed.
The Xia draft keeps the MPEG2-TS without change and send it to the receiver.
The receiver has the option to feed it as is to demultiplexers/decoders that
can process it as is or to do post processing. If preprocessing is needed
then hypothetically the receiver can convert the PSI to TOLV since there is
not much overhead and then you can post process like in begen draft. Of
course you do not need to change to TOLV which will require even less
overhead
Roni  

> From: David R Oran [mailto:[email-masked]]
> Sent: Wednesday, March 24, 2010 10:56 PM
> To: Roni Even
> Cc: 'Eric Friedrich'; 'Ali C. Begen (abegen)'; [email-masked]
> I'd be careful here - there's "MPEG2" and then there's "TS" It is true
> that the basic data encoding is MPEG2 188byte cells, and some of them
> are SI, some are ECM, etc. BUT what our server implementation does is
> extract the underlying data (essentially particular pieces from the
> relevant elementary streams) from the incoming multiplex and stash them
> away, along with a bunch of other meta-data concerned with cache window
> boundaries and how they align with GOPs, etc. So, by the time the code
> is done doing the parse of the incoming stream, the stuff we axtract
> doesn't look much like an MPEG2TS.
> 
> So, we'd have to actually *construct* a transport stream multiplex from
> scratch, and do so in a way that stitches back into the TS that will
> carry the burst on the unicast session.
> 
> What *STILL* doesn't seem to be sinkng in is that from our point of
> view it is not useful to try to mess with the incoming MPEG2TS, pull
> stuff out of it, adjust various pieces of it (e.g. PCRs) and then send
> it out in a way that abuts properly with the GOP that starts the burst.
> 
> >>>> as MPEG2-TS packets and converted to TOLV only when there is a
> need
> >>>> to
> >>> send a burst.
> >>>>
> >>>>
> >>>>
> >>>> Roni Even
> >>>>
> >>>> As individual
> >>>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 24 Mar 2010 16:38:26 -0500

"without change" is the key phrase. When you cherry-pick elements of a
valid MPEG2TS stream and send them piece-meal, it is not clear that the
resultant bitstream is compliant with MPEG2TS. 

Given an example of such a bitstream, we should be able to tell.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Wednesday, March 24, 2010 2:28 PM
To: Dave Oran (oran)
Cc: [email-masked]
Subject: Re: [AVT] meog2-ts preamble - question about begen draft

David,
None of the proposal is doing what you described. 
So the begen solution is to take the PSI packets on the Server convert
to
TOLVs and use the TOLVs on the receiver to build an MPEG2-TS stream that
take into account the specific demultiplxer/decoder on the client. The
overhead is not critical so it does not care whether to do it on all PSI
preamble information or only when needed.
The Xia draft keeps the MPEG2-TS without change and send it to the
receiver.
The receiver has the option to feed it as is to demultiplexers/decoders
that
can process it as is or to do post processing. If preprocessing is
needed
then hypothetically the receiver can convert the PSI to TOLV since there
is
not much overhead and then you can post process like in begen draft. Of
course you do not need to change to TOLV which will require even less
overhead
Roni  

> >>> be prepared beforehand, for less popular ones, it could be
prepared
> >>> upon
> >>>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >> Of

---

From: Peilin YANG <[email-masked]>
Date: Thu, 25 Mar 2010 07:01:28 +0800

Dear Bill,

In Xia draft the solution is clear for that. You can get it from the example of the draft. The preamble information is compliant with MPEG2-TS.

Best Regards,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期四, 三月 25日, 2010 上午5:38
主题: Re: [AVT] meog2-ts preamble - question about begen draft
收件人: Roni Even <[email-masked]>, "Dave Oran (oran)" <[email-masked]>
抄送: [email-masked]

> The receiver has the option to feed it as is to 
> demultiplexers/decodersthat
> then hypothetically the receiver can convert the PSI to TOLV since 
> thereis
> > > So can I understand that the effort to convert from Mpeg2-TS 
> to TOLV
> > is not
> > > an issue
> > that the basic data encoding is MPEG2 188byte cells, and some of 
> them> are SI, some are ECM, etc. BUT what our server 
> implementation does is
> > So, yes, it IS an issue since what we do is nothing like 
> "convert from
> > Mpeg2-TS to TOLV".
> > 
> > Cheers, DaveO.
> > 
> > > Roni
> > >
> > >>> I guess this is up to the implementation. For popular 
> channels, it
> > >>> could
> > >>>> from the primary multicast stream continuously even when no 
> need> to