RE: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs

["Goldberg, Adam" <agoldberg@sharplabs.com>]

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).

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.

(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. 

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?).

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.  

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.

[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.
> 
> 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."
> 
> 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.
> 
> Art Allison
> Director, Advanced Engineering
> NAB Science & Technology
> 1771 N St NW, Washington Dc 20036
> 202 429 5418
> 
> 
>