DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   Alternative Imaging Methods (https://www.dvinfo.net/forum/alternative-imaging-methods/)
-   -   4:4:4 12-bit Uncompressed DVX100 (https://www.dvinfo.net/forum/alternative-imaging-methods/20332-4-4-4-12-bit-uncompressed-dvx100.html)

Stephen van Vuuren March 1st, 2004 11:49 AM

How about wireless USB 2?:

http://anandtech.com/showdoc.html?i=1981

Juan P. Pertierra March 1st, 2004 12:01 PM

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

Jason Rodriguez March 1st, 2004 12:19 PM

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.

Stephen van Vuuren March 1st, 2004 12:23 PM

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.

Jason Rodriguez March 2nd, 2004 12:27 PM

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.

Justin Burris March 2nd, 2004 04:40 PM

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?

Adam Burtle March 3rd, 2004 02:23 AM

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

Stephen van Vuuren March 3rd, 2004 02:48 AM

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.

Juan P. Pertierra March 3rd, 2004 07:49 AM

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

Rodger Marjama March 3rd, 2004 09:40 AM

<<<-- 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

Lucia de Nieva March 3rd, 2004 05:59 PM

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.

Juan P. Pertierra March 4th, 2004 01:16 PM

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

Adam Burtle March 7th, 2004 12:44 AM

<<<-- 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..

Juan P. Pertierra March 7th, 2004 12:19 PM

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

Marc Takerkart March 8th, 2004 12:27 PM

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


All times are GMT -6. The time now is 10:22 AM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2025 The Digital Video Information Network