Support forum for DG Tools

[Received in PM so posted here for proper tracking.]

Can you please check this mkv? DGIndexNV 211 cannot open it or index it.

http://rationalqm.us/misc/test.mkv

Originally it was recorded .ts, cutted in Videoredo 6 and saved as "untouched" mkv.

FFMS2 works just fine with this file.

I hope you figure it out, thanks!

Investigating...

Time to upgrade the ancient MKV support code?

You could be right. Are you busy?

According to MediaInfo the MKV is format version 4
A recent remux of mine with MKVToolNix (46) is version 2

Remuxed test.mkv with MkvToolNix 46 and DGIndexNV can now open it
So I remuxed it with MKVToolNix 48 and DGIndexNV opens it fine
Version is still 2, DGIndexNV is 210

Thank you, gonca. I knew that remuxing "fixed" it, but hadn't figured out why. Now we know. I will see if I can add support for version 4.

The old parser wasn't properly ignoring the version 4 cue elements. I made a hack that appears reasonable and allows test.mkv to play while not breaking version 2 files. I call it a hack because I don't fully understand the EBML parser in that ancient code; should spend some time figuring out how it works. I would really appreciate getting some other version 4 samples to test this properly. If y'all have any please cough 'em up. Ta.

Fixed in slipstream 212. Marking RESOLVED.

Thanks for the fix!

BUT with new version 212b I noticed very long initialization/opening of avs script, it's like 12s+ freezing. It is visible even in seeking, when you doing like 30min jumps or you jump straight to the end. I saw it in latest AvsPmod, VDub or x264/x265.

I'm not seeing that with the test.mkv file you gave us, or with a longer version 4 file I found online. Did you update both DGIndexNV.exe and DGDecodeNV.dll? If so, can you provide a sample that exhibits this behavior and your script? Thank you.

Looks like it happens only with longer/bigger mkvs (not with short/small ones) made by VRD6 or MKVMerge 48. Old mkvs (v2) open immediately.

So do you have bigger mkv? Try remux it with new mkvmerge, open it with DGIndexNV and you'll see, hopefuly...

Link to mkvmerge 48 please? I have mkvtoolnix 21.0.0. How big is big enough? Can I simply mux some streams from a bluray, i.e., the source doesn't have to be an MKV?

Hi.

I can confirm the same thing.

Link to latest mkvtoolnix is: https://mkvtoolnix.download/downloads.html#windows

The mkv file I have tested with has been made by mkvmerge v40, and mediainfo shows it as a mkv version 4 file.
The file is around 8GB in size.

With the most recent 212 it takes a while for the file to load. Making small jump at the start of the movie is almost instant, but the closer
you get to the end of the file, the longer it takes. Even small jumps at the end of the file takes more than 20 seconds. It is as if it has to parse the entire file each time a jump is made or something. Hence the jumps are almost instant at start of file, and takes long at end of file.

Tried the same file with build 210, and the loading is almost instant, and doing jumps with the slider is almost instant as well. It doesn't matter if you are at the start and then click the slider bar almost at the end, it just moves there instantly, whereas 212 can take more than 20 seconds to do the same thing.

I guess you can mux whatever into the mkv container and it will show the same issue.

renols

OK, I'm going to back out the change and go back to the drawing board. You seem to say that some version 4 files worked with 210. If so, then there is something else about the test.mkv that is curious. I'll try to get a backed-out version out tonight.

Maybe it's VRD6's fault and sometimes make a bad mkv? It's still new and full of bugs...

That's what I want to believe too, because looking more at my parser it was already properly ignoring version 4 things. My hack was totally non-kosher. I have no idea why it worked for test.mkv. Continuing tomorrow...

Hi.

The mkv file I used has nothing to do with VideoRedo.

It is a plain encoded mkv file encoded with x264 (3015) and then muxed with mkvmerge v40 to add audio and some sup files.
It is that resulting mkv files I am opening in dgindexnv.

Whatever changed between 210 and 212 in the mkv parsing code has made a big difference when using the slider to jump forth and back on the timeline.

I hardly ever open mkv files in dgindexnv, and only tried it because I read this thread.

renols

Re-download 2053. I have backed out the MKV changes that caused this issue. Back to the drawing board on test.mkv.

Rocky wrote: ↑

Sat Jul 25, 2020 7:29 am

Re-download 2053. I have backed out the MKV changes that caused this issue. Back to the drawing board on test.mkv.

Works as expected. Moving around on the slide bar is now instant again.

Do we know if that test.mkv file is even mkv compliant?

I don't know if Mediainfo can be trusted on this, but it shows MKV version 4, even for mkv files created years ago.

renols

renols wrote: ↑

Sat Jul 25, 2020 9:05 am

Do we know if that test.mkv file is even mkv compliant

I don't know. How would you test that?

Maybe you can ask Mosu for an advice?

As per mkvalidator
4 warnings about CUEs but the file is valid

Seems I'm not the only one that has had issues with this kind of MKV muxed by ffmpeg:

https://trac.ffmpeg.org/ticket/4774?cve ... num_hist=3
https://github.com/Nevcairiel/LAVFilters/issues/120

Output from EAC3TO:

C:\Users\Don\Downloads>c:\standalone\eac3to\eac3to test.mkv
MKV, 1 video track, 1 audio track, 1 subtitle track, 0:00:18, 50i
1: h264/AVC, 1080i50 (16:9)
2: AC3, Czech, 5.1 channels, 384kbps, 48kHz, dialnorm: -23dB
3: DVBSUB, Czech
Bitstream parsing for track 3 failed.
Demuxing this track may still produce correct results - or not.

Really tempted to dismiss this as a broken file. However, let's see if there is a fix/workaround before doing that.

BTW test.mkv surprisingly works with old DGIndexIM!