Why isn't VFW / AVI suitable for B-frames?

[Inventive Software]

I don't get it. I have seen numerous arguments and threads about how AVI isn't suitable, but they seem to confuse me, more so because VFW is usually mentioned in the argument.

I want it cleared up. Clean, concise language, preferably English, on why VFW / AVI isn't suitable for B-frames.

I know that VFW is going out of favour with the advances of MPEG-4 ASP and AVC, but as far as I can see, there isn't much of a problem with the VFW codecs out there, eg DivX, XviD, x264. They work, and I don't get the argument that they have to "hack" the AVI file to make B-frames work. They play fine, they edit fine (at least the ones I create), I can't see the problem.

I understand that we should be moving forward, and that MPEG-4 ASP and AVC should be in the MP4 container, or MKV as that seems to work as well. I agree to a point, but I don't get the arguments against AVI. It's simple, it works, it's been around for donkey's years, and has stood up to everything that's been thrown at it. Why should we ditch something that works? It's like throwing out a machine that has been working without failure for 10 years, just because a newer model is out, and has some fancy new features that make it more desirable.

[bond]

http://forum.doom9.org/showthread.php?s=&threadid=80430

[XmSurfer]

If it works, it works. Ignore the people who complain about hacking the AVI standard to support B-Frames and h.264. The bottom line is that it works. You want to use AVI, then use it. If you don't want to use AVI, then don't use it. It's all about your personal preference, not about what some people on some board tries to get you to do. I'm a Matroska fan myself, but I'm not above experimenting with different codecs in AVI especially those that I've been told can't be placed in AVI like MPEG-1. Encoding is tedious work, I might as well have fun while I'm at it.

[foxyshadis]

MPEG-1 can be placed in AVI, ffdshow even has a decoder for it. Doesn't make it a good idea, but it works the same way as asp in avi.

An anecdote: A few weeks ago I pulled out one of my old concert rips to send a rockin' scene to a friend. Problem was, I'd encoded it without packed bitstream and with vbr mp3 audio. Once I find the scene I want I have to futz around looking for the real keyframe I wanted (because of the 2-frame lag), and when I chopped it out, I get audio from an entirely different part of the video. (I eventually had to use soundforge and reencode.) Only in the last week or two has Avery put the time in to support cutting vbr mp3 audio, after years of these problems, which is the problem: it puts the burden on the user, the encoder author, and the editor author to workaround limitations when viable formats exist. They make people work extra hard, they clutter up code which introduces spurious bugs of its own. (If I'd been thinking I'd have remuxed to mp4, but I didn't think it'd be that hard.)

If people are just going to encode and forget, great. It works fine for that. (Assuming you have up-to-date splitters, decoders, and players.) Since player authors have already put in the time to workaround most vbr seeking bugs, fine. Problem is, once it's in avi people want to edit, they want to play on set-tops, they want to re-encode (2 or 3 generations is usually enough for the audio skew to become noticeable), and they want authors to fix whatever playback problems are introduced by things the format was never made to support (like subtitles, new audio formats, cover art, menus, and second audio streams, besides b-frames). Everyone has to agree on a way to store them, or worse, follow the lead of one popular but horribly broken program (see nandub, esp. early versions) to fit them into places while hopefully fooling programs that don't know about them. Formats like mkv and mp4 have specs for graceful failover of unsupported elements; avi/riff only has 'JUNK' chunks. Vorbis simply cannot be added to avi because it's too different, and aac required similar workarounds as mp3 (but not the same, which means old players/splitters can't play them).

x264 can cause variable lag, depending on # of b-frames per gop, it can cause decode errors because it violates a key avi presumption - that key frames are reference boundaries (now a P following an I can reference a P before the I). It won't work on ipod or psp, it probably won't work on future settops (which will likely just follow the lead and use mp4).

[XmSurfer]

MPEG-1 can be placed in AVI, ffdshow even has a decoder for it.

That was my point. I little to subtle, perhaps.:)

[Yong]

AVI/VFW is simply outdated because it cant store some modern audio codes(video codecs too) that use VBR,
like foxyshadis said,
OGG vorbis and AAC is VBR by default,(afaik there is no strict CBR encoding mode for this two audio codec, VBR-MP3 doesnt work correctly too, unless using vdub to rewrite the header to cbr)
of course you can store it to AVI with some tricks, but dont expect it will work,
ive tested it before, the audio completely lag, causing the jerky video playback, crash, etc etc...
by using AVI/VFW should stay with some older audio codec like mp2/3, ac3, wav:D

[Inventive Software]

@Bond: Thanks for the clarification. It helped a lot.

I have another question that's related. Why isn't VFW suitable for MP4?

[bond]

@Bond: Thanks for the clarification. It helped a lot.

I have another question that's related. Why isn't VFW suitable for MP4?it is suitable, but when you want to use b-frames it will propably be a pita to write a tool that outputs correct b-frames to a correct mp4 via an interface that has no idea about b-frames ;)

[Inventive Software]

So this will probably be why nobody has tried to implement MP4 output in VirtualDub then. K thanks for that. T'is food for my hungry brain!