[popper]

Originally Posted by OLD BOY

I've been looking at a number of websites on this subject and I think there is more to this than meets the eye.

A quote from the www.ambarella.com web site, for example:

'MPEG-2 based broadcast content can still benefit from the extraordinary compression gain afforded by the H.264 format if the technology is used in newly deployed appliances while the already deployed appliances remain compatible.'

"I think there is more to this than meets the eye"
seriously, theres really nothing complicated about this.

Mpeg2 is one codec, AVC/H.264 is a totally seperate and newer codec (thats got a lot more options and even a lossless mode for pro editing etc, that Mpeg2 doesnt), Mpeg2 is NOT compatable with AVC , you need seperate decoders.

the simple answer is if you use an antiquated Mpeg2 codec to encode/transcode your video content and shove it on the wire.

you need the exact same codec on the other end of the wire so that your STB can then decode that video stream... and then shove it onscreen.

the AVC/ H.264 codec gives you on average 2 and a half times the compression that your antiquated Mpeg2 gets, so you save lots of bandwidth, bitrate , and drive storage space by using AVC, you NEED an AVC decoder codec inside your STB chipset to decode that.

NTL were running test of new STBs that could decode both the old Mpeg2 codec, and the far better AVC codec video streams....

TW were later running the so called V+ STBs that only had the old Mpeg2 codec chipset and so it cant decode any AVC encoded video that might one day get pushed down the wire.....

TW did this as they needed a quick fix for a STB that could also save the content locally on your STB as sky were killing them by this time.... they went withthe cheapest option and that was the old antiquated Mpeg2 only STBs that their mates in the US love so much and were them off as end of line.

meanwhile the world STB markets were moving to AVC SOC STBs that also included the old antiquated Mpef2 codec for the transition.....

so , to recap, Virgin media accountants made good short term profits on the books by dropping the far better long term NTL AVC capable STBs, and instead contracting for millions of antiquated end of line Mpeg2 only V+ STBs that couldnt decode the worlds AVC standard.....

in effect saving pennys on the CPE V+ STBs, to now need to spend lots of ££££££ for bandwidth costs, new AVC capable STBs that can take this AVC content, and transcoders that can take the industries generic AVC content and convert it on the fly to the higher bandwidth using antiquated Mpeg2 and stuff it on the wire to your MPeg2 only STBs so lived by lots of the US cable operators even today......

---------- Post added at 06:06 ---------- Previous post was at 05:47 ----------

Originally Posted by ShadowTD

Didn't VM invest in some H.264 -> MPEG2 kit for the headends a little while ago? So HD could be pushed around the majority of the network in the more bandwidth frugal 264, only using MPEG2 for the last leg?

your mixing it up a little, as a basic simplistic outline, the AVC to Mpeg2 transcoders are for taking any AVC content they might be fed from the worlds down sats for instance, and then they can realtime convert these feeds to the antiquated Mpeg2, then place it on the VM wire for your Mpeg2 only V+ and other STBs to decode and view.

sending AVC to your stb doesnt work as you dont have an AVC decoder onboard any of your virgin media STBs.

the newest sky STBs do, for their AVC HD content, as do the new freeview STBS,etc, only Uk VM cable is still stuck on the antiquated Mpeg2 only codec

if VM really cared about bandwidth, and using the internal network " majority of the network in the more bandwidth frugal 264" then yes ,AVC/H.264 would be a good thing, but they can also just use generic Multicasting to the outline storage kit, simple, send one single copy to all client servers listening at a set time over a basic Multicast 224.0.0.1 IP is all they need do, any time, as all the worlds ISP routers and related kit have the generic Multicast protocol as standard and have from day one.....

its a real shame they still go out of their way to filter it off from the end users CPE kit sat on your desks, as we could all benefit, and the worlds devs would havea reason to , and could simply retro fit the old "MBONE" and new multicasting protocol code into all the high bandwidth video streaming apps in a very short time (even todays P2p with muticast DHT etc) if the world ISPs just turned it back on all the way to the users.....finally

---------- Post added at 06:24 ---------- Previous post was at 06:06 ----------

Originally Posted by BenMcr

I think that is basically saying you can record in MPEG-2 but using H.264 compression which saves space - but the end appliances would still only be able to decode MPEG-2

totally lost me there ben , your flow doesnt make sense, if the STB had an AVC decoder, then you would keep it in that format, sending AVC to an Mpeg2 only STB would store it sure, but you couldnt do anything with it, least of all view it.... and the USB ports are mising the generic driver that exists for the V+ firmware so thats out too.... coying to an external USB drive and playing it on an AVC capable box, xbox360/PS3 for intance....

and again you cant stream this AVC stored on any Mpeg2 only VM STB as again, the generic driver to activate the STB Ethernet LAN stack and the existing code for basic networking to your PC has not been installed on the VM firmware/middleware, it does exist, but VM dont pay the fees to include it and thats always been a shame, as it might just about manage that network streaming if you pull it with your LAN PCs rather than push it with the internal STBs underpowered SOC/CPU, multicasting with even the underpowered STB CPU might stand a chance though.