[opendtv] Re: Redefining anamorphic
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 10 Mar 2008 09:06:35 -0700
I know not about extensions using MPEG-2 reserved values. I do know of ATSC
and SCTE constraints on MPEG-2 video, and if that's the best you have, it
appears to me that all ATSC- or SCTE-compliant encoders are also MPEG-2
complaint.
Did I misunderstand something in the specifications, or did I misunderstand
the point you were trying to make?
I also note that Harris Corporation (NetVx) and others are putting forth
encoders with multiple outputs where one output can be ATSC-compliant,
another DVB-compliant, etc. Seems that would suffice, no? (These things
are hot, and not just because Harris has announced they will stop supporting
older encoders in the near future.)
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Craig Birkmaier
Enviado el: Monday, March 10, 2008 9:03 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Redefining anamorphic
At 10:25 AM -0700 3/9/08, John Willkie wrote:
>Could you provide me with a reference to the language in ISO/IEC 13818:2000
>where this conformance matter is stated with "shall" language? My reading
>is that this type of stuff is in informative, not normative, annexes, if
>it's in there at all.
From my older copy of the standard (1995)
C ISO/IEC ISO/IEC 13818-2: 1995 (E)
Recommendation ITU-T H.262 (1995 E) 15
Definitions:
3.113 reserved: The term "reserved" when used in
the clauses defining the coded bitstream
indicates that the value may be used in the
future for ISO/IEC defined extensions.
5.3 Reserved, forbidden and marker_bit
The terms "reserved" and "forbidden" are used in
the description of some values of several fields
in the coded bitstream.
The term "reserved" indicates that the value may
be used in the future for ISO/IEC|ITU-T defined
extensions.
The term "forbidden" indicates a value that shall
never be used (usually in order to avoid
emulation of start codes).
The term "marker_bit" indicates a one bit integer
in which the value zero is forbidden (and it
therefore shall have the value '1'). These marker
bits are introduced at several points in the
syntax to avoid start code emulation.
6.3 Video bitstream semantics
6.3.1 Semantic rules for higher syntactic structures
This clause details the rules that govern the way
in which the higher level syntactic elements may
be combined together to produce a legal
bitstream. Subsequent clauses detail the semantic
meaning of all fields in the video bitstream.
Stuff deleted ...
At each point where extensions are allowed in the
bitstream any number of the extensions from the
defined allowable set may be included. However
each type of extension shall not occur more than
once. In the case that a decoder encounters an
extension with an extension identification that
is described as "reserved" in this specification
the decoder shall discard all subsequent data
until the next start code.
This requirement allows future definition of
compatible extensions to this specification.
>
>My reading is somewhat different -- that an MPEG-2 'user' (ATSC, ARIB,
SCTE,
>DVB), while relying on the mandatory transport stream elements -- PAT, PMT,
>elementary streams, etc. -- can define what is mandatory in their world.
>MPEG-2 is a toolkit, and ATSC and the rest use it.
Not exactly. The MPEG levels and profiles provide
the mechanism by which a subset of the available
tools can be used. But MPEG expected conformance
to these levels and profiles and defined
conformance here:
8 Profiles and levels
NOTE - In this Specification the word "profile"
is used as defined below. It should not be
confused with other definitions of "profile" and
in particular it does not have the meaning that is
defined by JTC1/SGFS.
Profiles and levels provide a means of defining
subsets of the syntax and semantics of this
Specification and thereby the decoder
capabilities required to decode a particular
bitstream. A profile is a defined subset of the
entire bitstream syntax that is defined by this
Specification. A level is a defined set of
constraints imposed on parameters in the
bitstream. Conformance tests will be carried out
against defined profiles at defined levels.
The purpose of defining conformance points in the
form of profiles and levels is to facilitate
bitstream interchange among different
applications. Implementers of this Specification
are encouraged to produce decoders and bitstreams
which correspond to those defined conformance
regions. The discretely defined profiles and
levels are the means of bitstream interchange
between applications of this Specification.
----------------------------------------
Obviously some implementations are not conformant
by ISO/IEC definition. If the deployment is
closed, this probably does not matter. If the
deployment is targeted at a broad audience, it
probably does matter.
Cable and DBS systems, for the most part, tried
to develop conformant decoders, to provide the
flexibility that those industries wanted in
controlling bandwidth requirements. As such, they
had no problem dealing with ATSC bitstreams,
which are a subset of the levels and profiles
that the ATSC standard claims to support. This
may or may not work the other way around. Many HD
capable receivers now use conformant decoders
that can handle all of the sub-line lengths
needed to deal with cable systems.
>
>As mentioned in this thread, DVB has made AFD mandatory in some contexts.
>
>ATSC has limited, for example, what you can do with a pid carrying a
program
>map table section. MPEG-2 permits more than one PMT section (one PMT
>section per MPEG-2 program) to share a single pid, and even permits other
>MPEG-2 private table sections on that pid.
>
>ATSC takes away that flexibility. You cannot have more than one PMT
section
>on the same pid, and the pid cannot carry privately defined table sections.
>(Thank the Almighty for that!)
>
>Nothing in MPEG-2 forbids you from having two different elementary streams
>on the same pid. ATSC takes that 'flexibility' away; except for PSIP (and
>perhaps data broadcasting), you can only have one elementary stream, or
>table section type on a single pid.
>
>The MPEG-2 user can define any raster size, sure. But YOU are not an
MPEG-2
>user; ATSC is. And, they have defined it differently than you desire.
>Methinks the case is long closed on that: at least one due-process
standards
>development organization didn't agree with you.
i worked in the ISO/MPEG process. I was trying to
develop a new level and profile when my economic
support to participate in this VERY EXPENSIVE
process evaporated.
I spent a great deal of time talking with
Leonardo and various sub-committee heads about
the conformance issue. They WERE NOT PLEASED that
the objectives of the standard were subverted.
They were not pleased that significant efforts to
improve the standard via the extension mechanism
were shut down by the actions of several national
bodies, who voted against these efforts because
manufacturers in these nations deployed
non-conformant products.
I have no problem with a standards body adopting
an MPEG level/profile into their standard. I have
no problem with the downstream body adding
restrictions for their standard, so long as they
do it in a way that allows the decoder to remain
conformant to the level and profile. And I have
no problem with a downstream standards body using
the reserved extensions in a level and profile to
document and implement enhancements to that
level and profile in a conformant manner.
I do have problems with sloppy implementations,
whether intentional or unintentional, that render
the ability to enhance the standard meaningless.
To be fair, for many companies the discipline
involved in developing products for an extensible
standard may not have been in place initially.
And ISO/MEG never could figure out how to create
an enforceable conformance regimen, due in part
to the cost of conformance testing. The MPEG
Industry Forum has attempted to deal with this
issue, but for MPEG-2 the cat got out of the bag
before the problem was even noticed.
Regards
Craig
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
