Hello,
for a new small project I am required to record a video with 30fps and 3 Mega pixels at least.
The video needs to be recorded 9 days long and save the data block-wise to the disc. So that after 9 days i have one big video file.
Is it possible using CVB? Can you give some tips on how to achieve that? I would prefer to use Wpf Bindings / c#.
Thanks in advance
Thats going to be challenging;
30fps x 3 mb = 90 mb/sec for mono images.
9 days * 24 * 60 * 60 = 777600 mb
Is there a specific reason why you would want the entire image into one single file? A file that big would be quite unwieldy for loading into RAM memory for example.
Is compression okay? And have you looked at CVB movie yet?
Hi!
Slight correction: 90 MB/s for 9 days results in an uncompressed file of 9 * 24 * 60 * 60 * 90 = 69,987,000 MB - roughly 67 TB.
While 
Movie does not place any constraints on the resulting file size itself, it will always practically be restricted to what the codecs and multiplexers and other objects used internally impose. The two that I have run into in the past are:
Also: Movie produces AVI files, and AVI files are generally not a good choice for producing such huge files: AVI files store relevant format information at the end of the file rather than at the beginning, so if on day 8 something goes wrong and the file is not closed properly it’ll be impossible to recover the written data with a tool that is capable of repairing broken AVI files.
Currently I would - regardless of the recording infrastructure - advise against streaming that amount of data into just one container (file).
This generally means for me that we need compression in any case. That kind of a file size is not what we want so compression is definitely necessary. Now my questions:
Multiple video files is not a problem anymore, so we wont have issues depending file sizes I guess.
Yes, for recording more than one frame into a container currently the only available option is AVI through the 
Movie tool.
Yes and no. “No” because does not come with compression codecs of its own. What the Movie tool does is interface to the operating system’s DirectShow infrastructure which offers a wide range of codecs for various formats (often through third party installers). One of the nicer aspects of this approach is that Movie can in principle make use of any DirectShow codec that is capable of digesting the format provided by the camera (I say in principle because in practice it is also necessary that the code of choice can be streamed into an AVI file because the only supported multiplexer is the AVI multiplexer; also the restriction to “capable of digesting the format provided by the camera” rules out the processing of anything beyond 8 bits per pixel monochrome or color).
We’ve been using the following in the past:
) as long as your disk(s) can keep up with the camera’s data rate. However, having no compression of course means that you’re going to need lots of space.I know that @Sebastian has done some things with a commercial h264 encoder as well - maybe he’d like to weigh in here…
And yes, once you break it down into individual files the file size becomes less of a concern. We’ve done that occasionally - the tricky bit is not loosing any frames when switching from one file to the next but - this might need a sufficiently large number of buffers configured on the driver.
Hi @johmarjac
Let me weigh in here 
The old implementations from DivX and Xvid are based on the H.263 (MPEG-4 Part2) which was designed for low resolutions and low bitrates.
With H.264 and also H.265 there exists new video compression standards which work well with high resolutions and high bitrates which we need for a good quality compression.
But these encoders are slow on the CPU.
Performance with real-time encoding
With 3MP and 30fps you need to record 90MB/s for mono images.
If you have a color camera we need to compress 270MB/s.
Luckily GPU manufactures like Nvidia have implemented the encoding in hardware for H.264 and H.265.
The encoding can be done in real-time if the needed bandwidth is not too high.
For our tests we used the H.264 codec from LEAD Technologies which has a complete implementation of the Direct Show interface in 32Bit and 64Bit and which support the GPUs from NVIDIA and Intel for a fast encoding.
Our Tests showed that we can encode up to 290 MB/s with a mono camera and 552 MB/s with a colour camera using a Nvidia GTX 1050 TI graphics card.
Faster cards did not speed up the encoding as the encoding engine (NVENC) is the same for the whole Nvidia GTX 10xx generation.
Quality
The Quality is less what you can see on Blu-ray discs which uses H.264.
In my experience, high-frequency information with high contrast and many edges is no problem even with this implementation.
But flat areas in the image especially dark areas with low contrast loose details.
Then the quality parameters need to be set to an extremely high value.
If this is important for you, you should consider using an MJPEG codec. This uses a JPEG image for every frame and works very well even with flat areas but only if the quality value is set to a very high value.
But this codec might not be fast enough for your requirements.
Compression
The compression strongly depends on the content of the video. Our tests showed using a scene with a lot of details and high movement a compression ratio of 50:1 with a reasonable quality (Quality factor 16).
And 10:1 with high quality (Quality factor 10). This compression ratios are based on a mono video.
If you have a color camera you can multiply the compression ratio by 3 as we compress 3 times the data.
For the codec it makes no difference as it always uses 3 planes.
Patents
Sadly the H.264 and H.265 encoders are covered by patents. Therefore you have to consider the patent conditions depending on how the codec is used.
We are able to sell the Codecs from Lead like H264, H265 and MJPEG. With this the license and patents are covered.
Currently we sell the LEAD H264 Codec mainly with individual development service.
@Sebastian and @illusive Thanks for the detailed informations, I will now have a conversation with the project manager to get more information and to discuss what we do. I myself havent seen the scene to be recorded yet, but I´ve heard it is not a motion scene. We will probably contact you again by then.
Best regards