[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
encaps metghods
Hi all,
Some other questions about encapsulation methods.
I The "enc" one
==================
I-1) Alignement stuff
- Well, it is said that the AF maintains a 4-bytes alignement,
this is sure a plus, but is it a requirement ?
- As described, nothing prevent the stuffing of multiple
SNDU into a single TS cell, to loose this alignement.
Indeed, if 4-bytes alignement is an important feature, I think
it should be said that it MUST be enforced with stuffing bytes
i.e leading to (figure 8) :
+------------------+ +------------------+
| Subnetwork | | Subnetwork |
| DU 1 | | DU 2 |
+------------------+ +------------------+
\ \ / /
\ \ / /
\ \ / /
+------*--------*--------+----------+----------+
|MPEG-2| Adapt. | end of | Stuffing | start of |
|Header| Header | SNDU 1 | bytes | SNDU 2 |
+------+--------+--------+----------+^---------+
| |
| |
+---------------------+
So that Start of SNDU2, is on a 4-bytes boundary
The same thing should apply if SNDU2 is fully sorted in the TS-cell
and a next SNDU3 starts here, it should be said that all SNDU are
re-constructed thanks to their inner length, and that padding is added
to preserve alignement.
I-2) The AF itself
Indeed, the descrption of the AF is :
0 7 8 15 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ad.hdr.length=3| flags 1 | priv.length=1 | pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
but the pointer, is only a private attribute, and hence not described
in 13818-1, so it should be described in the draft (how to compute,
etc ...)
I-3) The AF usage
The first usage descrition of AF, I don('t really see why.
it seems to me a special case that could be avoided, hence
the use case in figure 7 :
+-------------------+
|Encap | Subnetwork |
|Header| PU |
+-------------------+
\ /
\ /
\ /
+------*--------*--------------+------------+
|MPEG-2| Adapt. | Stuffing | SNDU |
|Header| Header | bytes | |
+------+--------+--------------+------------+
could become
+-------------------+
|Encap | Subnetwork |
|Header| PU |
+-------------------+
\ /
\ /
\ /
+------*--------*------------+---------------+
|MPEG-2| Adapt. | SNDU | Padding bytes |
|Header| Header | | (0xFF) |
+------+--------+------------+---------------+
with : PUSI = 1
AFC = 11
AF.pointer = 0
hence allowing: the AF is always followed by the end of SNDU.
I-4) when to put the AF
some case are not reallyu explained, (or I missed them ?) or I think
should be explained more in detail, that is when
- The last piece of SNDU is 184 bytes, hence TS cell is full
OK, no AF
==> slight error : (0/00 PUSI/AFC) should be (0/01 PUSI/AFC)
- No more SNDU available : OK no AF paddinbg wiht 0xFF
What to do when :
- the last piece of SNDU is 181-183 bytes ! hence, ther is not
enough room to store an AF ?
I would think : teat is as if there are no other SNDU to stuff,
i.e. (0/01 PUSI/AFC) no AF, and padding with 0xFF
- the last piece of SNDU is 180 bytes allowing just an AF to be stored
which is not reallu usefull, for nor further SNDu is to be found, so 2
solutions are possible
+ (0/11 PUSI/AFC) AF present AF.pointer=0;
+ (0/01 PUSI/AFC) no AF, padding the last 4 bytes with 0xFF
it would be good to have only one of those allowed.
More over, in a more general sens, bette than a long explication,
and exemple for each of those case would be great (with the PUSI/AFC
and pointer values detailed). It REALLY helps remove ANY amibiguity.
II) Both methods
==================
I don't really get the pros and cons of the ule/enc methods, but as MPE
already exists (and is deployed), I don't feel really easy about having
2 possible new methods for IP/MPEG-2, I think they should be
selected/merged
The difference bewteen the 2 :
This document contains the Simple Encapsulation, a simple and lean
encapsulation mechanism for the transport of IP Datagrams over ISO
MPEG-2 Transport Streams (TS)
This document contains an alternative Ultra Lightweight Encapsulation
(ULE) mechanism for the transport of IP Datagrams directly over ISO
MPEG-2 Transport Streams (TS) as TS private data
After reading 13818-1 does this mean (Indeed, I have troubles with this
norm, and still may be confusing things, if I'm wrong, please tell me) :
- for ENC method, there can be intermedaite layer between TS and the
ENC method, i.e. intermediate header such as PES or PSI packet header,
in this case it is not really shown in the various figures ?
==> is it really needed to carry ENC-packets into such other packets
(huge ovberhead)
- ULE is strictly for TS private data,
==> dose this mean, only for PID such as the associated Strrema type is
bewteen 0x80-0xFF (table 2.29) ?
III) The ULDE method
======================
III-1) format and semantic
As it is meant for private data, the semantic of PUSI/AFC is to
be defined in the draft, which means that the semantic/format of
the pointer should also be explained in the draft.
Here again, some exemples would really help.
III-2) payload pointer
Indeed as it is TS private data, meaning of PUSI/AFC is not
normalized, and may be the payload pointer may be omitted in
some cases (especially as the emission of a next available SNDU
in the ame TS cell is only a MAY)
To play with this, one could use th AFC bits :
01 : No payload pointer
11 : 1st bute is payload pointer
In case of SNDU starting on new TS-cells, it would help
- gain 1 byte
- keep the 4-byte alignement.
I don't know if it's worth the effort ...
III-3) remaining single byte
p11 it is said :
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.
For interop purpose, and possible re-definition (in case of brilliant
ideas to come ...) it is usually better to say
For the case of one remaining byte this MUST be assigned the value
of 0x00, this value MUST be ignored at the receiver.
Thanks for reading so far.
Any comments/corections welcomed.
Bests regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com