How to get CCI for unencrypted digital channels?

[moyekj]

How to check CCI setting for unencrypted digital channels for the S3?

For encrypted channels one can use the following (Motorola card) CableCARD screen to get the CCI value for a channel:
Messages & Settings -> Settings -> Remote, CableCARD, & Devices -> CableCARD Decoder -> Configure CableCARD # -> CableCARD Menu -> Conditional Access

However this screen is only updated when tuning to encrypted channels. On the same tuner if you tune to unencrypted channels this screen is not updated, presumably because the cableCARD is bypassed for unencrypted channels.

The reason I ask is that a friend with a Cox DVR (DCT6416 w/ Passport Echo) claims he can no longer get firewire extraction to work since CCI=0x02 for ABC HD even though it's retransmitted unencrypted. That DVR has detailed diagnostics screens where you can check for CCI and it does show CCI=0x02 - it used to be 0x00 not long ago when firewire capture was working. Seems odd CCI would be set for an unencrypted channel so could well be the cable company made an honest mistake as other HD locals have CCI=0x00.

My worry is that if/when TTG/MRV is enabled, all channels with CCI set to non-zero value will be restricted, so it would be nice to be able to check CCI for unencrypted channels. I'd like to make a note in my headend spreadsheet (see my sig) of the CCI setting for each of the digital channels.

[moyekj]

Boy, I hear crickets chirping loudly in this thread... I take the lack of responses/comments as no, there is no way to do this with the S3.

[MichaelK]

yup- I found that exactly myself months ago trying to diagnose my CCI problems.

The unencryted channels apparently have NO CCI value since they are unencrypted and the cablecard diagnoses screens are not updated to reflect that- they just keep the last value for you to look at.

[JDguy]

See the reference: SCTE-41 (http://www.scte.org/documents/pdf/ANSISCTE412004.pdf):

Section 1.1:
Content that is delivered unscrambled over Cable systems is not subject to this standard. Indeed, this standard would not provide any protection against unrestricted copying of such content. Any unscrambled content output by the Host on the POD interface will not benefit by scrambling upon its subsequent output from the POD on that same interface.
and Section 2.4.2
2.4.2 RULES FOR CP-SCRAMBLING BASED ON EMI VALUE AND CA-SCRAMBLING
1. CP-scrambling is applied only to protected content, as indicated by EMI greater than zero.
2. All copy-protected content is delivered CA-scrambled to the POD.
Also see Table 7.4-A CP-Scrambling based on CA-Scrambled State and EMI Value which explains that content that is not CA-scrambled should not have any CCI/EMI values.

[MichaelK]

Makes total sense- the way tivo handles it in their ui is the goofy thing.

Instead of reporting the last value tivo should say "NA" or "no value" or better yet "unencrypted content" something like that.

that way people could quickly tell if things are unencrypted.

Right now if you tune to an encrypted channel that has a CCI of 0x02 or 0x03 and then chnage to an unencrypted channel and you look at the cable card screens it will list the unencrypted channels channel number and rf information but reports the previous CCI value making it appear that encrypted content is being illegally flagged (assuming it's rebroadcast locals in quesiton)

[CrispyCritter]

Makes total sense- the way tivo handles it in their ui is the goofy thing.

Instead of reporting the last value tivo should say "NA" or "no value" or better yet "unencrypted content" something like that.

that way people could quickly tell if things are unencrypted.

Right now if you tune to an encrypted channel that has a CCI of 0x02 or 0x03 and then chnage to an unencrypted channel and you look at the cable card screens it will list the unencrypted channels channel number and rf information but reports the previous CCI value making it appear that encrypted content is being illegally flagged (assuming it's rebroadcast locals in quesiton)I don't understand several points here. Does TiVo have any control at all over what appears on the true cable card screens (those under "Configure CableCARD X")? I thought those screens were under the control of the cable card itself. One of those screens is the only screen reporting CCI, and it doesn't report channel number and frequency (at least on my versions of the screens). There are separate TiVo controlled screens under "Diagnostics" that report the frequency and channel number, but those don't report CCI.

So I'm confused about what's being complained about here!

[MichaelK]

I believe on my version of those screens from moto cards that on one screen I can find the channel and on another i can get the cci , but i could be confusing the cablecard screens with the tivo diag screens- it's been a few months since I was trying to figure it out to get my cable company to fix my issues.

[moyekj]

I don't understand several points here. Does TiVo have any control at all over what appears on the true cable card screens (those under "Configure CableCARD X")? I thought those screens were under the control of the cable card itself. One of those screens is the only screen reporting CCI, and it doesn't report channel number and frequency (at least on my versions of the screens). There are separate TiVo controlled screens under "Diagnostics" that report the frequency and channel number, but those don't report CCI.

So I'm confused about what's being complained about here! So the issue (not complaint) is that I can't find out the setting for CCI setting for unencrypted channels. The cableCARD Conditional Access screen is the only place with the S3 you can get CCI value, but that screen does not apply to unencrypted channels (in fact it confuses the issue for unencrypted channels as I doubt many S3 users are aware of this fact). It would be great if the diagnostics screen (which is divorced from cableCARD menus) would show correct CCI value and if a channel is encrypted or not.

I previously thought that CCI (or broadcast flag) only applied to encrypted channels, but apparently even unencrypted channels can have the flag set. It looks like right now for my headend ABC HD has CCI=0x02 even though it's unencrypted. Good sources from my cable company say that for terrestrial broadcast retransmissions their equipment simply passes through CCI from broadcaster and they cannot affect/change it, so apparently our local ABC broadcaster seems to be unintentionally setting the flag somehow. I have yet to get to the bottom of that.

[MichaelK]

first up- the broadcast flag and CCI values are different. (similar but different).

Is your cable provider putting CCI 0x02 on ALL the digital channels? Try the music channels- mine leqaves those at 0x00. And If not try a PPV if you have and it should be 0x03. Force the CCI value to 0x00 or 0x03 by finding another station and then switch back to your ABC. If it stays 0x00 or 0x03 then you know that the station is in fact not encrypted and not subject to a cci flag.

That will at least confirm that your cable plant isn't setting the CCI.

Beyond that- supposedly they will pass any "broadcast flag" the station sends. But I'm not sure anyone is really sending any since the court ruling that said they could be ignored.

I had very similar problems with my local cable company at first- they had a bunch of incorrectly flagged CCI's on cable channels and beyond that I ALSO had some issues with some tv programs on rebroadcast locals. With the help of the cable company's engineer we got all the cable channel flags corrected. I finally confirmed by trial and error with another user here that the broadcast channels weren't encrypted or CCI flagged as the cable engineer told me (I never bother with the music channels and my provider 0x02's ALL the digital channels- so all I ever say was 0x02- another user here on my head end kept getting 0x00 and then we figured out that the other user is mostly on music channels that my provider has at 0x00). My problems were with CBS (from their new york flagship) shows and the cable engineer thought they might be flagging stuff with the broadcast flag and that was my problem (as CBS is the one that really made a stink at the FCC about forcing the broadcast flag issue.). He was kind enough to check with CBS on it and he never heard back. But in the mean time a software update came along for the tivo and the problems with broadcast content all went away.

So try going to a 0x00 or 0x03 station first and then to the abc and see what you get.

[CrispyCritter]

So the issue (not complaint) is that I can't find out the setting for CCI setting for unencrypted channels. Yes, I was confused about MichaelK's complaint, not about your issue. I agree that it would be nice to get CCI value on the diagnostic screen; problems like this are only going to become more common as content control becomes more prevalent.
I previously thought that CCI (or broadcast flag) only applied to encrypted channels, but apparently even unencrypted channels can have the flag set. It looks like right now for my headend ABC HD has CCI=0x02 even though it's unencrypted. Good sources from my cable company say that for terrestrial broadcast retransmissions their equipment simply passes through CCI from broadcaster and they cannot affect/change it, so apparently our local ABC broadcaster seems to be unintentionally setting the flag somehow. I have yet to get to the bottom of that.Yes, that's the real intent of the Federal Code segment I posted in the other thread: the cable companies are not allowed to change the CCI code settings on most shows for most codes. What worries me a bit is the possibility that the cable companies ARE allowed to change an original network 0x02 to a 0x03 as it passes through the cable company. Presumably this would be under the theory that cable companies have copied the show in their process (as they sometimes do)? As I said, I don't have any evidence that this is proper, but my interpretation of the code says it might be allowed. Anybody know?

[moyekj]

Is your cable provider putting CCI 0x02 on ALL the digital channels? Try the music channels- mine leqaves those at 0x00. And If not try a PPV if you have and it should be 0x03. Force the CCI value to 0x00 or 0x03 by finding another station and then switch back to your ABC. If it stays 0x00 or 0x03 then you know that the station is in fact not encrypted and not subject to a cci flag. That will at least confirm that your cable plant isn't setting the CCI. No, not all encrypted digital channels are 0x02. For example CNN, TNT, etc. are 0x00. There are a few that are 0x02 such as ESPNHD.

I don't understand your experiment. Tuning to ABC HD does not affect CCI value ever because the station is unencrypted and therefore the cableCARD screen is not updated. Therefore as long as I'm tuned to ABC HD the CCI value will always be of the last encrypted channel I was tuned to for that cableCARD. So I can't get the CCI value with the S3 (the main reason why I started this thread). The reason I know that CCI=0x02 on that channel is because my friend with his DCT6416 DVR diagnostics confirms it to be so and he can't capture the firewire stream (which happens when CCI is not 0x00). A few weeks back firewire captures were working fine for that channel so somehow the CCI must have got set recently.

[MichaelK]

No, not all encrypted digital channels are 0x02. For example CNN, TNT, etc. are 0x00. There are a few that are 0x02 such as ESPNHD.

I don't understand your experiment. Tuning to ABC HD does not affect CCI value ever because the station is unencrypted and therefore the cableCARD screen is not updated. Therefore as long as I'm tuned to ABC HD the CCI value will always be of the last encrypted channel I was tuned to for that cableCARD. So I can't get the CCI value with the S3 (the main reason why I started this thread). The reason I know that CCI=0x02 on that channel is because my friend with his DCT6416 DVR diagnostics confirms it to be so and he can't capture the firewire stream (which happens when CCI is not 0x00). A few weeks back firewire captures were working fine for that channel so somehow the CCI must have got set recently.

just to explain my experiment for anyone who needs to figure out cci's:

0x00 doesn't mean the station isn't encrypted. If it's not a broadcast station and not ananlog then likely it IS encrytped. But is might not have any copy restrictions and so that's why it gets 0x00.

Encrypted is what keeps you from hooking up a qam tuner without the cablecard and seeing the channel. Encrypted channels CAN have copy restrictions such as CCI -0x03= copy never - only legal for VOD/PPV, 0x02 which is copy once, and 0x01 which is copy no more (copy once content that has been copied would get updated to this if I follow the rules correctly). Encryted channels also may have a CCI of 0X00 which is copy freely.

So it would be typical for a cable compnay to put up say toon disney on channel 101, a digital channel. They would encrypt the channel so people cant just connect their QAM tuner and get the digital basic tier for free. But there would not be a huge concern about someone copying and distributing house of mouse cartoons so the CCI bit could be set to 0x00 for copy freely.

If you tune your tivo to 101 the CCI bit on the card will go to 0x00. Then if you change the channel to an unencrpted channel (a boradcast channel) it should stay 0x00. To confirm that the second channel is in fact not encrytped and isn't itslef just encryted with a CCI of 0x00 then you need to next tune to a copy resticted channel such as ESPN HD- confirm that the CCI bit now jumps to CCI 0x02. Now flip back to the broadcast channel and if the CCI bit STAYS 0x02 you know that the broadcast channel itself has no CCI bit and is therefor unencrypted.

Follow?

You need to go to the questionable channel from 2 differnt CCI states. If the CCI state doesn't change from encryted channels to the questionable channel then you know that the channel IS NOT encryted by cable and has no CCI bit.


IF THE CHANNEL DOESN"T CHANGE THE CCI value in the experiment above then it has NO CCI VALUE to report.

So once you confirm there is no CCI value we have to figure out how to determine if there is a broadcast flag and that I dont know how to tell.


(incidently although i've seen no reports in the wild of it there are many other CCI values beyond 0x00, 0x01, 0x02, and 0x03. The 0X0 part deals with a bunch of other restirctions beyond digital copies- stuff like down rezzing and analog copy restrictions such as passing on macrovision flags)

[moyekj]

j If you tune your tivo to 101 the CCI bit on the card will go to 0x00. Then if you change the channel to an unencrpted channel (a boradcast channel) it should stay 0x00. To confirm that the second channel is in fact not encrytped and isn't itslef just encryted with a CCI of 0x00 then you need to next tune to a copy resticted channel such as ESPN HD- confirm that the CCI bit now jumps to CCI 0x02. Now flip back to the broadcast channel and if the CCI bit STAYS 0x02 you know that the broadcast channel itself has no CCI bit and is therefor unencrypted. This experiment works only to determine if a channel is unencrypted, but doesn't tell us what the CCI value is for that unencrypted channel since we know that CCI bit from cableCARD screen DOES NOT CHANGE for an unencrypted channel. So the problem still remains - no way to get CCI value for unencrypted channel from the S3.


(incidently although i've seen no reports in the wild of it there are many other CCI values beyond 0x00, 0x01, 0x02, and 0x03. The 0X0 part deals with a bunch of other restirctions beyond digital copies- stuff like down rezzing and analog copy restrictions such as passing on macrovision flags) CCI is only 2 bits so there are only 4 possible settings:
binary 00 = hex 0x00 = Copy Freely
binary 01 = hex 0x01 = Copy No More
binary 10 = hex 0x02 = Copy Once
binary 11 = hex 0x03 = Copy Never
For a good reference see (pages 4 & 11 of the PDF specifically):
http://www.dtcp.com/data/wp_spec.pdf

[Roderigo]

CCI is only 2 bits so there are only 4 possible settings:
binary 00 = hex 0x00 = Copy Freely
binary 01 = hex 0x01 = Copy No More
binary 10 = hex 0x02 = Copy Once
binary 11 = hex 0x03 = Copy Never
For a good reference see (pages 4 & 11 of the PDF specifically):
http://www.dtcp.com/data/wp_spec.pdf
Actually, the CCI is 8 bits.
Bit 3 & 4 are the APS bits, which specify what level of macrovision encoding needs to be applied to analog outputs. Bit 5 is the CIT, which specifies if the component output needs to have a lower resolution video image. Bits 6-8 are reserved.

Exhibit A1 of the DFAST license describes the CCI byte:

http://www.cablelabs.com/udcp/downloads/DFAST_Tech_License.pdf

[moyekj]

Actually, the CCI is 8 bits.
Bit 3 & 4 are the APS bits, which specify what level of macrovision encoding needs to be applied to analog outputs. Bit 5 is the CIT, which specifies if the component output needs to have a lower resolution video image. Bits 6-8 are reserved.

Exhibit A1 of the DFAST license describes the CCI byte:

http://www.cablelabs.com/udcp/downloads/DFAST_Tech_License.pdf I stand corrected. So it's the 2 LSB bits of the 8-bit CCI that are called the EMI bits which are the Digital Copy Control Bits which define the copy control permissions. So MichaelK is correct that the hex value of CCI could something other than the 4 values I listed above.

[MichaelK]

This experiment works only to determine if a channel is unencrypted, but doesn't tell us what the CCI value is for that unencrypted channel since we know that CCI bit from cableCARD screen DOES NOT CHANGE for an unencrypted channel. So the problem still remains - no way to get CCI value for unencrypted channel from the S3.
...

I am fairly certain that there IS NO CCI value if it's unencryted and that's the crux of the issue here.

Read JDguy's post above- he quotes the specs that says there is no point to EMI/CCI if the content is unenctypred.

So you cant determine the CCI value becasue it doesn't exist.

[moyekj]

I am fairly certain that there IS NO CCI value if it's unencryted and that's the crux of the issue here.

Read JDguy's post above- he quotes the specs that says there is no point to EMI/CCI if the content is unenctypred.

So you cant determine the CCI value becasue it doesn't exist. I can't prove for sure if CCI is set or not, but fact remains that DCT6416 diagnostics show that the channel is unencrypted and CCI=0x02 for ABCHD and firewire capture doesn't work. In the past the diagnostics showed CCI=0x00 and firewire capture worked correctly. Other network channels such as CBSHD show CCI=0x00 and firewire capture still works, so this seems like pretty good evidence that CCI is indeed set and affecting things.

The fact it is unencrypted is undisputed as I can tune to it with a clear QAM tuner on TV and PC capture card. I don't know of any software tool that can extract CCI setting from transport stream but if there is such a tool I could capture a stream with my PC tuner and run it through. TSReaderLite does not have any CCI value readings that I could find.

[sfhub]

The same thing happened in San Francisco. dr1394 helped diagnose. I'll try to explain what is happening without messing it up too much.

Broadcast Flag (BF) and Copy Control Information (CCI) are similar descriptors (flags) from different standards, that accomplish basically the same thing, namely DRM (ie whether you can copy something or not) BF is part of ATSC. CCI is part of DTCP (firewire, etc.) FCC has some control over ATSC. DTCP is controlled by industry/studios.

The reason this problem is so confusing is because the cable company (in SF case) apparently is *not* setting CCI for the channels in question. What is happening is the local station (or the nationwide feed) is setting BF in the ATSC stream and the Motorola box is deciding to *fabricate* the CCI based on the presence of the BF.

Now you may say BF was struck down. That is not entirely true. What happened is the rule *requiring* all devices to *honor* BF was struck down, because the courts ruled the FCC did not have the authority to force BF (which means forcing BF would require congress to write legislation). That means those PC HDTV cards and QAM tuners with firewire outputs *may* ignore BF (and indeed stuff like MyHD is unaffected by the local stations enabling BF). It does *not* mean devices *must* ignore BF and indeed we see the Motorola implementation not only does not ignore it, but uses BF to set up CCI, which is what is causing the firewire problem your friend is seeing.

I don't know whether TiVo is properly displaying CCI or not (that is a different discussion), but in this case there is no CCI to display because it is a figment of the Motorola box's imagination. If TiVo displays the ATSC BF descriptor, then something should show up there. If you capture the ATSC stream using something like MyHD and dump the meta-data using TSReader you'll most likely see a field like this:

Descriptor: ATSC Redistribution Control Descriptor
ff .

"FF" is the value of the broadcast flag.

Hope that clears things up.

[moyekj]

Thanks sfhub! As it just so happens I found the Comcast San Fran AVS thread just an hour or so and went through it and saw exactly what you were talking about above. I do have the Fusion 5 card so I used TSBrowser2 to capture a 1 minute sample of the cable RF channel. I then opened up the stream in TSReaderLite and ran export to html and sure enough I see:
Program Number: 1
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
c0 af c8 c0 02 00 ......
Descriptor: ATSC Component Name Descriptor
01 65 6e 67 01 00 00 07 4b 41 42 43 2d 48 44 .eng....KABC-HD
Descriptor: ATSC Redistribution Control Descriptor
ff .

There are 4 more programs in the stream in addition to the above. 3 of them are not related to ABC and do not have the Redistribution Control Descriptor, but there is another one related to ABC that also has it:
Program Number: 5
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
c0 af c8 c0 02 00 ......
Descriptor: ATSC Component Name Descriptor
01 65 6e 67 01 00 00 07 4b 41 42 43 2d 57 4e .eng....KABC-WN
Descriptor: ATSC Redistribution Control Descriptor
ff .

So curious if it was the local broadcaster and not Cox cable adding the information I also captured OTA ATSC transport stream and analyzed it. It contains 3 programs and, you guessed it, all have the same descriptor set:
Descriptor: ATSC Redistribution Control Descriptor
ff .

I didn't read all the way through the Comcast thread. Was the issue with KTVU ever solved?

[MichaelK]

edit: never mind

said much better above!

[moyekj]

So the question remaining now is how Tivo S3 will deal with programs marked with Broadcast Flag. We know that Motorola boxes enable CCI as a result of the BF which doesn't bode well. This unfortunately has the potential to affect TTG/MRV (if/when ever enabled for the S3) even for OTA ATSC broadcasts recorded from antenna inputs.

[sfhub]

I didn't read all the way through the Comcast thread. Was the issue with KTVU ever solved?
As far as I know the issue has not been resolved. The FCC is unlikely to care because they actually support the use of BF. The ruling really just said FCC does not have the authority to force BF.

It never said anything about whether the industry could come up with BF on its own and start using it, though, for the purposes of enforcing DRM, I personally find it silly to have a subset of equipment honoring BF.

To be clear, the ruling did *not* say BF cannot be used.

Probably your best bet is to have people complain to the station, but even then it may not work unless you get media involved, but they seem to have a bias in this case. I suspect so few people use the firewire port or even know it is there that in the end the person will just have to live with it.

[MichaelK]

So the question remaining now is how Tivo S3 will deal with programs marked with Broadcast Flag. We know that Motorola boxes enable CCI as a result of the BF which doesn't bode well. This unfortunately has the potential to affect TTG/MRV (if/when ever enabled for the S3) even for OTA ATSC broadcasts recorded from antenna inputs.


Can you get the KABC feed OTA and see what the tivo does with it? I think that would be the quickest way to find out. Record a show then check it's description and hit the info button- that page is usually where the cable copy protection specifics are listed.

I dont think I've heard of anyone else using the boradcast flag in the real world YET..

My bet is- Tivo, alsways lookign to make nice with the content folks, will completely respect the flags. The question then becomes what are the flags that are allowed to be placed on broadcast content? Is Copy Once (equal to a CCI flag of 0x02) the worst they can do?

[MichaelK]

As far as I know the issue has not been resolved. The FCC is unlikely to care because they actually support the use of BF. The ruling really just said FCC does not have the authority to force BF.

It never said anything about whether the industry could come up with BF on its own and start using it, though, for the purposes of enforcing DRM, I personally find it silly to have a subset of equipment honoring BF.

To be clear, the ruling did *not* say BF cannot be used.

Probably your best bet is to have people complain to the station, but even then it may not work unless you get media involved, but they seem to have a bias in this case. I suspect so few people use the firewire port or even know it is there that in the end the person will just have to live with it.


very well said (as your post above was also).

Long term- I think the content schlubs are likely to get congress to pass a law mandating the STB's respect the flags to replace the overturned FCC ruling that tried to do the same.

Complaining to your local pol's could be the way to go. If enough complain then at least we might keep them from passing any law to mandate flags, and maybe they actually lsiten to the constiutents and declare flags a no go at all (I can dream can't I...).

[moyekj]

Can you get the KABC feed OTA and see what the tivo does with it? I think that would be the quickest way to find out. Record a show then check it's description and hit the info button- that page is usually where the cable copy protection specifics are listed. I record that channel OTA all the time already with my S3 so I already have some recordings I can check. I don't recall seeing anything regarding copy protection in the detailed info pages but I'll check again.

In fact the only time I've noticed copy protection in action with the S3 is when recording a VOD recording (they are unencrypted and since there are 80 VOD channels I can usually find one that is in use). For those the CCI is set to 0x03 so I get the 90 minute restriction via the S3. Oddly enough for those I am able to play back the VOD recording and save it to a ReplayTV DVR via the S3 S-video output, so looks like SD analog outputs don't honor the CCI Copy Never restriction.

[dt_dc]

Oddly enough for those I am able to play back the VOD recording and save it to a ReplayTV DVR via the S3 S-video output, so looks like SD analog outputs don't honor the CCI Copy Never restriction.The least two signigicant CCI bits (EMI bits) only apply to digital output. The next two bits (APS bits) apply to analog output.

So ... I wouldn't expect analog (Macrovision) copy protection to be applied with a CCI of 0x03. I would expect analog (Macrovision) copy-never protection to be applied with a CCI of 0x15, 0x14, or 0x12.

http://www.cablelabs.com/udcp/downloads/DFAST_Tech_License.pdf

[MichaelK]

I record that channel OTA all the time already with my S3 so I already have some recordings I can check. I don't recall seeing anything regarding copy protection in the detailed info pages but I'll check again.

In fact the only time I've noticed copy protection in action with the S3 is when recording a VOD recording (they are unencrypted and since there are 80 VOD channels I can usually find one that is in use). For those the CCI is set to 0x03 so I get the 90 minute restriction via the S3. Oddly enough for those I am able to play back the VOD recording and save it to a ReplayTV DVR via the S3 S-video output, so looks like SD analog outputs don't honor the CCI Copy Never restriction.

the info page wont give you too much - but if it's copy never it will say so- something like the "due to restictions from the copyright owner- blah blah blah"

(I'm not sure what it says, if anything for copy once).

[MichaelK]

anyone know if "CCI" is the correct way to describe the broadcast flag? I think not, but I'm wondering if devices like the MOTO box that descibe it as such are correct or not?

[dt_dc]

anyone know if "CCI" is the correct way to describe the broadcast flag?No, it's not.I think not, but I'm wondering if devices like the MOTO box that descibe it as such are correct or not?The box is neither 'correct' nor 'incorrect'. The box isn't 'describing' the broadcast flag as 'CCI'. The box sees the broadcast flag and applies a CCI value to the stream. The box is neither correct nor incorrect. Boxes can do whatever the heck they want to (or not) with the broadcast flag ... their choice. This just happens to be what this particular box is doing.

[moyekj]

anyone know if "CCI" is the correct way to describe the broadcast flag? I think not, but I'm wondering if devices like the MOTO box that descibe it as such are correct or not? From what was said above looks like the Moto box is creating it's own CCI in reaction to the Broadcast Flag. So I would agree with what sfhub says above that Broadcast Flag is copy protection for terrestrial (ATSC) broadcasts and CCI is copy protection for cable broadcasts. They are not the same thing from an engineering/implementation perspective but are equivalent from a copy protection intent perspective. I guess the Moto boxes are trying to stay true to the intent of copy protection which is why they translate from BF to CCI (at least for the firewire output).

Unfortunately probably Tivo S3 in order to get CableLabs approval will also have to do something similar for TTG/MRV and perhaps even eSATA restrictions. I thought the ATSC recordings from antenna would be safe for TTG/MRV but now we are seeing that's not necessarily the case at all.

[MichaelK]

No, it's not.The box is neither 'correct' nor 'incorrect'. The box isn't 'describing' the broadcast flag as 'CCI'. The box sees the broadcast flag and applies a CCI value to the stream. The box is neither correct nor incorrect. Boxes can do whatever the heck they want to (or not) with the broadcast flag ... their choice. This just happens to be what this particular box is doing.


so it's alright by the standards for the boxes to make up their own CCI values? That's basically what is going on with the moto- no? It's looking at information not supplied by the cable plant ( but rather in the broadcast flag) and deciding on that what CCI to assign.

Isn't that a slippery slope? Maybe then Tivo should pass along in the guide data what channels are Broadcast and whip off all CCI protection if it exists since cable shouldn't be restricting that.

I know it's a stretch above but I'd think the standard would say CCI from the cable plant decides CCI at the box. Case closed.

[MichaelK]

or is it just a matter that the moto box is saying "CCI" as shorthand for "CCI OR Boradcast Flag Bit"?

dt_dc- do you know the spec for the boradcast flag system? Are the numerical values and their conditions the same for broadcast flags as for CCI flags?

[dt_dc]

Unfortunately probably Tivo S3 in order to get CableLabs approval will also have to do something similar for TTG/MRV and perhaps even eSATA restrictions.No ... Tivo doesn't have to do anything at all in response to the broadcast flag to get any sort of CableLabs approval. They can choose to do whatever the heck they want to (or not). Their call.

[dt_dc]

Isn't that a slippery slope? Maybe then Tivo should pass along in the guide data what channels are Broadcast and whip off all CCI protection if it exists since cable shouldn't be restricting that.Wouldn't have to pass anything in guide data at all. For unencrypted channels ... sure ... Tivo can do whatever the heck they want to. If they (or Motorola or Scientific Atlanta) want to look at some bit in the transport stream and make giant floating purple hippototomi dance on the screen in response to the bit being set (or not) ... they can. It's an unencrypted stream ... they don't have to look at the CCI bits ... they don't have to do anything at all they don't want to ...

Motorola is doing what they are doing on their boxes because ... it's an easy to way give effect to the broadcast flag. It fits into their existing code and handlers and everything else. And everyone is voluntarily giving some sort of effect to the broadcast flag becuase ... well, that just makes everyone's life easier.

[dt_dc]

dt_dc- do you know the spec for the boradcast flag system? Are the numerical values and their conditions the same for broadcast flags as for CCI flags?The 'broadcast flag' is the ATSC Redistribution Control Descriptor. The ATSC Redistribution Control Descriptor is a series of bits described in ATSC 65 (PSIP standard):
http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf

What the broadcast flag's 'values' mean is whatever you make them to mean ... no 'system' or 'valuation' is given.

Now, the FCC's broadcast flag rules only set forth one value ... present or not present. The broadcast flag was there ... or not. It was on ... or off. The values didn't matter ... all that mattered was that the redistribution control descriptor was there. The FCC's broadcast flag rules had no 'copy once', 'copy never', etc. values. Content was either flagged ... or not.

When content was passed via digital outputs that was marked with the broadcast flag ... it had to be encrypted. It was a 'redistribution control' trigger that was inteded to prevent unencrypted content from being (indiscriminately) redistributed (ie, unencrypted via the internet). But you could copy it as many times as you wanted ... heck, burn multiple copies off to AACS protected HD-DVDs and hand them to your friends ... do whatever you want ... just couldn't upload the content unencrypted up to the internet.

However, now, absent that, people are free to do whatever the heck they want to (or not) with the ATSC Redistribution Control Descriptor.

[MichaelK]

The 'broadcast flag' is the ATSC Redistribution Control Descriptor. The ATSC Redistribution Control Descriptor is a series of bits described in ATSC 65 (PSIP standard):
http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf

What the broadcast flag's 'values' mean is whatever you make them to mean ... no 'system' or 'valuation' is given.

Now, the FCC's broadcast flag rules only set forth one value ... present or not present. The broadcast flag was there ... or not. It was on ... or off. The values didn't matter ... all that mattered was that the redistribution control descriptor was there. The FCC's broadcast flag rules had no 'copy once', 'copy never', etc. values. Content was either flagged ... or not.

When content was passed via digital outputs that was marked with the broadcast flag ... it had to be encrypted. It was a 'redistribution control' trigger that was inteded to prevent unencrypted content from being (indiscriminately) redistributed (ie, unencrypted via the internet). But you could copy it as many times as you wanted ... heck, burn multiple copies off to AACS protected HD-DVDs and hand them to your friends ... do whatever you want ... just couldn't upload the content unencrypted up to the internet.

However, now, absent that, people are free to do whatever the heck they want to (or not) with the ATSC Redistribution Control Descriptor.


so if i'm following the fcc rule basically said if flag was true tehn just dont allow unencrypted copies.

But since that was overturned and there is no current flag rule people can choose to respond to the flag as they see fit and motorolla has decided that means "copy once"?

[dt_dc]

so if i'm following the fcc rule basically said if flag was true tehn just dont allow unencrypted copies.Basically, yes.But since that was overturned and there is no current flag rule people can choose to respond to the flag as they see fit and motorolla has decided that means "copy once"?Without getting into intricacies of the now-meaningless broadcast flag rule ... and from above descriptions ... yes.

Although, if memory serves ... I believe this behavior was just symptomatic of an early Motorola release aimed at giving intent of the broadcast flag (ie, making sure the Firewire outputs were encrypted) with minimal code work / changes. I believe this has been fixed in a later Motorola release and they now have an "encryption plus non-assertion" (ie, encrypt but don't assert copy protection levels) setting that they use for broadcast flag marked content.

However, I don't have access to Motorola system release notes so ... that's just what I think / recall. Take it for what you will.

[moyekj]

No ... Tivo doesn't have to do anything at all in response to the broadcast flag to get any sort of CableLabs approval. They can choose to do whatever the heck they want to (or not). Their call. I was thinking if they choose to assert CCI in some "quick and dirty" fashion as Motorola has done in response to BF presence then MRV/TTG and possibly eSATA would have to respect the CCI setting thus rendering such content ineligible. Hopefully that's not the case and Tivo will just ignore the BF - but being Tivo somehow I doubt BF will be ignored even though there is no mandate to honor it.

[MichaelK]

i too doubt tivo will ignore it, but it seams the original broadcast flag only required all content leaving the box to get encrypted. Tivo does that already. And If I recall the FCC approved their "tivoguard" as an acceptable encryption (when the FCC was trying to decide such things- but now moot). So in theory tivo doesn't need to do anything as they already move everything encrypted.

EXCEPT- that I believe TTG by means of tivo desktop plus and the mydvd program (toast also I presume?) will officially re-encode and produce unencrypted content (Ignoring the myriad of other ways to ditch the encryption at the moment- these 2 are officially sanctioned). So if Tivo want's to proactivly abide by the overturned ruling then they will have to flag their content so TTG wont allow that. Will be interesting to see if they take that step to do that.

Can mydvd produce CSS encrypted discs? That might be one way of "trying to do the right thing".

Not sure how they could handle tivo desktop plus' system of creating files for handheld devices. Maybe such downrezzed re-encoded copies were permitted under the now bye-bye broadcast flag rule?

[moyekj]

My friend reported firewire capture on the ABCHD channel is now working again. To confirm I captured another sample of the RF channel from cable feed and confirm the following no longer shows up in any of the ABC program streams:
Descriptor: ATSC Redistribution Control Descriptor=ff

My friend did send an email about this to the local ABC broadcaster, so maybe they actually do listen and the BF setting was unintentional - either that or it's an awfully big coincidence it got turned off at this point in time. Guess time will tell if it stays this way...

[moyekj]

SIGH.... ABCHD still does not have BF set but now all of a sudden CBSHD has the BF set and sure enough firewire recording is blocked by CCI=0x02. This was not set a couple of days ago on that channel and the setting is not program specific as several captures over different shows all show the flag there now...

[sfhub]

Rotating BF is BS

[MichaelK]

will be interesting to see what tivo does about the BF being set...