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.