[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How does MPE handle the last byte?



Based on this thread, I'm going to propose that we change the end-indicator
marker in ULE to be OxFFFF. This harmonises it with the "enc" draft, and
also with MPE and otehr MPEG-2 usage. Has anyone any objections?

Gorry

See in-line, for a more detailed response.

Patrick Cipiere wrote:
> 
> alain.ritoux@6wind.com wrote (>):
> 
> > To keep in sync whith what is done in the DVB world, maybe the
> > ULE-method should force padding & stuffing to be done also with 0xff,
> > (as in the ENC-Method).
> 
> Yes, we should definitely be conformant with existing standards.
> This one is not DVB but ISO/IEC 13818-1 (mpeg2)
> 
Agreed, so we should conform (as best we can) with this, and the way it
is used by thoses standards that build on it.

> > To have it simple, maybe then, in the ULE, the end-indicator should
> > be set to 0xffff (instead of 0x0000), which of course would forbid SNDU
> > with such a length field, but is it a big deal ?
> 
> In the ISO/IEC 13818-1 and DVB standards, the unused bits/bytes are
> most of the times (always?) set to 1 (0xff for bytes), so i guess we
> should keep that.
> 

Yes, I'd be happy for that, if people think this is better. It's slightly
harder to implement - but I guess that's not really an issue.  It also
prevents having a datagram of size "0xFFFF" - I don't see that as a 
problem.... if anyone does then please do say.

One other positive point is that it would "fix" one difference between
the 
two encpasulation formats.

> In ISO/IEC 13818-1 it is not said that a 0xff byte marks the end
> of a payload, but when a payload ends the stuffing bytes should
> (must?) be 0xff. The end of the payload is known by the upper layer: section
> (MPE being one of the numerous sections available: datagram section)
> 
> So if in the ULE, `end-indicator' is a marker, 0xffff might not be the
> right choice, 0x0000 would look more natural.

That was the original rationale, if I recall correctly.

> Anyway, i do not see the reason why we need an `end-indicator' marker.
> Like MPE, the SNDUs carry a length information which is enough for
> this layer to extract the information from the mpeg2 layer.
> 
> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com