[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> >
>
>
>