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