[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Adaptation field use in ULE / MPG2-TS specification
Hi,
Is there any decision/conclusion made by the work group on Adaption field
use in ULE by MPEG2-TS.
Best Regards,
William.
> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of William StanisLaus
> Sent: Friday, April 16, 2004 7:54 PM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: 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.
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>