I am trying to write a video using opencv. It is important for me to do this for sure - so it should be a lossless codec. I am working with OpenCV 2.4.1 on Ubuntu 12.04
I used to use the code of the fourth code 0. This gave me the exact result that I wanted, and I was able to completely restore the images.
I'm not sure what happened, but since the recent update (around July 20, 2012) something went wrong and I can no longer write files with this 4ccc code. I really donβt remember what it was, but it could have come from updating, removing some software from my software center and some other things that I did during the general cleanup ...
When I check the old file with mediainfo (http://www.fourcc.org/identifier/), I see the following result:
Complete name : oldsample.avi Format : AVI Format/Info : Audio Video Interleave Format profile : OpenDML File size : 1.07 GiB Duration : 41s 467ms Overall bit rate : 221 Mbps Writing application : Lavf53.5.0 Video ID : 0 Format : RGB Codec ID : 0x00000000 Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples Duration : 41s 467ms Bit rate : 221 Mbps Width : 640 pixels Height : 4294966 816 pixels Display aspect ratio : 0.000 Frame rate : 30.000 fps Bit depth : 8 bits Stream size : 1.07 GiB (100%)
Now I see that when I write using the 0 fourcc codec, the program actually uses the i420 codec by default. Here is the result from one of the files I'm trying to write now:
Complete name : newsample.avi Format : AVI Format/Info : Audio Video Interleave File size : 73.0 MiB Duration : 5s 533ms Overall bit rate : 111 Mbps Writing application : Lavf54.6.100 Video ID : 0 Format : YUV Codec ID : I420 Codec ID/Info : 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes. Duration : 5s 533ms Bit rate : 111 Mbps Width : 640 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate : 30.000 fps Compression mode : Lossless Bits/(Pixel*Frame) : 12.000 Stream size : 72.9 MiB (100%)
This format and other formats that I try to use (for example, huffyuv HFYU) do not work for me because I get such effects http://imgur.com/a/0OC4y - you see bright artifacts coming from that that I suppose is either lossy compression or color oversampling in the case of HFYU, which should be lossless. What you are watching is a red channel from one of my videos. The perceptual effect is negligible when you look at all 3 channels at the same time, but it is important that I accurately recreate the images.
Also, although I can play old files in media players such as vlc, I unexpectedly discovered that they are completely incompatible with opencv. When I try to open old video capture files, the open step works fine, but trying to perform a read operation results in segfault. Also, when I try to write with:
CV_FOURCC(0,0,0,0) 0
By default, Opencv defaults to I420.
Next, I tried to use some alternative codecs. "DIB" seems like something that should work for me, and on the opencv website (http://opencv.willowgarage.com/wiki/VideoCodecs) it is listed as a "recommended" codec. However, attempting to use this leads to the following message:
OpenCV-2.4.1/modules/highgui/src/cap_gstreamer.cpp:483: error: (-210) Gstreamer Opencv backend doesn't support this codec acutally. in function CvVideoWriter_GStreamer::open Aborted (core dumped)
I checked the opencv source for this codec and came across the following:
cd OpenCV-2.4.1/modules grep -i -r "CV_FOURCC" ./* ... ./highgui/src/cap_qt.cpp: /*if( fourcc == CV_FOURCC( 'D', 'I', 'B', ' ' )) ./highgui/include/opencv2/highgui/highgui_c.h:
I tried installing qt4 and reconfiguring with the WITH_QT flag, but that didn't change anything. I also tried to uncomment this part of the code and reinstall opencv, but that also didn't work.
My ultimate goal is any way to efficiently store and retrieve a video stream with 16 bits for each pixel (for example, 32float will work fine and then it should not be perfect). Right now I am decompressing 16 bits into the red and green channels, so I need this to be perfect - since error 1 in the red channel is multiplied by 256 in the final result. I have no success with any of the fourteen code codes available to me.