March 1st, 2004, 11:49 AM | #136 |
Space Hipster
Join Date: Oct 2001
Location: Greensboro, NC
Posts: 1,508
|
|
March 1st, 2004, 12:01 PM | #137 |
Major Player
Join Date: Jul 2003
Posts: 479
|
USB 2.0 does not have the necessary bandwidth...unless I use two interfaces.
I consider the option of dual USB/FW a last resort, because it requires the target computer to have two separate USB/FW cards...not that they are extremely expensive, but just a last resort. Juan |
March 1st, 2004, 12:19 PM | #138 |
Trustee
Join Date: Mar 2003
Location: Virginia Beach, VA
Posts: 1,095
|
I still say firewire is the best bet. It's a good peer-to-peer protocol that doesn't require a computer as an intermediary. If you plan on using this mod in the field, and you're using SATA, I think you're going to start running into some big problems that firewire 800 could easily avoid.
If all you're planning on doing is using the camera mod for green screen on a sound stage, then sure, having a PC close-by is no problem. But in the field, having I think it would be easiest to simply hook up via firewire and go. |
March 1st, 2004, 12:23 PM | #139 |
Space Hipster
Join Date: Oct 2001
Location: Greensboro, NC
Posts: 1,508
|
I was just joking about wireless USB, though the future standards that support 1000 Mb/s sound interesting.
But for this, I still like SATA because of the lower CPU utilization than firewire, less expensive and I'm sure it can be made PC less as well. |
March 2nd, 2004, 12:27 PM | #140 |
Trustee
Join Date: Mar 2003
Location: Virginia Beach, VA
Posts: 1,095
|
I'm not too sure about the "PC-less" part, because SATA was not designed as a peer-to-peer protocol, there is suppose to be a dedicated host (i.e. PC) on one end of the connection-which again will seriously screw people up who want to be on location without dragging an ATX case and a 120V generator around with them wherever they go.
|
March 2nd, 2004, 04:40 PM | #141 |
Regular Crew
Join Date: Jan 2004
Location: Olympia, WA
Posts: 54
|
I know virtually nothing about firewire 800. My main interest in this development of Juan's is the potential to get a DVCpro50 signal out of the DVX. Could there be options within this device for that, or would I need to just run the raw data out of the cam into a computer and convert it to DVCpro50 afterward?
|
March 3rd, 2004, 02:23 AM | #142 |
Regular Crew
Join Date: Oct 2003
Location: Los Angeles, CA
Posts: 173
|
It seems to me (and my limited hardware ninja knowledge) that firewire is the way to go.
Alternatively, here are some very fast, and cheap drives ... http://www.softwareandstuff.com/DRV10382.html |
March 3rd, 2004, 02:48 AM | #143 |
Space Hipster
Join Date: Oct 2001
Location: Greensboro, NC
Posts: 1,508
|
I aware that firewire is the current best option, but to support future higher bandwidths, I think SATA is an option.
SATA could easily be made PC-less via embedded firmware controllers, or even more interesting could pack a PC in the case http://www.flipstartpc.com Having a full function XP/Linux/OSX machine with a SATA drive would only be slighty larger than the Flipstart and would open all sorts of options, from RAID (via Seagate's 2.5" drives, 10,000 RPM drives if they release a SATA version or 2.5" notebook SATA drives which will arrive this year) to easy editing and output to tape in the field on battery without a notebook. I've used firewire drives on several systems and they are not ideally configured for speed. SATA is much faster on my system (i have had the same drives internal and external and the difference is dramatic. Firewire 800 does not solve the latency issues inherit in firewire from the reports I have seen (if you have firewire vs SATA benchmarks that prove otherwise, let me know). So, for Juan current needs (and future HDV and HD data rates), SATA via 2.5" RAID drives seems like a great, portable, fast and low cost solution. |
March 3rd, 2004, 07:49 AM | #144 |
Major Player
Join Date: Jul 2003
Posts: 479
|
Stephen has some really good points...the whole reason why I am even considering SATA is because of implementing FW800 is harder, and as a matter of fact i haven't found any general-purpose transceiver yet...the only kind i've found is the one that interfaces to PCI, which is intended to work on a PC...if I use this, i have to implement a driver somehow.
One thing to note, however, is that there really isn't any need for upgradeability. I know, i know, usually these are famous last words...but the truth is because of the nature of the application there isn't. The raw data rate is constant, and it will never increase....it is the same data rate for all modes(60i,30p,24p), so as long as there is a system that can record at that rate, there is no point in making it record any faster...unless there is something I am missing? I did some benchmark tests with my external LaCie 200GB FW drive, and it peaked at 67MB/sec in writing..i am unsure of whether this is continous or so. We need about 40MB/sec.... Another things to consider is that this is a one-way interface...so far we do not need the target computer/drive to send any info back other than control signals. Juan |
March 3rd, 2004, 09:40 AM | #145 |
Regular Crew
Join Date: Sep 2002
Location: Loveland, CO
Posts: 101
|
<<<-- Originally posted by Juan P. Pertierra :
Another things to consider is that this is a one-way interface...so far we do not need the target computer/drive to send any info back other than control signals. Juan -->>> Kinda sounds like a 800 MPH rocket sled and the rider has no cut-off and no parachute to me. If you have no redundant capture capabilities and no way to slow/pause the datastream, you better have a drive that has way more throughput then 40 Mb. Even a drive with a huge buffer could have problems unless the controller is smart enough to store data in an contiguous stream from shot to shot. Just a little to much seeking and any normal HD buffer will overflow at the 37 Mb or so transfer rate. Maybe a raid system would have a better chance? BTW - Glad you're making progress Juan. Just looking at some of the hurtles you may have to jump. -Rodger |
March 3rd, 2004, 05:59 PM | #146 |
Regular Crew
Join Date: Jan 2004
Location: Germany, Northern Europe
Posts: 32
|
Uncompressed @ IEEE 1394
In addition to my previous posts I would like to point at FCP4īs direct support of uncompressed 4:2:2 YUV 10- or 8-bit signals - http://www.apple.com/finalcutpro/specs.html. For recording, a portable hard drive like for instance the Quickstream Dv should do, so there would be no need to re-invent the wheel.
|
March 4th, 2004, 01:16 PM | #147 |
Major Player
Join Date: Jul 2003
Posts: 479
|
That would be nice, but I don't think it's quite that simple...anything that is streamed through a cable to a computer/drive has to be controlled somehow...either packeted(fw,usb) or with control lines(RS-232,etc). I doubt you can just drop raw 4:2:2 through a cable and expect the drive to record it.
besides, we have the problem of frame size...most of these standards are NTSC frame size, and we want to be able to record the 771x494 the camera puts out, so i have to make my own standard. I've been thinking long and hard about how to do this, and i've come across some possibilities...it seems one of the best ones is just to program an Altera array interface the data to PCI, which can then be hooked up to either a SATA or FW controller easily. I think as long as I can interface to PCI somehow, the best option is FW800, because then the Altera chip can be programmed to just stream the data if a drive is connected into a raw file. The file can be converted to any standard format(or unstandard 4:4:4 frames) using a simple program that i'll write. Juan |
March 7th, 2004, 12:44 AM | #148 |
Regular Crew
Join Date: Oct 2003
Location: Los Angeles, CA
Posts: 173
|
<<<-- Originally posted by Juan P. Pertierra : we want to be able to record the 771x494 the camera puts out-->>>
Maybe it was discussed several pages back and I missed it (my apologies if so), but I would assume the raw image size to be AT LEAST as large as PAL on the vertical and horizontal, since afaik the PAL cameras usually share chips with NTSC cameras.. so i would expect the frame size to be at least 771x576.. no? Also, i know it's 99% likely you have already thought of this, but please keep us XL1s (and other cam users) in mind, and make sure that this item can scale to other cameras if possible.. i.e. software/hardware drivers will be compatible with chips that may produce frames of 771+ or 576+ size ;) Sorry if i mentioned anything that was already covered.. |
March 7th, 2004, 12:19 PM | #149 |
Major Player
Join Date: Jul 2003
Posts: 479
|
Adam,
Logically, that's what makes sense...however in practice, the frames ARE 771x494. I've been capturing continous frames for a while now, and i'm absolutely sure that is the res.(at least in 24p) one thing i haven't tried is to switch between fine mode on and off....see if this has any effect on the raw resolution...however i'm pretty sure it is on fine mode 24P right now. I am already capturing frames at 10-bit color...for now this is going to have to do because my capture card is 32bit and won't handle all 36 lines. Also, the $50k+ logic analyzer in my lab died so i can't use that(has 64 lines). Right now I have one small glitch to get over: two of the connections are intermittent and causing some speckles in the image...i know how to fix it but I have 3 exams this week, so i'm going to attend to that first. The images look fantastic but i'll let you guys be the judge once I upload some frames. Remember that these are going to be 10-bit color frames...the camera actually does 12-bit but my card doesn't have enough lines. Juan |
March 8th, 2004, 12:27 PM | #150 |
Tourist
Join Date: Mar 2004
Location: chambly canada
Posts: 1
|
uncompressed
Hi Juan , I'm living in Quebec and I'm very interesting of your work , when you will be ready for pictures grab , it will be very intersting to have a 2 sec QT uncompressed file or a Targa sequence file that we can download to make some compositing or Color correction ; )
So if your DVx-100 modifications works I will be interest to pay for it and I'm sure that a lot of people here will be. Thank you
__________________
Marc |
| ||||||
|
|