matroska output for X264 [patch]

[multicone]

http://haali.cs.msu.ru/mkv/x264-mkv.patch

Haali made this patch for direct matroska output from X264. Can somebody pls. compile it ?

[berrinam]

I can't compile it, but I think it's a great idea anyway: no more mp4 muxing needed to put AVC in matroska.

[yokem55]

I was able to apply the patch and compile it on my linux machine. I haven't tested it yet, but the last time I tried to put avc in mkv with vorbis audio, mplayer didn't know how to keep the video in sync with the audio. Thus I'm not sure how useful this will be for me at the moment....

[multicone]

mplayer didn't know how to keep the video in sync with the audio VLC 0.8.2 is the most advanced Linux player for MKV files, followed by Xine.

[easyfab]

http://rapidshare.de/files/2939395/x264.exe.html

only for testing and i don't know if it really works.
based on r272 and with avisynth enabled but no mp4 output
for mkv name your file .mkv

[kurt]

i made a short test and it seems to work here!
Great! :)

[Shootist]

Nice feature! What about support of direct aac input, so that you no longer need to mux video and audio after encoding.

[Sharktooth]

added matroska patch to my builds:
http://forum.doom9.org/showthread.php?p=610495

[Doom9]

Nice feature! What about support of direct aac input, so that you no longer need to mux video and audio after encoding.next is audio encoding, then we start adding audio features from besweet, in the end there's yet another mencoder. And in turn you've added thousands upon thousands of little issues that'll take time away from further development of the codec...

[bond]

next is audio encoding, then we start adding audio features from besweet, in the end there's yet another mencoder. And in turn you've added thousands upon thousands of little issues that'll take time away from further development of the codec...indeed, better use mencoder before x264cli gets bloated. it should be only about avc encoding and nothing else

[Selur]

it should be only about avc encoding and nothing else
total agreement over here

Cu Selur

[Shootist]

ok. it was just an idea.

[baer999]

Hi I want to know what advantages *.mkv has against *.mp4, I just searched in this forum for the answer but didn't found it. I know that both are smaller than *.avi because of overhead etc, but what has mkv what mp4 hasn't ?

[kurt]

for me the only advantage is muxing AC3/DTS tracks and easy setting DAR for anamorphical encodings...
(speaking for mkv)

[Doom9]

easy setting DAR for anamorphical encodings... and what would be hard about x264 with respect to that?

[bond]

i see it that way:

if you want broad interoperability with various avc implementations, than use .mp4 together with aac audio

if you want to mix lots of different formats, eg avc with vorbis, dts and what not, and dont need your file to play "anywhere" than use mkv

[kurt]

and what would be hard about x264 with respect to that?
nothing actually. but i meant for example tools like matroska shell extension...

@bond: totally agreed

[Pendalf]

As i understand, this is for cli version.
Can it be made to produce normal h264-video in mkv from VirtualDubMod? Normally it produces video stream as from muxing h264 from avi, not from mp4, so for example Nero decoder can't handle it.

[berrinam]

Can it be made to produce normal h264-video in mkv from VirtualDubMod? Put simply: no. VirtualDubMod uses VFW interface, which is outdated and doesn't handle h264 properly.

@edit: However, it could be done by "circumventing" the vfw protocol, and writing the output directly to a file. Unfortunately, this removes the control that virtualdub has over the output.

[cuban]

I tried this build (273B with Matroska) and the result .mkv wasn't playable... MPC doesn't want to play it at all (both with internal and external matroska splitter), mPlayer plays it, but dropps frames (looks like it drops b-frames). When I put my mkv to VirtualDubMod, I got error messages like this:

"[!] MKV: A frame of stream 1 (at 1668 ms) had only a forward reference (maybe
broken file)."

I'll check this later with Matroska tools.

My commandline is: --bframe 2 --b-pyramid --ref 3 --analyse all --8x8dct --weightb --me "umh"

---------- EDIT------------
Hmm... I tried new Matroska tools, and had problems with putting mp4 -> mkv so i installed new Haali mkv splitter and now everything works fine. It confuses me, that new mPlayer cannot handle new .mkv streams, so i'll probably stay with mp4.

[Doom9]

shouldn't that be --me umh, so without the quotes?

[Sharktooth]

yeah.. also b-pyramid with 2 bframes? Useless...

[cuban]

so without the quotes?

Well, I guess it should :) I just checked it - x264 will encode with anything after --me
--me anystring

I guess then, that the default setting is used when there is unsupported --me setting (probably like mine), but no info about wrong --me option is given to the user :confused:

BIG thanks for pointing me that :)

[superdump]

Going back to opinions about including matroska output in x264. MP4 output is only in place so that the files produced are easily watchable afterwards, and MP4 is more approriate as it has been designed as the native container for h.264. However, the MP4 output is apparently unstable as yet so maybe matroska will have its uses for the purposes described above.

Also, the argument that mencoder should be used instead of x264cli because of this matroska patch doesn't seem to make sense to me. I don't see matroska output in MPlayer (well, libavformat) yet... maybe one of you matroska guys should make a patch for that. :)

[akupenguin]

I tried this build (273B with Matroska) and the result .mkv wasn't playable... MPC doesn't want to play it at all (both with internal and external matroska splitter), mPlayer plays it, but drops frames (looks like it drops b-frames). When I put my mkv to VirtualDubMod, I got error messages like this:

"[!] MKV: A frame of stream 1 (at 1668 ms) had only a forward reference (maybe broken file)."

It's right, the file is broken.
Before trying pyramid, lets just look at the results from 1 consecutive B-frame:
~> x264 -b 1 --no-b-adapt $infile -o foo.mkv
~> mkvinfo -v foo.mkv

+ EBML head
+ Segment, size unknown
|+ Segment information
| + Muxing application: Haali Matroska Writer b0
| + Writing application: x264
| + Timecode scale: 50000
| + Duration: 15.960s (00:00:15.960000000)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 38
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Video track
| + Pixel width: 176
| + Pixel height: 144
| + Display width: 11
| + Display height: 9
|+ Cluster
| + Cluster timecode: 0.000s
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000000000) <-- I
| + Frame with size 4873
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.080s = 00:00:00.080000000) <-- P
| + Frame with size 570
| + Reference block: -80.000000ms
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.040s = 00:00:00.040000000) <-- B
| + Frame with size 138
| + Reference block: 40.000000ms <-- wrong. or rather, it should write both forward and backward refs, and it only does one.
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.160s = 00:00:00.160000000) <-- P
| + Frame with size 748
| + Reference block: -120.000000ms <-- wrong. 160-120=40ms is a B-frame.
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.120s = 00:00:00.120000000)
| + Frame with size 126
| + Reference block: 40.000000ms
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.240s = 00:00:00.240000000)
| + Frame with size 772
| + Reference block: -120.000000ms
| + Block group
| + Block (track number 1, 1 frame(s), timecode 0.200s = 00:00:00.200000000)
| + Frame with size 114
| + Reference block: 40.000000ms

[Haali]

This is intentional. Since the encoder does not supply the referenced frames list, I set the previous frame in decoding order as a reference. Exactly the same thing happens inside mkvmerge. However this should not influence playback in any way, as references are not used by any current software. Their original purpose was to facilitate editing without knowing codec internals, but today they only signal keyframes when there are no refernces at all.
Still, for native mpeg-1/mpeg-2/mpeg4-asp the references are correctly calculated, not for avc though, because this is way more complex.

[cuban]

However this should not influence playback in any way, as references are not used by any current software.
When using Haali Matroska splitter everything works fine in MPC. With guliverkli 1.0.2.6 splitter playback doesnt start at all (it's "old", I can understand this). I don't know what splitter mPlayer uses, but there are problems with mkv created by x264 in this player (looks like dropping frames; the same video in mp4 plays ok). I will add, that mkv created from mp4 with Matroska Tools 1.5.0 plays fine in mPlayer.

[multicone]

MKV suport in mplayer is outdated since Mosu stopped caring about it. On Linux, use VLC 0.8.2 or Xine for much better matroska support.

[yokem55]

The problem with VLC and Xine is that the version of ffmpeg that they use is outdated with respect to h264 support. So while the mkv splitting will work properly, the h264 decoding gags on any of the high profile features enabled in the past month.

[foxyshadis]

I had a problem while muxing vorbis audio into the mkv output of x264.exe with mmg. The original out works fine without audio, but after muxing it skips, and seeks will usually crash zoomplayer & media player. Filter chain is haali (6/26/05)->ffdshow (7/3/05)->vmr9 and ffdshow audio for the vorbis. I'm going to try other versions of the splitter and ffdshow to test, and can make a test file. Same decoders work for ogm and mkv w/ x264 + vorbis made through vdub, although the audio lags a little in mkv.

This is the newest 1.1.1 of vorbis encoder, btw.

[pcjco04]

Same problem here :

MKV output from x264 CLI (build 273B) is playable and seekable with MPC (ffdshow 07032005 + Haali splitter 17 July 2005).

But re-mux with Mkvtoolnix 1.5.0 (without additional stream) it is playable but not seekable.