[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