Native MPEG4 MKV files

[ChristianHJW]

Hi,

as nobody came to the channel to start testing the native MPEG4 mode, i decided to post the switch here :

--engage native_bframes

It works only from CLI, but of course you can use mmg to make the CLI for you, copy it to clipboard, insert the switch and run the proggie from a 'command' window then with it.

Playback should work out of the box with matroskasplitter's since 1.0.4.x IIRC .....

Please tell us how its doing, but understand this is HIGHLY experimental. Reading works from AVI, OGM and MP4 files ....

[tiki4]

I'm curious, Christian,

just this morning I tried to mux a MP4 to MKV. The file contains LC-AAC audio and XviD video and was muxed in Graphedit with 3ivx MP4 muxer.

mkvmerge -i shows mp4v for video and mp4a for audio.

Then I tried to mux in mkvmerge (without that switch you posted here, didn't know yet) but mkvmerge showed something like 'unsupported/unknown' and muxed only the audio track.

tiki4

[ChristianHJW]

Originally posted by tiki4 just this morning I tried to mux a MP4 to MKV. The file contains LC-AAC audio and XviD video and was muxed in Graphedit with 3ivx MP4 muxer.
mkvmerge -i shows mp4v for video and mp4a for audio. Then I tried to mux in mkvmerge (without that switch you posted here, didn't know yet) but mkvmerge showed something like 'unsupported/unknown' and muxed only the audio track. tiki4

What program was used to make the MP4 file ? Please note that NeroDigital files are only supported since 0.8.2 , as we had a bug in the MP4 reader code.

[Koepi]

Originally posted by tiki4
The file contains LC-AAC audio and XviD video and was muxed in Graphedit with 3ivx MP4 muxer.
tiki4

As tiki4 stated, he used 3ivx mp4 muxer and graphedit, no nero digital in the chain.

regards
Koepi

[tiki4]

Originally posted by ChristianHJW
What program was used to make the MP4 file ? Please note that NeroDigital files are only supported since 0.8.2 , as we had a bug in the MP4 reader code.

Hm. The last release of mkvtoolnix that I am aware of is 0.8.1. That's on Mosu's Homepage and in the mkvtoolnix thread here. Do you already have a newer version? If so, it can't work with 0.8.1 that I have.

tiki4

Btw, Koepi is of course right, there is no Nero Digital in the chain. Audio was made with BeSweet (Nero dll's though) and video was made with VirtualDubMod XviD-1.0beta3 Koepi's build.

[Mosu]

Originally posted by tiki4
I'm curious, Christian,

just this morning I tried to mux a MP4 to MKV. The file contains LC-AAC audio and XviD video and was muxed in Graphedit with 3ivx MP4 muxer.

mkvmerge -i shows mp4v for video and mp4a for audio.

Then I tried to mux in mkvmerge (without that switch you posted here, didn't know yet) but mkvmerge showed something like 'unsupported/unknown' and muxed only the audio track.

tiki4

Correct, mkvmerge won't read MPEG4 video from MP4 files at the moment. That's a conscious decision, not a bug. I want to get some issues ironed out first. The same input demuxer does, however, read QuickTime files with e.g. Sorenson video. (Not that they're playable on Windows, but mplayer can ;))

[tiki4]

O.K., thanks,

that's clear now.

tiki4

[unmei]

i remuxed a mkv with xvid, aac,aac,ssa to a native mpeg-4 mkv using said switch.
the xvid is beta2 using closed gov and packet bitstream (IIRC).

The output played in TCMP , but at ~12 fps (the original would just play at 25 on that box, if nothing else is eating the cpu).

MPC 6.4.6.9 or 6.4.7.4 forced to xvid decoder: doesnt recognise the video track, plays only audio.
MPC 6.4.7.4 internal or external splitter: plays, maybe a tiny little faster than MPC but not by a important factor.

VLC 0.6.2 windows: opens directx out window, gray, then crashes. (sorry too lazy to get latest version as i don't usually use VLC).

WMP 8.0 plays the file, but even slower/jumpier than TCMP (don't usually use WMP, so maybe it could configured better).


matroska splitter installed 1.0.2.0 (same results with 1.0.1.9)
decoder in use was always FFDShow 2003-05-23
overlay mixer
mp4v, YUY2 (cos of subs i assume)


MKVinfo output:


(MKVInfo) + EBML head at 0
(MKVInfo) + Segment at 24
(MKVInfo) |+ Seek head at 36
(MKVInfo) | + Seek entry at 41
(MKVInfo) | + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo) at 44
(MKVInfo) | + Seek position: 4099 at 51
(MKVInfo) | + Seek entry at 56
(MKVInfo) | + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks) at 59
(MKVInfo) | + Seek position: 4237 at 66
(MKVInfo) | + Seek entry at 71
(MKVInfo) | + Seek ID: 0x11 0x4d 0x9b 0x74 (KaxSeekHead) at 74
(MKVInfo) | + Seek position: 731333876 at 81
(MKVInfo) | + Seek entry at 88
(MKVInfo) | + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues) at 91
(MKVInfo) | + Seek position: 731170932 at 98
(MKVInfo) | + Seek entry at 105
(MKVInfo) | + Seek ID: 0x10 0x43 0xa7 0x70 (KaxChapters) at 108
(MKVInfo) | + Seek position: 6673 at 115
(MKVInfo) |+ EbmlVoid (size: 4012) at 120
(MKVInfo) |+ Segment information at 4135
(MKVInfo) | + Muxing application: libebml v0.6.3 + libmatroska v0.6.2 at 4141
(MKVInfo) | + Writing application: mkvmerge v0.8.1 at 4179
(MKVInfo) | + Duration: 7670.840s at 4197
(MKVInfo) | + Date: Fri Jan 09 18:23:54 2004 UTC at 4204
(MKVInfo) | + Title: Prinzessin Mononoke J/D/d/d+ [kraut] at 4215
(MKVInfo) | + Segment UID: 0x9a 0x5a 0xbf 0x9d 0x6d 0x86 0xc6 0x75
0x68 0x25 0xfa 0x59 0x0c 0xc0 0x20 0x69 at 4254
(MKVInfo) |+ Segment tracks at 4273
(MKVInfo) | + A track at 4279
(MKVInfo) | + Track number: 1 at 4281
(MKVInfo) | + Track UID: 1659508490 at 4284
(MKVInfo) | + Track type: video at 4291
(MKVInfo) | + MinCache: 2 at 4294
(MKVInfo) | + Codec ID: V_MPEG4/ISO/ASP at 4298
(MKVInfo) | + MaxCache: 1 at 4315
(MKVInfo) | + Default duration: 40.000ms (25.000 fps for a video track) at 4319
(MKVInfo) | + Video track at 4327
(MKVInfo) | + Pixel width: 512 at 4329
(MKVInfo) | + Pixel height: 288 at 4333
(MKVInfo) | + Display width: 512 at 4337
(MKVInfo) | + Display height: 288 at 4342
(MKVInfo) | + Lacing flag: 0 at 4347
[snip]

[spyder]

I wonder why MinCache is more than MaxCache?

Spyder

[mikeX]

mkvtoolnix 0.8.1 winxp
video xvid
audio ogg vorbis
subtitles vobsub x2

300 sec with engage native bframes
150 sec without

with engage the audio was greatly out of sync on mplayer classic (coming late)

gonna post a more detailed output along with my command line later on

:: edit ::

my command line output:


E:\mkvtoolnix>"mkvmerge" -o "L:\catch_me_if_you_can.mkv" --default-track 0 --aspect-ratio "0:16/9" --fourcc "0:XVID" -d 0 -A -S --track-order 0 "L:\catch_me\xvi
d\2cd\catch_me-2cd.avi" --default-track -1522887935 --fourcc "-1522887935:XVID" --engage native_bframes -a -1522887935 -D -S --track-order -1522887935 "L:\catch
_me\xvid\catch_me-48kHz-q1.ogg" --language 1:ell --default-track 1 --fourcc "1:XVID" --language 0:eng --fourcc "0:XVID" -s 1,0 -D -A --track-order 1,0 "L:\catch
_me\xvid\2cd\vobsub\catch_me_if_you_can.idx"
Using AVI demultiplexer for L:\catch_me\xvid\2cd\catch_me-2cd.avi. Opening file.
This may take some time depending on the file's size.
+-> Using video output module for video track ID 0.
Using OGG/OGM demultiplexer for L:\catch_me\xvid\catch_me-48kHz-q1.ogg.
OGG/OGM demultiplexer (L:\catch_me\xvid\catch_me-48kHz-q1.ogg): using Vorbis output module for stream -1522887935.
Using VobSub subtitle reader for 'L:\catch_me\xvid\2cd\vobsub\catch_me_if_you_can.idx' & 'L:\catch_me\xvid\2cd\vobsub\catch_me_if_you_can.sub'.
+-> Using VobSub subtitle output module for subtitle track 1 (language: el).
+-> Using VobSub subtitle output module for subtitle track 0 (language: en).
Opened 'L:\catch_me_if_you_can.mkv' for writing.
progress: 202399/202399 frames (100%)
Writing cue entries (the index)...
Muxing took 309 seconds.

*******************************************************************************

E:\mkvtoolnix>"mkvmerge" -o "L:\catch_me_if_you_can-org.mkv" --default-track 0 --aspect-ratio "0:16/9" --fourcc "0:XVID" -d 0 -A -S --track-order 0 "L:\catch_me
\xvid\2cd\catch_me-2cd.avi" --default-track -1522887935 --fourcc "-1522887935:XVID" -a -1522887935 -D -S --track-order -1522887935 "L:\catch_me\xvid\catch_me-48
kHz-q1.ogg" --language 1:ell --default-track 1 --fourcc "1:XVID" --language 0:eng --fourcc "0:XVID" -s 1,0 -D -A --track-order 1,0 "L:\catch_me\xvid\2cd\vobsub\
catch_me_if_you_can.idx"
Using AVI demultiplexer for L:\catch_me\xvid\2cd\catch_me-2cd.avi. Opening file.
This may take some time depending on the file's size.
+-> Using video output module for video track ID 0.
Using OGG/OGM demultiplexer for L:\catch_me\xvid\catch_me-48kHz-q1.ogg.
OGG/OGM demultiplexer (L:\catch_me\xvid\catch_me-48kHz-q1.ogg): using Vorbis output module for stream -1522887935.
Using VobSub subtitle reader for 'L:\catch_me\xvid\2cd\vobsub\catch_me_if_you_can.idx' & 'L:\catch_me\xvid\2cd\vobsub\catch_me_if_you_can.sub'.
+-> Using VobSub subtitle output module for subtitle track 1 (language: el).
+-> Using VobSub subtitle output module for subtitle track 0 (language: en).
Opened 'L:\catch_me_if_you_can-org.mkv' for writing.
progress: 202399/202399 frames (100%)
Writing cue entries (the index)...
Muxing took 150 seconds.


note: cpu usage: 1st case --> 70-90%
2nd case --> 30-50%

[robUx4]

Originally posted by spyder
I wonder why MinCache is more than MaxCache?

Spyder

MinCache is a number of frames.
MaxCache is a size in octets. Apparently the value 1 is wrong.

[tiki4]

Just to add another negative report...

Xvid 1.0 beta 3 with or without packed b-frames, tried 1-2 max b-frames, all clips cannot be played correctly. I tried with 3ivx filter and also with ffdshow. Muxing was done with mkvmerge-0.8.1.

Because of that I tried on Linux with MPlayer 1.0pre3, linked against latest release of libmatroska. It didn't recognise the video track and just played the audio stream. Weird.

:( , tiki4

[Mosu]

Originally posted by tiki4
Just to add another negative report...

Xvid 1.0 beta 3 with or without packed b-frames, tried 1-2 max b-frames, all clips cannot be played correctly. I tried with 3ivx filter and also with ffdshow. Muxing was done with mkvmerge-0.8.1.

Because of that I tried on Linux with MPlayer 1.0pre3, linked against latest release of libmatroska. It didn't recognise the video track and just played the audio stream. Weird.

:( , tiki4

Guys, just to make this VERY clear:

This is not even beta code! There's a reason that --engage is not documented anywhere. This code will most likely NOT work!

Having said that: Yes tiki, mplayer does not contain support for this.

No, I can't give you all a timeframe about when that code might become more useable. Probably not before the end of March (diploma thesis woes and stuff). Maybe even later.

[tiki4]

Nothing wrong with that, Mosu. Good luck to your diploma thesis.

It's just, Christian asked for testing, didn't he? So we tested...

Great work, anyway.


tiki4

[Mosu]

Originally posted by tiki4
It's just, Christian asked for testing, didn't he? So we tested...

I just don't want you to get your hopes up too much ;) And don't doubt that I'm grateful for the testing - I am. It shows me that I need much more test files if I want to get this right.

[unmei]

"I wonder why MinCache is more than MaxCache?"

I have no idea whatsover about those chaches. I did not set anything special. The only reason i could think of for it being unexpected values: i use unrestricted profile.
Maybe max < min simply means: make no assuptions and be prepared for everything :)

[robUx4]

As said elsewhere :
MinCache is a number of frame
MaxCache is a size in octets

MaxCache = 1 is probably an error and shouldn't be there. (it's not used by any player right now)

[KpeX]

Finally got around to testing this ;). Muxed an XviD 1.0 Beta 3 stream to MKV using 0.8.1 and the --engage native_bframes switch, and I'm happy to report the result plays flawlessly in VLC 0.7.0. Playback is jerky as others have mentioned in DirectShow players.

However, if I take this native MPEG4 MKV and attempt to transmux it to MP4 using GraphEdit and the 3ivx filters, the resulting MP4 plays slow and jerky in any player, and shows an incorrect (longer) playing time, although this could just as well be a 3ivx problem.

Good luck with your future native code Mosu, it's a great start so far.

[tedgo]

Is there any chance to create native MPEG4 in MKV without this (buggy) switch?
Muxed Videofiles from the MP4-Container aren't recognized by mkvtoolnix and that's the only way i know...

(Sorry for my bad english but my last lesson's 20 years ago ;))

[SeeMoreDigital]

The other day I used Alex Noe's AVI-mux to mux an Mpeg4 and AAC into an MKV container...

Worked a charm... Or am I missing something?

Cheers

[tiki4]

Yep, you're missing something. Up to now Matroska stores MPEG4 video in a Video for Windows compatibility mode. 'Native MPEG4' means to store it in a different, platform-independent way.

tiki4

[Mosu]

Originally posted by tiki4
Yep, you're missing something. Up to now Matroska stores MPEG4 video in a Video for Windows compatibility mode. 'Native MPEG4' means to store it in a different, platform-independent way.

tiki4

'native' means not using packed bitstream, exactly ONE video frame per Matroska frame and using correct timestamps for those.

[shitowax]

Could you detail what do you mean by "correct timestamp" ? I don't really care what you do internaly in the mkv file format, but I care what kind of frame order and timestamping your DS splitter will output in this case cause it was reported to break the 3ivx muxer and/or the 3ivx decoder...

Originally posted by Mosu
'native' means not using packed bitstream, exactly ONE video frame per Matroska frame and using correct timestamps for those.

[Mosu]

Originally posted by shitowax
Could you detail what do you mean by "correct timestamp" ? I don't really care what you do internaly in the mkv file format, but I care what kind of frame order and timestamping your DS splitter will output in this case cause it was reported to break the 3ivx muxer and/or the 3ivx decoder...

At the moment we believe in storing frames in coding order and using display timestamps. So a sequence of (coding order) IPBB at 25fps will have the timestamps (I 0ms) (P 120ms) (B 40ms) (B 80ms). This of course requires buffering of a frame somewhere. The Matroska specs require such tracks to have a special CodecID so that the demuxer and/or decoder know they'll have to buffer.

[shitowax]

Interresting ... now I understand why it broke all muxers and decoders ;)

Originally posted by Mosu
At the moment we believe in storing frames in coding order and using display timestamps. So a sequence of (coding order) IPBB at 25fps will have the timestamps (I 0ms) (P 120ms) (B 40ms) (B 80ms). This of course requires buffering of a frame somewhere. The Matroska specs require such tracks to have a special CodecID so that the demuxer and/or decoder know they'll have to buffer.

[SeeMoreDigital]

Thanks for the explaination.

The Mpeg4 streams I used did not have any b-frames and so were not using packed bitstream either...

I guess this helped quite a bit then?

Cheers

[Mosu]

Originally posted by SeeMoreDigital
The Mpeg4 streams I used did not have any b-frames and so were not using packed bitstream either...

I guess this helped quite a bit then?

;) Well, B frames in 'VfW compatibility mode' are no problem at all. In this case the packed bitstream is taken as it is in the AVI and put into Matroska. Including the dummy frames. But this is not the case how it should be handled later when the native mode has been implemented properly.

[bond]

Originally posted by Mosu
'native' means not using packed bitstream, exactly ONE video frame per Matroska frame and using correct timestamps for those.does native leave the vfw delay frames in? does native remove the vol from every keyframe?

[Mosu]

Originally posted by bond
does native leave the vfw delay frames in? does native remove the vol from every keyframe?

It will of course kick the delay frames out - otherwise you'd end up having more frames then necessary. Dunno about the vols. There are reasons why this hasn't been implemented that, and not knowing enough about the whole issue is one of them.

[ChristianHJW]

Originally posted by shitowax
Interresting ... now I understand why it broke all muxers and decoders ;)

I know it was a bad idea to use the same FourCC for our test native streams, but the last word is not spoken on this, as we havent finally decided about the best way of doing it actually ( we will do that if the first working app for that exists, so we can make tests ).

DaveEL coded the nice Timstamp Manager Filter for us because of this, using it we will be able to define our own FourCC/GUID if necessary, and 'translate' it ( correct either frame or timestamp order ) so that the output will be bit identical to that coming from most of the MP4 demuxers ( if all companies doing those can agree on how to do it actually ;) ) .....

[shitowax]

I doubt companies will agree on anything except file format while M$ itself doesn't release an ISO splitter ... and I doubt it will anyway soon. We chose to limit the 3ivx splitter to output exactly the same kind of timestamping info than the avi splitter so that decoders can work the same way with stream coming from .avi and .mp4. I have no idea how ahead or mpegable chose to output their samples.

For your information, the ISO file format spec defines some tables to store equivalent of both PTS and DTS. So, it would be easy to output shifted PTS instead of DTS like the "mkv native" way.

Originally posted by ChristianHJW
DaveEL coded the nice Timstamp Manager Filter for us because of this, using it we will be able to define our own FourCC/GUID if necessary, and 'translate' it ( correct either frame or timestamp order ) so that the output will be bit identical to that coming from most of the MP4 demuxers ( if all companies doing those can agree on how to do it actually ;) ) .....