libavcodec amp; decoding vss AVC content

I'm wondering, does anybody have an idea why libavcodec turns VideoSoft's AVC streams into an ugly mess? There are no fancy features in my stream, just standard main profile with b-frames. And has anybody managed to extract such a stream from AVI and put it into an mp4? I can get the raw stream, but mp4box is less than cooperative.

libavcodec does not support packet bitstream...

I've only tried one sample, but:
VSS uses packed B-frames. libavcodec assumes that the demuxer delivers exactly one frame per packet. MPlayer could play the raw stream, and I didn't try remuxing.
What does mp4box complain of? quot;undefined NAL type 0quot; or the like?

I just managed to extract the raw AVC data from the AVI using YAMB (resp. mp4box) and directly remuxed it into MP4. Works perfectly after doing so.

Here's my commandline and the result

D:\gt;quot;mp4box.exequot; -add quot;D:\vss-qual3.264quot; -fps 23.976 -new quot;D:\vss-qual3.mp4quot;
AVC-H264 import - frame size 640 x 272 at 23.976 FPS
WARNING: NAL Unit type 0 not handled - adding
Import results: 3 samples - Slices: 2 I 2 P 1 B - 0 SEI - 2 IDR
Saving D:\vss-qual3.mp4: 0.500 secs Interleaving

I've used avi2raw from mpeg4ip 1.4.4 compiled by CelticDruid.

Using mp4box to extract the video, then mux the raw stream again works, but the result cannot be played (using the Nero decoder). So I re-enabled AVC in ffdshow, and now it seems to work out. So I take it that mp4box removes packed bitstream by default whereas avi2raw doesn't?

Unlike ASP, there is nothing in the bitstream itself that makes it quot;packedquot;, only the arrangement into AVI frames. VSSH puts a NALU type 0 in each otherwise empty frame, just because an empty frame has a special meaning in AVI, but those NALUs explicitly don't mean anything and shouldn't affect the function of a correct (de)muxer.
In short: I don't know what avi2raw could possibly do differently than mp4box.

I've got a philosophical question regarding all this quot;why does such implementation not work with whatever decoderquot; sort of thing :

What are standards there for if everyone is going to start coding his own little bit of quot;special better-than-the-standardquot; feature ? That sort of problem is rather common I see ...

I mean, a h.264 stream should be nothing more than a h.264 stream right ?
Specifications haven't been written for nothing ...
... but being a quot;future ex-noob-coderquot; myself I do understand that coding such quot;complexquot; things isn't easy though ...

The VSS H.264 streams are real H.264 streams, which is why remuxing fixes them. They don't violate the H.264 standard, because the standard doesn't say at all how frames are supposed to be delivered to the decoder. I would argue that they violate the AVI standard, but then so does every way of putting B-frames in AVI.

It seems remuxing the raw stream with mp4creator also works, but because of the various unresolved issues in mp4creator I'll stick to mp4box.