or Connect
AVS › AVS Forum › HDTV › HDTV Recorders › How to record via IEEE 1394 (Firewire) to Windows XP
New Posts  All Forums:Forum Nav:

How to record via IEEE 1394 (Firewire) to Windows XP - Page 114

post #3391 of 6013
Quote:
Originally Posted by tbully View Post

This was talked about around 30 days ago and I haven't heard anything on it. I thought I'd give it a bump. I'm seeing the same issue. VLC also does not show the output of the stream as it used to.

Is this the end? There is some content (unprotected) on my DVR that I'd like to clean up.

This seems to happen on all channels.

Same question here...I'm on Comcast and really want to get down to business of capturing my 6412 DVR shows into Windows via 1394 connection.

I've tried to be patient while the thread went down a different tangent...but dang....Any breakthroughs on this 1394/Comcast front?
post #3392 of 6013
I am having some strange problems with captured large clips from the Motorola DCT6412, and I am wondering if I am capturing correctly with CapDVHS.

If I capture a SMALL clip (a few minutes, 45-75 MB) from (for example) an already stored 1hr49minute SD movie from the DCT6412, I can do the following:
1) View and listen to it with Nero 7 Showtime on my PC
2) Create an excellent DVD if I use the HDTV2DVD tool described in the http://replayguide.sourceforge.net/dct6412/index.html link which is at the beginning of this thread. The picture when viewed on my TV is great (non-jerky), and the audio is good too.
3) Note, however, if I use Nero 7 Vision to read in this SMALL .ts file directly, the resulting burned DVD has audio but with a jerky picture.

Here is the problem. If I capture that same entire 1hr49minute movie, this is what happens with the LARGE (3 GB) .ts file. :
a). I can view the .ts file with Nero 7 Showtime on my PC, but there is no audio.
b). HDTV2DVD cannot even read in the .ts file.
c). HDTVtoMPEG2 (also described in the link above) can read in the .ts file and convert it to a mpg. That resultant .mpg file can be watched with Nero 7 Showtime and then it has audio. If I read in that .mpg file into Nero 7 Vision, I can create a DVD folder on my hard drive after it takes over 3 hours to reencode it. However, the burned DVD (from this hard drive folder) has a jerky picture, with sound that is fine, on my TV.
d). Note, if I use Nero 7 Vision to read in this LARGE .ts file direclty, the resultant DVD has no audio, and the picture is jerky on the TV.

I am using all of the CapDVHS settings mentioned at the beginning of this tread.

This is particularly frustrating as a retest can take over 5 hours, between recapturing the movie and then reencoding it to work on a DVD. Any suggestions would be greatly appreciated.

----
Update several hours later. I was able to fix the LARGE .ts, thanks to the post below from Lee11 on 5-11-2006. I cut off the first couple of seconds from the beginning of the .ts file using HDTVtoMPEG2 and saved it as another .ts filename. (HDTVtoMPEG2 is very quick.) Then I was able to read in the very slightly modified .ts file into HDTV2DVD. HDTV2DVD processed the 1hr49min file in just 2hrs16mins, and the picture and sound both look great on the DVD on my TV!

Quote:
Originally Posted by Lee11 View Post

I have encountered this problem several times, each time I was able to resolve by one of the following methods:
1) Re-save the file using HDTV2MPEG2, openign the file and then converting to a .ts file with another file name.
2) Trimming out the lead in to the program and then re-saving using HDTV2MPEG2

I haven't really found a pattern but I believe it doesn't like it when the specs change, say frame rate or resolution. I seem notice the problem more when the recording starts with SD and then changes to HD. But it is not always the case.

I say just try re-writing the files using a .ts editor of some kind, it has worked very consistently for me.

Good Luck.
post #3393 of 6013
Is the 5C encryption added by program or by channel. Is there a way to find out if a recording has any encryption associated with it? I know how to verify the status with the channel, but does it chage depending on the program?

Thanks!
post #3394 of 6013
Quote:
Originally Posted by sl1974 View Post

Is the 5C encryption added by program or by channel. Is there a way to find out if a recording has any encryption associated with it? I know how to verify the status with the channel, but does it chage depending on the program?

It can be changed per program, but I don't know how it is implemented by each cable/content provider.

It would be best to check the channel status during a particular program you are wondering about. If you don't want to interrupt what your STB is doing, you could just start CapDVHS during the program to see if the stream info comes up.
post #3395 of 6013
Quote:
Originally Posted by sl1974 View Post

Is the 5C encryption added by program or by channel. Is there a way to find out if a recording has any encryption associated with it? I know how to verify the status with the channel, but does it chage depending on the program?

Thanks!

On our Comcast Seattle boxes, 5C is always set to 0 but CCI (embedded on a program by program basis is being used to control what kind of copying is allowed. They are not all treated the same. For example, everything from KIRO-HD (CBS) has CCI set to 00x2 but only HD programs on KCPQ-HD (Fox) have CCI set to 00x2 (all SD programming on KCPQ-HD is set to 00x0). I'm discussing it with a customer service manager at the Redmond, WA office (Dave Perry) and really hope to get it resolved before March Madness.
post #3396 of 6013
wow, i haven't had to record anything via firewire for a couple weeks now. And today I tried and it seems 99% of every channel has the copy protection on now. I'm guessing we don't know any way behind this? It's silly that they do this when you can easily record via vcr or dvd recorder.
post #3397 of 6013
I'm in Boston and have a DCT 3412 I from Comcast. ESPNHD, HBOHD, and INHD have CCI set to 00x2. FOXHD, CBSHD, and NBCHD have CCI set to 00x0. I'm assuming that 00x2 means copy once, which would refer to copying to the DVR itself, and 00x0 means you can copy it off to a PC. I recorded a movie on Encore (CCI=00x2) but it won't stream using CapDVHS. Does this mean there's no way for me to transfer it off the box??? This is very disappointing if I'm unable to copy these programs off. Why do some channes allow it and others don't? I'm fairly new to all this, so I hoping someone out there can help me. Thanks.
post #3398 of 6013
Quote:
Originally Posted by plymakr88 View Post

I'm in Boston and have a DCT 3412 I from Comcast. ESPNHD, HBOHD, and INHD have CCI set to 00x2. FOXHD, CBSHD, and NBCHD have CCI set to 00x0. I'm assuming that 00x2 means copy once, which would refer to copying to the DVR itself, and 00x0 means you can copy it off to a PC. I recorded a movie on Encore (CCI=00x2) but it won't stream using CapDVHS. Does this mean there's no way for me to transfer it off the box??? This is very disappointing if I'm unable to copy these programs off. Why do some channes allow it and others don't? I'm fairly new to all this, so I hoping someone out there can help me. Thanks.

Yes. I am most certain that you will not be able to copy it to PC. Darn copy protection.
post #3399 of 6013
Quote:
Originally Posted by tluxon View Post

On our Comcast Seattle boxes, 5C is always set to 0 but CCI (embedded on a program by program basis is being used to control what kind of copying is allowed. They are not all treated the same. For example, everything from KIRO-HD (CBS) has CCI set to 00x2 but only HD programs on KCPQ-HD (Fox) have CCI set to 00x2 (all SD programming on KCPQ-HD is set to 00x0). I'm discussing it with a customer service manager at the Redmond, WA office (Dave Perry) and really hope to get it resolved before March Madness.

You say it's "embedded" on a program-by-program basis. Do you know anything about the Moto 3416 using Embedded CCI with the DTCP_Descriptor for MPEG-TS, as opposed to the Encryption Mode Indicator (EMI)?

According to the 5C DTCP spec, "recording devices such as D-VHS are a format-non-cognizant recording and playback device", meaning the 3416's output would require the EMI to encrypt any bitstream.

For those wanting more info, check out DTCP Specification Volume 1 Version 1.4 (Informational Version), starting at page 39 for CCI.
post #3400 of 6013
Quote:
Originally Posted by plymakr88 View Post

I'm in Boston and have a DCT 3412 I from Comcast. ESPNHD, HBOHD, and INHD have CCI set to 00x2. FOXHD, CBSHD, and NBCHD have CCI set to 00x0. I'm assuming that 00x2 means copy once, which would refer to copying to the DVR itself, and 00x0 means you can copy it off to a PC. I recorded a movie on Encore (CCI=00x2) but it won't stream using CapDVHS. Does this mean there's no way for me to transfer it off the box??? This is very disappointing if I'm unable to copy these programs off. Why do some channes allow it and others don't? I'm fairly new to all this, so I hoping someone out there can help me. Thanks.

CCI codes:

Copy Never (11 or 0x03)
Copy One Generation (10 or 0x02)
No More Copies (01 or 0x01)
Copy Freely (00 or 0x00)

"Copy One Generation" (0x02) does not refer to the initial recording on the DVR, but to one copy to a DTCP-compliant device, i.e., a DVHS deck.

A PC connected via Firewire is not DTCP-compliant, so no copying that requires authentication is allowed. That means only content marked "Copy Freely" (0x00) can be transferred to a PC, as all others require authentication.

I believe the premium channels, like Encore, are always marked "Copy One Generation" (0x02), even if the Encore channels are part of a digital cable package and not added a-la-carte.
post #3401 of 6013
Quote:
Originally Posted by ExDeus View Post

You say it's "embedded" on a program-by-program basis. Do you know anything about the Moto 3416 using Embedded CCI with the DTCP_Descriptor for MPEG-TS, as opposed to the Encryption Mode Indicator (EMI)?

According to the 5C DTCP spec, "recording devices such as D-VHS are a format-non-cognizant recording and playback device", meaning the 3416's output would require the EMI to encrypt any bitstream...

Thank you for your question because it helped me learn that there was more than one way for a program to carry CCI. I didn't realize my use of the term "embedded" might be inappropriate, as I was using it in a more generic way to characterize that the CCI value was being used in some manner to locally manage copying at a program-by-program level rather than a station-by-station level.

I've only gotten errors with anything I've tried to use to open and look at files I've captured from CCI=00x2 programs. If I sent you one would you be able to tell what method of CCI marking was being used?

A technician at one of our local stations (KIRODT-CBS) told me they put a new encoder in place at about the same time I started noticing all the KIRODT programming through Comcast had the CCI value of 00x2. However, I don't think he has any idea why or how the CCI value was suddenly different than the 00x0 it had always been before. Could be built into the encoder, I suppose, but wouldn't that also affect what they broadcast OTA? (I add that because the people recording OTA programming have noticed no difference)

When I brought the issue up with Comcast, they also didn't have any clue as to why the CCI value changed. All we know for sure at this point is that somewhere between September and October of '06, about half of the HD stations started showing CCI=00x2 where they had always been 00x0 before. There's no apparent rhyme or reason that we can make out as to what programs would or should be CCI=2, because we only see it from local stations (but not all - the local NBCHD & ABCHD are still CCI=00x0). ESPNHD, ESPN2HD, UHD, MHD, TNTHD, DHD, INHD (here it's actually a NBAHD, NFLHD, FSNHD and INHD mix), and GOLFVS (Golf and Versus) are all CCI=00x0.

I have a sense that this whole CCI thing has a long way to go before it's worked out and applied nationwide in a rational manner. Perhaps it's a function of various generations of encoders out there and DVRs that are not handling it uniformly.
post #3402 of 6013
Quote:
Originally Posted by tluxon View Post

I've only gotten errors with anything I've tried to use to open and look at files I've captured from CCI=00x2 programs. If I sent you one would you be able to tell what method of CCI marking was being used?

I can try capturing some protected content and see what I get. I don't remember if I can capture the encrypted stream, or if I just get a 0 byte file. I'll get back to you.

I don't know enough at this point to know what the encoder at your local broadcast affiliate would actually do. I don't know how content is delivered to them, or what each individual encoder might be doing (are they just rate-shaping, are they just encoding locally-originated content like an HD news broadcast, or are they transcoding all broadcast content from some other format?).

Quote:
Originally Posted by tluxon View Post

I don't think he has any idea why or how the CCI value was suddenly different than the 00x0 it had always been before. Could be built into the encoder, I suppose, but wouldn't that also affect what they broadcast OTA?

5C DTCP is used over digital buses with bi-directional communication, which would be required to negotiate a connection and authenticate a device. It wouldn't be used in broadcast (or at least it wouldn't be respected), as it's a uni-directional medium (your receiver can't communicate with the broadcast transmitter). An OTA tuner wouldn't even check for 5C DTCP. That's what the proposed Broadcast Flag was for.

I don't know the exact details about how the Comcast content is delivered to a STB, but I believe it has its own system for flagging content, which tells the STB how to flag the content with 5C DTCP when generating the new bitstream that is output on the Firewire ports. I believe the STB would have to generate a new bitstream for output over a new link, which means the box would have to control the adding of the EMI. If you were looking for something that changed with the box, and possibly the way it handles content, within the Sep-Oct timeframe, F/W 16.20 for the Moto boxes was first pushed out Sep-20.
post #3403 of 6013
Quote:
Originally Posted by ExDeus View Post

I can try capturing some protected content and see what I get. I don't remember if I can capture the encrypted stream, or if I just get a 0 byte file. I'll get back to you...

All of the files I've captured from CCI=2 programs are of essentially the same length they would be from a CCI=0 program. The difference seems to be solely in the header of the file. ???

If it's even possible it would be interesting for us each to capture the same few seconds of the same national show and compare them byte-for-byte. At the very least it would show us if something's been re-encoded or simply transcoded. Who knows what else we might be able to tell.

Quote:


...I don't know the exact details about how the Comcast content is delivered to a STB, but I believe it has its own system for flagging content, which tells the STB how to flag the content with 5C DTCP when generating the new bitstream that is output on the Firewire ports. I believe the STB would have to generate a new bitstream for output over a new link, which means the box would have to control the adding of the EMI. If you were looking for something that changed with the box, and possibly the way it handles content, within the Sep-Oct timeframe, F/W 16.20 for the Moto boxes was first pushed out Sep-20.

So you're saying the STB (in my case the DCT-3416) generates a new bitstream for output on its firewire ports? And you're thinking that the box itself has responsibility for adding the EMI? That gives me a completely different perspective than what I've had. I always get the CCI values for a program from the diagnostics screen for the two tuners, so I had figured the box was nothing more than a glorified tuner that simply passed on what it was given (in terms of content streams). I hadn't even entertained the idea that it might be involved in encoding/transcoding data, elevating the significance of the firmware the box is running on far beyond what I would've anticipated.

When my Microsoft software 3412 (at the time) first got the updated firmware (v12.35 IIRC), it immediately got the rebooting bug so I got it reverted back to v12.31 within the week. It was at least a couple weeks later that I first saw a station with CCI set to "00x2". Of the other stations that now have CCI=2 programs, I was still capturing from at least one of them more than a week after the first appearance of the CCI=2. This caused me to suspect (perhaps incorrectly?) that the firmware didn't have anything to do with the appearance of CCI=2.
post #3404 of 6013
Quote:
Originally Posted by tluxon View Post

So you're saying the STB (in my case the DCT-3416) generates a new bitstream for output on its firewire ports? And you're thinking that the box itself has responsibility for adding the EMI? That gives me a completely different perspective than what I've had. I always get the CCI values for a program from the diagnostics screen for the two tuners, so I had figured the box was nothing more than a glorified tuner that simply passed on what it was given (in terms of content streams). I hadn't even entertained the idea that it might be involved in encoding/transcoding data, elevating the significance of the firmware the box is running on far beyond what I would've anticipated.

My understanding is that DTCP is not used over the cable system. Some other scheme is used to scramble the data. DTCP is an encryption scheme designed for Firewire and used b/w 2 devices, which have to negotiate a set of encryption keys and then encrypt and decrypt data b/w the 2 devices. Similar to using SSL on an encrypted web page, the 2 devices negotiate to encrypt data for each other, and no third party can listen in and decrypt the data.

So even if the cable system used DTCP, the STB would have to decrypt the stream using DTCP, and then send it to the MPEG decoder for video output, and to a another chip to encrypt and package the content into a new bistream for output over Firewire. I'm not suggesting the STB encodes or transcodes the MPEG stream, but that it re-packs it into a new bitstream with the proper headers and flags for DTCP output over Firewire.

As far as the CCI values in the diagnostic menu go, I assume they are set by a flag in the data coming over the cable system, but that doesn't mean it has to be the CCI flag from DTCP, it could be any proprietary flag they use for the cable system.
post #3405 of 6013
Darn it! How come DVD's come out and they get cracked, HD-DVD comes out Blu-ray comes out, and the new AACS gets "decrypted". Its been years since we've had HD channels coming over FireWire TO OUR PC's, we even have files with REAL data, and we can't decrypt them! ack!!
post #3406 of 6013
Quote:
Originally Posted by Electrox3d View Post

Darn it! How come DVD's come out and they get cracked, HD-DVD comes out Blu-ray comes out, and the new AACS gets "decrypted". Its been years since we've had HD channels coming over FireWire TO OUR PC's, we even have files with REAL data, and we can't decrypt them! ack!!

Now you understand why they've never allowed a PC software-based 5C implementation...
post #3407 of 6013
The issues with 1394 capture of local DTV stations on cable are due to the Motorola boxes now responding to the ATSC Redistribution Control descriptor (also known as the Broadcast Flag) when it is present in the OTA bitstream.

The easiest way to get around this is with a QAM capture card for your PC.

Ron
post #3408 of 6013
I'm wondering if anyone has been able to successfully use the techniques in this thread to capture via firewire/IEE1394 the output from the Toshiba TV's that have that interface?
post #3409 of 6013
Quote:
Originally Posted by dr1394 View Post

The issues with 1394 capture of local DTV stations on cable are due to the Motorola boxes now responding to the ATSC Redistribution Control descriptor (also known as the Broadcast Flag) when it is present in the OTA bitstream.

The easiest way to get around this is with a QAM capture card for your PC.

Ron

That must be what's happening to several of our local OTA HD broadcasts. Isn't the Broadcast Flag supposed to be in "remission" at this time? Are OTA broadcasters able to just switch it off?

What QAM capture cards are most PC-friendly? What about component or HDMI capture cards? I believe Blackmagic has something, but I don't think it will do any good on CCI=00x2 content.
post #3410 of 6013
Quote:
Originally Posted by tluxon View Post

That must be what's happening to several of our local OTA HD broadcasts. Isn't the Broadcast Flag supposed to be in "remission" at this time? Are OTA broadcasters able to just switch it off?

What QAM capture cards are most PC-friendly? What about component or HDMI capture cards? I believe Blackmagic has something, but I don't think it will do any good on CCI=00x2 content.

The BlackMagic card clearly states that it won't capture copy-protected HDMI, which I'm pretty sure is ALL of the output from a Comcast/Moto box (since it requires an HDCP-compliant display).

Besides, it captures raw, uncompressed HDMI video - which is like 1GB/minute or worse and probably requires a multi-drive striped RAID array just to get the necessary write speed.
post #3411 of 6013
so I've read bits and pieces from this thread. I see that it's currently a losing battle. But I'll ask this on a side note.

Is there any way to record OnDemand content... even to the DVR. I'm fairly certain I have a 64XX model HD-DVR box from comcast. (I got it in July).

It's SD content, to be specific, exercise programs for the SO. And I'm aware of why we SHOULDN'T be able to record on demand content even to the DVR, but I'm curious if there's a workaround to the PC or otherwise that doens't involve a VCR
post #3412 of 6013
Quote:
Originally Posted by aC39 View Post

so I've read bits and pieces from this thread. I see that it's currently a losing battle. But I'll ask this on a side note.

Is there any way to record OnDemand content... even to the DVR. I'm fairly certain I have a 64XX model HD-DVR box from comcast. (I got it in July).

It's SD content, to be specific, exercise programs for the SO. And I'm aware of why we SHOULDN'T be able to record on demand content even to the DVR, but I'm curious if there's a workaround to the PC or otherwise that doens't involve a VCR

It's very rare for me to want to record OnDemand programming so far, but I have ReplayTVs hooked up to each of my 3416s which can record anything put out of its s-video or composite outputs, including OnDemand programming. It's a piece of cake to get the program to the PC using DVArchive.

There are many other methods, but that's mine.
post #3413 of 6013
Quote:
Originally Posted by jimre View Post

The BlackMagic card clearly states that it won't capture copy-protected HDMI, which I'm pretty sure is ALL of the output from a Comcast/Moto box (since it requires an HDCP-compliant display).

I would've thought that anything that could be captured by a PC over firewire (5C=0, CCI=00x0) would be capturable by that Blackmagic card as well. Is programming flagged copy free also considered to be copy-protected HDMI just because it's going out over HDMI?
Quote:


Besides, it captures raw, uncompressed HDMI video - which is like 1GB/minute or worse and probably requires a multi-drive striped RAID array just to get the necessary write speed.

Now that could be a problem - but at least then you'd have it to do something with.
post #3414 of 6013
Quote:
Originally Posted by Electrox3d View Post

Darn it! How come DVD's come out and they get cracked, HD-DVD comes out Blu-ray comes out, and the new AACS gets "decrypted". Its been years since we've had HD channels coming over FireWire TO OUR PC's, we even have files with REAL data, and we can't decrypt them! ack!!

I was just thinking the same thing after reading all the news articles.
post #3415 of 6013
Quote:
Originally Posted by tluxon View Post

That must be what's happening to several of our local OTA HD broadcasts. Isn't the Broadcast Flag supposed to be in "remission" at this time? Are OTA broadcasters able to just switch it off?

What QAM capture cards are most PC-friendly? What about component or HDMI capture cards? I believe Blackmagic has something, but I don't think it will do any good on CCI=00x2 content.

Many DTV stations inserted the RC descriptor into their bitstreams last year, when it looked like the Broadcast Flag was going to be implemented. Most have just left it in, but they could take it out. On FOX stations, it's being inserted by the FOX network. That's why the encryption isn't there during non-network programs.


For QAM capture, The MDP-130 seems pretty popular.

http://www.digitalconnection.com/Pro...deo/mdp130.asp

Ron
post #3416 of 6013
Quote:
Originally Posted by Electrox3d View Post

Darn it! How come DVD's come out and they get cracked, HD-DVD comes out Blu-ray comes out, and the new AACS gets "decrypted". Its been years since we've had HD channels coming over FireWire TO OUR PC's, we even have files with REAL data, and we can't decrypt them! ack!!

5C/DTCP is more difficult to hack, since it only runs on embedded systems which usually have a less popular CPU (like ARM or MIPS) and a real-time OS (like VxWorks). So it's very difficult to even start hacking a 5C/DTCP enabled box.

In addition, the actual scrambler is in silicon, so even if you could get to the content key, you'd still have to know how the (secret) cipher in the scrambler works.

The scrambled bitstreams that you've captured with capDVHS are useless. The content/scrambling key changes every 30 to 120 seconds, so you need many content keys to decrypt a movie.

Ron
post #3417 of 6013
Quote:
Originally Posted by tluxon View Post

I would've thought that anything that could be captured by a PC over firewire (5C=0, CCI=00x0) would be capturable by that Blackmagic card as well. Is programming flagged copy free also considered to be copy-protected HDMI just because it's going out over HDMI?.

When I read the Blackmagic specs that say it "won't capture copy-protected material", I was assuming that meant it wasn't HDCP-compliant - and, like with non-HCDP displays, the Comcast/Moto box would simply refuse to output *any* video. But perhaps the card is HDCP-compliant, and it simply obeys any copy-protection flags in HDCP content. I don't know if this is the case, or whether HDCP works like DTCP/5C in this regard.

But still - the sheer size & speed requirements of uncompressed HD video make it totally impractical for archiving or timeshifting, IMHO.
post #3418 of 6013
Quote:
Originally Posted by jimre View Post

But perhaps the card is HDCP-compliant, and it simply obeys any copy-protection flags in HDCP content. I don't know if this is the case, or whether HDCP works like DTCP/5C in this regard.

The HDCP signal does not contain any flags like DTCP/5C does.

Basically, if an HDMI signal is encrypted with HDCP, then it is always considered "copy never," so it cannot be recorded by any HDCP-compliant device. Otherwise, if it's not encrypted, then it is effectively considered "copy freely," so it can be recorded by any device, even by devices that cannot decrypt HDCP at all.

I suspect that the card cannot decrypt HDCP at all, not even for viewing purposes. If true, I would simply call it HDCP-incompatible, not HDCP-compliant. In other words, the card can only receive non-HDCP signals (i.e., HDMI signals that have not been encrypted with HDCP).
post #3419 of 6013
I can capture mpeg2 transport streams from my qam tuner (an HDHomeRun). I would like to look for the embedded DTCP_Descriptor to confirm if it really is there, and if so what the value of the DTCP_CCI field is. I want to compare that to what my Comcast 3412 (16.20) is reporting to try and get some evidence of where the CCI=2 determination on the 3412 is coming from.

I've looked through the technical spec

http://www.dtcp.com/data/info%202005...1%20%201p4.pdf

which clearly defines the format of the dtcp_descriptor, which is in fact an ATSC_CA descriptor. However, the document doesn't describe how to find the ATSC_CA descriptors, in the stream.

Does anyone know of a program that will analyze an MPEG-2 TS and print out the CCI flag, or dump the descriptors?

I did do the cheap thing already. The dtcp_descriptor has a 1 byte tag of 0x88 , followed by a 1 byte length, followed by the CA_System_ID of 0x0fff. I don't see that pattern in the stream, but it's not clear to me that I should really expect to see it in the clear.

I'm just looking at Comcast's transmission of HD OTA channels, which are not encrypted. Of the 4 networks, the 3412 get CCI=2 for NBC and ABC, and CCI=0 for CBS and FOX. My QAM tuner is happy to capture all of them, but I would like to be able to also get NBC and ABC by firewire off the 3412.
post #3420 of 6013
Quote:
Originally Posted by km View Post

I can capture mpeg2 transport streams from my qam tuner (an HDHomeRun). I would like to look for the embedded DTCP_Descriptor to confirm if it really is there, and if so what the value of the DTCP_CCI field is. I want to compare that to what my Comcast 3412 (16.20) is reporting to try and get some evidence of where the CCI=2 determination on the 3412 is coming from.

I've looked through the technical spec

http://www.dtcp.com/data/info%202005...1%20%201p4.pdf

which clearly defines the format of the dtcp_descriptor, which is in fact an ATSC_CA descriptor. However, the document doesn't describe how to find the ATSC_CA descriptors, in the stream.

Does anyone know of a program that will analyze an MPEG-2 TS and print out the CCI flag, or dump the descriptors?

I did do the cheap thing already. The dtcp_descriptor has a 1 byte tag of 0x88 , followed by a 1 byte length, followed by the CA_System_ID of 0x0fff. I don't see that pattern in the stream, but it's not clear to me that I should really expect to see it in the clear.

I'm just looking at Comcast's transmission of HD OTA channels, which are not encrypted. Of the 4 networks, the 3412 get CCI=2 for NBC and ABC, and CCI=0 for CBS and FOX. My QAM tuner is happy to capture all of them, but I would like to be able to also get NBC and ABC by firewire off the 3412.

You're looking for the wrong descriptor. You should be looking for the RC descriptor instead. It's tag is 0xAA. The DTCP descriptor is only sent on the 1394 link.

For tools, you can use TSReader:

http://www.coolstf.com/tsreader/

or you can use my command line tool xport (which also does demuxing):

http://www.w6rz.net/xport.zip

Here's the thread where myself and others debug this issue on Comcast in the SF Bay Area (starting around this post).

http://www.avsforum.com/avs-vb/showt...&&#post8963494

Ron
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HDTV Recorders
AVS › AVS Forum › HDTV › HDTV Recorders › How to record via IEEE 1394 (Firewire) to Windows XP