Feeds

back to article Next-gen H.265 video baked into Broadcom's monster TV brain

720p video at 30 frames per second and less than half a megabit a second: that's the promise of the H.265 vid compression tech, which is up for ratification any day now and already has chips ready to decode it. The codec scales from bandwidth-starved mobiles, allowing one to watch streamed TV in the park, to monster 4K Ultra HD …

COMMENTS

This topic is closed for new posts.

"720p vids at 30 frames per second and less than half a megabit a second: that's the promise of the H.265 video compression tech"

Might give Virgin Media's 60mbps "service" a chance to actually stream some video without stuttering or pausing.

1
3
Silver badge

Only as good as the encoder.

x264 has been finely tuned by the best in the field. Even if the h265 specification is superior, it'll start off far behind in quality of implimentation. Hopefully it'll be close enough to h264 that much of the x264 encoder can be simply reused and modified.

3
2
Silver badge

Re: Only as good as the encoder.

No idea why you managed to get a downvote. x264 is absolutely godly.

I didn't know Google was actively working on VP9, though, that's very interesting indeed.

2
1

Re: Only as good as the encoder.

This is "on chip" tech. Once industry makes up their minds (Apple and Microsoft/google), I am sure x265 is on its way and it will be a way more important project.

0
0

Looks good

but get the dude to jump around and run around and juggle with different coloured balls etc, unless you are watching mastermind, there aren't too many programmes or films that have one person sitting still without talking.. I do not disagree that it is a great advancement but how does it handle movement and change? it could go from looking nice to minecraft or worse very quick, or, suck up a lot more bandwidth...

8
0
Bronze badge
Thumb Down

Broadcom don't do processors

'ARM' in the name is a clue.

Broadcom make SoCs and related devices which include processrs from MIPS or ARM.

If El Reg want a semiconductor reporter let me know.

Also, H.264 is MPEG4 part 10 so which part of MPEG is H.265?

1
0
(Written by Reg staff) Silver badge

Re: Broadcom don't do processors

"Broadcom don't do processors"

Yes, give us some credit: the BCM part contains an ARM processor and does video decoding. As the article states :-)

The trollslayer turns out to be a troll. Who da thunk it? ;-)

C.

5
0
Anonymous Coward

Not too impressed I must say

To my eyes H.265 looks visibly worse than h.264. Even after the youtube encoding that must have lost some original detail in both versions.

I suspect I should be happy about the halved bandwidth usage. I won't make much difference in my home network. But I suspect it does for a mobile company's bank balance.

0
0
Alert

What a rubbish demo

I am sorry but did no one else think the demo was rubbish? Any video codec could have compressed someone resembling a statue against a static background! Come on, you only generally get to see how good a codec is when its given a challange. Take MPEG2 on freeview, if the scene is fairly static its pretty good, give it lots of motion or scene changes and boy it blocks worse than a bucket of LEGO.

What I would have like to have seen is how good it was and therefore its bandwidth if its a variable bit rate codec, when there is loads of movement, as it a real TV show or film.

7
1
Silver badge

Re: What a rubbish demo

How about encoding a segment of a football match (doesn't matter which type--all of them encourage movement)? With all the camera panning and player movement (not to mention the subtle green specking in the turf), that should tax the codec.

1
0
Silver badge

That's why codecs are usually compared with lots of different footage

And that has actually been done for decades. Just look at old BBC engineering reports.

For example here, in this report from 1962 titled "Tests of three systems of bandwidth compression of television signals"

http://www.bbc.co.uk/rd/publications/rdreport_1962_01.shtml

0
0
Silver badge

Re: That's why codecs are usually compared with lots of different footage

When watching BBC nature documentaries, it'a always the scenes of large dense flocks of birds that go blocky on iPlayer- lots movement in different directions. Still, that's some TV making that merits disc sales.

1
0
Silver badge

Re: That's why codecs are usually compared with lots of different footage

Well to be fair, the Internet uses unicasting, so it's not economic to provide everyone with multi megabit streams.

However what I don't understand why the BBC has to constantly transmit every local station as a full stream. The DVB standard permits you to share streams between channels and split them dynamically.

So during the day you may have 10 local channels on one transponder sharing one video stream. Then when the local windows start, you reduce its bitrate to 10% and start 9 other streams for the other local channels. Once the window is over you get back to one stream again. Sure local windows will look shitty, but then again, those rarely contain much movement.

It's done by some regional broadcasters in Germany (e.g. WDR) for their HDTV programes. It followed several years of testing that feature of DVB.

0
0

Re: That's why codecs are usually compared with lots of different footage

> BBC has to constantly transmit every local station as a full stream

If I recall correctly this has already changed[1] or is due to sometime soon if not done already.

The problem was combining the variable bandwidth stations in the MUX with the regional BBC1 feeds and sending to the regional transmitters: the technology to make BBC1 variable width in each region and merge didn't exist when Freeview started.

With newer kit, HD and analogue switch off the situation has (or will soon) change.

[1] I seem to recall it was linked to the completion of analogue switch off and HD roll out.

0
0
Anonymous Coward

Re: That's why codecs are usually compared with lots of different footage

It's like the megapixel myth all over again. Lets have lots of super high resolution but reduced quality, nice.

It would be like have twice the megapixels, but having jpeg compression quality setting halved.

0
0

@richardcox13

Christian Berger is talking about satellite, where each version of BBC One is a full-time independent stream simulcast on the same transponder, not Freeview, where each transmitter only transmits one variant of BBC One.

My understanding of the reason for simulcasting is simply that the BBC want to remain compatible with as much free-to-air satellite equipment as possible, and many do not support the idea of switching streams on and off and redirecting to a different PID. You have to have the peak capacity available anyway, there isn't something else that can be switched off when local news comes on, so it's a trade-off between having the streams on constantly and sending megabytes of NULL packets.

You could argue that you could use better compression for the regional content, to pack all the regional services into the space used by the single sustaining stream, but a five-fold compression ratio would be unwatchable (the BBC run four or five versions of BBC One per transponder, mixed in with other non-regional services or versions of BBC Two).

0
0
FAIL

Very bad demo

Anybody working with video compression knows that the hardest thing for it to do is handling rapid movement of detailed objects. Just having this dude sit there and barely move is no demo at all; I would have liked to see a such a comparison with a F1 race. Very strange that nobody present made an issue over this; were they all drugged?. One must also consider that there is not much of a comparison to make even if this clip was in 1080p h.264, as any "blockiness" and other artifacts, along with a loss in resolution could be the result of the Youtube encoding.

Very crappy demo, but I hope that h.265 lives up to the claims of 50% bandwidth less than h.264 with the same quality

3
1
Silver badge

Re: Very bad demo

Well I wouldn't be so optimistic, great advances are rare. However it can bring such advanced under new circumstances. For example when you have UHDTV video large block sizes might bring great advances.

0
0
Silver badge

Re: Very bad demo

The hardest thing to handle is actually overlayed independant motion. It really messes up the motion estimation algorithm. There's only one place you encounter video like that naturally, though: Moving water. If you want to see a codec screaming in pain, film some rough water.

0
0

Painful video...

Allt the technical reasons notwithstanding, it was cringeowrthy seeing the presneter try to muster some sort of enthusiasm...

I wish those guys would just report on things, rather than try to gather excitement from a croud which REALLY can't be arsed...

0
1
Bronze badge
Thumb Down

shittest demo of all time

man - that's like a Boots 'before and after' nano-makeup mince advert that !!

have cisco never heard of colour correction ? WTF is the point of asking people to tell the difference between 2 streams when you havn't even managed to get them colour balanced!!

And as the other commentards have already pointed out - a fucking demo of 'amazing new codec' where nothing fucking moves in the pictures..... jesus christ.

here's mine - on the left is a jpeg - it took 200kbit for 1 second, then fuck all... and looked the same.

arseholes.

stu

3
1
Facepalm

Worst demo ever

So much potential, so little delivery. It's for video goshdarn, don't show me near static content. And correct them colors! Bleh!

1
1
Anonymous Coward

While there are companies like Broadcom that would like to make sure VP9 never succeeds, they can't really control it. They might choose not to implement it, what happens if ARM adds it to future designs? What about ST-Ericsson, they could add it to products that compete with Broadcoms. Then either Broadcom has to ignore it and possibly see customers leave or adopt it in their own offerings.

Google could also pull a Microsoft in that the phone needs to support certain features for the OS to be installed or be called compatible. That could put Broadcomm out of being used by handset manufacturers. Many manufacturers would prefer to use one provider for the various offerings. If ST-Ericsson offers chips that support Android, Sailfish, Tizen and WP, wouldn't they prefer to go that route?

1
1
Silver badge

If Google's smart, it'll be pushing VP9 support early, possibly touting decreased costs due to no need for licensing. They were too late with VP8 because too many H.264 devices were already out; now they have a chance to jump in while the slate's still clean.

0
0
Anonymous Coward

* "...software-defined radio..."

Quote of the Decade (SDR): "The Software-Defined Radio will do for effective military communications what the Space Shuttle has done for inexpensive space flight."

While many of the recent hobbyist-grade software-define *receivers* are pretty nice and highly effective; unfortunately in the MilComms world, the SDR folks have been making promises that the SDR technology simply cannot keep.

It was only a few years ago that they spoke of covering 2MHz to 10GHz with one SDR transceiver (implying one power amplifier and one antenna). They spoke of downloading waveforms over the air, implying that the RF hardware would be able to cope with any arbitrary chunk of spectrum, and assuming that (for example) a UHF monopole could be pressed into service as a GPS antenna. They got ahead of themselves with encryption.

By transitioning the radio from hardware to software, unfortunately the hardware become computer hardware and thus becomes LESS supportable over the years. The hardware is typically obsolete before the project reaches (CDR) design review. Even the concept of swapping out circuit cards (tech insertion) can be foiled when the backplane du jour goes obsolete.

In summary - SDR is potentially a useful concept when applied at the IF stage. But one should apply critical thinking to the outlandish claims being made by the SDR folks.

0
0
Silver badge
Coat

This is the downside of hardware accelleration in mobile devices

No-one will bother to support a new / modified standard because you still need to cater for the millions of older devices.

CODEC development slows.

Mines the one with the new format graphic accelerator physical interface under the battery.

0
0
This topic is closed for new posts.