Log in

View Full Version : mkvtoolnix 4.1.1 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33

MuLTiTaSK
10th January 2010, 19:01
@stax76 & Mosu

:eek: i was wondering why it had a icon very cool function i did not know about i have to read the docs more carefully :thanks:
http://img532.imageshack.us/img532/7736/ss20100110125227.png

Mosu
10th January 2010, 19:16
@Mosu

I noticed there is a GUI for mkvinfo, besides mmg are there other GUIs included?

No. mmg & mkvinfo's GUI are the only ones.

Maybe you could add mkvinfo showing a file extension for each stream so applications don't need to maintain a dictionary, I'm not sure if my dictionary is up-to-date and bug free, where do I find which formats are currently supported by mkvextract?

mkvextract does not care about file extensions (neither does mkvmerge, btw, safe for a few exceptions -- VobSubs (the ".sub" for the ".idx") WavPack (the ".wvc" for the ".wv") etc.

There's no concise list of supported CodecIDs, but there's always the source code at e.g. http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/extract/xtr_base.cpp :

// Audio formats
else if (new_codec_id == MKV_A_AC3)
return new xtr_base_c(new_codec_id, new_tid, tspec, "Dolby Digital (AC3)");
else if (new_codec_id == MKV_A_EAC3)
return new xtr_base_c(new_codec_id, new_tid, tspec, "Dolby Digital Plus (EAC3)");
...

etc etc. The MKV_A_XYZ definitions are found in http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=blob;f=src/common/matroska.h

The xtr_xyz_c class determines the file type written. "xtr_base_c" means just the raw file, all the others use some kind of container format.

dic("A_FLAC") = "flac"

FLAC can also be written into OggFlac files (though no one does that, I guess).

dic("A_QUICKTIME") = "qdm"

Extraction of A_QUICKTIME and A_QUICKTIME/* tracks is not supported.

dic("A_REAL") = "ra"

".ra" is usually used for older RealAudio type containers. mkvextract writes "Real Media File Format" containers both for audio and video tracks (and both can be put into the same file, like multiple VobSub tracks can be extracted into the same .idx file). ".rm" is usually used for these containers.

dic("V_REAL") = "rmvb"

Same as above -- I guess that ".rm" is more common than ".rmvb", but I'm hardly the expert on Real files.

The rest looks ok, but I haven't checked whether or not you're missing CodecIDs.

Mosu
10th January 2010, 19:18
i was wondering why it had a icon very cool function i did not know about i have to read the docs more carefully :thanks:

And you didn't simply try clicking said icon? :) I guess I'm more curious than you are ;)

stax76
10th January 2010, 19:45
@Mosu

Thanks for the info, your support is fantastic.

@MuLTiTaSK

All GUI's packaged with StaxRip I know about can be launched under Tools > Launch, I've added mkvinfo GUI. Since MeGUI's loosely coupled toolbox approach of doing a GUI has advantages I'm adding better support to perform individual tasks manually, automation is good but sometimes a task needs to be performed manually. I've added Tools > Advanced > Demuxing > Demux a mkv file using mkvextract and I will add as many manual tasks as I can.

sneaker_ger
11th January 2010, 06:58
I have 2 feature requests:

1.) a command line viewer in the header editor gui
2.) an option to extract all streams and/or all attachments of a file without having to write huuge command lines every time if you simply want to demux everything and don't need any custom filenames

Mosu
11th January 2010, 09:06
I have 2 feature requests:

1.) a command line viewer in the header editor gui

Sorry, I will not implement this. Reason is that the header editor GUI does not call mkvpropedit for doing the work but actually writes to the file itself.

2.) an option to extract all streams and/or all attachments of a file without having to write huuge command lines every time if you simply want to demux everything and don't need any custom filenames

This may be implemented in the future.

MatLz
11th January 2010, 15:10
Hi Mosu!

Instead of splitting only at times, Will be possible to add a feature for splitting at frames?(of course at keyframes) By specifiing the frames....'100,4500,8864...' or by reading a X264 .qp file ?

Mosu
11th January 2010, 16:25
Probably not.

MatLz
11th January 2010, 16:33
Probably not.

What a probably pity...

Thx for your quick answer.

sneaker_ger
11th January 2010, 19:57
Sorry, I will not implement this. Reason is that the header editor GUI does not call mkvpropedit for doing the work but actually writes to the file itself.

I see. The reason I'm asking is that I actually couldn't find any complete documentation on how to use it. This one (http://darkflame.tenet.odessa.ua/cgi-bin/man/man2html?1+mkvpropedit) explains the basic usage but I have no idea how the flags etc. are named so I end up being unable to set them.


This may be implemented in the future.

That would be a huge time and hassle saver. Thank you for considering it.

stax76
11th January 2010, 23:10
@sneaker_ger

The latest StaxRip test built makes mkv demuxing easy, you would choose:

Tools > Advanced > Demuxing > Demux a mkv file using mkvextract

It will show a file browser where you choose a mkv file and it will show a folder browser where you choose a target directory, it'll demux all streams in the mkv file to the target directory. If you are interested you can find the test built here:

http://forum.doom9.org/showthread.php?p=1362809#post1362809

sneaker_ger
11th January 2010, 23:23
Thank you, but it only shows "Command prompt" for me under "Advanced". (And I'd like to use the CLI anyways...)

stax76
11th January 2010, 23:33
Do you have version 1141? If so then I forgot to reset the main menu, you can do this in three different ways, do you know one of them? I can't help with the command shell unless somebody built a console app with my code, 100 lines simple VB.NET code, should take less an hour to port.

sneaker_ger
11th January 2010, 23:37
I'll answer in the StaxRip thread to keep it on topic.

Snowknight26
12th January 2010, 03:45
Any chance of optimizing network muxing? Remuxing an from and to an mkv over a gigabit network takes ~2 minutes where as when running the same job locally took 9 seconds for ~2.5GB of total throughput.

millerci
20th January 2010, 14:28
Cropping Mkv.

With head editor i choose Video Track 1/Video Crop top and enter the value. 140 pixel for black bars. Video Crop bottom 140 pixel too. Save it. Then i returned to mkvmergegui and opened the movie inside the input section. Make the mux. Nothing happens. So after a long search and many tries i gave up.

Tried another solution for Crop the mkv. again in mkvtoolnix.

With Muxing -> Add command line options i entered this code --cropping <TID:left,top,right,bottom>. But i don't know any further operation. Which area i will give the cropping value? How do i write it? (Example 140 pixel fro top,140 pixel for bottom crop) Then How do i add this operation to Add to Job Queue? Or what is the right solution for this?

I want to crop my mkv movie without remux without encode again. Please somebody help me or show me a link how i can do it right.
:/

Mosu
20th January 2010, 14:39
I see. The reason I'm asking is that I actually couldn't find any complete documentation on how to use it. This one (http://darkflame.tenet.odessa.ua/cgi-bin/man/man2html?1+mkvpropedit) explains the basic usage

Just a note: the current documentation for all mkv* command line tools is always available at http://www.bunkus.org/videotools/mkvtoolnix/docs.html but I didn't include mkvpropedit's man page. Thanks for pointing this out (even indirectly ;) ). I've added it now: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html

but I have no idea how the flags etc. are named so I end up being unable to set them.

That's what mkvpropedit's --list-property-names option is for.

Mosu
20th January 2010, 14:40
Any chance of optimizing network muxing? Remuxing an from and to an mkv over a gigabit network takes ~2 minutes where as when running the same job locally took 9 seconds for ~2.5GB of total throughput.

No, sorry.

Mosu
20th January 2010, 14:49
With head editor i choose Video Track 1/Video Crop top and enter the value. 140 pixel for black bars. Video Crop bottom 140 pixel too. Save it. Then i returned to mkvmergegui and opened the movie inside the input section. Make the mux. Nothing happens. So after a long search and many tries i gave up.

My guess is that you actually mean "playback of the muxed file has not changed at all, no cropping is in effect" when you write "Nothing happens". In that case this is most likely a problem or missing feature in the playback software (demuxer, splitter, player). Cropping parameters are not widely supported by players.

Note that mkvmerge ONLY sets header values for cropping -- it does not alter the video stream at all. It is not an encoding application.

Mosu
20th January 2010, 14:52
Hey,

I've released mkvtoolnix v3.1.0. This release contains contains the usual mix of bug fixes and smaller enhancements.

Notes for folks building from source:

1. Library dependency changes: Boost v1.34.0 or later is now required. Boost's filesystem library is required as well (for those distributions that split the Boost development packages).

2. The man pages & mmg's guide have been translated to other languages, and the file layout in /usr/share/mkvtoolnix has been changed accordingly. I suggest you take a look at what a normal 'configure && make && make install' does and adjust the build scripts afterwards.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-3.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-3.1.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-3.1.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.1.0:

------------------------------------------------------------
2010-01-18 Moritz Bunkus <moritz@bunkus.org>
* Released v3.1.0.

2010-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If the first input file was a Quicktime/MP4 file and all tracks from that file were deselected for muxing then mkvmerge would crash. Fix for bug 458.

2010-01-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The option 'AAC is SBR/HE-AAC' was not honored for appended AAC tracks. This could lead to mkvmerge aborting with an error that the track parameters did not match if it itself could not detect HE-AAC in the second file.

2010-01-06 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Chinese Simplified translation for mmg's guide by Dean Lee (see AUTHORS).

2010-01-05 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Japanese translation for the man pages by Katsuhiko Nishimra (see AUTHORS).

2010-01-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The output file name is checked for invalid characters before the muxing process is started. Fix for bug 455.
* mkvpropedit, mmg: bug fix: Files with an infinite segment size are handled correctly now. Fix for bug 438.
* mkvmerge: bug fix: Matroska files which have its 'tracks' element located behind the clusters are read correctly now.
* mmg: enhancement: After muxing the "abort" button is changed to "open folder" which opens the explorer on the output file's folder. This only happens on Windows.

2010-01-02 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: When constructing the output file name mmg will only suggest names that don't exist already by appending a number to the file name (e.g. resulting in "/path/file (1).mkv").

2009-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading chapters from MP4 files that are stored in tracks with subtype 'text'. Such files are used e.g. on iPods/iPhones and can be created by HandBrake. Fix for bug 454.

2009-12-29 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The "tags" input box on the "general track options" tab was not updated when a track was selected. Fix for bug 453.

2009-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: If a MPEG-2 program stream file is added to mkvmerge whose base name ends in a number then mkvmerge will automatically read and process all other files in the same directory with the same base name, same extension and different numbers. Those files are treated as if they were a single big file. This applies e.g. to VOB files from DVD images that are named VTS_01_1.VOB, VTS_01_2.VOB, VTS_01_3.VOB etc. mmg will output an error message if the user tries to add or append one of the other files that mkvmerge will process automatically (e.g. if the user has added VTS_01_1.VOB already and tries to append VTS_01_2.VOB).

This also fixes bug 437.
* Build requirements changed: mkvtoolnix requires Boost v1.34.0 or later. It requires the Boost::Filesystem library (with all Boost versions) and the Boost::System libraries (starting with Boost v1.35.0).

2009-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: SRT files with negative timecodes will are not rejected anymore. Negative timecodes will be adjusted to start at 00:00:00.000.

2009-12-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: Added support for extracting Blu-Ray subtitles (CodecID "S_HDMV/PGS").

2009-12-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge/mmg: enhancement: Added an option '--segment-uid' for specifying the segment UIDs to use instead of having to use a XML file and '--segmentinfo'.
* Installer: The installer will no longer offer to run mmg after it has been installed. On Windows setups where a normal user account doesn't have administrator privileges this caused mmg to be run as the user "Administrator" instead of the normal user account causing confusion and some things not to work, e.g. drag & drop.

2009-12-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Zero-length frames in Theora bitstreams as created by libtheora v1.1 and later were dropped. Fix for bug 450.

2009-12-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: On Windows 2000/XP the 'add/append file' dialog was not showing files with certain extensions (e.g. ".srt" or ".mp4") if the option "all supported media files" was selected. Fix for bug 448.
------------------------------------------------------------

Have fun.

millerci
20th January 2010, 15:00
My guess is that you actually mean "playback of the muxed file has not changed at all, no cropping is in effect" when you write "Nothing happens". In that case this is most likely a problem or missing feature in the playback software (demuxer, splitter, player). Cropping parameters are not widely supported by players.

Note that mkvmerge ONLY sets header values for cropping -- it does not alter the video stream at all. It is not an encoding application.

You are right "no cropping is in effect".


hmm if i want a crop than i must do an encode. so how can i know the exact encode parameters that is used for the movie? If i knew it than i can put the right values so the movie won't lose its quality.

by the way mkvtoolnix is a great program. thank you for doing a great job like this. :) i just wish that a video tutorial includes tips for this good program will be most welcome.

stax76
20th January 2010, 15:43
I had also problems with the crop feature, I had a WMV that needed to be cropped, mkvmerge did not allow me to import wmv so I used Haali's DS muxer. The resulting mkv file played fine. Then I opened this file with mmg, entered the cropping, remuxed it. It would play jerky then and no matter what player I tried the crop didn't work. I ended up to reencode which didn't hurt much anyway.

sneaker_ger
20th January 2010, 17:40
Just a note: the current documentation for all mkv* command line tools is always available at http://www.bunkus.org/videotools/mkvtoolnix/docs.html but I didn't include mkvpropedit's man page. Thanks for pointing this out (even indirectly ;) ). I've added it now: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html



That's what mkvpropedit's --list-property-names option is for.

Thank you. I tried it again and it worked this time. The reason why I couldn't get it to work was because I tried your example in the help file:
The command line 'mkvpropedit source.mkv --edit track:a2 --set title=Comments' could be converted into the following option file:

It doesn't work because you cannot set "title" for a single track.

I had also problems with the crop feature, I had a WMV that needed to be cropped, mkvmerge did not allow me to import wmv so I used Haali's DS muxer. The resulting mkv file played fine. Then I opened this file with mmg, entered the cropping, remuxed it. It would play jerky then and no matter what player I tried the crop didn't work. I ended up to reencode which didn't hurt much anyway.

How about filing a bug report and uploading the sample? (Even if you ended up re-encoding)

Mosu
20th January 2010, 17:58
Thank you. I tried it again and it worked this time. The reason why I couldn't get it to work was because I tried your example in the help file:
...
It doesn't work because you cannot set "title" for a single track.

Dang. That's what happens when I write documentation but don't actually test it :) Exchanging "title" with "name" is probably what I'll do.

MuLTiTaSK
21st January 2010, 05:18
2010-01-20 Moritz Bunkus <moritz@bunkus.org>

* mmg: new feature: Added a control for mkvmerge's "--cropping"
parameter.

* mmg: enhancement: Added the file extensions ".dtshd", ".dts-hd",
".truehd" and ".true-hd" to mmg's"'add/append file" dialogs.

* mkvextract: bug fix: "mkvextract --version" was only writing an
empty string. Fix for bug 463.

top notch support like always Mosu :thanks:

Mosu
21st January 2010, 09:49
2010-01-20 Moritz Bunkus <moritz@bunkus.org>

* mmg: new feature: Added a control for mkvmerge's "--cropping"
parameter.

* mmg: enhancement: Added the file extensions ".dtshd", ".dts-hd",
".truehd" and ".true-hd" to mmg's"'add/append file" dialogs.

* mkvextract: bug fix: "mkvextract --version" was only writing an
empty string. Fix for bug 463.

top notch support like always Mosu :thanks:

Btw, there's also a pre-build including these fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100120-208-setup.exe

Maccara
21st January 2010, 13:42
Btw, there's also a pre-build including these fixes: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100120-208-setup.exe

This has the path problem again (happily overwrote the whole existing path settings, claiming it was "empty").

...I wonder why NSIS (or whoever's the installer was - didn't look :)) can't get this right...

Mosu
21st January 2010, 14:04
This has the path problem again (happily overwrote the whole existing path settings, claiming it was "empty").

? I don't quite understand what you mean. Care to elaborate?

Maccara
21st January 2010, 15:20
? I don't quite understand what you mean. Care to elaborate?

This is an old bug you've fixed once already: https://www.bunkus.org/bugzilla/show_bug.cgi?id=365

I know this is not your fault, but if you could check in case you updated NSIS and re-introduced this bug.

Mosu
21st January 2010, 17:28
Oh THAT problem. You guessed right. I've re-built NSIS again with 32k string size. Here's an updated installer: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100121-209-setup.exe

Atak_Snajpera
21st January 2010, 22:48
Will you add support in mkvextract for A_MS/ACM audio?
http://www.crist.com/Temp/pirates2_sample.mkv_0

Maccara
22nd January 2010, 06:25
Oh THAT problem. You guessed right. I've re-built NSIS again with 32k string size. Here's an updated installer

Thank you very much!

Didn't test it yet, but no reason to think it isn't working now (old known issue from 3 rd party component with a known solution ;)).

A bit annoying issue, though. Luckily I was feeling "unsecure" as I hadn't updated mkvtoolnix for a long time, so I had just backed up the registry keys involved in anticipation. ;)

Mosu
22nd January 2010, 08:44
Will you add support in mkvextract for A_MS/ACM audio?

No, sorry.

Snowknight26
22nd January 2010, 16:57
The tooltips for Language, Charset and Cue name format under Chapters, Segment UID's under File/segment linking and max. number of files under Splitting don't have any line breaks in it making them get cut off on everything but very high resolution desktops.

Mosu
22nd January 2010, 17:22
Tooltips suck on Windows (from a programmer's point of view). Maybe it's only wxWidget's tooltip implementation, I'm not sure.

I'll fix this, though.

fingershop
26th January 2010, 03:39
Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

The way it is now, each queued file must be configured one at a time, for enabled and disabled tracks, and their attributes, like language, default flags, framerates, aspect, etc.

Here's the idea: After configuring and adding the first file to the job queue, mmg would be able to automatically re-use that configuration for all other files added to the job queue. Of course this assumes that all files added will have the same or similarly structured files. This might also assume, when adding in streams, that a certain file naming method is used, so that those stream files could automatically be included.

Near the existing Add button, perhaps there could be a "Batch Add" button or similar, which would add the next file (or an entire folder of files?) to the job queue, automatically applying the same settings to each one it finds.

This would be a huge time saver, and would also keep you from making forgetful mistakes when creating batch jobs.

Chumbo
26th January 2010, 03:56
Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

The way it is now, each queued file must be configured one at a time, for enabled and disabled tracks, and their attributes, like language, default flags, framerates, aspect, etc.

Here's the idea: After configuring and adding the first file to the job queue, mmg would be able to automatically re-use that configuration for all other files added to the job queue. Of course this assumes that all files added will have the same or similarly structured files. This might also assume, when adding in streams, that a certain file naming method is used, so that those stream files could automatically be included.

Near the existing Add button, perhaps there could be a "Batch Add" button or similar, which would add the next file (or an entire folder of files?) to the job queue, automatically applying the same settings to each one it finds.

This would be a huge time saver, and would also keep you from making forgetful mistakes when creating batch jobs.
I do this all the time with a DOS batch/command file. Just copy the command line to the clipboard from the UI, paste it into a command file and use the dos-based for command to process each file by feeding it to the for loop.

Below is an example of a batch file I used just today to mux a bunch of episodes from elementry streams to MKV.
for /f "delims=" %%i in ('dir /b "*.h264"') do "d:\Program Files\MKVtoolnix\mkvmerge.exe" -o "d:\\media\\tv\\%%~ni.mkv" "--forced-track" "0:no" "--default-duration" "0:24000/1001fps" "-d" "0" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "%%i" "--language" "0:eng" "--forced-track" "0:no" "-a" "0" "-D" "-S" "-T" "--no-global-tags" "--no-chapters" "%%~ni.ac3" "--track-order" "0:0,1:0"

fingershop
26th January 2010, 04:52
Thanks Chumbo, I do use this method already, but its also cumbersome having to create and edit dos batch files each time I want to mux a bunch of files. The idea of simplicity for me is to keep all the configurations happening in the gui, without having to go back and forth to command prompts or such all the time. I appreciate being hands-on, but computers can handle this type of automation so much quicker and easier than doing it manually.

Oh, and you kinda emphasized my point :-)
If the gui made it easier to do this then you wouldn't need to use batch files instead.

Mosu
26th January 2010, 08:42
Hi, I frequently need to remux batches of similarly structured files, in which I'm adding and removing streams, and setting track attributes, all the same way for each file. Adding all these similar files to the job queue is very tedious and error prone, and I had an idea for simplifying this process, a kind of "quick batch" mode.

No, sorry. I've answered as to why I won't implement such a thing a couple of times before. The run-down is that in order to make such a thing really useful to a lot of people (instead of only a handfew or even only one: you) it would have to be really, really powerful requiring really, really a lot of work. I don't have that kind of time, nor do I have the motivation to do that as there are several scripting languages (shells like bash, zsh, maybe even the Windows Power Shell; scripting languages like Python, Ruby, Perl, Lua) available on all platforms for power users like yourself that are way more flexible and not that hard to learn.

fangorn
26th January 2010, 10:25
I, for instance, created a bash script using mkvmerge and many others to mux many input containers to MKV, MP4, TS, M2TS. (see avi2mkv from my Sig.)

It is much more convenient (in my eyes at least) than having to load hundreds of files in a oh so powerfull batch processor. (I designed it originally to transfer and markup multiple language TV show episodes in AVI containers to MKV, hence the name.)

It should be runnable in Cygwin under Windows, but I did not try to set it up. The dependencies are named in the script though, if someone wants to try getting it to run. I could even host a package adding all necessary programs to make it run under Cygwin standard installation if somebody would step up and mad it work. As I don't use Windows I am slightly handicaped in this matter. ;-)

Snowknight26
27th January 2010, 17:44
Any chance of having invalid paths be the first step in muxing? Even before, say, FLAC parsing?

fingershop
28th January 2010, 03:02
I'd like to rephrase my request... :-)

After you've configured a file for muxing, it would be handy if mmg would allow you to "replace" that file by choosing another one, while maintaining all configured settings.

Normally, you would click on the file in the Input files list, click the remove button, then click the add button to add another one and configure it.

Instead, you would click on the file in the Input files list, click the "replace" button, and (after manually choosing the replacement file) that's it, this file would be ready for muxing (or queuing) with no re-configuration needed.

I agree that a full automation method would take lots of work to implement. This simpler idea would, I'm guessing, take a much smaller amount work. Functionally, it might be as simple as verifying the replacement file's structure, and changing the file name variables (input and output) that will be used for muxing.

Yes, scripting languages are powerful, but none of them particularly let you choose streams and attributes from a gui, which is the key thing for ease of use.

Mosu
28th January 2010, 09:15
Any chance of having invalid paths be the first step in muxing? Even before, say, FLAC parsing?

If you want mkvmerge to check if all files named on the command line exist before actually opening and analyzing them then my answer is "no". This would mean quite a lot of changes to the very core of mkvmerge, one area I try to change as little as possible.

However, I can and will get rid of the 'pre-parsing' stage in FLAC's reader soon. It is not necessary if I get rid of the libFLAC dependency at the same time and implement my own FLAC file format parser which is easy enough to do -- mkvmerge only needs to know a few basic parameters about each FLAC frame; the data doesn't have to be decoded.

Mosu
28th January 2010, 09:17
I'd like to rephrase my request... :-)

After you've configured a file for muxing, it would be handy if mmg would allow you to "replace" that file by choosing another one, while maintaining all configured settings.

I won't implement that either, sorry. I'm not against having such a feature in the first place (so if someone would implement it and provide a patch I'd accept it gladly). I just reserve the right to spend my time on other things :)

Audionut
29th January 2010, 12:48
Any chance of supporting .ts

I've got a ton i'd like to transfer to .mkv.

Mosu
29th January 2010, 13:24
Not in the near future.

Snowknight26
31st January 2010, 07:41
Is it normal for the form components to be in different locations after muxing? I don't recall this prior to 3.1.0.

http://i45.tinypic.com/x0wu1x_th.jpg (http://i45.tinypic.com/x0wu1x.jpg)

http://i49.tinypic.com/1sz61g_th.jpg (http://i49.tinypic.com/1sz61g.jpg)

Mosu
31st January 2010, 16:13
Is it normal for the form components to be in different locations after muxing? I don't recall this prior to 3.1.0.

Hmm. It's possible that a carriage return has been added to the end of the "everything went fine" sentence by accident. It's not intentional, no. Maybe it also has something to do with the change to the 'Cancel' button's label to 'Open Folder'. I'll look into it one of these days.

Mosu
1st February 2010, 09:14
Hmm. It's possible that a carriage return has been added to the end of the "everything went fine" sentence by accident.

That carriage return has been present for ever. However, it has only been causing a re-layout of the dialog after the feature to change the 'cancel' button to 'open folder' had been added recently.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.1.0-build20100131-212-setup.exe

whatever-ever
2nd February 2010, 08:29
Ok here goes...

I've tried for 5 days to compile mkvtoolnix (or any part thereof) for windows. I compiled it with no hassle on my ubuntu pc, but for some reason i'm having a lot of trouble compiling with either mingw or cygwin.

All libraries have been compiled under mingw (./configure --prefix=/mingw), except boost, which i'm not sure i've "installed" properly. took a bit of copying and pasting files from here and there to /lib before i could finally get mingw to recognize that i have boost. but it get erros like this (currently only this one):
checking for boostlib >= 1.29.0... yes
checking whether the Boost::Regex library is available... yes
configure: error: Could not link against the Boost regex library !
First off, yes that is not the configure file for 3.10, i pasted the above from when i tried to compile 2.5.3 instead. The error is similar for 3.10 (although it's Boost::Filesystem it checks for first, and gives same output as above).

So it's probably my boost library that is foobar-- however, it always reports that the boost libraries exist, so maybe it's something about setting variables that my mingw has trouble with?

if test "x$as_val" = x""yes; then :
BOOST_FILESYSTEM_LIB="-l$ax_lib"; link_filesystem="yes"; break
else
link_filesystem="no"
fi

done

fi
if test "x$link_filesystem" != "xyes"; then
as_fn_error "Could not link against $ax_lib !" "$LINENO" 5

I've checked that this is where it reports the "could not link", and as you can see, ax_lib is not set for some reason, but link_filesystem both is and isn't set to yes?

Sorry if this is an obvious question, but for the life of me I cannot figure out how to fix this.

PS: "have you tried building boost?", yes, however not with any luck. i tried so by running bootstrap.sh etc., but it doesn't go so well, http://pastebin.com/f761baf28 (forever paste).

Currently using gcc 3.4.5 (mingw-vista special r3) and boost 1.41.0. Have also tried with 4.4.1 (which is the same as my ubuntu pc uses). iconv (GNU libiconv 1.13) here, but iconv (EGLIBC) 2.10.1 on the ubuntu pc.

Any hint that can help even the tiniest bit is greatly appreciated!