MKVToolnix MPEG-4 ASP native ISO mode and VFW mode

[Elias]

When creating ISO compliant MPEG-4 streams, you will get real ISO compliant streams. In MKVToolnix, it will look like this, depending on how you've created the streams.

If you create an MPEG-4 ASP Matroska file using VirtualDubMod, it'll look like this:

VFW:

http://img89.imageshack.us/img89/8359/mkvtoolnixmpeg4vfwlf4.th.png (http://img89.imageshack.us/my.php?image=mkvtoolnixmpeg4vfwlf4.png)

If you create an MPEG-4 ASP Matroska file using MeGUI (MeGUI supports ISO mode, not VFW mode), it'll look like this:

ISO:

http://img225.imageshack.us/img225/7853/mkvtoolnixmpeg4isoix5.th.png (http://img225.imageshack.us/my.php?image=mkvtoolnixmpeg4isoix5.png)

That's how it's supposed to be. You create Matroska files using VFW tools like VirtualDubMod, you will get VFW damaged Matroska files. The same is true if you create avi files encoded with DivX/XviD in VirtualDub, and then mux them into Matroska using MKVToolnix, it'll look exactly the same (V_MS/VFW/FOURCC, XVID).

Now, since I hate everything about Microsoft despite being a hypocrite and using Windows XP (due to awesome software like MeGUI, MKVToolnix, VirtualDub, Media Player Classic, etc., and not because of worthless Windows per se), I DON'T want my MPEG-4 encoded material to display any single trace of VFW or anything connected or related to Microsoft. I want my Matroska files to be pure MPEG-4 and ISO compliant. I don't want my Matroska files to display any avi fourCC.

Here's the trouble in paradise. When encoding MPEG-4 ASP into the Matroska container using MeGUI, and then remuxing the Matroska file into another Matroska file using mkvmerge (for editing purpose, such as changing language track, adding more audio, etc.) it's all working as it should. The new Matroska files reads as V_MPEG4/ISO/ASP, which is how it's supposed to be.

HOWEVER, when encoding to MPEG-4 ASP/SP using say, Quicktime Pro or Avidemux, and encoding it directly to the mp4 container, and then using MKVToolnix to put it in Matroska, this is what you'll get.

Avidemux encoded mp4 file (no VFW involved, right? Right):

http://img225.imageshack.us/img225/7681/mkvtoolnixmpeg4mp4wg7.th.png (http://img225.imageshack.us/my.php?image=mkvtoolnixmpeg4mp4wg7.png)

When taking the same Avidemux encoded mp4 file and putting it into Matroska using MKVToolnix, this is what you get:

http://img66.imageshack.us/img66/1163/mkvtoolnixmpeg4mp4tomkvom4.th.png (http://img66.imageshack.us/my.php?image=mkvtoolnixmpeg4mp4tomkvom4.png)

On the other hand, an MPEG-4 Matroska encoded file with Avidemux looks like this:

http://img89.imageshack.us/img89/4458/mkvtoolnixmpeg4isomkvap8.th.png (http://img89.imageshack.us/my.php?image=mkvtoolnixmpeg4isomkvap8.png)

Put it into Matroska using MKVToolnix, and it's still MPEG4 ISO:

http://img66.imageshack.us/img66/7311/mkvtoolnixmpeg4isomkvtoya6.th.png (http://img66.imageshack.us/my.php?image=mkvtoolnixmpeg4isomkvtoya6.png)

I get the same VFW error with MPEG-4 ASP files encoded with Quicktime when placing them into Matroska using MKVToolnix. This is only the case with MPEG-4 Part 2. Interestingly enough, this issue doesn't apply to MPEG-4 AVC encoded files. It is an MPEG-4 ASP issue only. I guess it's because MPEG-4 ASP has better avi support than MPEG-4 AVC. But still, MPEG-4 ASP files (even if made with VirtualDub and put into mp4 using MP4Box) imported from an mp4 container have been made into ISO compliant streams and should not be VFW streams once put into Matroska using mkvmerge.

Can any of you duplicate this issue? I don't mind if it's an XviD avi I'm muxing into Matroska, that's supposed to be a VFW stream. But when making mp4 files using non-VFW tools and putting them into Matroska and you still get VFW crap, that's annoying. I started using MeGUI because I wanted to get away from worthless Video for Windows, and now I get this.

Well, in any case, I wish to make the Matroska devs aware of this issue (if they aren't already), and see if we can work out a solution to this issue.

[Liisachan]

I think you're asking the same question as this one:

I created a native xvid mp4 from an xvid [...] Why is it being muxed as vfw and not natively? (http://forum.doom9.org/showthread.php?p=705372#post705372)

The short answer is: --engage native_mpeg4
But you may want to read the discussion in the linked thread.
FYI the opposite switch is: --engage allow_avc_in_vfw_mode

[Elias]

I think you're asking the same question as this one:

I created a native xvid mp4 from an xvid [...] Why is it being muxed as vfw and not natively? (http://forum.doom9.org/showthread.php?p=705372#post705372)

The short answer is: --engage native_mpeg4
But you may want to read the discussion in the linked thread.
FYI the opposite switch is: --engage allow_avc_in_vfw_modeThanks Liisachan. With that cleared, what I'm wondering, is why MPEG-4 ASP isn't native by default? I think it should be.

[Milvus]

Hopelessly it seem native MPEG-4 ASP is just badly supported by some players, leading for example to audio/video desynchro. We can just hope for wider and less buggy support in the future. I just for myself can't understand why there is still those kind of stupid problems.

[Elias]

Hopelessly it seem native MPEG-4 ASP is just badly supported by some players, leading for example to audio/video desynchro.That's the players' problem, not Matroska's. Matroska shouldn't appease b0rked media players. I have never had issues with native MPEG-4, however. What kind of media players are experiencing bugs with native MPEG-4?We can just hope for wider and less buggy support in the future. I just for myself can't understand why there is still those kind of stupid problems.Well, the reason for that is because MPEG-4 in avi has been made a standard and as a result of that, Matroska and mp4 have taken damage in terms of compatibility in other players, because developers haven't prioritised other containers and codecs since all that has been important is "XviD" and "DivX"...

[GodofaGap]

That's the players' problem, not Matroska's. Matroska shouldn't appease b0rked media players.
A wise man once said: "Just because it isn't your bug, doesn't mean it isn't your problem." A developer can deal with the same complaints every day (why my file no worky?) or he can use a default mode that does always work. Certainly when your format might not have the leverage that others like AVI and MP4 do carry, sometimes this is something you will have to do to get your format going.

I haven't been around in a while, but IIRC Mosu said his native ASP mode wasn't completely working as it should, and that the issue had very low-priority (since everything worked fine in VFW mode). That the native mode still hasn't become default could mean the problems are still there.

[Liisachan]

Mosu said in 2005 (http://forum.doom9.org/showthread.php?p=703021#post703021):

...Most players and filters do not really support native ASP storage yet. This includes Gabest's splitter, unfortunately. I/we should work on getting support for playback integrated into at least some of the Linux players first.

We decided very early that using the VfW compatibility mode for ASP was OK and the official way at least until native storage was solid enough to be made the standard for new files. We will not discontinue support for those files, ever.

...That's correct. For ASP ( = MPEG-4 part 2) the VfW mode is the default one, regardless of the source container (AVI, OGM, MP4).

...For AVC things are different.

...native ASP storage doesn't give a lot of pros compared to VfW mode storage at the moment.


I copy-pasted the highlights so you don't need to click the link and read many posts. Hope this will help. It was very interesting for me back then.

[Elias]

A wise man once said: "Just because it isn't your bug, doesn't mean it isn't your problem." A developer can deal with the same complaints every day (why my file no worky?) or he can use a default mode that does always work. Certainly when your format might not have the leverage that others like AVI and MP4 do carry, sometimes this is something you will have to do to get your format going.That's a good point. In my opinion though, native MPEG-4 ISO mode is a top priority. I'm just one of those guys who worships standards. I don't want cheap VFW hacks.I haven't been around in a while, but IIRC Mosu said his native ASP mode wasn't completely working as it should, and that the issue had very low-priority (since everything worked fine in VFW mode). That the native mode still hasn't become default could mean the problems are still there.So, is it Mosu's native ASP mode that isn't working properly or is it an issue with the software players?

I placed an ASP file into Matroska using native MPEG-4 mode, and the result was an unsynchronised audio/video file. This is unacceptable and a good reason as to why the native MPEG-4 container (mp4) is a better suited choice for MPEG-4 codecs.

However, I do like Matroska and it's the only non-MPEG4 container I'm willing to use, so in my opinion, this should be of higher priority with Matroska developers. Just because WVF ASP is working as it should in Matroska, it's no excuse to completely forget about native MPEG-4 mode. After all, we're talking about the MPEG-4 standard here, not some unknown Motion JPEG codec. MPEG-4 standard, not VFW standard.

[GodofaGap]

That's a good point. In my opinion though, native MPEG-4 ISO mode is a top priority. I'm just one of those guys who worships standards. I don't want cheap VFW hacks.
You not liking VFW and adoring MPEG4 has very little to do with things. Any way you are going to look at DivX's hack of MPEG4 (if that's what you want to call it) is pretty much the de facto standard. I can't think of any compelling reason (besides misplaced idealism) for demanding a native ASP mode. ASP will probably become a relic of the past soon anyway. The only reason why it is still alive is old hardware, and DivX funny enough.

So, is it Mosu's native ASP mode that isn't working properly or is it an issue with the software players?
AFAIK it's a little bit of both.

I placed an ASP file into Matroska using native MPEG-4 mode, and the result was an unsynchronised audio/video file. This is unacceptable and a good reason as to why the native MPEG-4 container (mp4) is a better suited choice for MPEG-4 codecs.
Unless you want Vorbis, AC3, Vobsubs, etc., etc. I would be happy to use VFW mode for such files. I just watch my files, I don't check how they are muxed all the time.

However, I do like Matroska and it's the only non-MPEG4 container I'm willing to use, so in my opinion, this should be of higher priority with Matroska developers. Just because WVF ASP is working as it should in Matroska, it's no excuse to completely forget about native MPEG-4 mode. After all, we're talking about the MPEG-4 standard here, not some unknown Motion JPEG codec. MPEG-4 standard, not VFW standard.
I think you should talk less about what other people should do. But that's just my opinion. :p

[Elias]

You not liking VFW and adoring MPEG4 has very little to do with things.Right.Any way you are going to look at DivX's hack of MPEG4 (if that's what you want to call it) is pretty much the de facto standard.I know, and that's a very serious, problem. I can't emphasize enough how serious of a problem that actually is. The codec industry must not ape DivX Networks on how to standardize MPEG-4 ASP. Codec and container software developers (and codec users) should preferably opt for MPEG-4 ASP ISO mode, not DivX/Windows/VFW mode.I can't think of any compelling reason (besides misplaced idealism) for demanding a native ASP mode.Are you serious? Misplaced idealism? Sigh...ASP will probably become a relic of the past soon anyway. The only reason why it is still alive is old hardware, and DivX funny enough.It doesn't matter. That's no excuse to break standards. If I encode to MPEG-1, I want to encode to MPEG-1 as it is standardized. I don't want to encode using cheap MPEG-1 hacks. See my point?Unless you want Vorbis, AC3, Vobsubs, etc., etc. I would be happy to use VFW mode for such files. I just watch my files, I don't check how they are muxed all the time.I prefer my files properly made, and following the proper standards.I think you should talk less about what other people should do. But that's just my opinion. :pLook, I'm not giving orders or anything. But this is MPEG-4 we're talking about. As I see it, Matroska does not as of yet support MPEG-4. I don't count cheap VFW hacks as pure MPEG-4. MPEG-4 ASP is a major codec and it should be supported 110% in a serious container like Matroska. It's a damn shame that Matroska still doesn't support native MPEG-4 ASP. It's almost as bad as not supporting mp3 audio in Matroska.

DivX made a half assed job with their MPEG-4 ASP codec in terms of standards. Why follow DivX's lead on this?

[GodofaGap]

I know, and that's a very serious, problem. I can't emphasize enough how serious of a problem that actually is. The codec industry must not ape DivX Networks on how to standardize MPEG-4 ASP. Codec and container software developers (and codec users) should preferably opt for MPEG-4 ASP ISO mode, not DivX/Windows/VFW mode.
Why preferably? DivX is one of the few serious contenders on the ASP market. There is no sense in losing touch with reality.
Are you serious? Misplaced idealism?
Hey, we are not talking about starving kids in Africa here. Again the goal is to watch video, not to have "compliant" files. And yes, for that to happen some people must follow the work of other people. Now if people follow the work of MPEG or a DivX derivative doesn't really matter to me, whatever makes me watch video. You almost make it sound like you would make MPEG compliant files even if you had no way of watching them ever.
It doesn't matter. That's no excuse to break standards. If I encode to MPEG-1, I want to encode to MPEG-1 as it is standardized. I don't want to encode using cheap MPEG-1 hacks. See my point?
I see the point as far as making MPEG1 video makes sure you can play it on things that support MPEG1 (hopefully). I can't think of any thing major that doesn't play DivX-type MPEG4 streams.

Look, I'm not giving orders or anything. But this is MPEG-4 we're talking about. As I see it, Matroska does not as of yet support MPEG-4. I don't count cheap VFW hacks as pure MPEG-4. MPEG-4 ASP is a major codec and it should be supported 110% in a serious container like Matroska. It's a damn shame that Matroska still doesn't support native MPEG-4 ASP.
This is just the multi-media equivalent of a semantical debate. You have to have a compelling reason why people should invest time in this and it should be a better one than you not liking three letters. If you truely want to be MPEG compliant, Matroska is simply not the container for you I suppose.

DivX made a half assed job with their MPEG-4 ASP codec in terms of standards. Why follow DivX's lead on this?
Because their stuff works and it's one of the few parties that matter?

[Liisachan]

Elias, even about MPEG-1, you can ask yourself those questions:

1. Do you use --strictly-enforce-ISO and -t when using lame?
2. Are you angry because lame mp3 files out there are not --strictly-enforce-ISO -t by default, which means the lame devs keep "ignoring" ISO?
3. Are you angry because MP3 decoders out there can decode such "broken" MP3 files that are not strictly ISO? Would you be happier if your player showed an error message that says "This MP3 file is not strictly ISO, so I refuse to decode it. You must re-encode it with --strictly-enforce-ISO"?

I can see your point to some extent. Trust me, you know how I'm angry with MSIE's xhtml support for example and am ready to make a web page that is not viewable with MSIE, ignoring the fact that in the real world more than half users use MSIE. Yeah, I'm ready to refuse many normal, innocent users just because their browsers are not w3c-strict, like some kind of religious extremists whose bible is w3c docs, although I know that is not very realistic and is almost pointless. And I could also say I'm angry with LAME or Xing about that vbr tag, which actually messes with av sync. But even I, being such a weirdo, wouldn't agree with you about this one.

We have to be flexible because this world is not perfect.

Another example would be: when using Unicode, you shouldn't use the Windows new line mark CRLF nor Unix one LF, but U+2028 "should be used wherever the desired function is unambiguous." according to the Recommendations. So, by the same logic as yours, I could ask you to stop using CR/LF in UTF-8/16 files; your Unicode files are not "strict" if they are like that, and your text editor is not strictly Unicode-enabled if it doesn't understand U+2028 as a new line character. I bet we have a lot of such non-strict things around us. But what you don't know doesn't hurt you. :p

edit: typo. sorry I meant Xing, not Xiph.

[Elias]

Elias, even about MPEG-1, you can ask yourself those questions:

1. Do you use --strictly-enforce-ISO and -t when using lame?
2. Are you angry because lame mp3 files out there are not --strictly-enforce-ISO -t by default, which means the lame devs keep "ignoring" ISO?
3. Are you angry because MP3 decoders out there can decode such "broken" MP3 files that are not strictly ISO? Would you be happier if your player showed an error message that says "This MP3 file is not strictly ISO, so I refuse to decode it. You must re-encode it with --strictly-enforce-ISO"?

1. I don't use lame or mp3 at all. I only encode to aac+mp4 or mpeg-4+mp4/matroska.
2. Lame devs ought to be ashamed of themselves. But I owe you for letting me know this about lame (never going to use lame again after this, not that I have been using lame in the past 3 years or so).
3. Yes, broken files shouldn't be supported at all. This is to make sure that crappy encoders are enforced to comply with the standards if the encoder developers want their software to work properly. Broken stuff should be unacceptable at all times.

If it ain't broke, don't fix it; and I would add to that: if it is broke, fix it or don't use it. And VFW MPEG-4 is broken as far as I'm concerned.I can see your point to some extent. Trust me, you know how I'm angry with MSIE's xhtml support for example and am ready to make a web page that is not viewable with MSIE, ignoring the fact that in the real world more than half users use MSIE. Yeah, I'm ready to refuse many normal, innocent users just because their browsers are not w3c-strict, like some kind of religious extremists whose bible is w3c docs, although I know that is not very realistic and is almost pointless. And I could also say I'm angry with LAME or Xing about that vbr tag, which actually messes with av sync. But even I, being such a weirdo, wouldn't agree with you about this one.:D

Why don't you agree with my veneration for industry standards? I am absolutely serious when it comes to standards. If some companies like Microsoft or DivX screw around with the industry set standards, I boycott them out of pure principle. Everyone else should. We must give softare developers the message that standards are not to be messed around with.We have to be flexible because this world is not perfect.Here is where you and I differ. I am a perfectionist. That doesn't mean I am perfect, but I try my damnedest to do things right as best as I can, unless I may have missed something in the first place.Another example would be: when using Unicode, you shouldn't use the Windows new line mark CRLF nor Unix one LF, but U+2028 "should be used wherever the desired function is unambiguous." according to the Recommendations. So, by the same logic as yours, I could ask you to stop using CR/LF in UTF-8/16 files; your Unicode files are not "strict" if they are like that, and your text editor is not strictly Unicode-enabled if it doesn't understand U+2028 as a new line character. I bet we have a lot of such non-strict things around us. But what you don't know doesn't hurt you. :p

edit: typo. sorry I meant Xing, not Xiph.Thanks for letting me know. I'll look into it :)

[Elias]

Why preferably? DivX is one of the few serious contenders on the ASP market. There is no sense in losing touch with reality.DivX is a half assed job as far as MPEG-4 is concerned. Is it a good MPEG-4 ASP codec? Yes, in terms of quality. But DivX is made as a "competing brand codec", not an interoperable compatible MPEG-4 codec (which is what MPEG-4 is all about). Although DivX is capable of outputting pure MPEG-4 ISO streams, if you know how to do it, I would say DivX Networks has screwed around a bit too much with the MPEG-4 standards for my taste.Hey, we are not talking about starving kids in Africa here. Again the goal is to watch video, not to have "compliant" files.You and I have different goals. I watch video and it works fine. But I feel better if the stuff I encode is encoded as it should be. I guess I'm just a little bit more of a weirdo than Liisachan is about this. I am entirely anal about standards.And yes, for that to happen some people must follow the work of other people. Now if people follow the work of MPEG or a DivX derivative doesn't really matter to me, whatever makes me watch video. You almost make it sound like you would make MPEG compliant files even if you had no way of watching them ever.I want my files to be MPEG compliant because I care about standards. If we don't follow standards, we have chaos in the codec world, similar to how Microsoft has screwed the entire WWW with their MSIE only compatible websites, etc.I see the point as far as making MPEG1 video makes sure you can play it on things that support MPEG1 (hopefully). I can't think of any thing major that doesn't play DivX-type MPEG4 streams.It's about the fact that DivX has restricted its codec to Windows. If DivX had done the job right from the beginning, I wouldn't care about complaining about VFW this or VFW that.This is just the multi-media equivalent of a semantical debate. You have to have a compelling reason why people should invest time in this and it should be a better one than you not liking three letters. If you truely want to be MPEG compliant, Matroska is simply not the container for you I suppose.I support Matroska because I like its goals, and that Matroska is open source. I like what the Matroska devs are trying to accomplish. However, if the Matroska devs would not support ISO standard mode in their container for any a/v codec, I wouldn't use their container at all.Because their stuff works and it's one of the few parties that matter?DivX stuff don't work as it should. It works fine to watch DivX video but it's still a codec that has been tampered with in an ugly way. Although I've seen worse. In any case, just because DivX ruined the MPEG-4 Part 2 standard with VFW, Packed Bitstream, and AVI, that's no excuse to appease DivX take on MPEG-4.

We codec users and codec software developers should not rely on DivX and should not be independent on how DivX decided to interpret MPEG-4.

[Elias]

In any case, back to topic:

I've done some tests with native MPEG-4 ASP mode in Matroska. The conclusion is that MPEG-4 Part 2 files encoded with GMC are the ones that MKVToolnix can't handle properly when imported into native MPEG-4.

MPEG-4 Simple Profile works flawlessly as native MPEG-4 in MKVToolnix. MPEG-4 Advanced Simple Profile with B-Frames works quite all right as well. It seems that GMC is the issue here. I haven't tried Qpel encoded MPEG-4 ASP as of yet.

Update:

I've tried some Qpel MPEG-4 files now, and it seems to be the same issue. So, in other words, Qpel and GMC encoded MPEG-4 ASP files don't work properly in native MPEG-4 mode. MPEG-4 ASP files with B-Frames or MPEG-4 SP files work fine in native MPEG-4 mode.

[GodofaGap]

I guess I'm just a little bit more of a weirdo than Liisachan is about this.
True. :p

I want my files to be MPEG compliant because I care about standards. If we don't follow standards, we have chaos in the codec world, similar to how Microsoft has screwed the entire WWW with their MSIE only compatible websites, etc.
Then let us have chaos. Chaos will sort itself out if there is enough demand, and it did. Perhaps not in the way you wanted to, but it did.

It's about the fact that DivX has restricted its codec to Windows.
Since when should developers make their software available for all platforms? Damn you Avisynth and VirtualDub developers! You are all evil!

DivX stuff don't work as it should. It works fine to watch DivX video but it's still a codec that has been tampered with in an ugly way. Although I've seen worse.
Divx works exactly like it should.


We codec users and codec software developers should not rely on DivX and should not be independent on how DivX decided to interpret MPEG-4.
I'm not telling anyone to rely on anything. I'm just saying that the future of ASP is mostly in the hands of Divx. You can deal with that reality as you seem fit, but crying about compliancy at this point is not showing much sense of it. Now, you can get away with that as a user, but not as a developer who wants to see his product used.

[squid_80]

So, in other words, Qpel and GMC encoded MPEG-4 ASP files don't work properly in native MPEG-4 mode. MPEG-4 ASP files with B-Frames or MPEG-4 SP files work fine in native MPEG-4 mode.

What are you using to play them back?

If you're so picky about standards why are you even trying to convert vfw mpeg4 asp files to native? Why aren't they encoded in native format to begin with?

[Elias]

What are you using to play them back?Media Player Classic+ffdshow and/or VLC.If you're so picky about standards why are you even trying to convert vfw mpeg4 asp files to native? Why aren't they encoded in native format to begin with?I of course, encode MPEG-4 ASP to native format, unless I need VirtualDub filters or anything important that requires VirtualDub to handle the job.

And if you read the thread you'd understand that MKVToolnix automatically converts native MPEG-4 ASP files to VFW MPEG-4.

[squid_80]

Media Player Classic+ffdshow and/or VLC.
Depending on how old your vlc build is, it may be broken. When native mpeg4 asp mkv files first started appearing the vlc developers said the files were non-standard and it took a while for it to be fixed. As for media player classic, it would depend on the splitter being used.

And if you read the thread you'd understand that MKVToolnix automatically converts native MPEG-4 ASP files to VFW MPEG-4.No, it converts mp4 files to vfw mode mpeg4 asp mkv. Native mpeg4 asp mkv files can be remuxed fine. If you want native mode no matter what use --engage native_mpeg4 as Liisachan said. I can't find any issues with qpel, gmc or any other advanced features (interlacing and custom matrix).

[Brother John]

Qpel and GMC encoded MPEG-4 ASP files don't work properly in native MPEG-4 mode.
They do. It’s just not always as straight forward as it could be because --engage native_mpeg4 is somewhat broken. (I can confirm audio sync issues with QPel files.) If you only use raw video streams or already native MPEG4 Matroska files as input for MKVMerge, VfW mode will never be triggered and I never had any sync or other issues.

Somewhat related: MKVExtract cannot demux native ASP from Matroska. Actually I’m not aware of any tool that can. So be sure you know what you’re doing before muxing.

[SeeMoreDigital]

Somewhat related: MKVExtract cannot demux native ASP from Matroska. Actually I’m not aware of any tool that can. So be sure you know what you’re doing before muxing.AVInaptic and AVI-Mux GUI are able to extract MPEG-4.2 video streams from out of the .MKV container to .RAW

Simply re-name the .RAW file extension to .M4V to facilitate re-muxing to .MP4 or .MKV


Cheers