Re: MPE Question

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Indeed the MPE specification *DOES* allow section packing as an option. Not
all drivers/implementations permit this.

Conversely, in ULE *ALL* compliant drivers MUST support it.

Gorry Fairhurst

On 28/4/05 6:42 am, "nurul" <azila@nrg.cs.usm.my> wrote:

> Hi,
> 
> Do MPE allows packing? cause as far as i concern it's only allow padding
> while ULE allows both. Correct me if i'm wrong.
> 
> regards,
> nurul
> 
> On Thu, 2005-04-28 at 13:22, Bernhard Collini-Nocker wrote:
>> Siva Veerepalli wrote:
>>> A couple of questions about MPE-FEC framing.
>>> 
>>> 1. The interim IP datacast standard A079 (meant to
>>> facilitate DVB-H trials) specifies that only one
>>> datagram should be used per MPE section i.e., no
>>> fragmentation of IP datagram over multiple MPE
>>> sections. However, the DVB Databroadcast specification
>>> allows fragmentation of the IP datagram over multiple
>>> sections. Does anyone know what the usual practice is?
>> 
>> In order to reduce encapsulation overhead, section packing is used, i.e.
>> if the (remainder of an) IP packet does not fit exactly in a TS packet a
>> subsequent IP packet may start in that TS packet as well.
>> In order to reduce jitter and latency, section packing is not used.
>> 
>> You can find both on existing services.
>> 
>>> Do the final DVB/IP datacast standards specify this
>>> for DVB-H?
>> 
>> The difficulty with section peckaing on the transmit side is that the
>> encapsulator needs to wait for subsequent IP packets to fill an
>> partially filled TS packet and therefor has typically a time-out
>> associated to that waiting, ie before flushing the buffer and
>> transmitting the final TS packet.
>> 
>>> 2. The MPE section has optional stuffing bytes at the
>>> end of the section. Are these used? If yes, for what?
>> 
>> Whenver an IP packets leaves "enough" space in the last TS packet
>> another IP packet could be inserted. If not wanted or needed, stuffing
>> takes care that the empty space is filled up with pattern 0xFF.
>> 
>>> thanks,
>>> Siva
>>> 
>>> 
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>> 
>> 
>