[opendtv] Monty (OPENDTV) Python: H.26x and the Holy Grail (are MPEG and VCEG Knights Templar sister-organizations?)
- From: "TLM" <TLM@xxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 13 Apr 2013 08:36:20 -0700
"H.264 was quickly adopted into GPU cores, providing both decoding and
encoding capabilities - even smartphones can handle decent HD production and
encoding today. H.265 will be no different. Most GPUs probably have enough
horsepower to deal with H.265 today....."
Craig [Birkmaier] you have seen the future and it is now, more or less.
However, one thing I must point out is that with H.264 *or* H.265, the
horsepower (and the CODEC processor node memory parameters) required for
encoding and decoding is highly dependent on the Picture resolution & frame
rate, CODEC Level & Profile, sampling structure (4:4:4, 4:2:2, 4:2:0, 8/10
bits), GOP structure (open GOP with only *one* beginning I frame for
streaming), or some IPB structure that's editable in Production and Post, or
another more suitable for channel changing at the consumer end, or full
I-Frame only (yes both of those standards can run that way too - for example
H.26x Post Production and D-Cinema applications). It is likely that a
terrestrial broadcast service might choose one mix of the above parameters
for content targeted toward H.265-capable DTVs and all variants of Table 3
(with a structure suitable for local affiliate news/commercial inserts),
cable or satellite might chose a different mix of parameters targeted at
their STBs with some freedom from Table 3, somebody targeting mobile and
handheld devices (a la ATSC and DVB) something different, IPTV/INET
delivered content something else.
The people making SW decoders that run on the GPU or CPU chips for all of
these various markets know all of this, as do the folks making high quality
broadcast encoders for these standards (some of which are now rack-mount PCs
on their insides!)
Note, too, that these standards are constructed with a
downward-compatibility requirement so that a decoder supporting any given
level and profile can make video out of any stream equal or less than that.
SO a heavyweight STB or PC should be able to decode just about anything
(perhaps not 4K yet), but a handheld may not (4K on a handheld? The doctor
said if it hurts when I do that, don't *do* that.).
I can tell you that at least one major broadcast/transmission standards body
is studying 10 bit requirements for HDTV and UHDTV, and the implications of
perhaps just going 4:2:0 for progressive content (4:2:2 sampling structure
is *only* required for interlace, which is going away anyway, and it doesn't
exist in the living room or on computers or handhelds at all). So if
service providers adopting those new standards for, say, cable and satellite
and IPTV/INET made the decision to go progressive-only (converting any
remaining interlace to progressive at the *head* end), they may choose to go
H.265 10 bit 4:2:0 progressive only, get all of the benefits of both H.265
and progressive coding efficiency, and be ready to go to UHDTV (4K) if and
when their market required that. THEN you have a context zone within which
you can start to ask valid questions.
On another note: going to higher frame rates, say 2x, does not double the
required bitrate or horsepower, and going to 4K (approx. 4x the number of
pixels as 1080) absolutely does not require 4x the bitrate, although it
might require 4x the (fast and expensive) memory.
Given all of the above one might then be able to get a handle on when the
decoders for said service, either in chip or SW form, might be available (if
you quantize your life in integer years I believe the answer is 2013 for
many of the services being contemplated).
If you think of the "horsepower required" as a sweet spot in market
requirements you can get a handle on the realities of where we're at. So:
Simply mulling about whether H.26x will need XYZ horsepower and when isn't
productive mulling. To quantify and qualify the answer you need more
market, commercial, and business plan context.
Tom McMahon
Del Rey Consultancy
TLM@xxxxxxxxxx
WWW.DelRey.Com
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Craig Birkmaier
Sent: Saturday, April 13, 2013 6:59 AM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: WTF is... H.265 aka HEVC?
On Apr 12, 2013, at 5:58 PM, "Manfredi, Albert E"
<albert.e.manfredi@xxxxxxxxxx> wrote:
> So I ask again, will today's typical quad-core PCs be up to the decode at
least? The article claims that multi-core GPUs are a better bet for H.265
than a simple increase in processor GHz, because the decode is amenable to
parallel processing.
>
> For sure, since people will want H.265 for their own videos, this will
generate a whole new push for higher speeds in PCs, smartphones, and
tablets, even if decoding takes less of an effort. The world has changed in
this regard. I don't see as much of an advantage in cheap decode and
expensive encode anymore, as there once was, perhaps.
>
I still remember when the broadcast industry pundits thought that MPEG-2 and
HD would protect them from the same fate as the audio industry, which was
transformed in the '80s to new computer based production tools. They
honestly believed that the processing requirements for HD and MPEG-2 would
require dedicated hardware for years, if not decades. Ironically, desktop
computers and software evolved so rapidly that HD production and MPEG-2
encoding were commonplace years before most consumers had an HDTV.
H.264 was quickly adopted into GPU cores, providing both decoding and
encoding capabilities - even smartphones can handle decent HD production and
encoding today. H.265 will be no different. Most GPUs probably have enough
horsepower to deal with h.265 today, but it will take a bit of time for the
software to catch up.
As for encoding, expensive versus cheap is all about "time." Most consumer
applications are NOT realtime, thus waiting a few minutes to encode the
video you just shot, so you can upload it to YouTube is no big deal.
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:
- » [opendtv] Monty (OPENDTV) Python: H.26x and the Holy Grail (are MPEG and VCEG Knights Templar sister-organizations?) - TLM