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. |
27th March 2016, 12:01 | #201 | Link | ||
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
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:
Quote:
Quote:
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! |
||
27th March 2016, 17:57 | #203 | Link |
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. |
29th March 2016, 12:14 | #205 | Link | |
Registered User
Join Date: Mar 2013
Posts: 35
|
Quote:
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. |
|
2nd April 2016, 11:09 | #207 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
@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 v83.0 If I ever ask you to upload something, please use my file server. |
2nd April 2016, 11:21 | #208 | Link |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
@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"! |
2nd April 2016, 11:44 | #209 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
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 v83.0 If I ever ask you to upload something, please use my file server. |
2nd April 2016, 12:04 | #210 | Link |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
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" 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. |
2nd April 2016, 13:46 | #211 | Link | ||
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
Quote:
In the JSON output it looks like this: Code:
"codec_private_data": "014d4033ffe10017674d40339a7405016d808800000303e80000bb5478c19501000468ee3c80", "codec_private_length": 38, Quote:
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 v83.0 If I ever ask you to upload something, please use my file server. |
||
2nd April 2016, 15:36 | #212 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
2nd April 2016, 15:46 | #213 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
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 v83.0 If I ever ask you to upload something, please use my file server. |
2nd April 2016, 16:26 | #214 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 2nd April 2016 at 16:29. |
2nd April 2016, 19:30 | #215 | Link | |||
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
Quote:
I don't actually need the codec_private_data... Quote:
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:
I understand your decision for StaxRip, but it has a totally different purpose from gMKVExtractGUI. Last edited by gpower2; 2nd April 2016 at 19:32. |
|||
2nd April 2016, 19:57 | #216 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
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.
I see. That's probably not something I will make mkvmerge output.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
2nd April 2016, 20:47 | #218 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,281
|
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]; 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 That way you don't even need to execute mkvinfo.
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
2nd April 2016, 21:29 | #219 | Link |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
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! |
3rd April 2016, 09:47 | #220 | Link |
gMKVExtractGUI author
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
|
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 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! Last edited by gpower2; 3rd April 2016 at 10:10. |
Tags |
extractor, gmkvextractgui, matroska, mkv, mkv extract, mkvextract, mkvextractgui |
|
|