There's really nothing special about [lexicon]H.264[/lexicon]: [lexicon]MPEG-4[/lexicon].2/ASP, aka
DivX/XviD, or WMV/VC-1 also have reordered B-brames (and even GMC
ones) and they have always worked in AVI.
There is also nothing special in [lexicon]MP4[/lexicon] to support reordered frames: [lexicon]MP4[/lexicon]
simply indexes the frames in decoding order marking the keyframes, same
as AVI or WMV or [lexicon]MPEG-2[/lexicon] PS/TS.
After all, the [lexicon]encoder[/lexicon] spits out the ES in decodng order and that is
what the [lexicon]decoder[/lexicon] expects and what AVI or any other [lexicon]container[/lexicon] stores.
The only grain of truth in AVI being unsuitable to store [lexicon]H.264[/lexicon] (or
anything else with reordered frames, including DivX/XviD) is not
actually something about AVI itself but about old VCM codecs,
traditionally used to decode data in AVIs, which assume non-reordered
frames (1 compressed [lexicon]frame[/lexicon] comes in, 1 uncompressed [lexicon]frame[/lexicon] goes out).
Despite that, a VCM [lexicon]decoder[/lexicon] can still do an acceptable job. Since almost
no player out there uses VFW for playback anymore and newer frameworks
like DirectShow or [lexicon]VLC[/lexicon]/ffmpeg have no such
limitation, storing [lexicon]H.264[/lexicon], which would have worked even with VCM
codecs, has no issues at all.
That does not mean that [lexicon]H.264[/lexicon] in AVI will work on an STB, which may
have hardcoded combinations of formats and [lexicon]H.264[/lexicon] in AVI is not a common
one.
FYI, I use [lexicon]H.264[/lexicon] in AVIs regularly.
This is just another legend like the "fact" that AVI does not stream
while in fact AVI streams perfectly well, since it is no different than
ASF/WMV or MOV/[lexicon]MP4[/lexicon]. The only reason while AVIs do not usually stream on
Windows is the implementation of the URLReader
and AVISplitter in DirectShow: the AVISplitter wants the index right
away, even if it is not needed (if fact, it will reject an AVI without
an index, despite the fact that the index is optional), so it will seek
to the end of the file first, but the URLReader
is not smart enough to use the protocol's seeking capabilities and will
simply [lexicon]cache[/lexicon] the whole file until it can return the index.
Both situations arise from mistaking what AVI can do for limitations of specific implementations of AVI players.