[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs
Thanks for the comments and critical words. I am trying to give you my
views and results of some endless discussions with collegues in the
networking and television world.
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 Channel", 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?
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.
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.
(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. ..."
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.
If there remains an opportunity to repair what I believe to be errors in the
draft, I'm eager and willing to participate from a MPEG-2 entertainment
(which is to say, legacy use of MPEG-2 Transport) point of view.
Of course the terms in the document should not conflict with meaning in
another context. However, ambiguous terms in other documents should be
avoided as well.
[Apologies for being strident at all, to say nothing of at such an
apparently late stage - if the above is perceived as such]
Regards,
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
-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Gorry Fairhurst
Sent: Friday, February 04, 2005 6:56 AM
To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker
Cc: AAllison@nab.org
Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descriptors
1) Done - point 1 was an edit mistake.
2) I think some text on data broadcast descriptors, stream-type, or/and PSI
entries would be a valuable addition.
On thinking about this, I wonder if the text about this should go at the end
of the Introduction (1.0) to the whole document, where people can see it
clearly and then undesrtand that there may be something else needed for
those
networks that rely on PSI for remultiplexing!
- Bernhard & others who understand PSI, can you work with Art to agree the
exact wording please?
Gorry Fairhurst
(ipdvb WG Chair)
Gorry Fairhurst wrote:
WG please read and respond to this message.
The following message was received on January 22nd before WGLC, but was
dropped because the email source address was not verified by the list
server.
The exact text of the message follows.
best wishes,
Gorry
(ipdvb WG Chair)
-----
1)
Thanks for considering my previous input...
I note that the new draft has an editorial oversight in that it contains
two definitions of PSI. I suggest the second should be deleted.
2)
I previously made a comment about the ancillary requirements when adding a
TS logical channel to a TS multiplex and asserted there appeared to be
under
specification. Perhaps it was viewed as out of scope, or perhaps I simply
don't recognize the change that resulted. I can not find what stream_type
is required to be used for the ULE stream when a "TS Logical Channel" is
added to a multiplex.
The problem here is the same as above. Without "applying" for a
"stream_type" for ULE there is no stream_type for ULE. In contrary why
should one register a stream_type value for ULE earlier than ULE is
standardized?
I suggest at least an informative note be added in Section 6 (after the
third line which says: "These are transmitted using a single TS Logical
Channel over a TS Multiplex.") The note should say "PSI entries to be
consistent with [ISO-MPEG] when constructing a conformant TS Multiplex and
means for Receivers to locate each such TS Logical Channel are outside the
scope of this recommendation."
Thanks, this is a very helpful suggestion for potential readers. In
addition the ipdvb-wg works on providing signalling other than PSI/SI.
Reason:
Just inserting a "TS Logical Channel" without including a
TS_Program_map_section that lists the PID and a stream_type does not
appear to me to result in a strictly MPEG-2 conformant bit stream; and
practically
could result in the PIDs being dropped by a remultiplexer. If the means
for binding the inserted element into a multiplex and subsequent discovery
is to be covered in another document, a pointer to that document would be
more helpful than this warning. It seems at least a warning is needed and
preferably a pointer to where this next level of TS construction is
defined.
From an architectural point of view it is a reasonable assupmption that
whatever is being sent in a TS multiplex should be referenced. However,
the reality is that "ghost" PIDs do occur in many services either
accidentially or for well-defined reasons.
What is the penalty for not being strictly MPEG-2 conformant/compliant?
Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington Dc 20036
202 429 5418
Regards,
Bernhard Collini-Nocker