[opendtv] Re: Redefining anamorphic
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Sun, 9 Mar 2008 10:25:50 -0700
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.
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.
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.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Craig Birkmaier
Enviado el: Sunday, March 09, 2008 7:35 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Redefining anamorphic
At 10:03 PM -0800 3/8/08, Ron Economos wrote:
>Are you saying that MPEG-2 decoders are not conformant because they
>can't display any input resolution properly scaled to the output format?
Since
>MPEG-2 or H.264 doesn't specify the "display process", I don't think
>that's a conformance point.
>
No.
I am saying that they are not conformant if you cannot define any
raster size and frame rate that can exist within the limits of an
MPEG level and profile. The total number of samples per second and
the maximum number of lines are defined in the MPEG Level.
So you can define any raster size - typically in multiples of
macroblocks - and as long as the total number of samples per second
for the level is not exceeded the decoder should be able to present
that raster to the display processor for presentation.
There are MANY reasons for a decoder to be considered NOT CONFORMANT.
The ATSC implementation with the restrictions in Table 3 could allow
a decoder manufacturer to ONLY support those raster format. If they
do restrict the operation of the decoder to specific formats, it is
non conformant. This HAPPENED with many early ATSC receiver
implementations. For this reason the ATSC could not add 720 x 480 to
the standard, because using that raster size would break some early
receivers.
It is also possible to build a non-conformant decoder by NOT PROPERLy
implementing the MPEG-2 extension mechanism. THere are many reserved
extensions in MPEG-2. Typically when you get to an extension when
parsing the bitstream you see a "zero" which tells the decoder the
extension is not being used. IF you later develop an extension that
"zero" becomes a "one," telling a decoder that understands the new
extension to look for the new bits. An older decoder SHOULD ignore
the extension and keep going. We could not add an extension to MPEG-2
to help identify breaks in the 3:2 cadence for 24P, because some
early decoders hard coded the extensions. So when you would change
that zero to a one the decoder would stop working.
At that point further work on MPEG-2 essentially stopped. The
extension mechanism was worthless.
A properly designed display processor should scale anything to the
local display resolution. As you have pointed out, some receiver
designs take short-cuts that make this impractical or impossible.
Shame on them...
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:
