DOthan 2ghz chip is in and we are getting 70-85% cpu in Black and WHite preview..this is not good..we got 22% with the 3.06ghz P4..not sure what is going on yet...

also does anyone know if windows 2000 supports SATA disks? it seems that the drives I have (10,000rpm) are not working at a fast datarate..maybe a limit of windows 2000? can someone point me to a good disk speed test .exe for testing the disks on the system?

there seems to be some dramatic speed changes in the chip
depending on which application. I t seems to be a killer chip with certain games . but less so with photoshop and others .

http://www.gamepc.com/labs/view_cont...desktop&page=1

Guys, remember what I say.You will have big headaches using Windows for these cameras....
Also try to avoid threads as much as you can...better is to have fast sequencial tasks..

I agree, if you don't need the thread cut it out. The problem would be different CPU, different achitechture, maybe the main board bios hasn't been updated to support it properly. Consult Intel on coding for your application, and consult mainboard and chipset companies for drivers and bios updates.

Wayne.

Fixing the problems of the SI-1300-RGB-CL
 

Rob S

I had a look at this page here:

http://www.epixinc.com/products/sv9m001.htm

And it gave me some ideas.

This gave me an idea:

Maybe we can get rid of the smear problem by reducing the overload causing it. There are a few ways:

- Use IR and ultra violet cut filters to reduce these emissions from strong light sources, thus reducing the satuation of a pixel compared to the surrounding pixels. As most strong light has high UV or IR content, then this might work very well. If we are extremely lucky the smear problem might be more sensitive to IR or UV.

- One changing gain to compensate (maybe change some on board components, but we aren't up to that, to reduce the circuits max load)

- Increase shutter speed, or use the artifical dual slope technique Steve suggested before (one fast frame and one normal 48th of a second).

- Use a ND filter to get it within limits.

- And playing around with pixel clock and parameters (read out) to see how they effect the smear.

Rolling shutter artifact, as per normal techniques.

So what do you reckon Rob, is it worth going to a camera store for filters to try this out?

Wayne.

Wayne,
I think you could test it out just by stopping down the lens. Sure you will get more DOF, but that shouldn't be related to what you are testing. If you can keep the Micron 1.3Mpix from saturating, any which way, it should be OK. Micron has said that the smearing is inherent in the pixel architecture and they changed that for the 3.2Mpix.

All CMOS color cameras are made with an IR cut filter to keep the colors from being skewed by IR. On some of ours it is built into the sensor cover glass, on others we add it.

Yes, thanks, I would like to see if Rob can improve his camera by doing this. Also if it canbe readily done to just the right amount, rather than having to stop everything down by half. If so, then that makes a reliable low end camera available for his software.

arrg!! why would I now be getting the PCI overflow issue with the new board?? "FIFO overflow" is the error

New board, new chipset design.

First In FIrst Out buffer. Long line of memory cells, circular (when it overflows it is trying to overrite a cell that hasn't been read out). Two pointers, one that pionts to new entry and ine that piont to entry being read. Whn pionters match problems, nothing canbe written (well at least thats a simple FIFO design, maybe more complicated). Different chipsets may have different fifo buffer sizes. So you can monitor how full the fifo is, and buffer anything that won't fit in dram, or findout what the smallest fifo buffers are in any chipset/PCI card/bys chip, and keep writes under this size. N ow I don't know if windows allows you to monitor this though. The problem might also be some timing hickup somewhere else in the computer/code causing data to be written to the fifo in big spurts that are too big to handle.

Because you are getting this problem, my guess is that the system doesn' throttle the FIFO, but that it works most of the time because i is big enough and fast enough to keep ahead of most applications (typical PC stuff). It could also mean that your framerate/pixel size is too for that chipset high.

When I think of it, if you are using dma from dram, then the dma/fifo circuites should throttle it.

the Dothan chip should have a heavy amount of on-chip L2 cache, around 2MB worth. What it doesn't have right now with the 855GME chipset is the memory bandwidth of the Prescott or Northwood on the 800Mhz front-side bus with dual memory channels. For that sort of memory bandwidth, you're going to have to wait till next January for the Alviso chipset which will have a dual-channel memory bus and 533Mhz front-side bus.

that is not needed! this board can do it if it's got a pci-x slot! I am not sure why I get FIFO overflow but it is NOT the cpu and should not be the pci buss..I am sending all the stuff off today for our programmer to have it all in his hands to work on and finish the thing

BTW the Bolex lenses look AWESOME..much much much better then the c-mount CCTV lens I have been using

For sure the "FIFO overflow" error is software/drivers related!
As example - now I have similar issue -capture with DVIO.exe(a small,no preview,but RockStable capture application for IEEE 1394 ONLY)
gives me 100% CPU load and dropped frames in windows1* and 00% CPU/no dropped frames in windows2*!

* windows1 and windows2 are winXP SP2 installations on different partitions,not visible each other.

Obin:
FIFO overflow means that the FIFOs on the capture card that buffer the streaming data are not being emptied as fast as they are filled. This means that you are running out of PCI bus bandwidth. On the frame grabber systems, the data is unpacked - 10 or 12 bits takes two bytes. The maximum pixel rate you can run at is 50-60MHz clock since that will put 100 to 120MB/sec across a bus that is rated at 132MB/sec max (not continuous since your OS likes to wander around, do some house cleaning, sweeping and ....washing windows at its whim).

Steve:
how come I can push 65mhz on one of the machines here at work? and the DFI board will only push 35mhz!! this does not seem ok ..am I wrong? when will the 64bit FG be out?

I am having a hard time taking this 32bit stuff much longer...

I don't think that it is the amount of memory bandwidth (lack of dual channel to split program from data might be something though). The amount of bandwidth that the card takes up (around 100MB's, to a number MB's persecond is a little like saying that the needle may overwhelm the hay stack, but that would need like a third party Elephant to try and sleep in the hay stack and sit on the needle, thus detroying the haystack in a rage to get out.

What Steve said is right, but I wonder why the same fifo's on a card have no problems in one machine and are in another (plus the speed issue), I still thiunk chipset issue, that the drivers have to handle. But doesn;t the chipset have it's own FIFo buffers to handle transfers to PCI bus devides?

I think the problem is that PCI32 capture cards (without compression, buffer or packing) are really like good for 720p.


Thanks

Wayne.

viewfinder
 

maybe everybody knows about, but:

http://www.elis.rug.ac.be/ELISgroups...s.html#mosarel

they have the reolution

merci

Obin, did you try these BIOS setings on DFI board?:

1. "Disable Unused PCI Clock" or "Auto detect PCI clock"
2. "PCI Latency Timer"

[Edit] something is wrong with the forum engine - long posts didn't pass...

Has a four or ten thousand character limit (forget which) ussually tells you that they are beyond x length.

The maximum length of posts on this board is 10.000 characters.
You can use the link "[check message length]" underneath the
input screen how much characters you are using. If you need
more simply split the message up into multiple posts (which
usually is a far better way anyway).

looks like windows XP is causing the FIFO overflow..does anyone know of windows 2000 drivers for the 855 Intel chipset and some drivers for SATA that work on the DFI board? that is the only problem with 2000, the drivers for SATA don't seem to work and the system is running the drives in PIO mode.
thanks for the help

<<<-- Originally posted by Rob Lohman : The maximum length of posts on this board is 10.000 characters.-->>>

Then the problem is in my "TVset" :) -my "unsuccessful" post was about 700-900 chars...

Obin: here - http://www.abit-usa.com/downloads/dr...ies=1&model=79 you'll find "Intel Chipset driver v 6.2.1.1001" and "Intel Application Accelerator RAID Edition v4.10" -these are for all intel chipsets and all windows versions and not for Abit only.May be they are on DFI web page too...

You can try this trick on winXP (or w2k) :
start new installation (assume disk c: is fresh formated) and on the 1-st blue screen ,when you see the mesage (bottom) "Press F6 to ... bla-bla" press the F5 button! Then choose "Standart PC".
That way You'll lose some extras -no Hiperthreading,turn off is possible only by the Power switch on the case (press and wait 4 seconds) ...
However in that new installation the windows will be forced to follow the hardware desires and not bully them.

UPDATE
 

All hardware has been sent out to our programmer for final code writing and tweaking. As things stand we have the capture software working with 1/4 pixel quad preview in RAW 8bit color and Black and White. We have save to disk with 12bit raw files and 8bit raw files. We have 16bit tiff export. we have full control of the camera from the UI. the last steps are to get the software bug free stable and finish all the details of UI etc. After this it's a matter of getting CineForm or someone else to support the effort so that we can edit and do post work with the footage on a compressed version that will stay in 10/12 bit from shoot to final product.

Cool, Marlin, have to look information up on the exact differences, any ideas?

To All:

The problem here is that unless we export to a standard format, then there will be workflow problems. The only way to get around this (apart from write our own editor, or rewrite Cineralla to Windows and Linux) is to write a simple plug in for some good editors, one top end, one middle, and one cheapy to satify everybody. The good news, is that if the editor in question has a internal RAW master format, or just the ability to handle raw files once passed the parrametters to define an internal Raw format, then it is simply a matter of installing a convert routine, and raw format parameters, as the plugin.

So what do you think, suggestions for Windows, Mac, and Linux (Cinerrella)?

Where is Rob S anyway, haven't seen him for a while?


Rob L

I'm getting problems trying to submit as well, it just says connection closed by remote server etc. I used to be able to reload the page then paste text and submit, but not even that is working now.

<<<-- Originally posted by Wayne Morellini : Cool, Marlin, have to look information up on the exact differences, any ideas?
-->>>

Wayne,if you mean the differences between Standart HAL (Hardware Abstraction Layer) and ACPI HAL -I don't know all of them, nor I have links or so.
All I know(feel) is:

1. May be it's BIOS related,but when I install windows2000 (no Service Pacs) in ACPI mode-
all devices will use IRQ9 regardless what is set by the motherboard and the conflicts on IRQ sharing is the main reason I know this stuff-my Matrox based Editing station was very good on freezing random...:) ...and just found confirmation in google: http://64.233.183.104/search?q=cache...en&lr=&strip=1

2. Many 3D games have much better performance (10%-30%) in Standart PC Mode - not checked (3-4 years ago I've read an article about that)

3. In my experience "Standart PC" mode is much more stable -no more blue screens of dead if once hardware is configured and work properly.

4. I guess pooling the devices is more optimized (more simple?) in Standart PC mode

5. If you have 2CPU system -only 1CPU will be discovered and used in Standart PC mode. May be "MPS Multiprocessor PC" mode is the equal mode for 2CPUs -I don't know since I don't like 2CPU systems. However Hiperthreading will work only with "Advanced Configuration and Power Interface (ACPI) PC" mode.

6 .No "turn off" and "hibernation".

...cannot remember more...

As "Happy End" I'll say that winXP and win2003 are 1000% better in stability and performance than win2000...

P.S. Quote from http://www.fceduc.umu.se/~jesruv98/info/acpi/acpi.html

...ACPI forces the peripherals to "wait for their turn" as they are used which is actually great if you have many peripherals since you get stability while using those periherals, but bad if you only have a few since performance is lost and no stability is gained.

P.S.2 I like the plug-in idea!...And Avisynth could be the "The choosed one"...IIRC such a plugin already exists???

What we need is a group effort to build plugins that will work with the RAW files we are saving and or work with some sort of compressed 10bit files like CineFOrm

To Obin
 

Would you be able to to edit 8bit avi files using Vegas Video 5?

Vegas can edit 8bit fine. I have done it with both 720 and 1080p footage..what we need is the 10/12bit support for editing and also the support for a compressed format

I guess I should also look at the MAC and Final Cut Pro as an option because of the native high-bitdepth suport of FC..I could look at encoding into the SheerVIdeo codec and editing on MAC...this would work for now untill some stuff is working on the PC

At this point Premiere Pro 1.5 has 8-bit internal calculations, but if you work with 10-bit material in a cuts only timeline, the output to 10-bit will preserve all 10 bits. It's not perfect, but I'm guessing Premiere Pro 2.0 will support higher bit-depths.

So as long as you do filtering and FX in another application (e.g. After Effects) that supports higher bit-depths, you'll be okay.

Editing in RAW would be an idea, but might need too much work to implement. I'm not a programmer, but seeing how much work it already takes to get these capture apps to run... So the alternative would be to convert the camera RAW sequences to a format that is already widely supported. Also to streamline postproduction I'd hate to have all material exist in some kind of proprietary solution. So the conversion to Blackmagic 10-bit, SheerVideo or Cineform CODECS come to mind, with the first two offering support on both Mac and PC platforms.

The conversion from RAW to RGB could be done in Photoshop (batch processing), or After Effects (using something like Ben Syversons plug-in). It would be like 'developing film' before starting post. Not ideal, but no dealbreaker to me.

On a side note, I realize that people may be reluctant to work with uncompressed 10-bit HD because of storage and bandwith issues. I just put together an internal RAID5 system using a PCI-X SATA-RAID adapter with 8 Maxtor SATA drives (7200rpm 200GB). I'm getting 230 MB/s sustained write and 360 MB/s sustained reads. That's sustained - not burst. It cost me around 1700 dollars for 1,4 TB of effective RAID5 storage...

So there's a thought for 'affordable' uncompressed HD editing on PC.

Bar3nd

Are sustained writes always much slower than sustained reads?

Barend, Your thoughts sound PERFECT!

Thank You!

Jason, sustained writes are sometimes slower,but sometimes faster... in "real life"!

Originally posted by Obin Olson : I guess I should also look at the MAC and Final Cut Pro as an option because of the native high-bitdepth suport of FC..I could look at encoding into the SheerVIdeo codec and editing on MAC...this would work for now untill some stuff is working on the PC

I still think this is the best solution. I know you've been working on PC because that's what you've got - and it's a lot easier to put one together for recording. But once you get to editing, for this project at least, you're better off on a Mac. On top of the Mac's native bit-depth support, you also have native DVCPROHD support - when you've finished your color correction and mastering, you have a widely used tape format to export for showing to broadcasters, distributors, or to use for a film out. Versus going all the way on PC where you going to have to cart harddrives around when you want to show some video (or film out), and the codecs you used as well.

Choosing for a Mac solution because of DVCProHD support is silly. You could just as easily transfer to DVCProHD through HDSDI on PC (unless you want to edit in DVCProHD...). But the thought of using DVCProHD as a transport medium to get the material transferred to film is even stranger. You wouldn't want to lower resolution (if the source is 1080), compress and limit bitdepth to 8-bits and then transfer to film. Just rent an HDCAM SR deck for one day and transfer to HDCAM SR through HDSDI and get the cleanest picture on film as possible.

Anyway, FCP is a very viable solution, but not much more viable than what's out there on the PC platform, not for long anyway. But this is somewhat off topic.

Jason, like optical drives, hard drives tend to write slower than they read. It's just less work to read than to actually modify the bits. So these results were along what I expected from single drive benchmarks. They are also 'realworld' results, that reflect the HD editing situation.

Well, back to developing camera's ;-)

Good luck and keep up the great work everybody.

Barend

Mostly lurking -- still too busy to get much done on the project.

Just rent an HDCAM SR deck for one day and transfer to HDCAM SR through HDSDI and get the cleanest picture on film as possible.

My understanding is that HDCAM is also 8-bit, but I could be wrong about that. It is most certainly going to compress the stuff we're going to be shooting anyway.


However, it doesn't matter. My point was that DVCPROHD was already supported by the software - you don't have to buy or rent any other equipment to get it to a point where someone else can watch it or it can be filmed out. It would save money and workflow headaches. And your average filmgoer or video watcher isn't going to see a difference between something that was sent to film or DVD at 1080p, or if it was a somepoint downconverted to 720p before getting to the point where they are looking at it.

The point of this project is to make something of a professional quality that doesn't cost too much and is more or less headache free. Why add more hassles than you have to?

HDCAM SR supports 1920x1080 4:2:2 in 10bit. You are thinking of regular old HDCAM (which you generally won't use for film-out just like you should never use DVCPRO-HD for film.) For film-out D5 or SR will work as they are both full resolution 10bit compressors. All HD decks are HDSDI based, there is not point in rendering to DVCPRO-HD. There is no advantage to a disk based DVCPRO-HD, it loses one third the resolution over your source, and that is before it applies 8bit compression. Apple promotes DVCPRO-HD as a convient format, but it is only convient when used with a $27k deck and Varicam source (much lower quality than the cameras being discussed here.) A $1k-$2k HDSDI card allows you to send full 10bit HD to any desk , not just DVCPRO-HD. It seems if you go to the trouble of shotting and editing in high quality, you would rent an appropriate deck to master to.

To all: there where some problems with the server. It has been
rebooted and everything should be working fine again now!

<<<-- Originally posted by Barend Onneweer :On a side note, I realize that people may be reluctant to work with uncompressed 10-bit HD because of storage and bandwith issues. I just put together an internal RAID5 system using a PCI-X SATA-RAID adapter with 8 Maxtor SATA drives (7200rpm 200GB). I'm getting 230 MB/s sustained write and 360 MB/s sustained reads. That's sustained - not burst. It cost me around 1700 dollars for 1,4 TB of effective RAID5 storage...

So there's a thought for 'affordable' uncompressed HD editing on PC.

Bar3nd -->>>

Yes, that has allways been the downside, but still cheaper then heaps of 35mm film stuff. That is why we shouldn't get to carried away with the price of other stuff, if we want to keep it affordable. But in the end, when you have a job, it is going to cost, unless you can backup to server tape!

The whole idea here was to do 4:4:4 raw for the benefit of the amazing clarity and detail that lesser formats ussually loose. The other problem was that while we can debate that RAW bayer equates 4:2:2, or 4:2:0, quality the truth is that there is a mismatch between the two pixel spaces and you are going to loose. So going o these comrpessed tape formats, or to 4:2:2 defeats the purpose a bit. If there is a $20 chip out there that could comrpess to lossless and visually lossless 4:2:2 or 4:2:0, I would say go for it. But without a lot of investment, this is the best for us.

Jason, like Barend said, particularly nowdays it requires a lot of power to flip a bit in the drive write cycle, where as sensing is still easy peasy.

To all, plugins:

If you are going to go to plugins, as said before, you might find native pathways, there might even be selectable bit depth format support above the packages specified max bit depth, built into the routines, support might be even easily programmable. Don't depend on what the package tells you or even the programming documentation sometimes, look at the programming API carefully for extras.

With this sort of thing, if people want Apple, the first person that goes to Apple and gets their support for a universal bayer 4:4:4 8-20 bit, multi-resolution format may take the market.

I don't know much of editor internals and which do plugins propperly, but would I be right in suggesting that (apart from the top editors popular here) that Vegas Lite would be the best mid line editor to make a plugin for? What would be the best low priced editor to write a plugin for (under $100 to free)?

David, a thought on your last post. We are dealing with 4:4:4 footage there must be RAW 4:4:4 tape format for things like Starwars, you could theoirectically hire, and then backup your drives onto something like this when production is over. Then you could re-use the drives. But lets look at it another way, we have 4:4:4 bayer, that's 8+ bits per pixel, 4:4:4 three chip is 24-bits per pixel. that's three times more than you need, so if we treat it as a data stream we could store three times more. Also we could use a lesser tape format as a data drive to backup to, any suggestions?

Now, speaking of suitable editors, if anybody is going to spend $1K, or $500, how's your versions of cineform, do they both support the bayer cineform system?

Wayne,
Yes to all of that. HDCAM SR does support dual link HDSDI what carries 4:4:4:4 RGBA -- maybe overkill for bayer data. But as they is no "mastering" tape format for raw bayer, YUV 4:2:2 single link HDSDI is perfectly suitable even for film out. I know that because I just saw the first feature film posted on a desktop PC using a compressed digital immediate (CineForm's) and presented on film in a large theatre (it used YUV 4:2:2 10bit for output.) It was a cast and crew screening so I'm still swarn to secrecy on the details.

The bayer development is still under wraps -- can't give details, but it seems like many of the proposed workflows only need a stand alone version of Prospect HD without the bayer stuff. Recording RAW bayer data to disk would allow of post conversion into 10bit YUV based CFHD fairly easily. I let you guys know when the stand alone version is available (it is coming soon.)