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.

Post a comment