ffvhuff encoding differences - VFW vs. ffmpeg/mencoder

[qyot27]

This has me stumped. I had wanted a way of quickly batch encoding scripts to YV12-mode HuffYUV (also using the adaptive huffman tables option) that would still tell me things like frame progress and other things that VirtualDub's batch controller doesn't. I found avs2avi and it worked the way I liked, except it has some issues with either ffdshow decoding the file through AVISource, or FFmpegSource, or both (see thread here (http://forum.doom9.org/showthread.php?t=141148) for my query on that topic). So, I thought I would see how ffmpeg itself and mencoder both fared when dealing with encoding such files.

As a test, I had a small FLV file that was served in a script only containing this line:
DirectShowSource("test.flv",fps=29.97,convertfps=true,audio=false)

When encoding with ffdshow (revision 2110, Sep 8 2008, clsid) through avs2avi - or VirtualDub, since there's only a difference of a few kilobytes in the output size - the size was at or around 60,182 KB.

Using ffmpeg (Sherpya-r14227), with these options:
ffmpeg -i test.avs -vcodec ffvhuff -context 1 -vstrict -1 -an test-ffmpeg.avi
The output size was 74,887 KB.

Using mencoder (dev-SVN-r27419-4.2.2), with roughly the same options produced a file only one kilobyte smaller than the ffmpeg output - which I expected.

My question was why is there a 14 MB difference in size between ffmpeg/mencoder and ffdshow's VFW? Now, when I use mencoder's VFW capabilities to call ffdshow:
mencoder "test.avs" -o "test-mencoder.avi" -ovc vfw -xvfwopts codec=ff_vfw.dll
Then the output is 61,711 KB. Which is close to the output produced by avs2avi or VirtualDub, but it's still larger by over a meg.

All of these encodes were done on the same test script - nothing changed at all. What I'm concerned about is that other things are occurring in mencoder (both in the instance of it encoding the file or the instance of using VFW) to cause the size difference - an unnecessary colorspace conversion, or something else. Since I don't really know much about how either ffmpeg or mencoder handle input files, then I don't know whether my fears/doubts are misplaced or if there are other conditions to be mindful of or commandline options to pass to make sure that everything is treated okay.

I've attached the log from all four (ffmpeg, avs2avi, mencoder, and mencoder using VFW) tests. Maybe there's something there that can shed light on this.

[Dark Shikari]

Because ffmpeg/mencoder by default use the fastest settings, while ffdshow uses slower but higher compression settings by default.

You have to explicitly pass median pred as an lavc opt, and you probably also want to pass Adaptive Huffman Tables (don't know what the lavcopt for that is).

[qyot27]

From what I read in the docs, the Adaptive Huffman Tables option is the -context 1 command, which I did use.

As for ffdshow, though, I have it set to use Planar prediction, rather than Median. Does ffmpeg/mencoder use Left by default, then?

[Dark Shikari]

From what I read in the docs, the Adaptive Huffman Tables option is the -context 1 command, which I did use.

As for ffdshow, though, I have it set to use Planar prediction, rather than Median. Does ffmpeg/mencoder use Left by default, then?ffmpeg/mencoder do indeed use left by default, AFAIK. I think its the -pred option.

[qyot27]

I ran another test, using -pred 1 to force plane/gradient prediction, and it came out a couple kilobytes smaller than the ffdshow output, so that issue is resolved (when I tested median prediction, it shaved another meg or two off that size). Although I would kind of like to know why using mencoder to call ffdshow caused an increase in the filesize of that test.

While I'm fairly sure it does this anyway based on the log outputs, I'd like to make absolutely sure - the way that ffmpeg/mencoder handles input and processing should be equivalent to using VirtualDub's 'Fast Recompress' mode, correct?

Also, what is the real difference between the prediction modes? Is it simply a difference of how thorough the search is, or are there other factors involved? I ask because in the original HuffYUV's config dialog, it states median is best for YUY2, but gradient is best for RGB. And considering that 'Planar YV12' has the term planar right there, does that mean plane prediction is more effective for that colorspace, or are those two things completely unrelated?

[Dark Shikari]

Also, what is the real difference between the prediction modes? Is it simply a difference of how thorough the search is, or are there other factors involved?Left prediction, for example simply coding each pixel as (Actual value - Left neighbor's value).

Its just how the pixel filter works. PNG images have a similar system.

[qyot27]

Ok, that's relieving. Thanks for all the info.

[squid_80]

Not sure about the libavcodec implementation of huffyuv but in the original huffyuv the median method has a very slow decompression speed compared to gradient, and is only able to compress a tiny bit more. So if you're archiving it's fine to use median, but if huffyuv is being used as an intermediate format I'd strongly recommend gradient over median.