Software side questions for a notebook capture setup

[Pascal_Parvex]

So, do I need a Core Duo notebook for decent editing with Broadcast? And I need Broadcast to capture, right? There no cheaper solution, right?

[bhiga]

You'd be best served with Broadcast, as EDIUS Pro 3 plus the Canopus Codec Option plus the P2 Format module will cost more than the Broadcast bundle.

For decent editing, you'll need CPU power and good drive throughput. It really depends on how much realtime you want. You can still scrub the timeline to see stuff even if you can't play it back in realtime.

Brandon

[Pascal_Parvex]

Yeah, but I'm worried about streaming recording without hiccups. And, what kind of drive do I need? For recording without dropouts I need an external drive right? And can a simple Firewire drive be carried in a bagpack without problems? And will a notebook battery last long enough?

And what is the link again to this seller selling Broadcast for 799$ for a limited time?

[bhiga]

Well, considering that DVCPRO HD is 100 Mbps, your hard drive will need to be able to sustain 12.5 MB/sec write. It should be okay for 5400 or 7200 rpm drives, it might be much to ask for a 4200 rpm drive, especially if the OS is on the same drive.

The FireWire drive is tricky because if you connect the camera and drive to the same FireWire bus, the drive can actually impede performance by "clogging" the bus with burst transfers.

Hope that helps,
Brandon

[Barry_Green]

Brandon, it'd be great if you'd do some testing on this and could propose situations that would be guaranteed to work.

I've tried with broadcast and I haven't found a reliable/stable capture solution yet. I can get it to capture for a while, but it always comes up with "your drive is too slow." That includes a FW800 G-Raid that is rated at over 50 megabytes per second! The drive isn't too slow, it's 4x faster than necessary, but Edius still pops up the "too slow" message.

FCP can capture live onto its internal hard drive for quite a while before dropping frames, but I can usually only get three or four seconds of 1080/60i captured through Broadcast.

I've tried capturing to an external USB2 drive, to keep the firewire bus separate; same conclusion. I bought a separate PCMCIA FW800 card to use with the laptop so I was running two separate firewire busses -- same problem.

I've tried it on my desktop -- same problem.

Seems to me that there must be some sort of buffering situation going on; I don't know how much RAM you allocate to a capture "dropped frames" buffer, but I'd say it might need to be a whole lot bigger, or something.

Is there any way you guys can test and verify if my results are abnormal, or let us know what the minimum system requirements are for *guaranteed* proper capture performance?

[bhiga]

Sorry, wish I could do some testing too, but I'm loaded with other stuff, especially with NAB coming.

If you're capturing to Canopus HQ format, the "drive too slow" message sometimes appears when the system is too busy doing other stuff.

If you're capturing native DVCPRO, then it shouldn't be a problem.

Remember that it's not only transfer speed that's necessary, but also transfer consistency (low latency) that is necessary for proper capture. If there's too much latency in the pipe, then the data simply can't "get there on time" which is often the case when FireWire devices are chained together. But you're using a separate FireWire interface, so that shouldn't be the problem.

General bus "bursting" can still be an issue though. Is there a way to throttle back the speed of your RAID? Sometimes you get the "too slow" problem when the drive is too fast - seems contradictory, but fast drives often use shorter, larger bursts of data instead of a steady trickle. Those bursts block the bus for a while, and if the bus is blocked long enough, then realtime data doesn't make it to its destination in time, resulting in dropped frames.

Brandon

[Pascal_Parvex]

Is there any way you guys can test and verify if my results are abnormal, or let us know what the minimum system requirements are for *guaranteed* proper capture performance?

Well, you must be doing something wrong, as there was this forum post in another forum, where the third solution worked smooth. They would have said if they had any hiccups.

I'm looking into buying a notebook with Core Duo. So should I take a harddisk with 7200 or 5400 RPM, or will I have to get an external drive?

[mule ferguson]

Laptop Capture Live Video
After a busy shoot edit for the chicken folks (Tyson) I did 2 trials on capturing live video, both to my Dual Core AMD 4800. 200 sata 0 raid internal drives 2g ram 7800 nvidia card I captured 20 mins of 1080/60 without any problems. Then I tried directly to a 7200 Maxtor 100 g drive. It would capture 4 min and stop. It said the disk was full. whick it was not.
So I guess my workflow will be directly to the laptop.

The Maxtor external captures the p2 card from the PCMIA ok.

Mule Ferguson

[bhiga]

Sounds reasonable - it's about the flow rate just as much as it is about the size of the pipe.

[CORUSA Design]

I was able to demo an HVX200 tonight. Was able to live capture to my desktop (Shuttle SN95G5v3) in HD without dropping any frames or having any glitches. I have 900GB internal, and another 300GB external drive. I was able to capture direct through the onboard firewire to my C drive, intro Premiere Pro 1.5, and also to my external also using an onboard firewire port.

Of course I have an AMD FX60 processor but only 2GB ram, and I was able to capture 5 hours without interuption or dropped frames, so I will find a comprable laptop to test this on now that I know it can be done without error to a desktop PC

::: Connor

[CORUSA Design]

Laptop Capture Live Video
Then I tried directly to a 7200 Maxtor 100 g drive. It would capture 4 min and stop. It said the disk was full. whick it was not.
So I guess my workflow will be directly to the laptop.

oh PS - your harddrive did this because it is formatted as FAT32...FAT32 drives cannot handle files larger than 4GB which is why it cut you off. You need to format the external as NTFS, then you will not get that error since NTFS does not have the 4GB file size restriction

::: Connor

[mule ferguson]

Thanks CORUSA:
Mule