[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Adaptation field use in ULE / MPG2-TS specification
Please see the comments inlined
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: Tuesday, April 13, 2004 9:30 PM
> To: ip-dvb@erg.abdn.ac.uk
> 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!
William> Adaptation field is more of a private section/data which is
optional to carry some useful information for satellite network. for
example, discontinuity indicator, random access indicator...., also
"transport private data" where you can send the propieratory data within the
network.
Also adaptation field is per MPEG2-TS header and not for ULE/IP etc.
headers. Means single SNDU can be distributed across MPEG2-TS. In that case
it is NOT required all the MPEG2-TS for this particular SNDU MUST carry
adaptation field.
mm when we read more into MPEG2-TS header,
transport_scrambling_control -- This 2 bit field indicates the scrambling
mode of the Transport Stream
packet payload. The Transport Stream packet header, and the ADAPTATION FIELD
when present, SHALL NOT be
SCRAMBLED. In the case of a null packet the value of the
transport_scrambling_control field shall be set to '00'.
- which is payload scrambling we were discussing sometime before.
The format of adaptation field if present ( AFC is 10 || 11 )
adaptation_field() {
adaptation_field_length 8 uimsbf
if(adaptation_field_length >0) {
discontinuity_indicator 1 bslbf
random_access_indicator 1 bslbf
elementary_stream_priority_indicator 1 bslbf
PCR_flag 1 bslbf
OPCR_flag 1 bslbf
splicing_point_flag 1 bslbf
transport_private_data_flag 1 bslbf
adaptation_field_extension_flag 1 bslbf
if(PCR_flag == '1') {
program_clock_reference_base 33 uimsbf
reserved 6 bslbf
program_clock_reference_extension 9 uimsbf
}
if(OPCR_flag == '1') {
original_program_clock_reference_base 33 uimsbf
reserved 6 bslbf
original_program_clock_reference_extension 9 uimsbf
}
if (splicing_point_flag == '1') {
splice_countdown 8 tcimsbf
}
if(transport_private_data_flag == '1') {
transport_private_data_length 8 uimsbf
for (i=0; i<transport_private_data_length;i++){
private_data_byte 8 bslbf
}
}
if (adaptation_field_extension_flag == '1' ) {
adaptation_field_extension_length 8 uimsbf
ltw_flag 1 bslbf
piecewise_rate_flag 1 bslbf
seamless_splice_flag 1 bslbf
reserved 5 bslbf
if (ltw_flag == '1') {
ltw_valid_flag 1 bslbf
ltw_offset 15 uimsbf
}
if (piecewise_rate_flag == '1') {
reserved 2 bslbf
piecewise_rate 22 uimsbf
}
if (seamless_splice_flag == '1'){
splice_type 4 bslbf
DTS_next_AU[32..30] 3 bslbf
marker_bit 1 bslbf
DTS_next_AU[29..15] 15 bslbf
marker_bit 1 bslbf
DTS_next_AU[14..0] 15 bslbf
marker_bit 1 bslbf
}
for ( i=0;i<N;i++) {
reserved 8 bslbf
}
}
for (i=0;i<N;i++){
stuffing_byte 8 bslbf
}
}
}
> 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.
William> To my knowledge the processing of Adaptation Field is part of
MPEG2-TS, and not ULE or any other MPE in that case.
Please correct me if i'm wrong.
>
> 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.
>