-----Original Message-----
From: Goldberg, Adam
Sent: Monday, February 07, 2005 12:42 AM
To: 'Bernhard Collini-Nocker'; Goldberg, Adam
Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman
Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast
Descripto
rs
See below...
Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA 22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell
Bernhard Collini-Nocker wrote:
Goldberg, Adam wrote:
I apologize for being "late to the party", but:
I do not see a particular need to define new term "TS Logical
and
indeed doing so creates risks of ill-specification (such as those Art
points
out), as well as confusion heaped upon someone familiar with MPEG-2
Transport (as typically used in entertainment delivery).
Unfortunately the MPEG-2 standards do not provide a reasonable term for
the purpose of networking. The question is whether other terms, for
example "PID network" or "PID stream" would be better received and
understood?
The term "TS logical channel" tries to verbally visualize that the
encapsulation uses a continouos stream of transport stream packets
using
one specific packet identifier to transport subnetwork data units.
Maybe
the term "TS (virtual) circuit" better names this?
It is perhaps not well defined in 13818-1, but the term of art is
"streams". Many people use "PID stream" which is a poor combination of
words. I'd have no objection to defining a "SNDU Stream" as something
like "a sequence of MPEG-2 Transport Stream packets identified by a
common
PID value" (or some such).
Perhaps discussing 'virtual circuits' relative to a Transport Stream is
begging for confusion. Use of any such words ("TS (virtual) circuit")
needs careful definition, likely requiring the above SNDU Stream
definition plus an explanation of what it means for multiple SNDU
Streams
to exist in a single Transport Stream.
Furthermore, the definition is quite wrong with respect to ATSC and
DVB
use
of "specific TS Logical Channels". To my knowledge, this internet-
draft
is
the only document anywhere which uses such terms. It is certainly
true
that
MPEG, DVB and ATSC define //elementary streams// identified by
stream_type
values. I suspect this is what is meant by "TS Logical Channel", but
it
is
difficult for me to tell.
I am not so sure, whether this analysis is correct. Elementary streams
are those that are transported as Packetized ES, whereas "auxillary"
data and signalling is transported as sections. Although a stream_type
in the program map section is used to reference both PESs and sections
the term elementary stream is used very vague and we tried to avoid
using it in the same vague manner.
Perhaps I overstepped with "elementary stream".
Consider the 13818-1 definition of "Packetized Elementary Stream": "A
continuous sequence of PES packets of one elementary stream with one
stream ID may be used to construct a PES Stream." (ISO/IEC
13818-1:2000 p.
xiii)
Stuff carried as payload of Transport Stream packets are merely
'payload'.
What the draft starts to define is a new type of payload stream (that
is,
a new way to carry data in a transport stream). The definition is not
compete.
According to, for example EN301192 v1.3.1, defines Data Piping as:
" The data broadcast service shall insert the data to be broadcast
directly in the payload of MPEG-2 TS packets."
That raises the question, how to call a continouos stream of MPEG-2 TS
packets with a certain PID?
Further the standard details that:
"The data broadcast service may use the payload_unit_start_indicator
field and the transport_priority field of the MPEG-2 Transport Stream
packets in a service private way. The use of the adaptation_field shall
be MPEG-2 compliant."
ULE uses PUSI and does not utilize the AF.
"The delivery of the bits in time through a data pipe is service
private
and is not specified in the present document."
It seems obvious that the use of the term "TS Data Pipe" would lead to
the wrong conclusion that ULE equals Data Piping. But Data Piping is
not
detailed at all, whereas ULE tries to be.
I'm not going to argue that DVB's specification is complete. I will
argue
that ULE isn't complete.
(from the draft)
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level [ISO-
MPEG]. It exists at level 2 of the ISO/OSI reference model. All
packets sent over a TS Logical Channel carry the same PID value
(this value is unique within a specific TS Multiplex). According to
MPEG-2, some TS Logical Channels are reserved for specific
signalling purposes. Other standards (e.g., ATSC, DVB) also reserve
specific TS Logical Channels.
While I'm commenting on this definition, it also seems to me that
"channel
at the MPEG-2 level" is either wrong or also ill-specified. What's a
channel? If you're talking about MPEG-2, it's certainly conceivable
that
the reader may associate "channel" with "[television] channel" - which
are
the subject of a large amount of ATSC and DVB systems.
The term channel is indeed problematic in the context of television,
however, network engineers might have a different understanding about
what a channel is.
According to ATIS a channel is "1. A connection between initiating and
terminating nodes of a circuit. 2. A single path provided by a
transmission medium via either (a) physical separation, such as by
multipair cable or (b) electrical separation, such as by frequency- or
time-division multiplexing. ..."
I understand that 'channel' vis-à-vis networking has a different meaning
than 'channel' vis-à-vis television. This was my point actually, that
those familiar with MPEG transport should not be assumed to be
networking-
types (even when speaking with respect to ULE).
Additionally, it is also wrong or ill-specified to say "According to
MPEG-2
... TS Logical Channels ...". There is no such concept defined or
used
within MPEG (unless what you really mean is elementary stream, in
which
case
what do you need this extraneous term for anyhow?).
Again, elementary stream is not exactly what is being meant:
For example EN 300468 v1.5.1 defines:
"component (ELEMENTARY Stream): one or more entities which together
make
up an event, e.g. video, audio, teletext"
and says further:
"The component descriptor identifies the type of component stream and
may be used to provide a text description of the elementary stream"
where:
"component_type: This 8-bit field specifies the type of the video,
audio
or EBU-data component. The coding of this field is specified in table
26."
Table 26 then lists all kinds of video, audio, and teletext formats,
but
unfortunately no networking formats.
At other places this standard is as innovative/creative in naming:
"event: grouping of elementary broadcast data streams with a defined
start and end time belonging to a common service, e.g. first half of a
football match, News Flash, first part of an entertainment show"
What is a "elementary broadcast data streams"? Not by guessing but by
definition?
In any case, Art is certainly correct that merely identifying a "TS
Logical
Channel" as a sequence of packets identified with a common PID value
without
identifying the PSI details is an invitation to multiplexers and
remultiplexers to drop those packets on the floor.
Oh yes, this is the real problem of defining something outside
television standardiszation bodies: one risks that ULE packets are
being
dropped.
We have discussed basically two approaches:
1. define the PSI and get an ID, or tag, or "stream_type" for ULE,
or 2.
define ULE and let somebody else do the PSI work.
We have had some reasons for choice 2.
This is a very easy thing to fix and something which should be done.
Without defining a stream_type for ULE data, it is neither possible to
construct a transport stream compliant with MPEG-2 nor one that
interoperates with other ULE equipment.
ATSC maintains a 'codepoint registry', and would be happy to allocate a
stream_type value for ULE data upon request from IETF. Furthermore, the
text to specify usage of the stream_type would be reasonably easy (and
perhaps ties in to my suggested "SNDU Stream" definition (that is,
define
it as