[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Corrections/Evolutions for ULE draft
Hi Gorry and all,
For the ULE methode, I made the following hypothsis :
- Padding at the end of TS si dobne with 0xff
- End Indicator is 0xffff
- It is forbidden for a SNDU to start in a TS cell if
it has not room left for its first 2 bytes
So to summary all previous things, and have all sugestions in a single
mail (sorry for repetition with older postings), I would propose the
following changes for the draft :
1) p3 reference
----------------
[draft-unisal-ipdvb-enc-01.txt]
would become
[CLAUSEN]
and the referecne section will be added
[CLAUSEN] draf-clausen-ipdvb-enc-01.txt
2) About the MPEG Header
--------------------------
3. Description of Method.
To have a stand alone document (without any implementation need
for a non free norm), maybe a MPEG header description could be
provided, with all the fixed fields values set (sync byte, AFC, ...)
and the needed explication for the others (PUSI, Countiunuity
Counter ...)
This I would have preferred, but I don't know wheter this is legally
feasible or not, with respect to ISO. Or maybe permission can be
requested to ISO for doing such.
3) Precision about SNDU format
-------------------------------
4. SDNU Format
"The special value 0x0000 indicates that there are no further SNDU
within the current TS packet (see section 5.1). The maximum value is
65531"
becomes
"The special value 0xffff indicates that there are no further SNDU
within the current TS packet (see section 5.1). The maximum value is
65530"
... following then Length and Type field definition, add :
"The length andd type filed are transmitted, with the most significant
byte first", hence a 1000 bytes IPv4 packet encapsulation would begin
with : 0x03 0xE8 0x08 0x00 0x45 ..."
Add the CRC-32 definition. Even if it is the same as the Ethernet
CRC-32, may be the polynomail should be provided:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0
(IF this is the good one ...)
4) Encapsulator processing
----------------------------
management of the last byte(s) on p11
"If the TS Packet carrying the final part of a SNDU has either zero
or one byte of unused payload, the encapsulator will start
transmission of the next SNDU in a new TS Packet. For the case of
one remaining byte this MAY be assigned the value of 0x00, but this
value MUST NOT be required at the receiver."
would become
"If there is not enough room in a TS packet to put the first
2 bytes of an SNDU (possibly due to the needed payload pointer),
the encapsulator will start transmission of this SNDU in a new
TS packet. The remaining bytes, MUST be set to 0xff and MUST be
ignored by the receiver"
(The same rule can be applied to the ENC method)
This is relatively a little bit different from what you
proposed in your slides, but straightforward to implement:
if (PUSI == 1)
Needed = 2;
else
Needed = 3;
if (bytes letf >= Needed)
{
if (PUSI == 0)
{
set PUSI = 1;
insert paload pointer;
}
sart new SNDU in this TS;
}
else
{
padd with 0xff;
New();
}
The packing requirement seem ot me too light :
"... it MAY start SNDU in the next available byte of the TS
packet payload"
would become
"... it SHOULD start SNDU in the next available byte of the TS
packet payload. The reciever MUST be able to process such packed
SNDU"
Moreover, the PayloadPointer definition is a little bit vague. So
"If the PUSI is set by this operation, the payload pointer MUST be
assigned to the position of the byte following the end of the first
SNDU in the TS Packet payload."
would become
"If the PUSI is set by this operation, the payload pointer MUST be
inserted as the first byte of the payload. It is an 8-bit field
whose value shall be the number of bytes, immediately following the
pointer_field until the first byte of the first SNDU that is present
in the payload of the Transport Stream packet (so a value of 0x00 in
the payload pointer indicates that the SNDU starts immediately
after the payload pointer)."
Withe the new end indicator value
figure 6
+-------------+
| Subnetwork |
| DU 3 |
+-------------+
\ \
\ \
\ \
+------+--------+--------+----------+
|MPEG-2| end of | 0x0000 | Unused |
|Header| SNDU 3 | | |
+------+--------+--------+----------+
PUSI=0 End
Indicator
would become
+-------------+
| Subnetwork |
| DU 3 |
+-------------+
\ \
\ \
\ \
+------+--------+--------+----------+
|MPEG-2| end of | 0xffff | Unused |
|Header| SNDU 3 | | |
+------+--------+--------+----------+
PUSI=0 End
Indicator
5) Decapsulator processing
---------------------------
About the payload pointer checking :
"A receiver that has partially received a SNDU (in the Current SNDU
buffer) MUST also check the Payload Pointer, of any received packets
with a PUSI value of 1. A Payload Pointer value of 1 indicates that
the receiver MUST discard any previously unreassembled SNDU, and
start processing the new SNDU that directly follows the Payload
Pointer."
Ther seems to be a conflict with the definition of the payload pointer
proposed to be in sync wiht DVB world, for in this case a value of '1'
is legal. Only a value of 0 is suspect. More over, is this paragraph
needed, as the following already includes the while case (about
unfinished SNDU btw s/ANDU/SNDU) where (PayloadPointer - 1)
would become (PayloadPointer).
6) Reference section
----------------------
It is a bit hard for a newbie, and most of them are for having some
background so having them separated could help (especially, as some
are NOT FREE) :
Directly related ones:
- [ISO-MPEG]
- [ETSI-DAT]
- [ISO-DMSCC]
"Not so important" ones (hmmm, see there no disrespect)
- all [ATSC-xx]
(btw [ATS-DAT] and [ATSC-DATG] are not used in the text)
- [ETSI-DVBS]
- [ETSI-DVBT]
- [ETSI-DVBC]
(btw [ISO-AUD] and [ISO-VID] are not used in the text)
- [ETSI-RCS] is used in the 1; Introduction, but not defined.
7) Exemples
--------------
This would lead to the following exemples that could be provided
in the draft in some annex part. (Thanks to tell if there is any
error)
A) Simple case
===============
SNDU A is 200 bytes long
SNDU B is 200 bytes long
PP=0
+-----+----+------+- -+------+
| HDR |0x00| A000 | ... | A182 |
+-----+---*+-*----+- -+------+
PUSI=1 * *
****
PP=17
+-----+----+------+- -+------+------+- -+------+
| HDR |0x11| A183 | ... | A199 | B000 | ... | B165 |
+-----+---*+------+- -+------+*-----+- -+------+
PUSI=1 * *
***********************
<--- 150 --->
stuffing bytes
+-----+------+- -+------+----+- -+----+
| HDR | B166 | ... | B199 |0xff| ... |0xff|
+-----+------+- -+------+----+- -+----+
PUSI=0
no PP
B) Corny cases with last byte
==============================
SNDU A is 183 bytes long
SNDU B is 182 bytes long
SNDU C is 181 bytes long
SNDU D is 185 bytes long
SNDU E is 364 bytes long
PP=0
+-----+----+------+- -+------+
| HDR |0x00| A000 | ... | A182 |
+-----+---*+-*----+- -+------+
PUSI=1 * *
****
unused
PP=0 byte
+-----+----+------+- -+------+----+
| HDR |0x00| B000 | ... | B181 |0xff|
+-----+---*+-*----+- -+------+----+
PUSI=1 * *
****
PP=0
+-----+----+------+- -+------+------+------+
| HDR |0x00| C000 | ... | C180 | D000 | D001 |
+-----+---*+-*----+- -+------+------+------+
PUSI=1 * *
**** unused
byte
+-----+------+- -+------+----+
| HDR | D002 | ... | D184 |0xff|
+-----+------+- -+------+----+
PUSI=0
no PP
PP=0
+-----+----+------+- -+------+
| HDR |0x00| E000 | ... | E182 |
+-----+--*-+-*----+- -+------+
PUSI=1 * *
*****
PP=181
+-----+----+------+- -+------+------+------+
| HDR |0xb5| E183 | ... | E363 | F000 | F001 |
+-----+---*+------+- -+------+*-----+------+
PUSI=1 * *
***********************
+-----+------+- -+------+
| HDR | F002 | ... | F099 | ...
+-----+------+- -+------+
PUSI=0
C) Small packets
==================
SNDU A is 200 bytes long
SNDU B is 60 bytes long
SNDU C is 60 bytes long
PP=0
+-----+----+------+- -+------+
| HDR |0x00| A000 | ... | A182 |
+-----+---*+-*----+- -+------+
PUSI=1 * *
****
PP=17
+-----+----+------+- -+------+------+-
| HDR |0x11| A183 | ... | A199 | B000 | ...
+-----+---*+------+- -+------+*-----+-
PUSI=1 * *
***********************
<--- 46 --->
stuffing bytes
including end-indicator
-+------+------+- -+------+----+- -+----+
... | B059 | C000 | ... | C059 |0xff| ... |0xff|
-+------+------+- -+------+----+- -+----+
Any comment welcomed.
Cheers.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com