February 27, 2003
Converted Library Files
All I did today was to convert the H.261 4:2:0 YUV dumps in the VQM Oracle library to BigYUV format. I wrote a pair of batch Perl scripts to do the conversion and renaming.
4:2:0 Planar -> BigYUV Converter
I finished my 4:2:0 planar to BigYUV conversion program today. So I can convert all of the H.261 dumps in the VQM Oracle library, and also H.261 dumps from vicdump. The chroma lines are doubled, not interlaced.
February 24, 2003
One Frame Only
I did some poking around into my Open Mash video capture code for Mac OS X and discovered that VDCompressDone only returns true the first time. After that, since it always returns false, vic stops rendering the frame. That's why no image is ever displayed.
At the same time, the OrangeWare driver, for use with the Orange Micro iBot doesn't open when I try to specifically use it with OpenComponent. I am going to try OpenDefaultComponent instead, without the IOXperts driver installed. Maybe that will work.
Disk Renderer & Adaptable Video Q-Factors
I tested the disk renderer today and it works great. But I discovered some other problems which I wasn't previously aware of.
While verifying my frame dumps in Matlab, I saw that the H.261 dumps didn't parse correctly. Turns out the frame dumping code wasn't dumping out 4:2:0 and 4:1:1 codecs in BigYUV format. So M-JPEG came out fine, but H.261 didn't. I am in the process of writing a converter to change all of the existing H.261 dumps from YCbCr planar to BigYUV.
There is also a problem where vicdump does not receive every frame transmitted. Either my RTP recast program is reporting the incorrect number of frames, or Open Mash is not getting every frame. Of course, the VQM Software needs both dumps to have the same number of frames. Also, for the number of frames that are getting dumped, the total file size is way too small compared to the original YUV dump. I think this may be related to the YCbCr planar instead of BigYUV issue mentioned above.
Ketan and I also had our weekly meeting today. We talked about the q-factors for the super adaptable video descriptor. There is no easy way to skip to a specific q-factor. So no matter what, if you are going to make a change, you need to parse through the entire video file. Unless there is some addressing scheme in the descriptor. But that could easily make the descriptor extremely large, since the q-factor can change on a macroblock basis. So Ketan and I came up with an idea to store in the descriptor a global mapping that translates q-factors in the original high quality version to q-factors in the compressed version. This way, you can very quickly identify which of two versions has better quality, and merge along q-factors by parsing the entire file. So if you compress by scaling the q-factors, you are likely to get better compression than by simply removing coefficients. But it takes longer because you have to do some recoding.
February 20, 2003
At Andrew Swan's suggestion, instead of using the existing renderers and colormodels, I created a new disk renderer based on the null renderer class. This disk renderer is very simple and just creates the YUV frame and dumps it to disk. I haven't tested it yet, but it compiles into mash and smash, so hopefully vicdump will be able to use it just fine.
February 10, 2003
Super Adaptive Video
Ketan and I spent most of our meeting today talking about the super adaptive video project that I will be working on for COMP 249. I had gone through and written down all of the possible data partitioning components of MPEG-2 and we went through them to figure out which ones make sense and which ones don't.
We decided to leave out fields and keep video progressive. There are the I, P, and B frames, which need to be sequentially numbered in the original and remembered in partitioned versions. A bit pattern in the descriptor would work, and could be kept small using a fourier analysis plus run-length encoded supplemental bits instead of the complete bit pattern. Although even for a two hour 30fps video, the bit pattern remains pretty managable.
Which DCT coefficients are kept also needs a bit pattern. Since the idea is to let different versions be put together to form a higher quality version, the two versions need to pick different coefficients to keep. The DCT coefficient bit pattern indicates which ones are kept.
For the motion vectors, we decided to not throw them out since reconstructed video probably wouldn't be very valuable without them. However, we require no residual motion vectors, and since portions of the video plane may be cropped out, sometimes external block data will need to be carried over since motion vectors are differentially encoded.
There is also the q-scale, which changes on a block by block basis. Choosing which block is better requires going through both versions of a video and picking those with the lower q-scale. However, we want to be able to determine if there is any real value to be gained by this pass without actually doing the pass. One way would be to generate a hash or checksum of the q-scale values to identify if two versions with otherwise identical descriptors may result in a higher quality reconstructed version. But this still requires you to go through the entire video to find what might simply be a single possible point of improvement. So something better would be much more useful.
February 4, 2003
Continued Work on Vic Dumper
February 3, 2003
Verified NCNI Dumps
Before I return the DV deck and tape to Tyler Johnson, I wanted to make sure that my video dumps came out okay. So I did a quick run recasting the dumps to make sure there wasn't anything weird or empty frames. Everything seemed fine.