4:2:2 10-bit RAW vs Filmscan encoding
 

Is there a rough idea of the encoding speeds in terms of RAW vs Filmscan encoding ?
I have a 2.3GHz Core i7 and I am looking to encode 2x streams of 3K 3D video using Virtualdub. The USB3 vision cameras have a DirectShow driver that offers 10-bit 4:2:2 video as an option.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

RAW is a pixel format (Bayer) and Filmscan is a compression level, not a comparison, different things.10-bit 4:2:2 is not RAW, but would still be nice. An i7 should be able to encode 10-bit YUV (4:2:2) stereo HD at 60p, not sure about 3K.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

The camera stream RAW video over USB3 - the DirectShow driver offer different debayered inputs across different pins.
I can capture 10-bit 4:2:2 from the DS pins.
I can also capture the RAW data before debayering - however this will have to be via an API call to Cineform RAW.

How does 3K RAW Cineform encoding speed compare to YUV 4:2:2 encoding ?

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

Hi again, David.
Would you consider allowing me to access documentation about Cineform RAW API ?
I looked at the code where the camera writes out a RAW avi, and its quite a simple loop.
It copies out each RAW image and appends it to an AVI file. When its done, the file is closed.

I would just abstract it with CFRawOpen() CFRAWAppend() and CFRawClose() to create CF Raw.

I can offer this with a GUI so others can record CF Raw from Point Grey USB3 cameras.
I just need to make sure that you allow use of custom frame sizes for CF Raw files. All these cameras allow ROI and Binning so there is a great variety of frame sizes I can use.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

I found a twitter account with links to the SDK - https://twitter.com/CineFormSDK

Just going through the code examples, the code examples are only for DPX to CF FilmScan1 conversion.

Does CFHD_EncodeSample() work if the passed frame is just a RAW file ? ATM, it seems to expect a DPX frame and there does not seem to be a flag that tells it otherwise.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

The sample code supports any pixel format the codec supports. While the demo code uses DPX files, everything you need is there.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

Both 16x9?

If YUV was at 3K, YUV has twice the number of chroma samples, and is therefore half the speed of RAW. If YUV was at 1920.

YUV HD 1920*1080*2 = 4147200 samples
3K RAW 3072*1728 = 5308416 samples

3K RAW is 5308416/4147200 = 1.28 or 28% slower. 3K RAW would still win for awesomeness.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

Both 16x9 and the same res. I would guess that Cineform RAW is the faster option. at 12-bit. Sent an email to your sw biz - lets see what they send out.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

I've going through the headers. I had a question about this -

uint32_t videochannels = 1; // Set to 2 for 3D/stereoscopic encoding. Source image buffer must have left eye stacked upon the right.

Isn't there a way to call the Encoder with 2 separate raw images ? Stacking one image over another will be a large memory copy operation that will serve no purpose.

Perhaps the first one with CFHD_MetadataTrack = METADATATYPE_MODIFIED_LEFT then with METADATATYPE_MODIFIED_RIGHT
or
CFHD_VideoSelect
or
CFHD_Stereo3DType

There is a lack of documentation about the Metadata types. Just brief blurbs in the comments.

If stacking is the only option - do I simply append the packed raw image buffers and pass them to CF ?

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

Stacking is the only option for 3D. The metadata is mainly for decoder control.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

And a stack is simply packed raw data from both cameras concatenated together into a single char* or void* buffer ? Left eye first, Right eye second?
For example ,

char Image-right[size]
char Image-left[size]

char Image-3d[2*size]

copy Image-right[] to Image-3d[size] to Image-3d[2*size-1]
copy Image-left[] to Image-3d[0] to Image-3d[size-1]

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

yes, continuous memory.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

Do you only encode half the height per frame in 3D ?

For 3D, videochannels=2

>>
// Initialize the encoder with the height of each channel
int encodedHeight = frameHeight / videochannels;
>>

Also, there are lots of references to "threading the encoder" ?

Do I - as the caller of CFHD_Encode() have to divide up the frame and deal with threading ?
I thought this was done internally.

Re: 4:2:2 10-bit RAW vs Filmscan encoding
 

No, each frame is full res.

As you are not signed up as a developer, you should just experiment, it will all make sense once you get it working. You can use the SDK for your own personal projects. For any commercial product you will need an formal agreement with GoPro -- warning that is tricky to get these days.