mkvtoolnix 1.6.5 is out

[buzzqw]

i know that isn't your perfect answer

but i resolved the "dilemma" by muxing aac audio into mp4 audio file (mp4box) and then adding this mp4 into matroska

quick&dirty

BHH

[tomos]

ah ok, so just add the audio alone (not audio and video) with that?

sweet, will give that a go - thanks :D

[tomos]

just to add, that worked. thanks dude :D

[buzzqw]

of course... after muxing acc into mp4 open mmg.exe then add video AND audio.MP4 :D

glad to help!
BHH

[foxyshadis]

It's not really quick and dirty, it's that raw aac isn't really supported by mkvmerge, iirc. It has to be mpeg-4 aac. I may be wrong though.

[issa]

Latest CVS/SVN msvc unicode build,

URL: http://rapidshare.de/files/17462847/mktoolnix-1.6.5-msvc-unicode-20060408.7z.html

[Mosu]

No, raw AAC IS fully supported. There's always a warning message if "--aac-is-sbr..." is not used because that fact cannot be concluded from the raw AAC headers. But that's just that, a warning.

But this warning does not have anything to do with mkvmerge hanging at the end of the muxing process. If it is hanging then that's a bug somewhere. Please try muxing only the audio file and, in another run, only the video. If mkvmerge hangs on either runs then I'd like to ask you to upload the offending file to my FTP server (see signature).

Thanks.

[tomos]

just tried the audio by itself with "--aac-is-sbr 0" etc and it hangs. the mkvmerge process runs @ 99% CPU utiliz.. and if i end task that, then i can get into the GUI to copy and paste the err (guessing mmg.exe is the actual GUI)

i can upload the aac file but it is 120meg. i have no idea how to split one of these files

[Mosu]

If you're willing to upload it then please do so -- I definitely have the space and bandwidth available.

[tomos]

nevermind, i'll do it now :)

[tomos]

all done. hope that aac file helps.

p.s. called it mkvmerge freezing.acc :p

[Elic]

When I began ripping I made few TV-rips and coded audiotrack with Windows Media Audio (and AVI as container of course :) ). Now, I want to remux these rips into matroska (mainly because I like ordered chapters and subtitles). I tried mkvtoolnix and discovered that it doesn't support WMA at all. How can I mux matroska with WMA audio track, or is this trick possible with other tools? Or, are there any plans about supporting WMAs by mkvtoolnix?

[Koti]

I am pretty sure gabest mkv muxer and haali's muxer accept wma with no issues . Then you can open the mkv with mkvtoolnix and add chapters / descriptions

edit:
muxed a vp7 .avi with .wma audio using gabests muxer in graphedit. Opened the resulting file in mkvtoolnix and added titles and chapters.
vp7 wma chaptered .mkv (http://www.megaupload.com/?d=3WH0PQ3Y) 1,879 kb sample

[Isochroma]

mkvtoolnix does not accept either WMA or WMV for input. I believe Mr. Bunkus left them out for a particular reason - he does not want to support or encourage monopolistic media formats.

Your best bet would be to use the Solveig ASF muxer, graphedit, etc. Perhaps even better (and simpler) just use directshowsource() to decode the audio and re-encode to mp3, flac, ac3, etc.

[Egh]

I tried mkvtoolnix and discovered that it doesn't support WMA at all. How can I mux matroska with WMA audio track, or is this trick possible with other tools?

Haali matroska muxer in graphedit for instance. That's probably best option if you don't want to reencode the audio.

[Liisachan]

Gabest's muxer on Graphedit works too for wma--even wmv.

NOTE: In the past, I experienced that mkvmerge didn't accept such an MKV created on Graphedit. If that still happens, load your (wma).mkv on VirtualDubMod and save it losslessly without doing anything by Direct Stream Copy. Then, the resulted mkv will be accepted by mmg.

[Mosu]

mkvtoolnix does not accept either WMA or WMV for input. I believe Mr. Bunkus left them out for a particular reason - he does not want to support or encourage monopolistic media formats.

Well, it's not THAT simple. I'd love to support getting rid of such stuff, but Microsoft has patents on the file formats WMV and ASF and has proven in the past to come after programs which support these formats. Ok, it hasn't happended with a lot of other projects (e.g. mplayer, ffmpeg etc etc), but I'd rather not risk wasting my time on this at the moment.

[Egh]

Gabest's muxer on Graphedit works too for wma--even wmv.

NOTE: In the past, I experienced that mkvmerge didn't accept such an MKV created on Graphedit. If that still happens, load your (wma).mkv on VirtualDubMod and save it losslessly without doing anything by Direct Stream Copy. Then, the resulted mkv will be accepted by mmg.

if such thing happens again, report it as a bug.

IIRC that was Haali muxer bug, not mkvmerge. Now it's ok iirc.

As for wma/wmv accept in graphedit -- there's no miracle here. Cause those DS muxers do NOT accept wmv fileformat. They only accept wmv/wma streams, which are splitted e.g. by haali splitter.

The obvious problem with such workaround for mkvmerge is that it's a cross-platform application and can't rely on DirectShow filters to do the job.

[Elic]

:thanks: you all for help. I already tried Liisachan's technology (VDM then mmg), and it works fine. Of course I will never code audio as WMA :) - but with those rips, I was complete dummy and considered that "DivX ;)" video must be mixed with "DivX ;)" audio only... :rolleyes:

[tomos]

any luck having a look at my aac file? the one that caused mkvmerge to lock up?

[Mosu]

Yes. It contains huge gaps which in turn do not contain any AAC header. I've modified mkvmerge to not crash on such files, but I really wonder where you got this one from, or how you created it. It only contained about 7 MB of usable AAC data. Maybe it's an incomplete download from a P2P network?

[tomos]

it was from a japanese transport stream. it has way more than 7MB of data. it has audio for 1hr 56mins.

after following the info given previously and converting it to an mp4 file, its now working fine (muxed with mkvmerge with the accompaning avi). used the same aac as i ftp to you in fact.

the file may have bad headers but it was definetely complete tho.

[Mosu]

Very strange file.... I'm pretty sure that mkvmerge will never support such files. But if you can work around this by muxing to MP4 first then that's at least a possibility.

[tomos]

definetely weird, thankfully thats the 1st and only file like that i;ve seen :)

[lexor]

I see a few fixes were introduced since the original post, is the link in the first post the latest version with all the fixes?

[Liisachan]

1.6.5 is the newest official build as of now.
newer builds for testing are here
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[LeMoi]

While muxing an mp4 file into an mkv, i have the following warning :
Warning: '*.video.mp4' track 1: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.
The mp4 has ben created with x264.exe build 504.

It's not the first time I have this warning, but before that, there were no playback error. Now, with this one, (I just uploaded the beginning of the file in your ftp), I have issues, with CoreAVC or ffdshow, the video seems to have "jerks" (I don't know if it's the right english term, but you'll see with the file [EDIT : i tried to upload in "LeMoi"'s folder, but i had no permission, so i hope you'll recognize it]). I don't have the .mp4 anymore, but if I extract the h264 raw from the file and mux it in an mp4 file with MP4Box, there are no "jerks" any more, but the video seems to be accelerated since it's complete but lasts 25m22s instead of 26m28s.

Is this a problem in the codec ? a playback problem ? a muxing problem ? Can it be fixed without the original .mp4 ? If no, how can i do so that this bug does'nt happen any more ?

[Liisachan]

Microsoft has patents on the file formats WMV and ASF and has proven in the past to come after programs which support these formats. Mosu, zambelli just said something interesting.
http://forum.doom9.org/showthread.php?p=819162#post819162


[Answering to my "MS is the one who told VirtualDub to stop ASF support."]
Not exactly true. That whole VDub ASF episode has been blown way out of proportion. Avery Lee can tell you himself that he never actually got a cease and desist letter from Microsoft. Whoever contacted him didn't do so on behalf of Microsoft's legal department, but Avery didn't feel like pushing the issue. I'll be the first one to tell you that ASF support in VDub would've been a cool thing to have.


Whether or not what zambelli is saying about VD is true, is not really important. Maybe zambelli is biased too. But what's important is, matroska muxing/editing tools could safely support ASF/WMA/WMV, if you'd like to...

What would you think?

[Egh]

Whether or not what zambelli is saying about VD is true, is not really important. Maybe zambelli is biased too. But what's important is, matroska muxing/editing tools could safely support ASF/WMA/WMV, if you'd like to...

What would you think?

That's true about VD. You can read that in Lee's blog @ virtualdub.org (try to find a date corresponding to 1.3/1.4 versions, cause asf import was removed after 1.3c version, which i still happily posses :approved: )

Another matter though is that Lee was superior, i.e. he did the ASF import in short using reverse engineering and that alone might raise concerns. I don't know if full specs for ASF were officially published at all, but they certainly hadn't been published before 1.3 vdub was released.

Summing up, you can use M$ designed way to import streams from asf/wmv i.e. thru DShow filters, but that won't work on non-windows systems.

[Liisachan]

@Egh: Hmm, I still wonder... RE is legal unless the target is patented, and ASF, the file format, not the codec, is not patented, right?

@Mosu:
I might have already told you this, but mkvextact refuses to convert UTF-8 to 16, one of the simplest conv. Or am I doing anything wrong here...?

These work:
mkvextract tracks SRT.mkv -c UTF-8 2:UTF-8.srt
mkvextract tracks SRT.mkv -c WINDOWS-1252 2:WINDOWS-1252.srt

These don't work, producing garbage:
mkvextract tracks SRT.mkv -c UTF-16 2:UTF-16.srt
mkvextract tracks SRT.mkv -c UTF-16LE 2:UTF-16LE.srt
mkvextract tracks SRT.mkv -c UTF-16BE 2:UTF-16BE.srt

In case you'd like to check the resulted UTF-16.srt etc: SRT.mkv and SRTs mkvextract produced are in this zip (http://ffdshow.faireal.net/tmp/mkvextract_c_utf16.zip) (6 KB)

Tyia.

[Mosu]

@Mosu:
I might have already told you this, but mkvextact refuses to convert UTF-8 to 16, one of the simplest conv. Or am I doing anything wrong here...?

That's true, and I don't expect that to change any time soon. Internally mkv* work with UTF-8 encoded strings. Adding proper support for conversion into UTF-16/32 would require to change almost all string handling from UTF-8 encoded multi-byte strings to wide char strings. Originally I didn't do this because of evil bugs in gcc 2.95, and now I don't because of the huge amount of work required for this.

I might support this one day with a quick work around.

[Mosu]

While muxing an mp4 file into an mkv, i have the following warning :

Yeah, there's nothing I can do about it, sorry. Apart from parsing the frames and re-creating the timecodes myself, which mkvmerge will most likely never be able to do. It's most likely a muxing problem on x64's end.

[Mosu]

Mosu, zambelli just said something interesting.
http://forum.doom9.org/showthread.php?p=819162#post819162

Yes, that definitely sounds interesting. Might even be enough to change my mind on not supporting ASF on principle. (There's still the "lack of time" issue, though)

[Liisachan]

Thank you Mosu. Now I kind of remember...
Yesterday while trying to explain Shirokuu how to do SRT.mkv->Hardsub.avi I needed that for him/her, since I was not sure if VSFilter liked UTF-8.
http://forum.doom9.org/showthread.php?p=820354#post820354
I did a quick test just now and current VSFilter seems to be ok with UTF-8 too. So I could have just used default, without -c, after all. Well, how about simply "Error: -c UTF-16 is not yet implemented" rather than writing a broken file?

--Anyway, here's another small thing I found today.
For instance, Video frame 12 (0-based) is at 0.5005 sec @ 24000/1001 fps.
12 * 1001 / 24000 = 0.5005

VirtualDub reports it correctly as 0:00:00.501 rounded to millisec, but when mkvmerged and then mkvinfo'ed it is reported as
| + Block (track number 1, 1 frame(s), timecode 0.500s = 00:00:00.500000000)

So I believe that it's 0.500 internally in MKV and I guess MKVmerge is calculating this order, which is more lossy.
( 1001.0 / 24000.0 ) * 12

Similary, the Frame 36, at 1.5015 sec, is reported correctly as 1.502 by VD, while it's 1.501 by Mkvmerge->Mkvinfo. And so on.

Currently I can't make any real demo where this causes any critical problem, but this seems potentially risky.
Very simply put (this example is actually not proper tho), a subber might use VD and think "ok, this frame is 1.502. I'll do frame-accurate timing" and write 00:01.502 in the sub script that has ms accuracy to specify that frame, but when muxed into mkv, that video frame would now be treated as 1.501, which could mess up the sub timing.

If the true value is 1.5015 sec and if it is rounded to millisec, then the result should be 1.502. That's what I think.

[LeMoi]

Yeah, there's nothing I can do about it, sorry. Apart from parsing the frames and re-creating the timecodes myself, which mkvmerge will most likely never be able to do. It's most likely a muxing problem on x64's end.
Yeah i know it's an x264 problem, i just thought mmg could fix this problem :). Anyway i know use build 502 and it's OK

[issa]

Rev. 3223 aka 1.7.0 msvc unicode build,

Download: RapidShare (http://rapidshare.de/files/19199277/mkvtoolnix-1.7.0-unicode-msvc.7z.html) or MegaUpload (http://rapidshare.de/files/19199277/mkvtoolnix-1.7.0-unicode-msvc.7z.html)

Note: Recompile to get bz2 support.

[Mosu]

Hey users and packagers,

Here's the newest release of mkvtoolnix after nearly five months of slow development. This release features a couple of bug fixes and almost no new features.

The usual links to...
...the home page:
http://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.7.0.tar.bz2
...the Windows Unicode installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.7.0-setup.exe

The other binaries will be available from my homepage and the other assorted web pages shortly.

Here's the ChangeLog since 1.6.5:

------------------------------------------------------------
2006-04-28 Moritz Bunkus <moritz@bunkus.org>
* Released v1.7.0.
* mkvmerge: enhancement: Added support for MIME type detection via libmagic (patch by Robert Millan with heavy modifications by myself).

2006-04-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Theora headers were not handled correctly.

2006-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The WavPack reader was broken on 64bit systems (e.g. AMD64).

2006-03-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Theora timecode handling was broken, and Ogg/Theora files were not identified correctly (they showed up as "unknown" in mmg).

2006-02-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The 'adjust timecodes' function accepts timecodes like 'XXXXXunit' with 'unit' being 'ms', 'us', 'ns' or 's'.
* mkvmerge: enhancement: mkvmerge will no longer refuse to concatenate files with differing Codec Private contents and only issue a warning in such cases.
* mkvmerge: bug fix: Quicktime/MP4 reader: Added support for version 1 media headers ('mdhd' atom) with 64bit fields. Fixed the duration of the last packet passed downstream. Fixed overflow issues during re-scaling from the Quicktime/MP4's time scale to nano seconds used by mkvmerge.

2006-01-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Muxing wasn't working Windows 9x/ME because mkvmerge was trying to use Unicode file access functions when determining which directories to create. Fixes Anthill bug #177.

2006-01-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for the "Delay:" feature and for negative timecodes in VobSub IDX files.

2005-12-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: If mmg is set to automatically fill in the output file name then it will clear the output file name once all input files have been removed.

2005-12-12 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a crash that occured if the user removed an attachment and clicked somewhere in the empty space in the attachment list. Occured only on Windows.

2005-12-10 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Re-added Chinese to the list of popular languages (those are listed first in the language drop down boxes).

2005-12-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The last change to the ISO 639 language handling broke the VobSub reader so that it reported the wrong language codes. This also caused mmg to not display the correct language after adding a VobSub file.
------------------------------------------------------------

Have fun :)

[tomos]

thanks :D

[klinika]

Most excellent Mosu :D I don't know if this has been addressed before, but there remains one minor bug in mmg: the aspect ratio resets when you click on the video track and some other track and repeat a few times. Can anyone reproduce?

[Egh]

Pitty you didn't wait for some bugreports on the last /pre/ version :P

Here's an interesting though minor bug in mmg:

Put a cursor in "Global" section in the box "..after the timecodes". (enable splitting first, of course) then press Ctrl+N. Of course, it becomes all disabled (including "Enable splitting" checkbox). Enable it again -- you'll see TWO selections on the radiobuttons in this section, "after this size" and "..after the timecodes", and the latter will be disabled :) You can now switch selections between those boxes but "..after the timecodes" box remains disabled despite being chosen. You can click on a "..after a duration" box first and then "unlock" timecodes editbox.

That was a minor but funny bug.

Now the bad news (i discovered that only yesterday with april prerelease build).


Here's the ChangeLog since 1.6.5:

------------------------------------------------------------

2006-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The WavPack reader was broken on 64bit systems (e.g. AMD64).
------------------------------------------------------------


Are you sure this bugfix didn't b0rk wav import on 32bit systems? :O

MMG.exe now can't import a simplistic wav which is even stereo only and PCM16 ;) On attempt to import it says " Multiplexer failed to initialize: wav_reader no data chunk was found". Needless to say that the file is played flawlessly by winamp and recognized by windows standard programs.

[Liisachan]

WavPack is a lossy/lossless dual audio codec like OptimFROG. Not related to ".wav" file. I can't reproduce that WAV pb either.


G:\>mkvmerge glider.wav -o test.mka
mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:19:57
'glider.wav': Using the WAV demultiplexer.
'glider.wav' track 0: Using the PCM output module.
The file 'test.mka' has been opened for writing.
progress: 100%
The cue entries (the index) are being written...
Muxing took 1 second.


Didn't you "save wav" from VDM?


G:\>mkvmerge vdm.wav -o test2.mka
mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:19:57

Error: The demultiplexer for the file 'vdm.wav' failed to initialize:
wav_reader: No data chunk was found.

[issa]

Pitty you didn't wait for some bugreports on the last /pre/ version :P

Here's an interesting though minor bug in mmg:

Put a cursor in "Global" section in the box "..after the timecodes". (enable splitting first, of course) then press Ctrl+N. Of course, it becomes all disabled (including "Enable splitting" checkbox). Enable it again -- you'll see TWO selections on the radiobuttons in this section, "after this size" and "..after the timecodes", and the latter will be disabled :) You can now switch selections between those boxes but "..after the timecodes" box remains disabled despite being chosen. You can click on a "..after a duration" box first and then "unlock" timecodes editbox.

That was a minor but funny bug.



I assume you were trying the latest version (1.7.0). Would you like to try my build to see if the bug still exist? Since I cannot reproduce the bug you said.

[Egh]

Didn't you "save wav" from VDM?



No. I used graphedit (i.e. ffdshow audio to decode and wavdest.ax filter to convert it into wav format).

I didn't say it happens with all wav files, but e.g. for the current project I have 10 wavs 25 min long each and all transcoded from AAC into wav in the above described way :P

These wavs are played not only by winamp, but even by windows standard programs so I think this particular format fully complies with M$. But mkvmerge doesn't accept it, so I think that's some kind of bug in the import.

The error, btw, happens in mmg on drag&drop of the audio file already, so that's not only mkvmerge problem, I guess.

P.S. the problem, of course, was first detected in the april /pre/ builds of mkvtoolnix, so that's not specifically 1.7.0 problem.

[thoralf]

hi mosu,

iirc, mkvmerge (the gui) had the ability to extract the language setting from a stream's name a while ago: loading an ogg with a filename like "movietitle track x espanol.ogg" caused the language for this track to be set to "spa (Castilian)". I quite liked this feature (didn't it work for vobsubs as well?), it seems to be gone in recent versions ...
Another bug, also language-related: if you loaded vobsubs from a idx file with more than one stream in it in 1.6.5, setting the language of the eg. second stream caused the language setting of the first one to be changed as well. I don't know if this applies to 1.7.0 as well, as I don't have a vobsub to test around here atm.

keep up the good work & thanks a million times,
thoralf.

[Liisachan]

@Egh
i can reproduce your pb here, but the same pb in 1.6.0 so not enbugged in 1.7.0.

Workaround: open your WavDest out.wav with your audio editor, and resave it as Windows PCM (ofcos this is lossless and very quick)

"AAC" is not related: pb is in WavDest->File Writer part, as the same pb can be reproduced for MP3->(wavdest)->Wav.
Mosu might want to check this thing...

http://ffdshow.faireal.net/tmp/wavdest.png


G:\ttest>mkvmerge WaveDest_Out.wav -o NOOO.mka
mkvmerge v1.6.0 ('Ist das so') built on Oct 14 2005 16:39:51

Error: The demultiplexer for the file 'WaveDest_Out.wav' failed to initialize:
wav_reader: No data chunk was found.

G:\ttest>mkvmerge Resaved_as_WinPCM.wav -o YEEESS.mka
mkvmerge v1.6.0 ('Ist das so') built on Oct 14 2005 16:39:51
'Resaved_as_WinPCM.wav': Using the WAV demultiplexer.
'Resaved_as_WinPCM.wav' track 0: Using the PCM output module.
The file 'YEEESS.mka' has been opened for writing.
progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.


WaveDest_Out.wav (http://ffdshow.faireal.net/tmp/WaveDest_Out.wav)
784KB

Resaved_as_WinPCM.wav (http://ffdshow.faireal.net/tmp/Resaved_as_WinPCM.wav)
784KB

EDIT: I meant to call it WavDest_Out.wav but happened to name it WaveDest_Out.wav with extra e.

[Booji Boy]

@Mosu/Mods: Wouldn't it be a good idea to split this thread into two and so making a fresh new one for mkvmerge 1.7.x? This one got quite long already.

@Mosu: Will mmg someday support displaying and re-editing the attachments and chapters when importing mkvs? That would be handy. Although they are taken over by mkvmerge, they are not shown in the GUI and therefore not editable from within it.

[Mosu]

@Mosu/Mods: Wouldn't it be a good idea to split this thread into two and so making a fresh new one for mkvmerge 1.7.x? This one got quite long already.

I usually create a new thread once in a while, but I don't want to spam the whole board with "new mkvtoolnix release!!!!" threads. Ok, I haven't released as many versions during the past few months like I did two years ago, but still...

@Mosu: Will mmg someday support displaying and re-editing the attachments and chapters when importing mkvs? That would be handy. Although they are taken over by mkvmerge, they are not shown in the GUI and therefore not editable from within it.

While I agree that this would indeed be useful and easier to work with I doubt that I'll find the time to implement it at the moment. Sorry.

[Tima]

An old problem reappears:

---------------------------
mkvmerge GUI: error
---------------------------
The stretch setting for track nr. 0 in file 'E:\DVD\Pr_King_Kong\project T02 3_2ch 384Kbps DELAY 0ms.rus.ac3' is invalid.
---------------------------
ОК
---------------------------


"mkvmerge" -o "E:\DVD\Pr_King_Kong\King Kong.mkv" --priority lower --language 1:eng --default-track 1 -d 1 -A -S E:\DVD\Pr_King_Kong\project.mkv --sync 0:0,1001/960 --default-track 0 -a 0 -D -S "E:\DVD\Pr_King_Kong\project T02 3_2ch 384Kbps DELAY 0ms.rus.ac3" -a 0 -D -S E:\DVD\Pr_King_Kong\project.audio.eng.ogg --language 0:eng --sync 0:0,1001/960 --default-track 0 --compression 0:zlib --language 1:rus --sync 1:0,1001/960 -s 0,1 -D -A E:\DVD\Pr_King_Kong\project.subs.idx --track-order 0:1,1:0,2:0,3:0,3:1 --title "King Kong" --split size:797 --split-max-files 3 --link
when executing commandline manually, everything is running ok.. but the resulting video doesn't play properly in MPC (audio is ok). In VLC it doesn't play at all..

[Ron70]

I have been doing some experimenting with converting some of my HD Transport stream files to mkv. For the most part I like the results. Fast accurate seeks, FF and Rew actually work and smother playback. The only problem has to do with the 1088 encode for mod 16 and 1080 display. The transport streams display correctly but the mkv has a grey bar at the bottom. I have looked through mkvmerge and tried to find something in the online mkvtool documentation that fixes this problem without any luck.

Does anyone have any experience with HD MPEG2 or an idea of what I might try?

Edit:
I am using Zoomplayer: Haali Media Splitter - nVidia Decoders

[Isochroma]

Change your decoder. Unfortunately, there are few other mpeg-2 decoders that can offer the features of Nvidia's. Personally, I both recommend and use re-encoding. MPEG-4 ASP, aka divx 6.22 with quantizer of 1.

Playback is about same CPU, because MPEG-4 decoders are much better optimized than most MPEG-2 ones. Size is about the same. If you have a slow CPU, use WMV2 via ffdshow vfw encoder.

I mux the mpeg-4 in native mode.