Extracting Native Mpeg-4 ASP

[dragonle87]

I have many mkv files with xvid stored as native mpeg-4 asp streams. The problem with many of them is a/v out-of-sync. Before that, they were all in-sync when originally stored in vfw compatibility mode. Basically, I want to revert them back to vfw format to fix the sync problem, but mkvextractgui 1.6.4 can't extract them nor is there any options in mkvmerge 2.0.0 that can change back to vfw format. Once converted using --engage native_mpeg4 command, I can't go back, unless I still have the original files prior to muxing. Unfortunately, they been deleted and I don't want to go thru the whole encoding process again for all of these files. So, are there any programs out there that can extract the native streams out of mkv? Somebody plz help me cause I'm pretty frustrated.

[HeadBangeR77]

It's just a vague memory, but I can recall AVI-MUX GUI (suitable both for AVIs and MKVs) to demux some raw ASP video streams from my matroska files. IIRC they could be muxed with audio streams using the same tool afterwards (MKV merge doesn't support raw ASP streams, AFAIR). Yet I haven't heard of any method of going back to VfW compatibility mode. Hope I've helped a bit.

cheers,
HDBR77

[bond]

i doubt native mpeg can lead to sync issues itself, might be some other problem

is the desync constant or increasing with playback time?

[SeeMoreDigital]

AVI-Mux GUI is able to de-mux MPEG-4 Part-2 streams from either the .AVI or .MKV containers to an "RAW" stream. Although if you re-name the files extension from .RAW to .CMP or .M4V, the streams are more "elementary" than "RAW", as they include certain stream data that can be read by GSpot.

YAMB is also able to de-mux MPEG-4 Part-2 streams from either the .AVI or .MP4 containers to an "elementary" .CMP stream. YAMB can also de-mux MPEG-4 Part-2 streams from the .MP4 container directly to the .AVI container.

Plus, it's possible to use YAMB to change the FPS speed of an "elementary" MPEG-4 Part-2 .CMP stream when muxing it to the .MP4 container.


Cheers

[dragonle87]

Well, after a long google for a solution to my problem, tidbit results turned up empty. The only answer is the long and difficult path: recode and mux it to mkv in vfw mode. As much as I hate avi hacks inside mkv, the old saying still rings true: don't fix what is not broken. If the hacks are needed that bad just to keep a/v in sync, might as well leave them alone then and avoid native mpeg4 storage with the --engage switch.

@bond:

I found part of my answer thru your post here:

http://forum.doom9.org/archive/index.php/t-108795.html

Excerpt:

go to the 'Muxing' menu, select 'Add commandline options', choose '--engage native_mpeg4' from the dropdown-menu.sorry teegedeck, but its not possible to create correct native mpeg4 from all the f*ed up avi files with the option you mentioned. (mosu is also not claiming that it works)
also i have told mosu that currently native mpeg4 creation from correct mp4 files is also not working correctly as my tests have shown



@SeeMoreDigital

I found part of my answer thru your post here:

http://forum.doom9.org/showthread.php?t=93927&page=3

Excerpt:

It also does not seem to be possible to mux .cmp streams into the .avi container.



Having read this, I noticed my title thread is incorrect. Should have been: "Need Help Converting Native mpeg4-ASP Back to AVI"

Basically, I was able to extract the raw mpeg4 stream from mkv via avi-mux gui, then mux it back into mp4 via YAMB, then again extract to avi via YAMB but it errored and produced a corrupted file.

However, probably the thing I'm most angry about is that the author of mkvmerge didn't include some sort of warning popup window that says "converting to native mpeg4 streams does not guarantee a/v sync" or "the default and recommended mode for MPEG4 ASP storage is VFW, not native" or something to that effect. Had he done that, I would have been more cautious and could have avoided this whole mess.

*Big Sigh*

It's gonna take me awhile to recover from this mess (don't even know whether I got the strength/interest to start from scratch and recode all of them again). Hopefully, let this be an example for anyone who might be in the same situation that I'm in.

[Mosu]

However, probably the thing I'm most angry about is that the author of mkvmerge didn't include some sort of warning popup window that says "converting to native mpeg4 streams does not guarantee a/v sync" or "the default and recommended mode for MPEG4 ASP storage is VFW, not native" or something to that effect. Had he done that, I would have been more cautious and could have avoided this whole mess.

Using any of the --engage options is not supported. This is stated in the "command line options dialog":

### Development hacks ###
Options meant ONLY for developpers. Do not use them. If something is considered to be an officially supported option then it's NOT in this list!

If you completely ignore such a warning then you have no right to complain about it later.

[bond]

is the desync constant or increasing with playback time?so ?

[Brother John]

The problem is the conversion vfw->native via --engage native_mpeg, not native streams as such. Those work perfectly fine in Matroska as long as they are native streams from the beginning; e.g. encoded by Xvid_Encraw or x264.exe and never stored in an AVI.

I have a whole lot of those "native from scratch" stored in Matroska and not a single sync issue. My only experiment with --engage native_mpeg4 got me into exactly your situation though. So VfW mode is absolutely not necessary if you use the proper encoding workflow. MeGUI can do this for example.

[bond]

maybe its possible to get the vfw mode mkv stream into avi and remux this avi to mp4 with mp4box (mp4box can fix the vfw crap) and than create a correct native mkv from that mp4...

[Mosu]

The best solution, obviously, would be to fix mkvmerge's sync issues with the conversion from VfW mode to native mode. For that I'd need sample files and a description of how the desync occurs (meaning is it a fixed offset? Does it get worse progressively? etc etc).

[foxyshadis]

vfw mode (http://foxyshadis.slightlydark.com/random/[Koop%5d Damaged Rei-mix - vfw.mkv)
--engage native_mpeg4 (http://foxyshadis.slightlydark.com/random/[Koop%5d Damaged Rei-mix - native.mkv)

As soon as the beat comes in it should be obvious that the tracks are out of sync, even though the exact same audio file was muxed in. (I'd never even noticed before dragonle87 brought it up, I guess I need to pay more attention.) It appears to be a fixed offset, since it's no longer at the end of a much longer mux.

[Mosu]

Thanks, downloading.

[Mosu]

Hmm, any chance you could also upload the AVI, please?

[foxyshadis]

original avi (http://foxyshadis.slightlydark.com/random/[Koop%5d Damaged Rei-mix - trim1.avi)
It's packed, but it occurs either way. It used 3 b-frames, I think. Do you need the audio as well?

[SeeMoreDigital]

original avi (http://foxyshadis.slightlydark.com/random/[Koop%5d Damaged Rei-mix - trim1.avi)
It's packed, but it occurs either way. It used 3 b-frames, I think. Do you need the audio as well?Is there any particular reason why that sample runs at 29.960 fps and not 29.970?


Cheers

[foxyshadis]

I assume it's premiere's fault, or whatever NLE was actually used for that video (http://www.animemusicvideos.org/members/members_videoinfo.php?v=10098). Probably Premiere, since I remember having all kinds of problems with framerates back when I tried to use it.

[Mosu]

original avi (http://foxyshadis.slightlydark.com/random/[Koop%5d Damaged Rei-mix - trim1.avi)
It's packed, but it occurs either way. It used 3 b-frames, I think. Do you need the audio as well?

No thanks, I got the audio fromt he two Matroska files and the tracks are identical. This should be all I need.