Difference native asp versus non native asp

[JoeBG]

Hi,

can someone explain this difference please - thank you very much :)

[Kopernikus]

There is no native asp or non correct asp.

This
http://forum.doom9.org/showthread.php?p=860156#post860156
is about native asp in mkv. Is this your question?

There is a vfw mode in mkv that allows it to store every codec in mkv that can be stored in avi, by mimicking the avi structure. But then you can not use some of the more advanced features of matroska.

encraw muxes mpeg4 asp correct (read "not in vfw mode") to mkv.

[JoeBG]

No, this was not my question.

mp4box transforms non native avi files to native asp files. It removes packet bitstreams, drops frames etc. I really would like to understand the difference of asp in avi and native asp in mp4 or mkv (this just works if you import native asp in mp4 into mkv).

Hope someone knows this :) . I just remember, that bond explained it when mp4box got this feature in 2004 or 2005. But I can´t find the explanation again. :(

[Sharktooth]

AVI is a limited container and the MPEG-4 ASP bitstream needs to be modified to be hacked into AVI.
The VFW subsystem is also limited and was not meant to be used with complex codecs like MPEG-4.
More advanced containers dont need those hacks (violation of the standards) and need compliant (or if you prefer native) streams.

[GodofaGap]

@JoeBG:

Assume you have a MPEG4 video sequence (in display order):

I1 B2 B3 P4

Since the b-frames B2 and B3 can only be decoded if we know I1 and P4 the decoding order of this sequence is:

I1 P4 B2 B3

The problem with the VFW API (not so much with AVI I think) is, that it must return a frame if it requests one (the infamous 'one frame in, one frame out' principle). Effectively this means that decoding order = display order, but for a stream with b-frames this will obviously will result in jerky motion as frame 4 would need to be decoded before frame 2 and 3.

The solution to this is that frame 4 is packed together with frame 2 so they can be decoded at the same time, like this:

I1 [P4B2] B3 N4'

Now we can decode and display the frames in the correct order. As you can see the place of frame 4 is now occupied by an N-VOP (which is basically a dropped frame). What will happen is that when the 2nd frame (the packed frame) is received it will decode both the P and B frame, but will return the B-frame for display, the P-frame is stored in a buffer/memory (which it needs to do anyway). When two frames later the codec receives the N frame, it will disregard that and return the previously decoded P-frame.

Removing packed bitstream is nothing more than separating the P and B frame and removing the N-vop.

Another thing that is different between MP4 and AVI is that MP4 can store a thing called the VOL header (something which contains 'global' decoding data) in a separate place and therefor only once. In AVI the VOL header must be present in every I frame, otherwise an I frame would not be compliant with the AVI definition of a keyframe. Unless you accept not being able to seek in the file, or not being able to cut it.

Note that for Matroska (mkvmerge), the default and recommended mode for MPEG4 ASP storage is VFW, not native.

[squid_80]

I've always wondered why the VOL is stored with each I-frame instead of being stored once in the stream format block. Anyone know why?

[bond]

"native" asp is a mkv centric name, as mkv can store asp the same way as avi (the hacky way) or as defined by the mkv specs (the native way)

mpeg-4's own container, mp4, only knows one way of storing asp (the correct way ;) )

when mp4box converts asp from avi it gets rid of all the crap coming with avi (which is pretty hard to do, thats why we only have two tools being able to do that (mp4box and 3ivx, yeah not more))
a list of avi hacks and problems for asp is in my mp4 faq:
http://forum.doom9.org/showthread.php?t=62723

I've always wondered why the VOL is stored with each I-frame instead of being stored once in the stream format block. Anyone know why?this is only done with avi, not in mp4 or native mkv

strictly speaking there is no sane reason why to store the vol multiple times, as the vol is not allowed to change in an asp stream (in contrary to avc streams). but does anyone expect something sane with avi? ;)

[squid_80]

this is only done with avi, not in mp4 or native mkv
That's what I'm talking about... People say it is stored with every I frame to allow cutting since if it was stored only once and you chopped that keyframe out, bye bye VOL. For example:
Imagine someone would cut up the MPEG4-AVI with VirtualDub. What would happen if he tried to play a part with no VOL header.
But if it was stored in the stream format block this wouldn't be a problem since the format doesn't change when editing, we'd be saving ~20 bytes for every keyframe and mp4box wouldn't have to do so much work to convert avi->mp4.

[GodofaGap]

strictly speaking there is no sane reason why to store the vol multiple times, as the vol is not allowed to change in an asp stream (in contrary to avc streams). but does anyone expect something sane with avi?
For AVI the reason is very simple. An I-frame without VOL header does not follow the definition of a keyframe. One could cut up the stream and render the part without VOL useless.

[GodofaGap]

But if it was stored in the stream format block this wouldn't be a problem since the format doesn't change when editing, we'd be saving ~20 bytes for every keyframe and mp4box wouldn't have to do so much work to convert avi->mp4.

(Sorry for ****** up the posts).

I don't know if the stream format block in AVI can accomodate for the VOL header (shouldn't it always be a BITMAPINFOHEADER)? But I think a lot of the MPEG4 in AVI stuff is decided by DivX, and well, they have not always made the best decisions.

[foxyshadis]

In fact divx only brought forward msmpeg3's format, I guess figuring there had to be some reason they did it that way. Who can say why an engineer at MS chose it to behave that way almost 10 years ago.

On the other hand, doing it this way does let you combine qpel and non-qpel streams, and sometimes other options, even if it won't play on a standalone.

[squid_80]

I don't know if the stream format block in AVI can accomodate for the VOL header (shouldn't it always be a BITMAPINFOHEADER)?
Nope. It starts with a BITMAPINFOHEADER but can be as big as needed since the size is given in biSize. Huffyuv for example stores compression tables after the BITMAPINFOHEADER.

[GodofaGap]

Ah, well... then I dunno. :)

[bond]

divx also invented packed bitstream and xvid showed that worst of all avi hacks is not necessary