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

When I open vlc and stream ondemand then go to lord of the rings which is 5c=1 in hd it captures about a second of the movie then stops and then I can do the same process over again but with capdvhs open instead of vlc and it records a second of it even though it is 5c=1 has anyone else been able to do this?

So this sounds like the Blackmagic HDMI capture card would record *nothing* from a Comcast/Moto box, not even in-the-clear channels - since the box doesn't output video at all to non-HDCP displays.

Same here. For some reason 5c=1 on my local stations, yet 5c and CCI = 0 for stations like DHD, TNTHD, INHD, all Encore movie channels...etc...

It makes no sense at all, like someone is randomly flipping switches. I was under the impression that for local hd stations the cable companies were required to leave 5c=0.

Anyways, comcast is soon taking over my area, so it doesn't look too good for the future of my firewire capturing.

On the upside, I finally got HD streaming over LAN working with my Motorola 6200 and VLC.

Well, I did get a hold of TSReader and no RC descriptor. Below is what shows for two HD channels from Atlanta Comcast via QAM. Program 10 is the CBS affiliate, Program 806 is NBC, both off the same QAM channel (108). The 3416 shows CCI=0 on CBS and CCI=2 on NBC.
There is no RC (0xAA) descriptor on either, but there is private data descriptor 0XA3 on NBC.

I'm not including it below, but I also checked FOX (CCI=0) which has no 0XA3, and ABC (CCI=2) which does have an 0XA3. So it look 0XA3 is the discriminator in Atlanta.

Is there a tag name for 0XA3 that TSReader doesn't know?

Program Number: 10
Descriptor: Smoothing Buffer Descriptor
SB Leak Rate: 0 SB Size: 0
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)

Stream Type: 0x02 MPEG-2 Video PID 62 (0x003e)
MPEG Video: Bitrate 38.810 Mbps Resolution 1920 x 1080i
MPEG Video: Framerate 29.97 fps Aspect Ratio 16:9 Chroma Format 4:2:0
Descriptor: Data Stream Alignment Descriptor
Alignment type: video access unit
Descriptor: User Private Descriptor: 0x86
e2 65 6e 67 7e 3f ff 65 6e 67 c1 3f ff .eng~?.eng.?.

Stream Type: 0x81 AC-3 Audio PID 63 (0x003f)
AC3: Bitrate 384 Kbps Sample Rate 48 KHz
AC3: Mode complete main Coding 3/2 5 L, C, R, SL, SR
Descriptor: Registration Descriptor
Format identifier: 0x41432d33 (AC-3)
Descriptor: ISO639 Language Descriptor
Language: eng
Audio type: undefined
Descriptor: User Private Descriptor: 0x81
08 bc 1b 09 1f .....

-------
Program Number: 806
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
SB Leak Rate: 45000 SB Size: 512
Descriptor: User Private Descriptor: 0xa3
01 65 6e 67 01 00 00 05 50 72 6f 67 31 .eng....Prog1
Descriptor: User Private Descriptor: 0xaa
ff .



Stream Type: 0x02 MPEG-2 Video PID 49 (0x0031)
MPEG Video: Bitrate 38.810 Mbps Resolution 1920 x 1080i
MPEG Video: Framerate 29.97 fps Aspect Ratio 16:9 Chroma Format 4:2:0
Descriptor: Video Stream Descriptor
Multiple frame rate flag: False
Frame rate: 29.97¼
MPEG-1 only flag: False
Constrained paramter flag: True
Still picture flag: False
Descriptor: Data Stream Alignment Descriptor
Alignment type: video access unit

Stream Type: 0x81 AC-3 Audio PID 52 (0x0034)
AC3: Bitrate 384 Kbps Sample Rate 48 KHz
AC3: Mode complete main Coding 3/2 5 L, C, R, SL, SR
Descriptor: Registration Descriptor
Format identifier: 0x41432d33 (AC-3)
Descriptor: User Private Descriptor: 0x81
08 38 05 00 00 00 .8....
Descriptor: ISO639 Language Descriptor
Language: eng
Audio type: undefined
Descriptor: Data Stream Alignment Descriptor
Alignment type: slice, or video access unit

Um, what about that last line: Descriptor: User Private Descriptor: 0xaa ff?

I would imagine 0xaa is the RC flag and the value "ff" means copy never. Am I wrong?

TSReader doesn't claim to support the 0xaa RC Descriptor tag, so might it just show up as "User Pirvate Descriptor" by default if it's unrecognized?

Yes, I must be a little blind missing that last 0xaa descriptor.

Also, its there only in the other CC=2 channel the ABC affiliate

Program Number: 3
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
SB Leak Rate: 45000 SB Size: 512
Descriptor: User Private Descriptor: 0xa3
01 65 6e 67 01 00 00 06 57 53 42 2d 44 54 .eng....WSB-DT
Descriptor: User Private Descriptor: 0xaa
ff .

Also note, that these two CC=2 streams have both an "0xaa" and "0xa3" Descriptor,
and all the CC=0 have neither.

Although "0xa3" is shown as private, I also see it listed in the TSReader reference as ATSC "component name". There are two ascii strings in each, "eng" common to both and "prog1" in the NBC, and "WSB-DT" the station name in the ABC.

I think we have a clue, that whoever is inserting the "0xaa" is also inserting the"0xa3". Still not clear to me who that is. I wonder if the "eng" identifies it in some way.

It seems likely to me, especially given the results in the SF Bay area, that the 0xaa and 0xa3 tags are being added by your local broadcaster, and the Moto box adds the DTCP tags in order to honor the RC tags. For broadcast content coming from the network, it also appears the flag could come from the broadcast master.

I doubt the 0xa3 is important with respect to the copy protection. It's probably just added for other purposes by the same hardware or software that adds the RC Descriptor.

The component_name_descriptor syntax and usage is defined in ATSC a_65c (the PSIP specification).

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

As ExDeus suggests, it has nothing to do with copy protection. The RC_descriptor is also defined in a_65c. The value (0xff) has no meaning. In fact, on FOX network feeds, you'll see this descriptor with zero length (just the 0xAA). On the Motorola STB's, just the presence of the RC_descriptor triggers 1394 encryption.

BTW, if you capture an in the clear stream on 1394 and run it through TSReader, you'll see the DTCP_descriptor.

Ron

Since my HDHomeRun will also capture OTA ATSC, I can compare the QAM directly to the ATSC.
For example. for NBC

OTA

Program Number: 3 WXIA-DT
Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
SB Leak Rate: 45000 SB Size: 512
Descriptor: ATSC Component Name Descriptor
Component Name: Prog1
Descriptor: ATSC Redistribution Control Descriptor
ff .

QAM

Descriptor: Registration Descriptor
Format identifier: 0x47413934 (GA94)
Descriptor: Smoothing Buffer Descriptor
SB Leak Rate: 45000 SB Size: 512
Descriptor: User Private Descriptor: 0xa3
01 65 6e 67 01 00 00 05 50 72 6f 67 31 .eng....Prog1
Descriptor: User Private Descriptor: 0xaa
ff .

So, the same 2 descriptors show on OTA/ATSC and Comcst/QAM, its just that TSReader declares them private and doesn't label them for QAM.

I agree that the ATSC Redistribution Control Descriptor is the critical one, I read in the IEEE paper

http://ieeexplore.ieee.org/iel5/5/33232/01566622.pdf

Redistribution Control Descriptor: The core purpose
for the redistribution control descriptor (commonly referred
to as the broadcast flag), is to signal that the content owner
is asserting his or her rights with regard to redistribution
of the program. The ATSC PSIP standard states that The
descriptor's existence within the ATSC stream shall mean:
technological control of consumer redistribution is signaled.'
The FCC in the United States codified the broadcast
flag in rules that may be found in 47 CFR 73.8 and 73.9 [7]
and 47 CFR 76.1909 [12].

So I guess it comes down to the Atlanta NBC and ABC affiliates asserting the "broadcast flag" and the Motorola 3416 implementing it with CCI=2 over DTCP. Probably these two stations are using a common component (since they are also the only ones with a ATSC Component Name Descriptor) that may default to asserting the RC descriptor.

It would appear that Comcast is not directly involved.

There is however, one Comcast related mystery. As it turns out CCI=2 only shows on only one of the two headends in the area. The Comcast engineer says that both get the same ATSC station feeds and are configured identically.

I checked out my local channels via Comcast, and only the Fox and (Fox owned) MyNetworkTV affiliates have CCI=2.

I also noticed in the Diagnostic Menu of my Moto 3416, in the d06 CURRENT CHANNEL STATUS page, CCI=0x02 and RC Flag=0x01.

For those with CCI=2, are you also seeing RC Flag=0x01?

My capture over Firewire didn't work (DTCP was enabled by the RC Flag!), and OTA TS captures show the following:

Notice only the HD stream has the RC flag. I'd say it's pretty clear the RC flag in a stream triggers the DTCP CCI=2.

My comcast area is the opposite of this. All the local HD channels, ABC, Fox, etc... can be easily captured as they have CCI = 0 but the other HD channels like MHD, UHD, etc... are CCI = 2 and DRM = 1 when looking in the d06 menu of my 3416.

The other digital SD channels are hit or miss it seems like. For example I can't capture the cartoon network, Nickelodean or MTV, but Food TV, CNN and The Fuse Network is ok.

One thing that seemed strange to me was that I could capture all the ESPN SD channels fine, but not ESPNHD or ESPN2HD. They show the same programming so I'm guessing it's the HD part that makes the difference.

I tried to do some test captures last night which lead me to this conclusion. I even rebooted my STB, unplugged it for a few minutes and plugged it back in, to make sure I didn't have some wierd settings set.

Yes. I just checked all the locals that have CCI set to 0x02, and every one of them have the RC Flag set as 0x01. If indeed the origin of the Broadcast Flag is national, it would seem that some boxes convert that into a CCI=0x02 and some of them do not. Perhaps there is something the local cable companies can do (if they're so inclined) to suppress the STB's built-in "adjustment" of the CCI value in response to the RC Flag.

I keep getting ERROR:Cannot open output file or ERROR 80040217:Cannot connect sample grabber when using Cap-DVHS. I had this working on a 6412 before, and the box died. I hooked up another 6412, and it will not work no matter how many times I uninstall and reinstall the driver. I'm showing the Motorola device in Cap-DVHS, but it gives the above error(s) whenever I try to use Cap-DVHS. Anyone have a fix for this? It's driving me nuts! I'm using firmware 16.20

I'm going to start with the obvious: CapDVHS will not overwrite a file that exists. Have you tried deleting the output file or changing the name to a new output file before attempting to record?

HD or SD i do not have RC Flag=0x01 on channels with CCI=0x02 tho I do have DRM=0x01 on those channels.

I'm on Armstrong cable in Western PA and seemingly all of the HD broadcasts of the major networks are CCI=0x02 with a mix of RC=0x01. I can record SD channels just fine, but only one or two HD channels are CCI=0x00. This was the first time I set up the FW->PC and I thought I hosed something up, but apparently we're getting hosed from somewhere else

Checked a little closer tonight and it's similar to what others have seen:
Locals that are CCI=0x02 all have RC=0x01.
Stations where CCI=0x02 and RC=0x00 are 5C=1.

Is it only true for the 3250 or 8300HD works as well?


5c?
If so, wouldn't a DVHS deck work just fine?


I failed to see what would change with the arrival of those recordable HD formats when the problem is at capturing...

I'm still interested in the value of the "broadcast flag" on the troublesome channels. Notice that TSReader shows

Descriptor: ATSC Redistribution Control Descriptor
ff .

I'm wondering about the "ff" value of the descriptor and what it means.

It seems like the definitive documentation on this that everything refers to is

http://www.atsc.org/standards/A65-B.pdf

which is a members only document., I can't get.

Does anyone have information on the possible flag value, and in particular what "0xff" means?

I'm thinking that an affirmative value of the descriptor is something other than "ff", and that the Motorola implementation keys on the existence of the descriptor rather than its value.

I already answered these questions (along with the correct link to a_65), only 10 posts back.

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

Ron

Guys, this is very strange. My Moto 6208 has 5C set at 0 for all of my HD channels. I am able to capture to my laptop for all of them, with the exception of HBO. Unfortunately, my 6208 will not display any CCI information on any channel. I am sure it has to do with the CCI flag. How can I analyze the steam to see what is going on. When I "record", I do not get a 0-byte file. I am afraid to call them, as they just might flag the other 15 channels.

So, the 6208 doesn't have the same diagnostic screens as the later models?

Using VLC streaming is the easiest way to see which channels you can capture. If it streams in VLC, capdvhs should capture it.

My 6208 has different diagnostic screens. VLC will stream all HD channels with the exception of HBO. I am probably beating a dead horse here, but I would just love to know what is going on.

djdrock,

what are the other channels that you are able to record? If it's NBCHD, ABCHD, CBSHD ESPNHD, TNTHD, etc. then I'm pretty sure everyone can copy those. It's the premium subscription channels like HBO that are flagged "copy never" and don't work (as you have seen).

I can copy Sho-HD, HDNet, HDNet Movies, Discovery HD, Universal HD, MTV-HD etc...I know, it is strange, every channel except HBO-HD.

I have scoured the net looking for similar circumstances of this, and nowhere can I find someone with the moto 6208, has 5C=0, can record all HD channels except HBO-HD. One thing to note, the only non-HD channel that I can record, or see through VLC, is Encore WAM, and one local station. Very very strange. Maybe I shouldn't complain, but wow, this is crazy!

My 6200 moto box is the same way. I can record INHD, Discovery HD, TNTHD, all Encore SD channels, yet, 5c=1 for my locals, Cartoon Network, and some random other SD channels. I don't subscribe to HDNet, HDNet Movies, UHD, Sho-HD, or HBO-HD so I can't test those out.

Can someone give a list of Cablevision high def channels that you can archive to PC via this method (also how long does it take to archive a 1 hour high def show?)
Lastly, what's the filesize on a 1 hour high def show?

thanks,
Jon

I have Cox, not Cablevision. File capture is done in real time though. You play the show on the cable box, and hit capture on the PC. So it takes 1 hour for a 1 hour show. For me, a 1 hour show in HD is 7-8 GB, although it does vary some, and probably depends on whether it's 720p or 1080i.

Chris

i'm "attempting" to capture from a comcast HD PVR, and i'm getting mixed results. the shows i'm trying to capture are recorded performances by Beck on SNL and david letterman a couple months ago.

i did a test with CAPDVHS and reviewed it with VLC on a (regular broadcast, not recorded) SD channel of something random (i think it was "peoples court" or something like that).

video and audio were fine.

so, i queued up my DVR recordings. pressed play on the TV... then went over to the PC input and hit record on CAPDVHS. went back to the TV input to watch the performance. went back to the computer and stopped the recording. saw a large file was made. great! nope

when i played this in VLC it NEVER showed any audio, and it was kind of laggy at points.

so, i repeated the capture process on the same show again. this time i saw a grey sceen was recorded for the first few minutes, then the laggy video came in.. still no audio.

third time - all i got was a grey screen, no audio

fourth time - the grey screen would come and go, when i do see video it's laggy still. no audio again.


could the problem be my PC specs can't do HD playback? or that i'm trying to record from the DVR instead of regular broadcast? or that its HD?

here are my PC specs:
P4 1.7 GHz
ASUS P4T-E
1GB RDRAM (4x256)
250 GB ATA 7200
GeForce4 128MB Ti4400

I'm NOT an expert, and I've never gotten a scenario like that to work, but these are some of the problems I'd expect with what you're doing:

-one may need a special Transport Stream (TS) player or converter to deal with the gross data spewed out on HDD. This data, I expect, is similar if not identical to the TS files on a DVD. Maybe worse, since it's HDTV.

-may need some extra HDDs to handle the data, and a spare PC to devote to TS conversion.

-may have to rerun conversions because of overrun and underrun problems.

-automatic resets and retries initiated by the slapcard on a standard HDD may ruin a run. Maybe a guy needs several of those special HDDS that don't do thermal resets, etc.

-if standard SD is OK then maybe it's easier to get a show from ********** than record it oneself.

-for HDTV to DVD a guy may have to wait for HD DVD burners.

what isn't clear to me is whether i'm having record/capture problems, or playback issues (of the raw .ts files created). if it's just a playback issue, then i'd be inclined to keep archiving stuff to my pc and sort out the playback later. my DVR is full and Rome and 24 just started new seasons