Record video while saving to disc

#1

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

#2

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?

#3

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 :cvb: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:

  • Depending on the file system, file size itself may be an issue (FAT as far as I know does not allow for files > 4 GB, see e.g. here (hint: The AVI file writer used in Movie2 does produce OpenDML 1.02 compliant files and is not restricted to 4 GB)
  • When using compression codecs and multiplexers, the multiplexer might become an issue. I have seen MP4 Multiplexers choke on the 4 GB boundary as well as compressors behave weirdly.

Also: :cvb: 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).

#4

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:

  1. Does CVB only support AVI files?
  2. Does CVB provide functionality for compressing the recorded video while recording so that it is possible to compress it before its written to disk?

Multiple video files is not a problem anymore, so we wont have issues depending file sizes I guess.

#5

Yes, for recording more than one frame into a container currently the only available option is AVI through the :cvb: Movie tool.

Yes and no. “No” because :cvb: does not come with compression codecs of its own. What the :cvb: 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 :cvb: 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:

  • Uncompressed
    Of course quality-wise perfect as there is no data loss. Works fine (and with very low CPU load… :slightly_smiling_face:) 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.
  • RLE
    “built-in” codec of DirectShow. RLE stands for “Run Length Encoded” and does - in this case - not mean lossless! Works reasonably fast with reasonably low CPU load and reasonably good image quality - but the compression rate is merely something around 2 or 3.
  • DivX
    Third party codec which requires a license. I am not sure whether or not they still support the DirectShow interface - if not, it might be necessary to check for older versions. DivX gives you good quality at surprisingly reasonable consumption of CPU-time (the quality-time-tradeoff is of course configurable) at a compression rate in the range between 100 and 1000. The codec does of course support multithreaded encoding and scales surprisingly well with the number of course you allow it to use.
  • xvid
    Also one of the codecs from the MP4 family. Quality and compression ratio are roughly on par with what you can achieve with DivX codec, but from what I have seen the CPU consumption is slightly higher. This codec is open source - keep in mind to check and meet the legal requirements when using it in a commercial product.

I know that @Sebastian has done some things with a commercial h264 encoder as well - maybe he’d like to weigh in here… :slightly_smiling_face:

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.

#6

Hi @johmarjac
Let me weigh in here :slight_smile:

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.

#7

@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

1 Like