Riva VX vs On2 Flix Pro vs Vegas h.264

[Jason Robinson]

In case anyone is interested, I decided to perform a flash encoding render-off to determine for myself how much of a difference there is between the free Flash encoder Riva VX, the expensive On2 Flix Pro, and the new h.264 direct from the Vegas timeline.

I encoded the files at virtually the same bitrate 768Kbps, but some times I wasn't sure if that was the overall bitrate and the 128Kbps/44Khz stereo audio signal was included in the bitrate, or was separate. Each final rendered file was almost the same file size. Both flash files were encoded from a 320x240 render direct from the timeline in Vegas using the Microsoft Video 1 AVI wrapper (because that is the AVI format supported by Riva VX).

EDIT: below link yanked till I get my AVI -> flash workflow improved to even the comparison
Visit my comparison page with the three videos embedded side by side.

See the attached screen shot for a sample of the differences at virtually the same frame in the video. I wonder what bitrate it would take for Riva VX to equal the quality of the On2 Flix Pro render, and to equal the AVC/h.264 render.

I am in the process of rendering an h264 file with a video bitrate of 640Kbps so that the video + 128Kbps audio isn't above 768Kbps total. That might be a more fair comparison to the other flash codecs. But Vegas is still ahead of hte curve because it can do 2 pass rendering.

My final question is are there any flash encoders that actually multithread? Flix Pro and Riva VX didn't seem to touch more than one thread, so there seems to be extremely little reason to use flash now that h.264 is such an amazing codec.

Would a 320x240 768Kbps h.264 file be a problem for any potential viewers to my customer's web site? My customer wants the video embedded in their site and I have no idea how wide spread the ability to play h.264 is in the various flash player installs out there. Is this still too new for widespread use?

The flash player on my test page is the JW Player from Longtail.

[Jason Robinson]

I looked at the AVI used for On2 and Riva VX and I am noticing that it is exhibiting the banding that makes the two flash encoders look bad compared to h.264, so i will need to redo ALL the flash encoding with a better AVI source file. Apparently the Microsoft Video 1 AVI encode is not that great. :-/

Stay tuned for more results. I'll try rendering a full frame 720x480 Microsoft Video 1 AVI and THEN use the encoders to scale it down to 320x240.

[Seth Bloombaum]

Great test - thanks for spending the time and sharing your results!

The On2 FLIX version (VP6 codec) should indeed be looking better. You're right in that the MS Video 1 intermediate codec is a legacy codec from Windows 3.1 days(!), it isn't very good by today's standards.

For a freeware/open source encoder that will accept more types of codecs and containers on the input side, I recommend Super-C. Both Riva and Super-C should have the same output - the Sorenson Spark codec. This is the freeware codec that was the first available when Adobe introduced video for Flash.

Your first post seems to suggest that the MS Video 1 codec wasn't used for the h.264/Vegas encode?

I've found this wikipedia page most helpful in helping to answer questions about when Adobe added support for various codecs. As you'll see there, h.264 support was added in late 2007. I think that's long enough...

However, what the article doesn't say is that the decode of h.264 is relatively pretty complex, with a high processor load. I think we're at a point where On2 VP6 and h.264 both have some advantages. VP6 is really very good. h.264 is better quality for the bitrate, but only a little, and at the expense of decode complexity.

I guess it's my firm expectation that when you wring out your intermediate codec workflow the VP6 and h.264 outputs are going to look a LOT closer.

768Kbps is a lot of bandwidth for 320x240. You should be able to get well below 500Kbps and have acceptable results both with the On2 VP6 codec and h.264. Depending on the nature of the content, you might find acceptable results below 400Kbps. Somewhere down there you're going to find the full-screen view that the JW-Longtail player offers is unacceptable.

Flash encoders that multithread - I've read on this forum that Adobe Flash (CS3? CS4?) is multithreaded. Haven't personally confirmed that. It will allow you to encode to Spark, VP6, or h.264.

[Jason Robinson]

yes essentially all my results were invalidated by the horrible quality of hte MS vide o1 codec. utterly terrible!

I have since rendered out using Cinepak (which took for friggn ever to render!). I'll re-render the flash versions from that. I will also put the cinepak avi on a new vegas timeline and render out to h264 so that everything is rendered from the same source AVI and nothing has a "native footage" advantage over the other.

[Jason Robinson]

the more I look into this, the codec limitations set by the supported AVIs for Riva, are all pretty crappy. I tried the MS Video 1 codec (total crap) and now Cinepak (marginally better). Cinepak still has bad banding problems, but not as bad as MS Video 1.

Out of the list of codecs support by Riva, which is the highest quality? Because apparently Riva can't take uncompressed AVI (which is a bit counter intuitive) so I have to choose some sort of AVI format in order for my compression test to be of any use.

[Jason Robinson]

Ok, it looks like the Intel Indeo R3.2 is (mostly) lossless AND is supported by Riva VX, so now I can make a true comparison by putting this shortened AVI on a new timeline and rendering out via h264, Riva VX -> flash, and On2 -> flash. Stay tuned.....

[Jason Robinson]

Seth thanks for the great information. I have fixed the intermediate AVI codec problems (Intel Indeo seems to work great) and I am indeed finding the differences between h264 and On2 to be barely visible. I was able to tell the difference between Riva and On2 Flix Pro, which is a bit of a concern for me.

And since my client's potential viewers aren't on even remotely up to date machines, I think h.264 is a bit too new (still) for their needs. So I'll just give Riva a bit more bandwidth than On2/h2.64 and see if that can make up the encoding differences. I am noticing significant motion errors.

Ok, below is the web page with the comparison. I have rendered FOUR versions with each encoder: at 320x240@272kbps, at 320x240@512kbps, at 720x480@512kbps, and at 720x480@768kbps to see if I can bring out problems in each encoder / codec. I'm not entirely sure if this is a totally "legitimate" comparison, but it seemed like a good way to showcase the codec.

Visit The Flash Encoder Render Test Page

One thing I noticed is the keyframes for the h264 encoded 720x480@512Kbps version. If you look at the background wall, you see that every second the major blocks of color / texture are changed. This is not evident in the flash version of the 720x480@512Kbps files (unless I am just missing seeing it).

[Seth Bloombaum]

Indeo 3.2 also goes pretty far back - it was really the first codec that did a good job with people. Faces looked like faces! One thing to keep in mind is that it was intended as a distribution codec, in, um... 1992?

Out of the list of Riva-acceptable codecs you linked to, the clear winner would be MP4 as an intermediate codec. What's up with that, you may ask? Isn't that the same h.264 I'm using as a distribution codec out of Vegas? Yes it is.

MP4/h.264/AVC/MPEG4 use as an intermediate codec was pioneered because of the file size limitations some online sharing sites have had for video upload. Basically, the best picture for the bitrate and file size. Sound familiar?

For use as an intermediate codec you'd give more bitrate. Say, between 1.2 and 2Mbps for standard def, but you could even do more. And MP4/... really does make a pretty good intermediate codec.

OK, that's Riva VX. To me, it looks like it hasn't been updated much on the input side - WMV 7/8 but not 9? Um, that's a few years out of date.

Super-C is really great for outputting Flash/Spark, and much more flexible on the input side:
SUPER-C

Best practices with intermediate codecs is to give lots of bitrate, then let the final encode shave it down for the distribution codec.

I do think VP6 is still a very respectable online delivery codec! FlixPro at $240 is not the only way to get it! Take a close look at this comparison of Flix encoder specs. Flix Standard has a lot going for it... and it is one of the great bargains in an outstanding proprietary codec - $40!

So, before dropping $240 on Flix Pro, you might want to do yet another test of the demo version of Flix Standard... and see if it does it for you.

For the visible keyframe artifacts - The things that help are changing the keyframe interval (shorter), increasing bitrate, and maybe 2-pass encoding (not sure about this one).

For a fixed camera position like you have, you can also consider/test some tricks. Like, use the secondary color corrector to even out the wall. Use a denoiser to even out the wall. Draw a soft-edged garbage matte outside of action and gaussian blur or drop in a framegrab outside the matte (which has the added benefit of freeing up bitrate for the action areas of the frame). Sometimes a barely perceptible gaussian blur across everything can help.

Well, that's all kind of esoteric, but when it really, really matters, these tricks can come in handy.

[Jason Robinson]

very interesting idea to use h264 as an intermediate codec. I had pretty much always assumed that avi meant "lossless" but clearly my adventures with Microsoft Video 1 AVI illustrates the problems in that line of thinking. Who know that AVI could vary so much!

Regarding masking out the BG, that simply isn't something I have time for (nor do my client's have the budget to pay me to find the time), but that sounds like an interesting idea.

The part I do have control over is use of the encoder to tweak the settings. I did think about fiddling with the interleave / whatever it is that sets the keyframes, but I wanted the encoders to be set at defaults in order to demonstrate the codec's abilities. Tweaking them definitely falls outside of my experience level for now.

Thanks for all the assistance in this thread.

[Henry Dale]

To extend the idea of masking out the background, to cut down on video file size and bit rate without compromising quality, you could try this:

You can encode an alpha channel for flv files, so you could shoot the subject in front of a green/blue screen, mask out the background, encode the video with a background alpha of zero, and then insert a background in the swf file. That way, you can still have a background with a detailed pattern, but it would be downloaded only once at the start with the swf.

To extend this even further, you can use vector graphics and text in the swf to regularly change the background (or foreground, for example to insert subtitles) at a miniscule fraction of the bandwidth cost of doing it in the video.

[Jason Robinson]

Originally Posted by Henry Dale

To extend the idea of masking out the background, to cut down on video file size and bit rate without compromising quality, you could try this:

You can encode an alpha channel for flv files, so you could shoot the subject in front of a green/blue screen, mask out the background, encode the video with a background alpha of zero, and then insert a background in the swf file. That way, you can still have a background with a detailed pattern, but it would be downloaded only once at the start with the swf.

To extend this even further, you can use vector graphics and text in the swf to regularly change the background (or foreground, for example to insert subtitles) at a miniscule fraction of the bandwidth cost of doing it in the video.

While this solution does sound great, we are talking about a job where I earned roughly $10 / hr, so there is no way I'm going to put that much effort into workarounds.