Subject: Re: [AVT] On the TS Preamble issue

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 24 Mar 2010 18:00:49 +0100

Hi

and thanks for the response. I guess the numeric examples you give below iw with some bitrate in mind. This can change abit depending on maxMTU and media bitrate. For instance if one imagine a larger MTU and high definition TV, would not the extra unecessary overhead incraese then. Not sur if it is a big issue though.

Regardless of this, one alternative is to just send only the useful info (PAT, PMT...) in one packet. It is told that some STB may break due to eg timing issues but is not the risk equally big with your proposed scheme ? 

Are we talking about solving an issue for legacy STBs ?, what is the chance that these STBs will be used with fast channel change technology ?

/Ingemar

> -----Original Message-----
> From: Peilin YANG [mailto:[email-masked]] 
> Sent: den 24 mars 2010 09:17
> To: Ingemar Johansson S
> Cc: [email-masked]; DRAGE Keith; Roni Even
> Subject: Re:On the TS Preamble issue
> 
> Hi Ingemar, 
> 
> Thank you very much for analyzing two drafts. Pleaase see inline.
> 
> Peilin
> 
> 
> ----- 原邮件 -----
> 发件人: Ingemar Johansson S <[email-masked]>
> 日期: 星期三, 三月 24日, 2010 上午8:49
> 主题: On the TS Preamble issue
> 收件人: "[email-masked]" <[email-masked]>
> 抄送: "Ali C. Begen (abegen)" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> 
> Hi
> 
> I have tried to follow (with limited knowledge about MPEG TS) 
> the debate around the two alternatives to send the preamble 
> to the STBs. 
> As I understand t one simple alterantive is to just collect 
> all the PAT, CAT, PMT and other elements in one packet and 
> send it to the STB. I got it explained that it may work for 
> certain STBs while others might choke. 
> 
> One solution is then to pack the preamble elements with care 
> and send them to the STBs where they are unpacked 
> (draft-begen-avt-rtp-mpeg2ts-preamble-04). My question is 
> then, if the STBs need to be upgraded to handle the nw 
> format, why not upgrade them to handle the simple format ?. I 
> believe I miss some important piece of information here 
> (complexity, memory ?)
> 
> As regards to draft-xia-avt-mpeg2ts-preamble alternative, I 
> am unclear of how much extra overhead in terms of unecessary 
> data that is sent with the retransmission packets just to 
> update the STB with the necessary preamble, from an engineers 
> point of view it seems to me a bit awkward to e.g send 
> 1000bytes of data for 10bytes of useful information (numbers 
> are just wild guesswork from my side).
> 
> Peilin: I am sure that there is no such exaggerated extra 
> overhead(sending 1000bytes of data for 10bytes of useful 
> information). Commonly the preamble information can be sent 
> in one RTP packet. The extra information focus on PAT, PMT 
> and PCR TS packets(totally including 3*188 = 564bytes), and 
> its useful information is approximate 200bytes. If there are 
> two TS packets for ECM/EMM. Total inforamtion is about 
> 940(5*188)bytes. The useful inform
> 
> ation is about 576(200+2*188)bytes.  
> 
> Regards
> /Ingemar
> =================================
> INGEMAR JOHANSSON  M.Sc. 
> Senior Research Engineer 
> 
>  
>  
> 
>

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ingemar Johansson S
> Sent: Wednesday, March 24, 2010 10:01 AM
> To: Peilin YANG
> Cc: [email-masked]; Roni Even
> Subject: Re: [AVT] On the TS Preamble issue
> 
> Hi
> 
> and thanks for the response. I guess the numeric examples you give
below iw with some bitrate in mind.
> This can change abit depending on maxMTU and media bitrate. For
instance if one imagine a larger MTU
> and high definition TV, would not the extra unecessary overhead
incraese then. Not sur if it is a big
> issue though.

Yep, MTU size is a variable. So, we should strive to produce the minimum
size of payload to minimize the chances of preamble fragmentation.
 
> Regardless of this, one alternative is to just send only the useful
info (PAT, PMT...) in one packet.
> It is told that some STB may break due to eg timing issues but is not
the risk equally big with your
> proposed scheme ?
> 
> Are we talking about solving an issue for legacy STBs ?, what is the
chance that these STBs will be
> used with fast channel change technology ?

Fast channel change (RAMS) is something added in the RTP layer and the
demux/decoder chipset side remains pretty untouched. We do whatever we
can do at the RTP side to make the demux/decoder side as happy (and
fast) as possible. It is easier to update/revise the code for the
RAMS/preamble part since it is a software revision, whereas the certain
decoder chipset functionality cannot be changed w/o the hardware
upgrades. So, we need to live with their existing restrictions.

-acbegen