[Justin Thyme]

... how does the OCAP middlewear effect TiVo?

What is OCAP and why is it bad?

I don't see why CEA vendors should have to support an entire proprietary operating system (OCAP) and proprietary Network just to register a crummy OK button click for PPV or VOD.

There has been a lot of discussion and curiousity about what importance of OCAP is in being about to watch TV our way. I have made an attempt here to put together the picture as I see it. I have no clear idea of a solution to the problem presented- all I am doing here is attempting to describe the situation. Although it has rather vast implications, the essential details are simple. How this struggle plays out affects Tivo in profound ways.

Looking at this historically, when you have a dumb box on the end of a wire, the cable company traffic is one way. The Cablecard 1.0 spec supported that set up. The cableco headend server is just pumping data down to the box and the box decripts it and plays it. Once the box gets some more powerful processors, more interesting things can be done. Software can run on the box and send messages back to the Cable Company servers. This could be something simple like requesting a VOD channel, to something more complex, like running an interactive guide or a channel specific app like a Home Shopping Channel bidding/ order entry application. So having some kind of software is essential for these new kinds of services. At present, in the US there is an impasse between the cable companies and the consumer electronics companies. Elsewhere, other software is being used and the impasse has been solved. The essense is that the CE companies do not wish to be the victim of an operating system dominance scheme.

The objective in Operating system wars is to create a situation where all third party vendors are creating sofware, hardware and services which depends on your operating system Software. This was the basis of major battles of recent history- like MSDOS versus DR-DOS (digital research dos), Windows versus OS/2, Windows versus Netscape and so on. OS struggles have vast implications.

It is true that both Netscape and OCAP occupy middleground between the low level operating system and the application software that the user is interacting with, but they fall into the same operating system dominance strategy because it is not the position in the hierarchy that is crucial, but whether the applications are dependent on their Layer, rather than someone else's.

Being able to define the dominant software API is critical to controlling the fate of the class of consumer electronic device that uses it.

In the mid 90's, Microsoft assembled the Cable companies in Redmond and proposed that Cable Companies use Head end and Set top box software which would do many wonderous things which are only now appearing today, such as Video on demand and the capability to copy video locally to an STB.**** By 1997, MS had purchased 1 Billion in Comcast stock to grease the deal. But the proposal to put it mildly was most unwelcome. After a crucial presentation by Gates in 1997 in New York, Cable execs exclaimed "I don't want to be Bill Gates' next download", with full suggestion of the brown shade of download which would be recieved. Malone stated at the TCI meeting shortly after, ""Bill Gates would like to be the only technology supplier for this whole evolution. We would all be very foolish to allow this to happen." source

But they liked the strategy. CableLabs was created to essentially reinvent and control the standards in their own way with their own proprietary and patented technologies. They would control their fate by controlling the hardware specs (eg cablecard) as well as the software layer (OCAP). Further, by controlling operating system software embedded in devices like TVs, they could expand their influence by providing the OS for CE devices- the role that Gates covetted. Gates didn't have the content leverage over the CE companies. Cable did.

The implications for control of the OS in the living room are enormous... You have a horse betting program written in OCAP, and so if the gambler gets hooked on it, the consumer wants to have it on their portable device- so naturally any vendors that want the application must license OCAP from cablelabs. Naturally, the OCAP data feed in such a product scenario would come from the cableco, and the consumer must pay for that. It is a lucrative situation with a high degree of leverage.

If the internet didn't happen along, we very well could have been interacting on proprietary closed cable networks rather than on an open nonpropietary network, with the attendant social goods in the internet case of the absence of boundaries of a global network where no single entity is in control or can dominate.

In europe and asia, the possibility of such OS domination by a single entity was prevented by using an open standard. In these countries, Ocap's function is filled by DVB-MHP and is used both for cable and satellite interactive digital TV applications. Although based on MHP, OCAP is controlled by Cablelabs, a consortium controlled by US cable companies.

Independent CE companies do not want to see themselves get subjected to the kind of abuse of dominant market position that a certain software company has lorded over the computer industry. In the US, if a CE company wants a television that provides the full range of entertainment services, then they are being told by cablelabs that they must license and support OCAP. There is a class of CE companies who cater to the needs of Cable companies who buy billions of dollars of set top boxes- these include NDS, Thomson, Motorolla, and Scientific Atlanta. These companies are very eager for cableco contracts and openly embrace these competing OS's. Third party vendors not involved with such contracts, and who like Sony, Panasonic, and Toshiba instead manufacture alternatives to carrier boxes take great umbrage at attempts by the cablecos to cast their participation in the Cablecard/OCAP discussions as signifying endorsement in any way of OCAP.

Example Snippy little note from Sony to the FCC about OCAP BS here.​

There is no technical reason for requiring OCAP in particular or even Cable proprietary network technology to switch channels- such as for VOD, switched channel, or PPV. The cableco's are using dominance in content delivery to leverage themselves into the provider of system software for the devices that CE companies build. To do that would be to surrender control.

Others are also avoiding the cow pie. In FIOS, Verizon has used fiber as a transport for a conventional one way cable system. But they have avoided the cable company's strategy of proprietary lock on technology by entirely avoiding use of the cable protocols for interactivity. They are using Internet Protocol transport (IP) instead for communication back to the video headend server**. AT&T (nee SBC)'s fiber system is using IP entirely. Since it would have been foolish to rely on protocols controlled by cableco competitors, these two telco's chose a vendor whose interests did not compete to a high degree with theirs.

Microsoft TV, take 2. Although Verizon has chosen a hybrid scheme of two different MS OS packages, this is for transitional purposes only, and both AT&T and Verizon FIOS have chosen Microsoft TV IPTV edition as their long term software platform. Although Microsoft has its own software dominance scheme, the telcos are more comfortable with MS's business model does not compete with theirs as the cableco's do. Theoretically, the telcos could switch horses to an Apple OSX, but Apple so far is no show in the living room. Alternatively, the telcos could go with DVB-MBH or choose to each roll their own proprietary scheme and control their own fates at the expense of interop with other CE devices. Microsoft's CES2006 demonstration of creating a branded experience on third party portable devices (with DirecTv) was a signal to carriers of the lost benefits if they choose an OS isolationist stance.

Ultimately, the world is moving to devices that can access content from a variety of content vendors, and so the interaction protocol and programs will have to be more generalized than those defined by particular content vendors.

When you look at what the OCAP, IPTV, and DVB-MHB software is doing- guide, navigation to multiple sources of content, player of music, photos, and a high level language for interactive applications, the feature list bears a striking resemblance to one we here are all familiar with. This little guy has a lot of Chutzpah.

Advocates of the protocols or language of one vendor over another oftentimes are unknowingly acting as proxies for rather large companies whose business interests and practices have a minimal degree of overlap with the best interests of consumers.

** See Verizon filing with FCC, Page 6. They are Cablecard 1.0 compatible with interactivity sharply divergent from Cablelabs' cablecard 2.0 proposal. Some mention of the motivations on page 8.
**** More information on this little MS debacle here

 

[davezatz]

TiVo has an opening for Director of Software Engineer... familiarity with OCAP is a plus.

 

[TechDreamer]

Thanks for the info, it was a nice read.

 

[dt_dc]

Re: "Open" telco (Verizon/SBC) IP/Ethernet/DVB vs. "Closed" cable DOCSIS/QPSK/OCAP ...
Please, please don't feed into this hype.

For Verizon (and cable) this is a hardware / architecture issue and ultimately cost / perception issue. It's not a question of "openess" and "standards" ... or "closed" and "proprietary".

Verizon and cable have some disagreements ... but quite frankly other than some rhetoric being thrown around ... "closed" vs. "open" and "proprietary" vs. "standardized" has nothing to do with it ...

1. DOCSIS/QPSK (cable) vs. IP/Ethernet (Verizon)

IP/Ethernet vs. DOCSIS/QPSK for plug and play / CableCard standards comes down to this very simple issue ...

DOCSIS/QPSK standards means Verizon has to spend $$$ (or convince CE makers and consumers to spend extra $$$ for "standard+Verizon").

IP/Ethernet standards means cable has to spend $$$ (or convince CE makers and consumers to spend extra $$$ for "standard+cable").

DOCSIS/QPSK + IP/Ethernet standards means the CE companies and consumers have to spend extra $$$ for "Verzion-and-or-cable-standard".

Really ... honestly ... it's that simple. Which standard supports/compliments an MVPD's existing architecture. Which standard will force an MVPD to spend extra $$$ to support it and is uncomplimentarty with their existing architecture.

Also, both methods can just as easily be used for (what I think you would consider) a "closed / propietary" network as for an "open / standard" network.

We can explore this some more ... but trust me. This has nothing to do with "closed / propietary" vs. "open / standard". Don't buy the hype(rbole).

2. OCAP (cable) vs. something "in progress" presumably DVB-MHP or something very similar (Verizon)

Well, hard to say without somthing concrete from Verizon. But really. OCAP and DVB-MHP are both based on the DVB-GEM spec. CableLabs went to the DVB Project and asked them how to remove the DVB-specific sections of MHP and make it applicable to existing US cable systems (without millions/billions in plant re-architecture). DVB came up with GEM which would allow for that (and allow for other region-specific issues to be addressed). CableLabs is doing exactly what the DVB Project laid out for them to do.

The difference between the European (DVB Project) and the US (ATSC/CableLabs) is (again) NOT "open" vs "closed" or "proprietary" vs. "standard" or anything like that.

The difference is that in Europe there's a single DVB Project while in the US this function is split between the ATSC and CableLabs (and now, ATIS). Yes, the telcos have their equivalance to CableLabs. It's ATIS http://www.atis.org/.

Cable-controlled CableLabs is laying out their vision (preferable to cable companies) ... telco-controlled ATIS will be laying out theirs (preferable to telcos). That's it ... that's the difference.

Don't paint this as "cable vs. telcos and CEA".
It's not. There are two very different things going on there.
- cable vs. telcos
- MVPDs (cable and telcos and dbs) vs. CEA

The first battle really isn't very interesting. Each side has the same fundamental arguments / goals / results. The second one however ... is much more interesting.

 

[Justin Thyme]

I most certainly did not mean to imply a favorite among any of these. I am not waving the open standards flag. If anything- I am waving the interoperability flag/ not letting any player achieve dominance flag.

"Open" DVB-MHP doesn't support MP3, MPEG-4, no XML parser support... The ISV is also told that very likely any files they wrote to persistent store won't be there next time they are executed. Sounds like a pretty crappy software environment for multimedia to me. I mean really- no MP3? Maybe the EU commission or whoever came up with this thing just couldn't agree if MP3 was better than raw wave files...

Regarding transport mechanisms, if the goal is to allow third party navigation devices that can access multiple sources of content, then any box will have to support IP- either by modem or 100BT I think that is what ACAP (ocap for atsc) is doing. DBS needs an alternate return path, and the telcos are using IP. Ok fine. They all need an IP server api for requesting VOD and PPV and Switched channels.

To do this, why is this not just a fricking API called via HTTPS secure connection in the example of PPV? Like- here I am- here's my authentication... I want this channel, agree to pay. Done. The software that calls that server api? Why does anyone have to specify. It could be called by a COBOL app. Who cares. And whether it is HTTPS- who cares. It's there and it works for banking so why listen to any requests for 5 years to invent a new security protocol. Really- it's not the point that HTTPS is an open standard- it's just that it's there and it works so why reinvent the wheel.

Beyond whether you use existing protocols, the key question to me is why you need to require any of this heavy weight client support at all for something that could be answered with a client-software-agnostic server call.

I see why you need all this stuff to download arbitrary apps like a Pizza application from the server and know it will run on everyone's devices, but PPV, VOD, switched channels? I see no technical justification why you need MHP, OCAP or MS IPTV to do it. Yet people are told they must have MS IPTV or OCAP if third parties want to be able to navigate their content.

The carrier comes out with a new service- they publish the server API spec and are required to use that API for operation of the feature. MS, Apple, Sony- whoever devices can support or not support those new APIs if they so choose and they can access those apis with whatever language or client implementation they choose.

Maybe there is a technical rational for all this client (set top box software environment) Junk. I just don't see it.

 

[AtomicDecay]

This might not be the right thread to ask this question, but I'll inject it anyway...since it got me thinking and I don't recall seeing it addressed in the other Series 3 threads.

With the specs released so far, would the Series 3 support the above mentioned FIOS/teleco system?

 

[dt_dc]

Ok ... yes ... now you're getting into what I called "MVPDs (cable and telcos and dbs) vs. CEA"

Just to reCAP

Lets say you wanted to build a system to allow consumer availability of navigation devices for interactive services ... hypothetically

Ok ... lots of ways someone may want / think / whatever to do this. But I'll break it down into two.

1) "API Style" (Edit: previously labled "Open and inflexible")
AKA the "API" method talked about by JT above. Also what the CEA is advocating.

Give CE makers an API and they will use it. Or an XML schema via HTTPS. Or some standardized OOB signal / protocol via QPSK. It doesn't really matter.

If we look at a specific example ... like a program guide ...

Tivo and Sony and everyone else has a way to get the actual guide data. Maybe there's a getGuideData(date) API call that returns guide data objects for a specific date. Or maybe they call https://guidedata?date and get XML back that they can parse for the data.

It doesn't matter.

The point is that Tivo (and Sony and everyone else) has access to that actual guide data and can do what they want with it. Present it on-screen as they want. Make it blue ... make it green. Search it ... sort it. Heck, mix it in with other content (like downloadable content from the internet) ... whatever. The user gets a guide.

The cable company feeds up the guide data. Tivo, Sony, other CE companies, whomever are free to do with it as they wish. Cable doesn't have much say in the matter.

2) "VM (Virtual Machine) Style" (Edit: previosly labled "Closed and flexible")
AKA the "heavy weight client" talked about by JT above. Also what CableLabs is advocating.

Give cable a standard software environment and they will use it. Or a virtual machine or whatever you want to call it.

If we look at a specific example ... like a program guide ...

Tivo and Sony and everyone else provides a standard software environment. Cable-provided software runs in that environment. The user gets a guide.

The point is that Tivo (and Sony and everyone else) don't have any access to the actual guide data. They can't really do anything with it. It's presented on-screen as the cable company wants. It's blue or green or mixed with other content ... based on the cable company provided functionality.

The CE companies give cable a standard software environment. Cable is free to do with it as they wish. Tivo, Sony, other CE companies don't really have much say in the matter.

No brainer you (and many others) are probably saying ... I take option #1
Obviously the better choice. You got the "open" part right ... but why the heck do you call it inflexible ...

Notes
- I could make an argument for (and against) either of these approaches
- CableLabs / OCAP and DVB / MHP both lend themselves equally well to either approach. The standard bodies are usually smart enough to keep out of this and leave it as an "implementation detail"

 

[Justin Thyme]

This might not be the right thread to ask this question, but I'll inject it anyway...since it got me thinking and I don't recall seeing it addressed in the other Series 3 threads.

With the specs released so far, would the Series 3 support the above mentioned FIOS/teleco system?

Surprizingly, Verizon has indicated they have lined up a manufacturer for a plug and play POD (cablecard security device) in a presentation to the FCC last october (see slide 8). However the device is using DVB, so Tivo would have to write some more code to assure compatibility.

I suppose it is not so surprizing if they are actually doing cablecard support- after all MS is a close partner and has gone to huge effort to be able to have MCE computers able to use cablecards. It would be a raw deal if their computers couldn't access FIOS for usage as a dvr.

• We selected an open standard (DVB) for our digital video delivery
• Our supplier has developed new PODs for us to support the DVB open standard
• Our deployment supports One-Way PnP

More detail discussed in TCF thread here.

However, as far as I know, there is no definitive document that says FIOS will support all cable card devices, some devices, or only some specially modified cablecard devices.

 

[vman41]

Seems to me that the model for OCAP is what they did with DVD players. The content provider (DVD publisher) is given cotnrol over the user interface for accessing the content.

 

[Justin Thyme]

Let's see if that's a close analogy.

first off- the dvd player has no UI to be replaced,

secondly, the dvd vendor is in no particular position of market dominance due to factors favoring a technical monopoly (eg. limited geosync orbit locations, limitted airwaves bandwidth, limitted ability to run wires to all homes),

thirdly, the dvd UI is not software, but a set of static menus. What is being required here would be as if dvd's actually ran software of a language of their own choosing- and they could say to play our movie you must implement our variant of unix so that it will play our dorky menu so the consumer can play the thing they really care about- the movie.

It is as if MGM required a computing environment on the dvd player with an operating system that the MGM specifies but the dvd manufacturer must port to their hardware.

Oh yeah, and then Warner brothers gets to specify a different language/ operatiing system of their own invention if they want. That is, DirectTv could do something different than OCAP, FIOS could do something different, Dish could....

Is that anything like DVD players?

 

[Justin Thyme]

I got the impression you are leaving the inflexible explanation for another note. Maybe I could anticipate the association the inflexible objection. The issue is not standards bodies determining specs "open", the issue is whether the server api used is public and accessible (not hiding inside a proprietary network). Consider the following Public but closed flexible scenario:

Let the Cablecos innovate- do their competitive thing- define their server api however they want. Like Windows APIs, it's not set by any publically accountable standards body etc. They just do what they want.

Very flexible. Like Apple, they can change their system API all they want. They won't make a totally unstable specification for business reasons- but if they wanted to change the api every year, then fine- they have that flexibility.

They just have to use the server API they publish, make timely notifications of upcoming changes.

Carrier is free to sell navigation devices using the UI they feel their consumers want to have.

Competitors are free to build a navigation device that also connects to the carrier's network and can access all of its non software content but presents a different UI. If they want to present the cableco software content, they can do that too, but they have to support OCAP.

Other carrier groups like the Telcos or the DBS providers can define their own APIs.

Now, you may notice a similar theme to another case where leverage of one set of products is used to gain advantage in another. Essentially, Microsoft is being required to not use its operating system advantage to favor other unrelated products. If people want to buy their SQL database, then fine, but if people want to buy just their OS, and a different database, then the third party database should have the full access to the operating system APIs that the Microsoft SQL database product had.

The principles seem directly transferable to the case with carriers.

Carriers want to bundle software with content- that's fine. If that is what customers want then more power to the carriers. But the carriers should not be able to engage in product tying- the practice of using the demand for their video to leverage their software into everyone's living rooms. If some third party vendor thinks that people want just the video without the goofy software, then fine- their product should have the technical api specification necessary to provide access to all that video content in the same way that a third party telephone vendor has all the necessary specifications to build a phone that can be plugged into any wall outlet and work reliably.

All the vendors need are the server APIs. I don't see that they need to be open- just public. I don't see that they need to meet some arbitrary measure of Computer Science quality- the Carrier simplly needs to show that the apis constitute all the ones that their software is using.

I don't see that the industry has to converge on be all end all standard. It wouldn't be a huge deal if to select a PPV movie there are 4 different sets of apis- for telcos, 1 for cablecos, 1 for dish and 1 for direct.

I just don't see where the huge issues are for doing Server APIs other than the Carriers insisting they have a right to tie their software to their video entertainment.

 

[11274]

It's not clear to me how comprehensive the OCAP api is. Is it complete enough that Tivo could port their entire functionality on top of OCAP?

I notice that Comcast announced that they were buying between 250K and a million Panasonic OCAP HD DVR's this year.

There has been no announcement of how much Tivo functionality will be available on their Comcast 6412/3412 port. I had assumed that it was partially constrained by the Motorola firmware and Comcast infrastructure. For example, Comcast DVR's don't have persistent guide storage., but current Tivo SA boxes do. Which will the Comcast/Tivo do, or even could do.

With Comcast adding a million OCAP boxes to the mix, does that mean that Tivo must port to this interface, and what limits would that impose?

 

[Justin Thyme]

I will take a swing at some of your questions about Tivo and the Moto box, but so far my assumptions (for example that the comcast deal was for a Tivo UI on top of OCAP) have been totally wrong/ delusional fiction. Take it with a huge grain of salt. Later in the year when we have the benefit of an official announcement, Tivo will make all this stuff clear.

It's not clear to me how comprehensive the OCAP api is. Is it complete enough that Tivo could port their entire functionality on top of OCAP?

Ok. This one I do know. OCAP is java, and so much of what is crucial to the Tivo UI- like trickplay behavior with the remote are too realtime oriented to be implementable in a high level language. But as OCAP is unsuitable to low level features, it is also unsuitable for high level features. The idea that an application cannot count on data that it stored being present when the application returns means you are pretty limitted in the kinds of Apps you can implement. Here is an implementor oriented FAQ on MHP and OCAP.

After you look at it a bit, you might wonder why anyone would want such a half baked API, and what could you possibly build with it. Well- Say shopping channel wants to allow people to look at the product details for a particular item, maybe see a video of the product again, the user can add it to their shopping basket and do order entry- basically an Amazon site with video. I figure you could do that in OCAP. Now. If shopping channel implements in OCAP/GEM, then that application will run on all boxes that have OCAP support. From what I am reading, the GEM portion of OCAP, ACAP and MHP is the carrier independent portion and is portable. OCAP adds Cableco stuff, ACAP adds ATSC specific stuff, and MHP assumes the DVB video standard in use in Europe and Asia. So written properly, the content vendor's application EG shopping channel's "Amazon application" could be ported to an ACAP or MHP carrier. And if the telco's adopted the GEM core, they could have an OCAP for Telcos and the content vendor's ability to port their app would be much easier. Looks like a nice proposition except the telcos are not going for GEM, they are using Microsoft's IPTV, and no one is using OCAP, MHP, or ACAP anyway. (When I say no one- I mean fewer than 5,000,000). The reason is there are tons of digital boxes that can't run it.

So the Cableco's are trying to imply some momentum towards OCAP with the CES announcements of major purchases, and the FCC PR letters that suggest Sony is on board- a suggestion Sony took such rude offence to in their letter.

Remember, this is the same Sony that is advancing Blu-ray, which incorporates a Java (BD-J) engine for interactive bonus material content using what? You guessed it- the GEM (Globally Executed MHP) core.**

So what are they so pissed off about with OCAP? As far as I understand it (still fragmentary, it is that the current Cablecard2.0 OCAP spec creates a Virtual machine for the Carrier's UI- so that whether a customer had a Sony HD cablecard DVR, or a Toshiba 50 inch cablecard plasma screen, it would function as if it were a machine identical to the carrier provided boxes.

Although I suppose the CE company's like the idea of Amazon type application portability, they don't like this darker side of OCAP which is that it turns the CE device basically into a slave of the carrier. From what I understand (and this may be bogus), the carrier can download their UI, their guide, totally hijack the Television, DVR, STB. The CE companies want to differentiate their products and do that in their UI and integrated services, but basically the Carriers want all third party devices to be clean slates- and OCAP does that.

Anyway- It's all the grand vision of interactive TV- at least according to the carriers. But the CE companies are seeing multiple sources of content and the need for a UI that can navigate between these multiple sources. Naturally, each carrier is not going to welcome initiatives that make their form of ITV just one of many. While "no one" uses OCAP, there is one place where lots and lots of people doing ITV right now. It's called the web. These web sites aren't using this hobbled and oddball GEM common layer, and they are running them on hardware platforms a LOT more heterogeneous than devices capable of running OCAP.

I guess that is more than what you asked. But no- you couldn't do the Tivo UI on it. But OCAP support to a Tivo would allow the Cableco to turn your Tivo into a Adelphia UI or Cablevision UI or whatever- because that what the consumer wants, right? A Cablevision virtual machine.

I notice that Comcast announced that they were buying between 250K and a million Panasonic OCAP HD DVR's this year.

There has been no announcement of how much Tivo functionality will be available on their Comcast 6412/3412 port. I had assumed that it was partially constrained by the Motorola firmware and Comcast infrastructure. For example, Comcast DVR's don't have persistent guide storage., but current Tivo SA boxes do. Which will the Comcast/Tivo do, or even could do.

Megazone stated it is a native Motorolla application. He and Tivo personnel have stated it is intended to be a full port of the Tivo experience. With a multigigabyte hard disk, and the power of running natively on the Moto box, yeah- I think they can manage persistent guide storage. Someone familiar with any shortcomings of the dct6412 might comment on some features that might be challenges for Tivo.

With Comcast adding a million OCAP boxes to the mix, does that mean that Tivo must port to this interface, and what limits would that impose?

I tried to answer that in the ramble above. The cablecos are trying to give the industry a sense of momentum, just as Microsoft is. So whether those are indicative of real trends or boondoggles is a matter of conjecture. What really matters is how the market reacts to ITV applications and which compelling applications emerge. And mind you, there are significant doubts that consumers much want to interact sitting at the couch rather than at their computer. But if some trend does emerge, then CE companies will want to provide support for those sorts of applications. Some vendors like Apple will eschew standards except for their own that traffic to their content. Tivo has a Java machine already, and technically should be able to react should some cross platform ITV compelling applications arise. The [Edit- BCM7401/BCM3255 (see footnote)]****- the likely chip pair for the S3, has support for BD-J, and at CES they annouced a Tool deal with Sonic, so theoretically they are positioned well for BD interactivity (S3-BD combo box running BD-Java apps).

**At CES2006 there was a bit of a shock when it was announced that first BD devices would not have BD-J interactivity support. The main guesses as to the reason seem to be 1) the Java engine won't be ready in time or 2) the hardware requirements for such a "full profile" box requires a CPU that would push the prices from $1000 (without) to $1800 (with BD-J).
**** SATA, dual smartcard, 10/100BT, USB2.0, 2 complete HD AV channels in and out, sound familiar? source source2 BCM cablelabs announcement [Edit- earlier this read the BCM7411. As mentioned in the August announcement (source2), the 7401 supecedes its functionality. The BCM7401 replaces the BCM7411/BCM7038 chip pair

 

[dt_dc]

I got the impression you are leaving the inflexible explanation for another note.

Yes I was. Although ... thinking about it over the weekend I think I like "API Style" and "VM Style" better. Less leading. (editing above note now)

I mainly just wanted to get the point of "control" accross. Which you obviously get but alot of people don't ...

Anyway, yes you're right. There's nothing (not even your pizza-ordering app) that you can't do "API Style". Yes ... it's all about control and functionality and other non-content ralated issues ... "product-tying".

Going forward a few steps ... why should Tivo (or Sony or Apple or anyone else) be able to sell pop-ups to advertisers while the cable companies can't? Why should Tivo (or Aplle or Google or anyone else) be able to explore different revenue models while cable companies can't? For example, lets say EuroCup makes a deal where their games can be watched free ... if you get some commercials at the start and half-time that can't be fast-forwarded through and a little logo/commercial in one corner during the game. Why should Tivo, Apple and Google be able to make this deal ... but not the cable companies? Why should CE companies be able to product-tie but not MVPDs?

Where CE/cable got into disagreement over the "API Style" was ...

Cable: "Ok, and now we have some meta-data with the content that describes functionality/behavior that you have to follow/enforce."

CEA: "Woah there. We just want the content. We don't want/need to be told any rules associated with it."

Cable: "Ok, that's fine. Just be aware that certain content may only be available to 'certified' apps that follow these rules."

CEA: "Woah there. We need access to all the content. Pay for it or not, that's fine. DRM associated with it or not ... that's fine. But behavior and rules associated with it? No ..."

Cable: "Look ... nothing to worry about. We've made a deal with some advertisers so that when you FF certain content you just need to pop-up an image durring that time. Oh, and you can't put any of your UI over that pop-up so the UI needs to be costrained to certain parts of the screen ..."

CEA: "But ... we were making the same deals with advertisers ..."

Cable: "Oh, and as part of another deal we may have certain content that can't be FF'd through at all ..."

CEA: "But ..."

Cable: "And again ... if you don't want to follow these rules that's fine. Just be aware that certain content may not be available."

Ok you say. CE companies should be able to provide their software without any behavior / rules attached. Cable companies can provide theirs. Let the consumer decide.

The problem is that if cable can provide their software ... they can also make certain content only available through their software. That same "pizza ordering app" that can only run on certain boxes ... well, perhaps Dominos makes a deal where certain content is free if it's also running that pizza ordering app. Otherwise you have to pay for it. Or perhaps, otherwise it's not available at all.

The CEA isn't willing to take that risk either so ...

It comes down to the cable company providing all software ... or the cable company providing none. Or ... the FCC getting way more involved in this spat than they already are and having to figure out exactly what must be open and available to the CE companies.

Prohibiting "product tying" sounds nice in theory. But (almost) no one sees video content as a stand-alone product. Behavior and functionality can be tied to video when it's distributed via media (DVD, next-gen optical, etc) ... via download (Tivo, Apple, Google, etc). So just because someone spends the $$$ to run a cable to your house or put a sattelite in the air ... they can't do the same?

Google's DRM that they announced with their Video service. I'd be a little curious to know what comes with it. One the one hand ... a DRM scheme allows you to make sure you get paid for certain content ... content doesn't get spread around ... etc. OTOH ... having your own DRM that compliant products must license in order to view content is also another way to enforce certain rules / behaviors / and other "product tying" practices. "Content marked with ______ must have ______ behavior."

 

[Justin Thyme]

Windows 95 came with desktop icons that directed users to MSN accounts. Say they had other advertiser links on their desktop. Should their OEMs be able to subtract this content and put on content of their own? Or should MS be able to say- love it or leave it. It's a package deal and you either install it as we built it, or you can go elsewhere. No fair making edits to our IP. The US government answered that.

If OEMS and customers should be able to separate software + content in the MS case, then why shouldn't they be able to in the content + software case?

If a browser has an option to disallow popups with advertising content, should that be illegal? It is the web site owner's content- and they pay good money for putting that content up there. They pay for that with advertisements. So is it unfair of some browsers to muck with their livelihood? How far does government protection of the particular presentation of content go? In Japan, the head of the broadcasters association claimed that FF over adverts was copyright infringement.

Take a case of more explicity dividing of content from behavior. If a company writes a program to display data (say just the text) on the Encarta DVD without use of Encarta program, should that illegal? User purchased the DVD, are they precluded from using an alternate software package? Should wordperfect be prevented from displaying Word files?

There is an often commented on evolution from classic monopolistic practices. People can say: A is not a monopoly because there is alternative product B. But this dodge is still very effective because if you buy into A or B, you are locked in because A only works with A compatible hardware, and after you have bought enough A compatible things, there is no way you can afford to switch to B. Call them whatever you want, pseudo vertical monopoly fiefdoms- whatever. It's anti competitive behavior.

Now, let's take a look at a favored mechanism of using one product to leverage another. Proprietary DRM, or "behavior with data"(ocap). Same principle. Consumer buys a portable video player. But the device only supports a proprietary DRM that is not licensable by any other company. So the only source of protected commercial content is from the same company. Bingo. Fiefdom. One way to deal with this is to say- fine you have your proprietary DRM and all, but if you don't want to license it, then you must support in your portable player at least one other DRM licensable by all competitors of your Video store business. You can't tie unrelated products.

So how does that apply to OCAP? In the above case, software in the hardware drives customers to one content provider. OCAP is in reverse- dominance in content drives software into hardware. So the analog to the DRM solution is to say fine Cableco's- you can sell all the content + behavior product you want, and make it work real dandy on hardware you provide either directly or through your surrogates. But you may not use your content to leverage yourself into an unrelated product category- OS software on entertainment platforms.

The way to prevent software vendors from using dominance in system software to leverage their way into unrelated applications businesses is to require them to document all the APIs they are using.

Cablecos may advocate the benefits of their client software, but access to their servers must be through public apis and a network that competitors to their client software may use.

 

[dt_dc]

If a browser has an option to disallow popups with advertising content, should that be illegal? It is the web site owner's content- and they pay good money for putting that content up there. They pay for that with advertisements. So is it unfair of some browsers to muck with their livelihood? How far does government protection of the particular presentation of content go?

And if a web-site wants to publish content that is only viewable with a certain browser that does not block pop-ups ... should that be illegal? It's encrypted in a certain way and only certain browsers that follow their rules can unencrypt the content. So ... certain browsers and certain customers won't have access to certain content. Isn't that the web site / copyright owner's choice? Does the government have the right to insist / mandate that all content on my web site must be equally available to everyone and every browser?

After all ... I might use my great web site / content to leverage some unrelated product (browser) onto the market ...

 

[smark]

Key point though is that the content is ours.

 

[Justin Thyme]

Hold on a second, okay Smark?

DT- Consider the Microsoft Word example. Can Microsoft put DRM on it's word format and use the DMCA to say that competitors like OpenOffice may not read it's file format because they would be breaking their DRM?

 

[dt_dc]

Take a case of more explicity dividing of content from behavior. If a company writes a program to display data (say just the text) on the Encarta DVD without use of Encarta program, should that illegal? User purchased the DVD, are they precluded from using an alternate software package? Should wordperfect be prevented from displaying Word files?

Yes ... but do we force that divide? Microsoft can't encrypt Encarta data so that only the Encarta program can read it? Microsoft can't hand out free Encarta DVDs and pay for it by embedding liked adverts that the Encarta program respects? Microsoft must use plain-text for it's content so other programs can use it? If I am writing a new word processing program ... I must save the files in a format that Microsoft and WordPerfect (whoever owns them now) can use and import/edit if they want? It's probably in my benefit to do so ... but maybe I'm Adobe with a slightly different take on the model. I want to give away a viewer and only charge for the editor. That should be illegal? Adobe should be forced to let anyone make a pdf editor?

 

[dt_dc]

DT- Consider the Microsoft Word example. Can Microsoft put DRM on it's word format and use the DMCA to say that competitors like OpenOffice may not read it's file format because they would be breaking their DRM?

Can someone other than Microsoft do it if they wanted to? If I wanted to come out with a word processor with DRM-protected files only viewable / editable by my program ... is that OK (or not)?