uncompressed deck

[Wayne Morellini]

Originally Posted by 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

That is why I listed the simple ones first. The first 3 require a few registers/locations of scratch-pad ram, and no other buffering, and are designed to be simple calculation that stream directly to the disk. They follow very simple rule that can be put in hardware, unlike the more complex buffered techniques (item 4 on wards, though run-length encoding only requires a value and a counter for the number times it is repeated).

I don't know if it takes to put this into hardware, but this is as simple, as a filter and might require less than 50 lines of code. Apart from the register memory (in case you have to encode static memory register) I think the simple functions might take hundreds or a thousand gates (If the function design is changed to suit FPGA economics).

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.

Why not forget it for now, get the standard HD version on the market, and worry about compression afterwards, as a down loadable FPGA upgrade to customers?

Thanks

Wayne.

[Ashley Cooper]

Changing gears a little bit, would this unit be able to deal with the variable frame rates of a Varicam or HVX200? Also, how would it handle HD100 material. I could be mistaken, but I thought I read that that camera's HD analog output was 60p only.

[Keith Wakeham]

Thats an interesting question, and one that has an unfortunately not straight forward answer, so sorry in advanced.

Short answer yes, but not efficiently.

Long answer below
Varicam and I'm not 100% sure, but HVX200's analog outputs shoudl be similar are using a very simple method of variable framerate. The way Varicam outputs over HD-SDI is to use meta data encoded into the horizontal and vertical blanking periods that says its an active video frame(A "flagged" frame). What this means is that output still looks like 60p but with duplicate frames every now and again. This is done to ensure compatibilty with SMPTE 296, 292, and 274 specifications. Without this ensured compatability some displays wouldn't be able to deal with the non standard framerates. The HVX200 will be similar, just without any flags because its analog. SMPTE only defines a handful of framerates for each format, so they are the only true acceptable formates. They are 24, 25, 30, 50, 60 and 1.001 divisor derivatives of each. That means whatever a camera outputs has to be in one of these formats no matter what. So what my smpte decoder sees is only the active video, it doesn't understand metadata (yet, I still need to deal with timecode, audio, and stuff latter) so it will capture the 60p stream. So its very wasteful when 24p is encoded to 60p. But this can all be changed with a update at a latter time.

Also, what i'm working on is still in the HD-SDI only , so converters must be used to change the analog from the HVX and HD100 to HD-SDI before my HDU-1 will be able to capture that.