uncompressed deck

[Keith Wakeham]

For those who don't know, I was involved with the electronics level design of a camera in alternative imagine part of this forum.

We'll we backburnered that and went full speed for a deck.

http://dvinfo.net/conf/showthread.php?t=57992

Anyway, figure alternative imaging needed the announcement since the HD camera projects seemed to die but this is where it will probably be most viewed.

So the link is in my signature or follow the above to the thread.

Comments?

[Wayne Morellini]

Thanks Keith, good to see you going public with this.

Check his site ;)

[Mike Marriage]

Looks great!

Do you have a rough price yet?

[Keith Wakeham]

Were hoping for the 2.5K USD price range with an 800GB pack that should give about 84 minutes @ 1920 x 1080 @ 30p or 60i or 105 minutes @ 24p.

[Petr Marusek]

Keith and Wayne, Thanks for the information. I am definitely interested.

Keith, I'm sure it records 10 bits, but H1 HDSDI has 2 bits set to zero. Maybe you could add an 8 bit mode with increased capacity.

[Wayne Morellini]

Originally Posted by Keith Wakeham

Were hoping for the 2.5K USD price range with an 800GB pack that should give about 84 minutes @ 1920 x 1080 @ 30p or 60i or 105 minutes @ 24p.

Does the machine have 4:2:2, and 4:2:0 recording modes? I can see it looks like it does pixel packing.

[Keith Wakeham]

HD-SDI for smpte 274 is 10 bit. Theoritically, yes we can have it drop the unnecessary bits but are we going to - I don't think so. More for that if someone is using something like a HDL-40 or varicam, and they accidently puts it in 8bit mode for a previous shoot and they shot something dark somewhere else with a 10bit capable camera and it reconizes it as 8 bit at first but then see's 10 the device is going to get very confused.

Now with the computer interface, it can scale it down to 8bit, but the hd-sdi output on playback still needs to be spitting 10bit, so if it doesn't then again things get a little crazy.

When we get to a stage where some people can test it out then we'll see about it maybe.

As for 4:2:2 and 4:2:0. SMPTE 292 single link defines only 4:2:2. So thats what will be captured. I think 4:2:0 is a bad idea for interlaced anyway which is what some stuff would be spitting out anyway.

I do have hopes that I can sync two of these together for 12bit per channel 4:4:4 over dual link uncompressed. - Good if you happen to own an Origin, D20, Genesis, F950, or Viper (Maybe Red?). Doubt many people here own them though.

[K. Forman]

Keith- Any chance of hot swappable HDDs?

[Keith Wakeham]

The drives will be swappable, just not hot swappable. It will need to be shut down, swap drives, then start it up again. Considering it can "boot up" faster than the time it take for the hard drives to spin up I don't see it as an issue.

Sorry I kinda dropped off the planet. A lot of work and delays have changed a lot about the project and I'm really bad at keeping the website anywhat up to date.

The big thing that has come out of the problems we've had to face is that we have cut the expected drive numbers in half (now 5x7200 rpm laptop drives) which also cuts out power consumption in half. This has lead to a fair amount of re-coding of the project and was the result of another issue as well.

This re-coding has pushed everything back but its still going to happen.

[Steven Thomas]

Excellent Keith!
Keep us posted.
Sounds good to me.

[Glenn Chan]

Were hoping for the 2.5K USD price range with an 800GB pack that should give about 84 minutes @ 1920 x 1080 @ 30p or 60i or 105 minutes @ 24p.

That's barely more than the cost of some of the storage solutions for the HVX200...

[Keith Wakeham]

Using less drives means recording time gets cut down unfortunately, but theirs less chance of drive failure and since we haven't programmed in our planned redundancy yet either into the prototype we really want less drives to reduce risk of failure.

[Wayne Morellini]

Prices are dependent on the amount that people are willing/can pay (they tend to use the supply and demand economic theory) as well as cost. Unfortunately, it is upto the intelligence of the individual to purchase the most cost effective solution in a capitalist/market driven economy.

[Wayne Morellini]

Originally Posted by Keith Wakeham

Using less drives means recording time gets cut down unfortunately, but theirs less chance of drive failure and since we haven't programmed in our planned redundancy yet either into the prototype we really want less drives to reduce risk of failure.

Unfortunately, recording HDSDI tends to consume a lot more space than machine vision bayer, but I have an idea for a very simple compression system that would very simply fit into your FPGA.

You know that you can store the difference between frames, and obviously you have dropped that because of the complexity. But chroma follows the luminance around, so the blue and red values are very predictable, therefore you can store the difference they have instead. I have wrote about this sort of idea before a number of time. You should get close to bayer sizes for 4:4:4, but you have to do a couple of more things first:

This is written for RGB logic, so has to be adjusted for Luminance plus two chroma (which would make the data value s flow differently).

1. Use the first chroma primary value in a sequence (maybe a number in a image, if the chroma colour turns completely on or off) as the base value (proportion). Now you can record the subsequent chroma pixel values as differences from each previous pixel primary chroma value. This might also be applied to luminance.

2. An alternative, that should reduce the magnitude of the difference (less bits) that has to be recorded even more, is to use the difference in luminance as an additional predictor. Now the new chroma value is calculated as the % of difference given to the new luminance (over the previous luminance) but applied in % to the previous chroma value being predicted.

3. In some circumstances you might get better with the chroma on it's own (testing would reveal if it is a real concern). Then you might have a switch for each pixel, or you could have a switch and a run count of how many following pixels use it. But as I said, there might be no significant advantage to having a switch.

4. The next step to get more compression is to record the difference between lines (simple, efficient, Fax standards regularly employ this one). With the above scheme, this might be a bit limited as compared to not having the above. Now you should definitely find situations where it is either better to record using pixel difference, or line difference. So a switch/run-length mechanism might likely help.

5. Run length encoding and other compression techniques might be applied, maybe best on a bit plane basis (this is a term where pixels are addressed by bit position in the pixels, so a plane of bit 2, is the monochrome image of all bit 2's of all pixels, except here you are doing bit plane on the difference data instead). Because all the data is organised into minimal differences, and likely big strings of 0's and strings of ones (especially with method 2 applied) except in luminance data steam, very high compression can be achieved. Faxes could do 50:1 with the simpler, and B&W, text aware version of this, but you shouldn't expect anywhere near that, 3:1 would be sufficient, if your lucky 5:1 might be possible.

6. If you did what you guys intended to do, recording the difference between images as well, you could easily lend up with compression over 10:1. Which means one drive. Or a few more for SHD.

Hopefully you will get upto 3:1 using methods 1 and 2, 3 if needed, which are simple calculations which just requires running registers for the proportions and the real value. Methods 4 is simple but requires more memory and logic, method 5 is more complex again requiring a memory. 6 simple, but a memory.


You are welcome to contact me about using this.

[Keith Wakeham]

Wayne, as always some very interesting Ideas - Wish I had a little more time to digest them all. Our limiting factor is programming and Ram. We don't have any dedicated Ram whatsoever, so buffering a single frame is impossible without using some of our precious I/O pins for memory which pushes up to another chip with more routing and design of a circuit board, which just caused a 2 month delay already. The other is that most of these encoding techniques would take months to implement without a team of people.

Even with a prewritten core, if that core is not capable of doing exactly what I want in a fast fashion I can't use it. Its like opencores.net had some fpga to ata interface. Problem was that one side maybe give me the ATA outputs I want but the interface to the core was a wishbone interface which was just as complicated as ATA. I've had to go over hundreds of pages of documents and build a PIO interface and now have had to completely re-write it for uDMA. I started coding a year ago, and at the time was realitively inexperienced with fpgas compared to a Pro. Although its taken less than a month to get uDMA to work I can't handle doing comparative encoding or lossless compression in the foreseable future.

So although I understand that it would be beneficial to use compression I'm thinking shoot HQ first, dump to compressed latter when you wanna backup your shots and reuse the hard drive pack.