[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Adaptation field use in ULE / MPG2-TS specification
Let me add my understanding with MPEG2-TS decode.
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 PUSI, says the start of new payload or continuation of the pervious
payload for this MPEG packet.
i.e. if PUSI = 0 , continuation/end of the previous payload and PUSI = 1
start of new payload.
NOTE the packet is identified based on the PID.
Continuity counter plays a decent role, if the MPE packet doesn't fit in one
MPEG header.
Regarding Adaptation field, i have already explained in detail.
Tor's concern (if i am not wrong) is "transport private data" in adaptation
field which he wants to use to carry some private information within his
network, which is purely internal and propieratory, which he uses for his
network management. and also he is concerned that, his transport private
data is going to be less than 50 bytes say for example and doesn't want to
waste rest of the payload capacity, hence he wants to club with the traffic
payload, so he updates the adaptation field control as "11". i.e it contains
adaptation field as well as SNDU payload. BUT ULE draft doesn't support this
AFC and discards the packet.
Tor correct me if my understand is wrong.
Best Regards,
William.
> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of Gorry Fairhurst
> Sent: Friday, April 16, 2004 6:43 PM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Re: Adaptation field use in ULE / MPG2-TS specification
>
>
> I'm interested in use-cases that could illustrate how the AF would be
> used (if equipment supported this) with ULE TS.
>
> Can you give me more details of what how you see an AF being added by
> some "lower layer" equipment, and how this
> could actually be used with a stream of SNDUs using ULE?
>
> Tor Brekke wrote:
>
> >
> > 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,
>
> >>> The following worries/interests me, specifically
> - does this assume the "lower layer processing" understands the
> semantics of the PUSI?
> Can you explain what you mean by this statement, so that we can
> understand the full implications...
>
> > 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.
> > > >
> > >
> > >
> > >
> >
> >
>