In the MPG transport stream packet definition
the MPG header format is defined. There is an explicit exception for the
PUSI bit which the standard does not define for private data (in this context
I guess ULE must be considered private). All other fields are defined either
independent of the payload type. I interpret this to say that we are not
free to redefine the use of the adaptation field for a new payload type,
and that adaptation fields may be inserted at lower layers (seen from the
MPG layer the payload is only a stream of octets, possibly including synchronisation
points as signalld by PUSI).
Note again that we are not interested
in enforcing the use of the adaptation field in other systems. We only
want to ensure that ULE can be used on systems which use the adaptation
field.
--Tor
"HDClausen" <clausen@cosy.sbg.ac.at> Sent by: owner-ip-dvb@erg.abdn.ac.uk
14.04.2004 21:45
Please respond to
ip-dvb@erg.abdn.ac.uk
To
<ip-dvb@erg.abdn.ac.uk>
cc
Subject
Re: Adaptation field use
in ULE / MPG2-TS specification
> Explicitly
> prohibiting this in the ULE specification seems to be in violation
> the MPG2 specification (i.e. ISO/IEC-13818-1).
Could you, please, indicate where in the decument I can find this.
Art Allison wrote: "Only PES or PSI structures are standardized for
carriage
by 13838-1 in
MPEG-2 TS packets." If that is the case (and this is what I understood
from
the document) than any other use is not in violation with MPEG-2 but with
something else i.e. the question is: is DVB-RCS imposing a recommendation
which is not (yet) required by MPEG-2.
This does not mean we should not discuss this subject and come up with
a
solution.
--H. Clausen
----- Original Message -----
From: "Tor Brekke" <tor.brekke@nbs.nera.no>
To: <ip-dvb@erg.abdn.ac.uk>
Cc: <ip-dvb@erg.abdn.ac.uk>; <owner-ip-dvb@erg.abdn.ac.uk>
Sent: Wednesday, April 14, 2004 1:01 AM
Subject: Re: Adaptation field use in ULE / MPG2-TS specification
> Want to fill in somewhat to William's detailed answer.
>
> 1) There is a proposal in DVB-RCS to utilise the adaptation
field to
> perform inband signalling for the DVB-RCS network. This signalling
has to
> be independent of the higher layers, as it has to be available before
> these are up (same applies for Ethernet, which may of course not even
be
> present). This was the reason for bringing this up in the first place.
The
> problem is more general though. The adaptation field can be used by
the
> MPG2-TS layer (ref. William's detailed explanation). Explicitly
> prohibiting this in the ULE specification seems to be in violation
with
> the MPG2 specification (i.e. ISO/IEC-13818-1).
>
> 2) All receivers should as a minimum be able to rip off the field.
As
> William S. says this is part of MPG processing and should not concern
ULE
> at all (unless you have a specific design in mind....). In any case
the
> performance hit of checking one bit and throwing away some data every
now
> and then (most likely never in most systems) should not affect performance
> much.
>
> --Tor Brekke
>
>
>
>
> Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Sent by: owner-ip-dvb@erg.abdn.ac.uk
> 13.04.2004 17:59
> Please respond to
> ip-dvb@erg.abdn.ac.uk
>
>
> To
> ip-dvb@erg.abdn.ac.uk
> cc
>
> Subject
> Re: Adaptation field use in ULE / MPG2-TS specification
>
>
>
>
>
>
> So... as I recall, the rationale behind the current rev. was:
>
> 1) There was no stated requirement for the Adaptation Field
> when used with ULE, if this requirement has emerged, then
> I think we need to know what function is being propossed
> and why this is performed at the MPEG-2 layer, rather than
> at the IP/Ethernet layers. Please send text!
>
> 2) There is a cost at adding Adaptation Field processing, in
> that it impacts implementation/performance of the ULE receiver.
> This has a performance hit, if it is mandatory to support it.
> If it is optional, then there is a compatability hit.
>
> Thoughts?
>
> Gorry
>
> P.S. Note: ULE does *NOT* use the PES syntax for the data
> sent on these streams.
>
> William StanisLaus wrote:
>
> > Here ULE is not preventing use of lower level MPEG2 packet header
> > fields, rather we should figure out why we drop the packet based
on
> > the adaptation field control, is there any reason behind to specify
in
> > the draft to drop packets other than AFC is "01"
> >
> > In the case of adaptation field, which is coupled with MPEG2-TS
> > header, itself will be decoded and action could have taken well
before
> > the control reaches ULE. Hence the goal of adaptation field is
> > accomplished, if it is going to be a sequential/linear processing.
But
> > the question is, when the AFC is "11" in such case
MPEG2-TS payload
> > contains both adaptation field private section data and actual
payload
> > (SNDU), SNDU payload processing will be dropped as per
the ULE draft.
> >
> > Best Regards,
> > William.
> >
> > -----Original Message-----
> > From: owner-ip-dvb@erg.abdn.ac.uk
> > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of
Allison, Art
> > Sent: Tuesday, April 13, 2004 6:51 PM
> > To: 'ip-dvb@erg.abdn.ac.uk'
> > Subject: RE: Adaptation field use in ULE / MPG2-TS
specification
> >
> > I agree with Tor (and am a bit chagrined that I
didn't notice
> > this). The ULE draft should not prevent use of
the 'lower' level
> > MPEG-2 packet header fields, and that included
the adaptation
> > field. A key concept ( Tor's point #2) in
MPEG-2 systems is the
> > layering with each layer having a separable function.
Building
> > vertically integrated designs that constrain this
reduce long term
> > flexibility and can have other impacts like the
one Tor identified.
> >
> > However, now that I glance at the header structure...to
send this
> > data in TS packets, 'payload start indicator' must
be set to a
> > value. It is one bit, where 0= no PES start in
this packet, and 1=
> > PES or PSI start in this packet. Suggest define
that it be set to 0.
> >
> > Art
> > ::{)>
> > Art Allison
> > Director Advanced Engineering
> > NAB
> > 1771 N St NW
> > Washington DC 20036
> > 202 429 5418
> >
> > -----Original Message-----
> > From: William StanisLaus [mailto:williams@calsoft.co.in]
> > Sent: Tuesday, April 13, 2004 8:18
AM
> > To: ip-dvb@erg.abdn.ac.uk
> > Subject: RE: Adaptation field use
in ULE / MPG2-TS specification
> >
> > Hi Marie-Jose,
> > I understand your point
here about extension headers. But
> > actually Adaptation field specified
here is part of
> > MPEG2-TS header and not ULE, in that
case even ULE is a
> > payload for MPEG2-TS. If adaption
field control is 10 or 11 in
> > bits, MPEG2-TS contains private adaption
field, and incase of
> > "10" we need not care about
anything, but still ULE draft says
> > anything other than " 01"
in AFC, receiver MUST discard.
> > Thanks for your comment
Tor Brekke, but i wonder why we
> > have such limitation in ULE, even
though we are not worried in
> > ULE about the MPEG2-TS private section
of Adaption field, if
> > we are not going to take any action
based on the adaption
> > field and control field we can just
ignore. I see this as an
> > implementation issue and should not
be limited in
> > specification/draft.
> >
> > transport_packet(){
> >
> > sync_byte
> > 8 bslbf
> >
> > transport_error_indicator
> > 1 bslbf
> >
> > payload_unit_start_indicator
> > 1 bslbf
> >
> > transport_priority
> > 1 bslbf
> >
> > PID
> > 13 uimsbf
> >
> > transport_scrambling_control
> > 2 bslbf
> >
> > adaptation_field_control
> > 2 bslbf
> >
> > continuity_counter
> > 4 uimsbf
> > if(adaptation_field_control=='10'
||
> > adaptation_field_control=='11'){
> >
adaptation_field()
> > }
> > if(adaptation_field_control=='01'
||
> > adaptation_field_control=='11') {
> >
for (i=0;i<N;i++){
> >
> > data_byte
> >
8 bslbf
> >
}
> > }
> > }
> >
> > here N data_byte's is SNDU as specified
by ULE.
> >
> > Also ULE cannot limit anything on
exisiting underlying
> > protocol as such MPEG2-TS. But definitly
it can limit or
> > provide more services to above layers.
> >
> >
> > Best Regards,
> > William StanisLaus
> > CalSoft, Nortel Networks Division
> >
> >
> > -----Original Message-----
> > From: owner-ip-dvb@erg.abdn.ac.uk
> > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf Of
> > Marie-Jose Montpetit
> > Sent: Tuesday, April
13, 2004 4:00 PM
> > To: ip-dvb@erg.abdn.ac.uk
> > Subject: Re: Adaptation
field use in ULE / MPG2-TS
> > specification
> >
> > Thanks for you input.
If you follow recent discussions
> > there is a proposal
to use extension headers in ULE to
> > support system specific
signalling (and other). It would
> > be interesting to know
more about how you process the
> > information but I think
our philosophy would be to use the
> > headers in the same
way as you describe: transparent to
> > system who do not know
what to do with them, processed by
> > the ones who do. This
is consistent with IPv6 extension
> > headers and also with
other implementations of extension
> > headers (cable for
example).
> >
> > So I do believe we
could use ULE in RCS. Actually in a
> > recent study sponsored
by ESA we showed that for traffic
> > with a lot of ACK bursts
(http: for example) ULE was very
> > efficient because of
it's packing capability.
> >
> > Again thanks for your
input.
> >
> > Marie-Jose
> >
> >
> >
> >
> > -----
Original Message -----
> > From:
Tor Brekke <mailto:tor.brekke@nbs.nera.no>
> > To: ip-dvb@erg.abdn.ac.uk
<mailto:ip-dvb@erg.abdn.ac.uk>
> > Sent:
Tuesday, April 13, 2004 3:02 AM
> > Subject:
Adaptation field use in ULE / MPG2-TS
> > specification
> >
> >
> > Hello,
> >
> > I am
jumping into this discussion at a fairly late
> > stage.
Having just read the ULE draft I have to make a
> > comment
about the use of the adaptation field though.
> > In the
draft it says that "TS Packets from a ULE
> > Encapsulator
MUST be sent with an AFC value of '01'",
> > i.e.
without adaptation field. Now the adaptation
> > field
contains a private field which according to the
> > MPG2-TS
specification (ISO/IEC 13818-1) can be used to
> > transmit
system dependent data.
> > Now to
the question: Why is this limitation imposed on
> > ULE?
> >
> > I have
two main reasons to ask this.
> > 1) Firstly
there is ongoing work to use the private
> > adaptation
field for network internal signalling in
> > the DVB-RCS
standard. This means that ULE will not
> > work
over DVB-RCS systems employing the adaptation
> > field
signalling.
> > 2) As
far as I have been able to determine all other
> > encapsulation
forms over MPG2-TS are transparent to
> > the adaptation
field, i.e. the adaptation field and
> > payload
are handled independently (even though there
> > may be
an implicit connection between them). It seems
> > strange
to break this logicinf the MPG2- TS mechanism
> > for a
new encapsulation type.
> >
> > Best
Regards
> > Tor Brekke
> > Nera
Broadband Satellite AS.
> >
>
>
>