Announcing DCTRecordApp (Motorola 620x recording app for Windows) - Page 2  

me> I fail to see the requirement for 5C - unless the DCT won't even transmit the stream to the HTPC.

martyj19> Two strikes. The DCT won't even transmit the stream to the HTPC, and in addition you cannot avoid having to decrypt it in the HTPC because it is sent from the DCT encrypted.

Well, I accept the 1st strike (i.e. the DCT won't even transmit the stream to the HTPC). Guess this works to the JVC D-VHS deck due to some authentication process. Most disappointing - though now that I think about it the Copy Limitation can only be known to be enforced by 5C-compliant devices. Oh, well...

As for your 2nd strike - I think you missed my point. If the HTPC simply never decrypts the content and passes it *back* to a 5C compliant device for recording/display (e.g. the very set-top which streamed it to the HTPC originally), then no decryption in HTPC is required. I would personally be content to utilize the MPEG-2 HL/MP decoding in the set-top rather than dealing with all the hiccups/limitations of similar HTPC-based decoders...

But your 1st strike kinda makes this all moot :-( So much for "fair use"...

John,
Thanks for the reply. FYI, DVHStool will successfully concatenate and play back your material. However, it has no ability to skip forward/back etc.; you have to shut it down to select a new start point. Sure wish Zoomplayer had seamless playback working.

Regarding 5C, this tool will capture 5C content (note I relay the firewire THROUGH my JVC, thus the stream is passed); HOWEVER, the captured content is encrypted and unreadable. So INHD 1/2 and ESPNHD are scrambled files, but all OTA material is fine.

Spearse

Without going into too much repetition, your second scenario wouldn't succeed for similar reasons.

Let's not forget that on average we have had working Firewire ports for somewhere around a month now, and things are still getting off the ground. There is no reason why a computer based 5C compliant recorder couldn't be created. Though it is a somewhat tricky design, not at all out of reach of someone with the right kind of experience, and as I pointed out it is not something that the average individual could probably attempt due to the expense and liability involved.

I'm stuck on where there is a fair use problem. If today I am lucky enough to have access to HD content and a 5C compliant recorder like the JVC, I can record that content and play it as many times as I want. The thing I can't do is use the JVC to copy it in ways that aren't permitted by Copy Never or Copy Once, and another thing I probably can't do is successfully create a copy of the content that doesn't honor the copy flags by cracking the protocols. If I have Copy Once content, I can take it off the recorder onto a disc and play that as many times as I want.

For whatever reason the content creators have decided that it is worth going to a lot of trouble to protect content with more than DVD resolution (520,000 pixels it is actually).

spearse,

If you use DVHSTools in preview mode (i.e. do not output to the JVC but just preview on your screen), then there is a slider bar. It works fine, but sometimes DVHSTools will crash when using the slider bar.

Don't know if this is related but....
I just received a notification from my local cable provider (Insight) informing me that they are "temporarily pulling the plug" on my DVI connection until they can patch (ie develop) a program that will enforce the encryption. I'm using the Motorola DCT HD box. As for now, I am forced to use my component cables until they upgrade the software on the box. Any comments?

sammylou,
I sure don't like the direction they are heading here. Comcast has already clamped down on non-OTA channels by turning on 5C.
spearse

All- turns out DVHStools does have shortcut keys, trial and error exposes them for HD playback. I've tried Murdoc HD player but it's not very reliable, and picky on directshow filter playback. Zoomplayer seems incapable of smooth (non-disjointed) multi-file playback (thanks for the tip though John!) I have tried the new Mpeg public domain splitter, no improvement.

Spearse

As I understood this, sources like cable STBs don't transmit video streams to a particular sink on the bus--they broadcast it to everyone. If it's DTCP protected, you can't do anything with the data unless you get a key with which to decrypt it, and to do that, you have to know the authentication protocols and have the proper credentials. You can capture and record the encrypted content, but since it's encrypted with a dynamically generated key, if you don't obtain the encryption key from the source when you capture the content, it's useless.

I do stand corrected on the "won't transmit" part. Someone pointed out later that it is possible to eavesdrop the session for example if you have a JVC and a computer both on the 1394 connected to the cable box.

And very true on the dynamically generated keys, I chose not to go into that much detail at the time.

martyj19,
I sure wish you could "eavesdrop", but I have the 6200-->DVHS-->PC daisychain and the PC still won't decode 5C. Note the JVC must be "tuned" to the firewire for the PC to capture non-5C stuff, so something odd is going on-- perhaps the JVC is "relaying" the firewire data vs. passively bussing it on to the PC.

Spearse

That's what would be expected. Firewire is a network bus not unlike Ethernet. As I gather it, and I don't have the equipment I'd need to see this for myself, if you have a cable box, a DVHS, and a PC all on Firewire, the data meant for the DVHS is also visible to the PC. The difference is that the DVHS is a 5C compliant device and can establish a properly authenticated session and negotiate encryption keys for the transfer. The PC is not a 5C compliant device (without software that no one has yet written and may not due to liability issues that I've touched on earlier).

But even if it were 5C compliant it could not decrypt the stream between the cable box and the DVHS. Because the encryption keys are negotiated between the sender and receiver, and renegotiated periodically, there is (supposed to be) no way for an eavesdropper to know what these keys are and thus no way for an eavesdropper to decrypt the data. This is well understood technology that is very similar to how your credit card number is protected as it passes over the Internet.

Can someone post a quick step by step howto for getting the meidvhs driver installed? Do you need to hack the INF file to enter the ID number(s) of the 620x box? I only have 7.07 and don't see an AV/C device in device manager, will that device only show up when I have 7.10? The devices I see now are "61883 Class Bus Device" and "Unknown device" both listed as on the firewire bus.

Martyj19,
Right, that's my understanding of firewire as well. But my setup is not behaving like a network bus. It's acting like my JVC is the center of a "star" topology. The JVC must be tuned to the 6200 input, or the PC doesn't "see" the 6200 video stream. Yet my PC does see and device-enable the 6200 itself even if the JVC isn't tuned to the 6200. Strange, huh?
Spearse

There seems to be a cookbook including an INF file in the sticky "HowTO record via 1394/Firewire to WindowsXP", if that helps.

Thanks. :)

I don't know if this helps you at all (since it's for a mac), but on this site: http://mac_hdtv_timer.home.comcast.net/tips.html he's using applescripts to change the channels on a DCT6200, although it seems there are quite a few workarounds for it.

More info here: http://mac_hdtv_timer.home.comcast.net/channel.html

Thanks for the Apps. Some of the best recordings I've ever made of TV. Very large SD files though.

Anyone know how you would convert these .ts files to mpg format?

Tim Huey

Just did a timed recording of "MI2" from CBS. 1080i. Several large files. Seemed to get the whole thing though.

Anyone know how to append all these pieces together? How bout editing out the commericals?

Tim Huey

HDTVtoMPEG2 v1.10b

Perfect. Thanks.

Now, is there anything that will combine .TS files together.

Tim

It will do that to.

It combines, splits, edits, and converts to mpeg what else could you ask for?

That might explain why when I gave it one chunk it didn't convert it to MPEG2. All I got was a 2k file. Odd. I will try with several files.

Tim

I cant get it to record to anywhere but C:\\ which I dont have much space on as I partition my drive. Is there a way to have it know to go to E:\\Caps for example by default?

I've been following this thread for a while and and can't resist asking these questions (I've spent at least a man-week trying to sort this stuff out and there just seems to be no clear explanation of these topics)

1) Regarding 5C:

Doesn't "5C" actually mean the "5 Companies?"

and is used to loosely refer to all the copyguards that the "5C" imposed?

Broadcast Flag, on the other hand is an FCC rule and not, per se, 5C?

2) Regarding IEEE:

is there a handshake between the Motorola and the recording device to see if it is BF compliant?

and if not, the Motorola will not stream the data?

I have read other people say the JVC 40k and newer employ BF and of course all the copyguards. If this is the case, that would be why only the JVC can record off the Motorola, i.e., it is the only BF enabled device.

Further, I would think that any protected signal would have zero chance of being recorded by the JVC. (The JVC halts recording when it encounters stone age macrovision on VHS tapes. It won't even give you a "macrovision corrupted" copy!)

However, if the JVC is the only device that records some Motorola signal, there surely couldn't have been ANY copy protection and it must mean that it was a "permitted recording" broadcast flag setting AND there is a BF handshake to establish a "legal" recorder.

I have the Motorola (Comcast) and had a 30k that recorded fine from the IEEE. I just bot a 40k and haven't had a chance to plumb it in yet.

I am an ex-FORTRAN programmer and just starting object oriented programming with Delphi and am very interested to dissect this program that has been written to record IEEE.

I suspect that the BF definition must be specified in FCC rules somewhere. Perhaps it is a word in a packet header. The protocol of the handshake is another matter and would have to be specified by the FCC for compatibility.

These are a lot of questions and I haven't been able to find any sort of answer to them from weeks of searching on the internet. So I guess I'll have to start pestering people for help.

Appologies
Tom

The Broadcast Flag and 5C are two different things, although they can be used
together. 5C (also known as DTCP) is used primarily on IEEE1394, although
it can also be used on USB and IP (Internet Protocol).

To find out all you could ever want to know about 5C/DTCP, see:

http://www.dtcp.com

The Broadcast Flag is just a descriptor in the OTA MPEG-2 Transport Stream.
It is defined here (as the "redistribution control descriptor"):

http://www.atsc.org/standards/a_65b.pdf

After July 1, 2005, ATSC receivers are to be designed such that if they have
a digital output, the content will have distribution control. For DVI/HDMI,
this means HDCP will be turned on. For IEEE1394, this means that the content
will be encrypted, but still copy freely (this sounds like an oxymoron, but
it's a supported mode in 5C/DTCP, controlled by the EPN bit).

In addition, the ATSC receiver must be designed such that the in the clear
bitstream cannot be accessed on the circuit board (to prevent "hacking").
This is the "robustness" portion of the Broadcast Flag, and many folks
believe that this will increase the cost of ATSC receivers just as the
cost was finally starting to come down.

The basic idea behind redistribution control is to keep content off of PC's
and hence off of the Internet (since no PC is 5C/DTCP compliant). D-VHS (and
blue laser optical recorders) are 5C/DTCP compliant, and you will be able
to record Broadcast Flag content on these devices. You will also be able
to make unlimited copies, but only one at a time with another 5C/DTCP
compliant recorder (and not a PC).

To answer you second question specifically, the Broadcast Flag would instruct
an ATSC receiver or cable box with IEEE1394 output to set it's flags
appropriately (in another MPEG-2 Transport Stream descriptor called the
DTCP_descriptor). That is, CCI (copy control information) would be set to
"copy freely", but EPN would be asserted. EPN assertion causes the output
to be encrypted. Only another 5C/DTCP enabled box can decrypt this
stream. The receiving box doesn't really know that the Broadcast Flag
turned on the encryption, all it sees is "copy freely" and EPN asserted.

Ron

Ron,

Thanks a bunch for the lesson!

Yes, I simply can't believe BF will allow any form of "unlimited copying" given the mentallity of MPAA and RIAA. However, who knows, that's what they claim, eh?

The fallout of all this is that BF turns on encryption and that renders non-BF recorders useless. (I heard this mentioned a number of times in other threads.)

Of course, there have been recent challenges to BF and who knows, what the outcome may be, but I am not hopefull. They challenge that the FCC does not have this authority but Congress could quickly rectify that issue.(www.slashdot.com is great news sit to check every day regarding relevant technological advances and legal encroachments.)

I was working on a HTPC configuration that would be BF non-compliant that would also record 5.1 mainly for Time Slipping. Having to give up 5.1 to Timeslip is unaccpetable! I'll probably resort to an OTA Linux rig and call it quits.

I wonder if they will start X-raying ATSC chips and drilling into them like they did to hack VideoCipher, eh?

Thanks again,
Tom