Comments on: Details on TiVo Series 4?

By: cableric

cableric — Fri, 07 Dec 2007 03:14:16 +0000

MegaZone – Eh, we’re talking apples and oranges here. Although you are well informed on some aspects of OCAP, on others you’re off base. Anyway, unless you work for CableLabs, Unisoft, Vidiom, Guideworks, ect. you’d have no idea what a universal plug-in is, so don’t feel too bad.

I’ve got to stop bringing work home with me…

Cheers,
cableric

By: hdtivo

hdtivo — Fri, 30 Nov 2007 18:40:55 +0000

When people have these OCAP Series 3 Platform TiVoes in their homes, how long before they start saying we’d really like to be able to [i]initiate[/i] the VOD/PPV in Cable mode, but then switch to TiVo mode to actually watch it?

How long before people say, well, I really like the TiVo interface so I don’t use PPV/VOD as much as I would if I could watch it in TiVo mode?

By: MegaZone

MegaZone — Fri, 30 Nov 2007 01:10:21 +0000

Razor – OCAP was created because the FCC mandated that cable open their systems to other HW providers. But they didn’t mandate a way to accomplish that. So the cable industry did what would cause them the least amount of pain – keeping the same head end systems and introducing a universal application layer that would allow them to deploy whatever applications they needed to support their existing systems. It wouldn’t been a lot more work for them to create a standardized API for all the cable systems, since there are many different systems, to allow CE vendors to code to that one API. That’s what the CE wanted with their DCR+ proposal.

For some CE vendors, it is fine – like TV vendors. They don’t have an existing UI, so OCAP allows them to access additional services, like SDV, VOD, and PPV, which they were previously unable to access natively. But for CE vendors like TiVo, or PC vendors selling Media Center PCs, etc, this was unacceptable because the main features of those products is the software. So allowing the cable companies to replace the software utterly destroys the value of the products. Which is why this compromise is important.

By: MegaZone

MegaZone — Fri, 30 Nov 2007 01:05:12 +0000

The VOD vendors are being *required* to support OCAP. Time Warner and Comcast have both stated that they will be moved to OCAP boxes by the end of 2008. Their VOD vendors have to get on board or get kicked to the curb, no choice. There is no need for a universal plug-in – that’s the point for OCAP. Each MSO can have a unique plug-in. As long as it runs on OCAP and talks to the local head end, that’s what OCAP is all about. The idea is there is no need for standardized applications, because the platform is standardized.

One of the main points to OCAP was avoiding the need for a standardized interface. It isn’t little known that CableLabs didn’t specify standards for a universal plug-in – it is VERY well known, since that was the entire point to OCAP. *NOT* creating a standardized interface to services like VOD or PPV – but rather creating a standardized *platform* that can support the variety of different applications needed to talk to the variety of back-end systems and to allow each MSO to deploy customized applications.

Even if Comcast and TW had the same back end, the OCAP app could be completely different because each MSO may want a different user experience.

By: razordullwit

razordullwit — Fri, 30 Nov 2007 01:01:57 +0000

I suppose that is a halfway decent compromise. Why CableLABS ever thought that people would want to pay for their own cable boxes that ran the same crappy interface that leased boxes run is beyond me…or maybe they knew they wouldn’t, and that was the whole point in the first place.

By: cableric

cableric — Thu, 29 Nov 2007 23:57:27 +0000

It’s not so much the MSO’s building the VOD plug-in as it is the VOD vendor building a plug-in that the MSO would then host on their local OCAP server. When an OCAP device connects to the MSO’s network the plug-in would be loaded (in this case) to the TiVo. The plug-in would be specific to the VOD vendor, in our case C-COR, but would adhere to an OCAP standard for VOD. The only thing that’s really happened is TiVo is preparing to accept a standardized plug-in for video on-demand services. Have any VOD verndors done this? Last I heard, no. This largely stems from a little known fact that CableLabs never specifically addressed creating a set of standards for a universal plug-in. Guidworks build a universal plug-in…but whether or not they will license to others is questionable. So how open is OpenCable when I company (or two, as Guideworks = Gemstar + Comcast) owns the key?

By: Dave Zatz

Dave Zatz — Thu, 29 Nov 2007 21:58:09 +0000

cableric brought up an interesting angle to this discussion on Gizmodo: You’re also talking about getting the big three VOD vendors on board with an OCAP application. Right now C-COR (Now Arris), SeaChange, and Concurrent don’t have OCAP applications for a product like this.

So even if this DVR has dual personalities, what universal OCAP interface is going to live on the cable side of it? Or is each cable provider going to have to build or license their own mini-platform with hooks into various services (or stand alone apps) such as VOD.

Also how will companies like Digeo (Moxi) planning retail DVRs feel about this proposed solution? Hmmm…

By: MegaZone

MegaZone — Thu, 29 Nov 2007 21:26:22 +0000

Oh – and Java is not always processor intensive and sluggish. In the early days Java was a lot slower, but over the years not only has hardware sped up several orders of magnitude, but the Java Virtual Machines have been greatly improved with a lot of speed enhancements, not the least of which is Just-In-Time compilation.

Now, on a PC a Java application is pretty much always going to be slower than a natively compiled application. The native application is compiled into byte code that runs natively on the processor. While the Java code is compiled into Java byte code which runs on the JVM. The JVM is implemented in native code, but it needs to interpret the Java byte code on the fly and translate it for local execution. That step adds overhead, so even the most efficient JVM can’t be as fast as native code. But the overall penalty is much lower today than in the past, and it is a tradeoff with the benefit of ‘write once, run anywhere’ – being able to release one application that will run on multiple platforms and not having to port it to each native architecture.

But, even better, on specialized hardware the JVM can be implemented in the hardware itself. With Java-enabled CPUs the Java byte code is executed natively. It *is* the native code, so there is no need for the JVM to translate – so that overhead is gone. In that case the Java byte code is just as fast as any other native code. And there are chips for set top boxes with native Java execution, so it depends on the box and the chip used as to what the performance is.