| User review:
|
To be honest my comments were more a grouse about inappropriate criticism than a real vote in favour of a codec I've had only just started playing with - I came here looking for reviews which mentioned compression ratio and instead read comments about dropped frames which are easily avoided by using something else for capture (with lossless codecs there is no reason not to recompress). Your own criticisms however are about its proper use and are completely legitimate.
As for direct comparisons: that was difficult for me because I don't use Vdub at the moment - instead I'm processing video with my own experimental VDub-alike tool which I created in order to get around some VDub limitations, eg. it works with YUV as the native (internal) video format and allows me to do some other things that VDub can't, like not being limited to one frame out of a filter for every frame into it (eg. a deinterlace filter is free to output fields as two separate frames). Also my testbed doesn't handle audio, it's purely a video processor, so my output videos would be lacking the audio stream, meaning I can't just compare file size against the original Huffyuv capture....
(btw. I get no errors from this codec in my own testbed app. Maybe this is because I only feed it YUY2 frames).
However, I've just done a comparison using a 2299 frame PAL resolution (720x576) video clip, originally captured using Huffyuv with no audio. The Huffyuv version of this file was about 550meg, the MCU codec (in fully lossless compression mode) took an hour to compress this file and the result was about 515MB. There were no video filters enabled in my testbed at the time, so this would be about the best speed this codec is capable of on my 2.6GHz Celeron home PC. Needless to say this was not impressive performance in terms of either speed or compression. Output quality seemed to be lossless as claimed, so no problem there.
I then wanted to try the "highest compression ratio" preset. Unfortunately I could not get this selection to stick. If (after choosing this setting) I immediately went back into the codec's config dialog I found that it had reverted to the fully lossless setting used in my previous test. It does the same thing in VDub so this doesn't seem to be a bug in my testbed software. In Windows "Control Panel" the setting does stick, but configuring it there doesn't seem to carry over into VDub or my app. Just in case it was only a problem with the dialog and the setting /was/ actually being configured correctly I went ahead and compressed the file again anyway: again it took an hour and the results were identical to my previous test, so this looks like a bug in the codec. Until this bug is fixed I can't check the quality or performance of the "visually lossless" mode.
|
