TiVo just released their third quarter earnings. In addition to the typical net loss ($8.2 million this time around), some interesting details on a future TiVo box have emerged:
TiVo and the cable industry have come to an agreement on a blue-print for a retail TiVo DVR using the cable industry’s OpenCable Application Platform that will have full two-way cable service functionality. While the technical specifications are still being worked out, such a set-top box will mean TiVo subscribers will be able to get full access to cable VOD and other two-way cable services. This could also mean that a standalone TiVo offering could fully substitute for a cable operator set-top box. This understanding was communicated yesterday to the FCC through an ex parte filing by TiVo.
In Comcast Motorola TiVo news, boxes are trickling out to non-employees in New England with “full marketing efforts” to commence shortly. As far as pricing:
We are very excited by the emphasis that Comcast has placed on this product within its organization and their plans to aggressively market it at a $2.95 up-charge as well as through packaged bundles and win-back offers.
I didn’t dial into the call, but I’ll peruse the transcript tomorrow for any additional interesting nuggets. Though it’s probably safe to assume TiVo Lovers will have more details and speculation tonight…
I guess that’s good news. I just finished paying off my Series 3. I can’t wait to get the Series 4 and have the next, better model come out a few months later for half the price.
Seriously, though, I hope that we see a large selection of boxes that offer viable alternatives to cable company’s boxes. More compitition (hopefully) means better products at lower prices.
Hmm, this doesn’t make much sense.
If the TiVo was OCAP then wouldn’t it use the Cable co’s software instead of TiVos. Obviously the Comcast TiVo software would be the exception.
Once again, continuing to be bummed by the lack of a DVR with a decent feature-set for satellite customers.
You’d think they’d want to cater to a more affluent audience that doesn’t mind paying whatever to get what they want out of TV.
What he said.
I understood that the biggest issue with OCAP was it had a whole UI. Now maybe they could do some kind of “VM” type thing with it, where you could switch between the Tivo UI and the OCAP UI or something, to allow you to watch On Demand movies say or to use some Cable Company service like yellow pages. And switch back to Tivo when you need to.
Seems like this might be more complex than its worth, at least for most people. Guess we’ll see…
Don’t blame Tivo for not having a newer generation box for SAT customers. Blame the SAT companies who wont let tivo in.
I have an S2 box (RS-TX20) that works just fine attached to a satellite receiver. There is no option like that for S3 and it doesn’t look like there will be one for S4 – that’s hardly the fault of satellite providers.
Wait, a $2.95 upcharge for a TiVo-enabled Moto box? I ditched my Comcast DVR when they sent me a letter saying the cost for leasing it each month was going to be raised to $15. Since I would pay that for TiVo service, and actually get an interface I liked and a remote control I didn’t want to smash against the wall, I bought a TiVo HD. So now Comcast is going to charge $15+$2.95 for their crappy hardware and a pretty TiVo face. For what? On-Demand which sucks if you don’t have a premium package? Pardon my french but eff that.
People lament TiVo’s service fee, but it’s $15 I would otherwise be giving to the cable company for a product that infuriated me. The $300 premium of buying the hardware is worth it.
With the price increases for DVRs, cable is giving TiVo a nice umbrella under which to take some share with the TiVoHD if they only know what to do with it.
Thanks Dave, I finally got my post up – I was at a client site all afternoon.
Oh Ben, once again your failure to understand OCAP (while continuously attempting to speak about it intelligently) is startling for a man of your self proclaimed “expertise”.
I wish SOMEONE would explain OCAP in plain english. A common conception seems to be that OCAP brings the cable company UI with it — that is, if I have an OCAP enabled TiVo, I will be forced to switch over to I-Guide or whatever ugly interface my cable co uses. I don’t think this is necessarily true, however, I also understand that it’s not exactly a “low-level” process, as it’s Java based and Java is almost always processor intensive and sluggish. All the cable co documentation about it isn’t really written with Joe Home Theater in mind, so can anyone explain it in simple terms?
razor – Normally that is what OCAP means. OCAP is a Java-based application platform, and typically an OCAP device is simple an empty vessel that the cable MSO fills with their software, downloaded to run on the OCAP platform. So normally a device that supported OCAP would not have its own UI, it would have the cable companies OCAP application software pushed down to it and you’d get the cable MSO’s UI. So an OCAP device from vendor A and an OCAP device from vendor B would have *identical* UIs – both would show the cable MSOs software.
But if you read the few details TiVo released via their FCC filing, what the compromise they’ve reached with the NCTA means is a relaxation of these requirements. A device created under the compromise would be something of a hybrid. It would run its native UI to access linear content – pretty much what a unidirectional CableCARD host device can access today, plus SDV. (Though such a device would not need the dongle, as it would have the upstream communication capability built in.)
However, it would *also* be capable of hosting OCAP applications, and it would switch to ‘OCAP mode’ when the user accessed one of those areas – such as VOD or PPV, or any advanced services the cable MSO might offer via OCAP. I’ve seen demos of OCAP applications that include email, voicemail, weather, movie listings, etc.
So the unit would have two ‘personalities’, one native and one OCAP. If you have two such devices from Vendor A and Vendor B, they’d have different ‘native’ personalities, but identical OCAP personalities as both would share the cable MSOs OCAP apps.
So this is a compromise on the part of the cable industry – which, until now, has insisted on full OCAP support with no native applications, and the consumer electronics industry’s DCR+ proposal, which had *no* OCAP, and instead proposed a new set of interfaces to allow 100% native access to all functions.
Full OCAP would limit innovation and remove consumer choice, while DCR+ would delay devices by a couple of years, most likely, even after an agreement were reached – which didn’t look like it would happen any time soon. So this compromise seems pretty reasonable and I think it is good for consumers, the cable industry, and the CE industry.
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.
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…
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?
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.
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.
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.
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? ;)
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