View Single Post
Old 2nd April 2016, 19:30   #215  |  Link
gpower2
gMKVExtractGUI author
 
gpower2's Avatar
 
Join Date: Aug 2003
Location: Greece / Thessaloniki
Posts: 251
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.

Last edited by gpower2; 2nd April 2016 at 19:32.
gpower2 is offline   Reply With Quote