Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th March 2016, 13:01   #201  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
New version 1.7.0 is out, fixing the issue with the mkvinfo gui popup with the new MKVToolNix version v9.0.0, and adding an option for not showing the success popup messagebox.

Download link:
https://sourceforge.net/projects/gmk....0.7z/download

Changelog:
  • Add support for the new --no-gui parameter of mkvinfo for MKVToolNix v9.0.0 and newer, without breaking compatibility with older MKVToolnix versions
  • Add option to not show the success popup messagebox
  • Add setting for showing or not the success popup messagebox

Quote:
Originally Posted by Wildfire
It's not just that it's a pop-up (as a matter of fact, I get two pop-ups), it adds a huge delay to opening a file with gMKVExtractGUI. I have to wait a while for the first mkvinfo to do its work, then I close it, another mkvinfo window pop ups which then takes a while analysing my file...
This is an issue because of a change in MKVToolNix's v9.0.0 default behavior for mkvinfo. It's fixed in new version (v1.7.0)

Quote:
Originally Posted by Telion
Second this, needing to close a popup every time is becoming a bit irritating. It is a common GUI design guideline that informational messages should go into a status bar in an unobtrusive way. Only errors should invoke a modal dialog box to specifically attract user's attention to the fact that his intent was not accomplished and he must take some further actions.
I couldn't disagree more with this. In fact I get really frustrated when applications use this design, since most of the time I don't sit in front of the application's status bar, waiting for it to get to 100%, but I do other stuff, expecting a signal from the app that the process is finished.
However, since it wasn't difficult to implement, I added an option for changing the default behavior in the new version (v1.7.0), so I am waiting for feedback!


Enjoy people!
__________________
Gp2 says: Don't be a fool, just be cool :D !
gpower2 is offline   Reply With Quote
Old 27th March 2016, 17:25   #202  |  Link
alfixdvd
Registered User
 
Join Date: Mar 2004
Posts: 243
Thanks for the update.
alfixdvd is offline   Reply With Quote
Old 27th March 2016, 18:57   #203  |  Link
Telion
Registered User
 
Join Date: Sep 2011
Posts: 78
@gpower2

Big thanks for adding that option!

Can you please consider making another small UX enhancement and add a big "Close" button rightward of "Abort" one? Then after a job is done it would be convenient to move the mouse just a little from the previously pressed "Extract" button to exit the app without going all the way up to that small "X" or resorting to keyboard.

And maybe it would be also worth to allow a user to immediately paste a full filename into the "Input file" field and press Enter to load it without the need to open the "Browse..." dialog first.
Telion is offline   Reply With Quote
Old 28th March 2016, 01:35   #204  |  Link
Wildfire
Registered User
 
Join Date: Apr 2003
Location: the Netherlands
Posts: 156
Thanks for the update, all is okay again!
Wildfire is offline   Reply With Quote
Old 29th March 2016, 13:14   #205  |  Link
Solon8
Registered User
 
Join Date: Mar 2013
Posts: 35
Quote:
Originally Posted by gpower2 View Post
I couldn't disagree more with this. In fact I get really frustrated when applications use this design, since most of the time I don't sit in front of the application's status bar, waiting for it to get to 100%, but I do other stuff, expecting a signal from the app that the process is finished.
However, since it wasn't difficult to implement, I added an option for changing the default behavior in the new version (v1.7.0), so I am waiting for feedback!
Thank you for implementing this.

My only suggestion, but I'm not sure everyone agrees, would be to keep the sound signal. I was just lazy to click the popup, but I didn't mind the sound to tell me processing was over.
Solon8 is offline   Reply With Quote
Old 1st April 2016, 01:37   #206  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Great app, just wished I could reduce its height/width by quite a margin (current hardcoded minimum is too big imho).
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 2nd April 2016, 12:09   #207  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
@gpower2: Why are you invoking mkvinfo in the first place? mkvinfo is NOT designed to be the source of information for other programs. There are several reasons: for example it only reports elements that are actually present (e.g. mkvinfo might not show a "language" element for a track which means that the track's language is actually "eng"), nor does it show elements located after the first cluster by default (e.g. it won't show tags if they're located at the end) – unless you make its output verbose in which case it outputs everything from the file which takes a long time.

mkvmerge's identification output is actually what you should use instead, especially since I've implemented JSON output for it (mkvmerge --identification-format json --identify yourfile.mkv). Its output IS designed to be parsed by other applications, it will handle absent elements with default values properly (e.g. it will show "eng" as a track's language if the track does not actually contain a "language" element), and it will show all elements (tags, chapters, attachments…) no matter where they're located. In less time than mkvinfo's verbose output would.

On top of that I'm very careful not to change mkvmerge's behavior regarding the identification output. Such a change like mkvinfo's regarding the GUI wouldn't have affected gMKVExtractGUI if it had used mkvmerge instead.

So… what are you using mkvinfo for that mkvmerge doesn't give you? I'm really curious if there's something missing in mkvmerge's output that I could add for you.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 12:21   #208  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
@Mosu
I just replied in the GitHub issue! I guess great minds think alike!
gMKVExtractGUI uses mkvinfo's output in order to determine the relative delay between video and audio tracks. This information cannot be determined from mkvmerge's output. I also use mkvinfo's output to get the CodecPrivate value for each track segment.

To be honest, until recently, I hadn't noticed that you meticulously added the version information in the executables, so I wasn't sure I could robustly detect the version of MKVToolNix that the user uses. However, now that I know that, I can be more flexible about which options to use and when, so if you could add these extra information in mkvmerge's output, that would be perfect!

Thanks for showing interest in a MKVToolNix's "byproduct"!
__________________
Gp2 says: Don't be a fool, just be cool :D !
gpower2 is offline   Reply With Quote
Old 2nd April 2016, 12:44   #209  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
Thanks for the feedback. CodecPrivate is already included in mkvmerge's identification output, but the relative delay isn't.

That one's a bit tricky to implement, too. In general I don't want identification to be quick (it's already taking a long time due to all the different file types it supports). Scanning the file for the minimum timecode for each track is time consuming, and I definitely don't want to do it for each and every file as most people wouldn't need that information. I could introduce some kind of flags that enable deeper inspection of the file.

How do you handle e.g. subtitle tracks at the moment? Their first timestamp could be almost anywhere within the file.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 13:04   #210  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
Well, I guess when I was asked to include CodecPrivate, mkvmerge didn't output it, or I was lazy enough not to check for it!

As for the relative delay, it was indeed quite tricky to quickly determine it. I only try to find the relative delay for video and audio tracks, and not subtitle tracks, since this information isn't really useful to anyone.
In order to find it, I execute mkvinfo with --check-mode option, parsing its output line by line, trying to match this regex:
Code:
"track number {0}, \d frame\(s\), timecode (\d+\.\d+)s"
I then check if the delay (first timecode) is for a video track or for an audio track, assuming that there is only one video track for the file.
After I find the delays for all the tracks, I kill mkvinfo process, in
order to not waste time, and calculate the relative delay for the audio tracks.
Most of the times, video tracks have 0 delay, so the audio tracks' relative delay is the same as their first timecode. If video track has a delay greater than 0, then audio tracks' relative delay is calculated as track's delay minus the video track's delay.

I know it's way hacky, but it was the fastest and only way to get this information. If you have a better way of determining this, I'm all ears!

PS.
This procedure is executed immediately after getting mkvmerge's identify output, so I already have a list of the tracks and their types, in order to get the info I want from mkvinfo's output and then kill it immediately.
__________________
Gp2 says: Don't be a fool, just be cool :D !
gpower2 is offline   Reply With Quote
Old 2nd April 2016, 14:46   #211  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
Quote:
Originally Posted by gpower2 View Post
Well, I guess when I was asked to include CodecPrivate, mkvmerge didn't output it, or I was lazy enough not to check for it!
It was first included in version… uhm…

In the JSON output it looks like this:

Code:
        "codec_private_data": "014d4033ffe10017674d40339a7405016d808800000303e80000bb5478c19501000468ee3c80",
        "codec_private_length": 38,
The data itself is a hexdump. For tracks that don't have a CodecPrivate element these two elements aren't output.

Quote:
As for the relative delay…
I'm current implementing the following mechanism:

mkvmerge will always try to find the minimum timestamp for each track. It will process at most five seconds of data before giving up. If a timestamp is found for a track then it will be reported as "minimum_timestamp" (a number in nanoseconds) in the identification output. If no timestamp was found within the probing window (e.g. for subtitles that only start later) the element won't be present. The probing process will be aborteed as soon as five seconds of content have been observed (as stated above) or as soon as a timestamp has been found for every track, whichever happens first.

The timestamp reported will not necessarily be the first one for a track. For example, a video track may start with a B frame with a higher timestamp than the I frame coming shortly after it. mkvmerge will really report the minimum of what it finds.

Would that be useful to you? If so I can provide new pre-builds for testing soon.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 16:36   #212  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,873
Note from another mkvtoolnix GUI programmer : In StaxRip I had a huge messy function growing over the years parsing mkvinfo output, 1-2 years ago I rewrote it using MediaInfo for audio and video replacing the messy function with clean OOP and added a demuxing GUI for mkv and mp4. For chapters and attachments I still use the old mkvinfo output parsing.
stax76 is offline   Reply With Quote
Old 2nd April 2016, 16:46   #213  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
Note that I make no guarantees whatsoever that the track IDs mkvmerge requires will match the ones that MediaInfo outputs. I only guarantee that the IDs that mkvmerge's identification outputs are the ones you need to use with mkvmerge and mkvextract. Only mkvmerge knows which tracks it supports; MediaInfo can only guess and may get it wrong. It usually doesn't, but that's no guarantee. You've been warned.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 17:26   #214  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,873
For a GUI that supports all kinds of formats and tools MediaInfo is a blessing, anything else in this situation would be a mess. One thing tricky I noticed and worked around is that MediaInfo works with 'TrueHD/AC3' as single stream ID and mkvmerge splits it into two. I just hope my code works and if it don't, hope that people report issues and fixes won't introduce new issues.

Last edited by stax76; 2nd April 2016 at 17:29.
stax76 is offline   Reply With Quote
Old 2nd April 2016, 20:30   #215  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
Quote:
Originally Posted by Mosu View Post
It was first included in version… uhm…

In the JSON output it looks like this:

Code:
        "codec_private_data": "014d4033ffe10017674d40339a7405016d808800000303e80000bb5478c19501000468ee3c80",
        "codec_private_length": 38,
The data itself is a hexdump. For tracks that don't have a CodecPrivate element these two elements aren't output.
Actually the CodecPrivate that I use from mkvinfo is like this: "length 45 (h.264 profile: High @L4.1)".
I don't actually need the codec_private_data...

Quote:
Originally Posted by Mosu View Post
I'm current implementing the following mechanism:

mkvmerge will always try to find the minimum timestamp for each track. It will process at most five seconds of data before giving up. If a timestamp is found for a track then it will be reported as "minimum_timestamp" (a number in nanoseconds) in the identification output. If no timestamp was found within the probing window (e.g. for subtitles that only start later) the element won't be present. The probing process will be aborteed as soon as five seconds of content have been observed (as stated above) or as soon as a timestamp has been found for every track, whichever happens first.

The timestamp reported will not necessarily be the first one for a track. For example, a video track may start with a B frame with a higher timestamp than the I frame coming shortly after it. mkvmerge will really report the minimum of what it finds.

Would that be useful to you? If so I can provide new pre-builds for testing soon.
That actually sounds... perfect!
Perhaps you could only do this for video and audio tracks, since I can't think of a case where other track types would benefit from such information.
From my experience, it shouldn't take too long.
Actually, the procedure that I described you is almost instant, and it executes both mkvmerge and mkvinfo!

Thanks for your continuous support!

Quote:
Originally Posted by stax76
Note from another mkvtoolnix GUI programmer : In StaxRip I had a huge messy function growing over the years parsing mkvinfo output, 1-2 years ago I rewrote it using MediaInfo for audio and video replacing the messy function with clean OOP and added a demuxing GUI for mkv and mp4. For chapters and attachments I still use the old mkvinfo output parsing.
gMKVExtractGUI is supposed to be a complimentary application to MKVToolNix, with it and .NET framework as the only dependencies. Using MediaInfo would break this and also make it a lot more difficult to maintain, having to keep track of both MKVToolNix and MediaInfo versions.
I understand your decision for StaxRip, but it has a totally different purpose from gMKVExtractGUI.
__________________
Gp2 says: Don't be a fool, just be cool :D !

Last edited by gpower2; 2nd April 2016 at 20:32.
gpower2 is offline   Reply With Quote
Old 2nd April 2016, 20:57   #216  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
I've just uploaded new pre-builds that contain the change for "minimum_timestamp". I've decided on a 10 second search window which should pretty much always catch all audio and video tracks. Build numbers 01175 and higher contain the functionality.

Quote:
Originally Posted by gpower2 View Post
Actually the CodecPrivate that I use from mkvinfo is like this: "length 45 (h.264 profile: High @L4.1)".
I see. That's probably not something I will make mkvmerge output.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 21:31   #217  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
Thanks for the new pre-builds!
I will test it and come back with feedback ASAP!
__________________
Gp2 says: Don't be a fool, just be cool :D !
gpower2 is offline   Reply With Quote
Old 2nd April 2016, 21:47   #218  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 3,815
About the CodecPrivate thingy. mkvinfo outputs profile information for two codecs: AVC/h.265 and HEVC/h.265. Those can be easily gathered yourself by parsing the "codec_private" attributes mkvmerge outputs. Here's how.

AVC/h.264: trivial. Connvert the first four pair of hex numbers to four bytes. Then you get the following variables:

Code:
// bytes[0] is always 1 and can be ignored.
profile_idc    = bytes[1];
profile_compat = bytes[2];
level_idc      = bytes[3];
Then you can determine the profile and level strings like mkvinfo does.

For HEVC/h.265 is a bit more complicated, but not by much. Convert the codec private hex numbers to bytes. Then you'll need some specific bits. I'll write some pseudo code; see here for the code mkvinfo uses:

Code:
// Start reading at the start of the codec private bytes.
skip 8 bits (version number)
skip 2 bits (profile space)
skip 1 bit (tier flag)
profile_idc = read 5 bits
skip 32 bits (profile compatibility flags)
skip 1 bit (progressive source flag)
skip 1 bit (interlace source flag)
skip 1 bit (nonpacked constraint flag)
skip 1 bit (frame only constraint flag)
skip 44 bits (reserved)
level_idc = read 8 bits
And here's how those numbers translate into the profile strings.

That way you don't even need to execute mkvinfo.
__________________
Latest MKVToolNix is v41.0.0

If I ever ask you to upload something, please use my file server.
Mosu is online now   Reply With Quote
Old 2nd April 2016, 22:29   #219  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
That's amazing!
I didn't know that mkvinfo just parsed the codec private data and then presented it in a user friendly way!

It seems to me that now mkvmerge provides me with all the necessary information!

I will give it a try first thing in the morning!

Thanks again Mosu!
__________________
Gp2 says: Don't be a fool, just be cool :D !
gpower2 is offline   Reply With Quote
Old 3rd April 2016, 10:47   #220  |  Link
gpower2
Yet another Doom9 member
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 199
After testing pre build 01176, I have to say that the minimum timestamp works as expected!

However, I forgot that I also used mkvinfo to get some general info about the file:

Code:
Writing Application: mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar  2 2014 21:34:26
Muxing Application: libebml v1.3.0 + libmatroska v1.4.1
Duration: 5979.008s (01:39:39.008)
Date: Sat Apr 12 17:44:19 2014 UTC
Is there any chance those information could also be added to the output of mkvmerge?

Thanks again!

PS.

Actually, I checked again and mkvmerge already provides most of the information, except the Date field, so if you could add it, that would be all I need!
__________________
Gp2 says: Don't be a fool, just be cool :D !

Last edited by gpower2; 3rd April 2016 at 11:10.
gpower2 is offline   Reply With Quote
Reply

Tags
extractor, gmkvextractgui, matroska, mkv, mkv extract, mkvextract, mkvextractgui

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.