[RESOLVED] DGDecnv 2052 2016-12-15 slow seeking mkv

[bheerschop]

In short:
I initially thought that Megui was hanging when I indexed a mkv with the slipsteam version 2016-12-15 (year-month-day)of DGDecnv.
When I tried the same avs script in virtualdub, I discoverd the seeking is very slow.
For example, I open the script in virtualdub then I click in the middle of the timeline. It takes about 40 seconds before the frame at that position is showing.
With slipstream version 2016-11-03 the same frame is shown almost instantly (in about 1,5 sec)

Simple avisynth script:

Code: Select all

LoadPlugin("D:\dgdecnv2052 20161215\DGDecodeNV.dll")
DGSource("D:\puss in boots - 20161215.dgi",fieldop=0)

Code: Select all

General
Format                         : Matroska
Format version                 : Version 4 / Version 2
File size                      : 20.4 GiB
Duration                       : 1h 30mn
Overall bit rate mode          : Variable
Overall bit rate               : 32.3 Mbps
Movie name                     : Main feature
Writing library                : Lavf57.3.100

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High@L4.1
Format settings, CABAC         : Yes
Format settings, ReFrames      : 4 frames
Codec ID                       : V_MPEG4/ISO/AVC
Bit rate mode                  : Variable
Maximum bit rate               : 30.0 Mbps
Width                          : 1 920 pixels
Height                         : 1 080 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Variable
Original frame rate            : 23.976 fps
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 8 bits
Scan type                      : Progressive
Default                        : No
Forced                         : No
DURATION                       : 01:30:14.534000000

Audio #1
ID                             : 2
Format                         : TrueHD
Codec ID                       : A_TRUEHD
Duration                       : 1h 30mn
Bit rate mode                  : Variable
Maximum bit rate               : 6 129 Kbps
Channel(s)                     : 8 channels
Channel positions              : Front: L C R, Side: L R, Back: L R, LFE
Sampling rate                  : 48.0 KHz
Frame rate                     : 1 200.000 fps (40 spf)
Bit depth                      : 24 bits
Compression mode               : Lossless
Language                       : English
Default                        : Yes
Forced                         : No
DURATION                       : 01:30:14.560000000

Audio #2
ID                             : 3
Format                         : AC-3
Format/Info                    : Audio Coding 3
Mode extension                 : CM (complete main)
Format settings, Endianness    : Big
Codec ID                       : A_AC3
Duration                       : 1h 30mn
Bit rate mode                  : Constant
Bit rate                       : 640 Kbps
Channel(s)                     : 6 channels
Channel positions              : Front: L C R, Side: L R, LFE
Sampling rate                  : 48.0 KHz
Frame rate                     : 31.250 fps (1536 spf)
Bit depth                      : 16 bits
Compression mode               : Lossy
Stream size                    : 413 MiB (2%)
Language                       : Dutch
Default                        : No
Forced                         : No
DURATION                       : 01:30:14.560000000

Audio #3
ID                             : 4
Format                         : AC-3
Format/Info                    : Audio Coding 3
Mode extension                 : CM (complete main)
Format settings, Endianness    : Big
Codec ID                       : A_AC3
Duration                       : 1h 30mn
Bit rate mode                  : Constant
Bit rate                       : 640 Kbps
Channel(s)                     : 6 channels
Channel positions              : Front: L C R, Side: L R, LFE
Sampling rate                  : 48.0 KHz
Frame rate                     : 31.250 fps (1536 spf)
Bit depth                      : 16 bits
Compression mode               : Lossy
Stream size                    : 413 MiB (2%)
Language                       : Dutch
Default                        : No
Forced                         : No
DURATION                       : 01:30:14.560000000

Text
ID                             : 5
Format                         : PGS
Codec ID                       : S_HDMV/PGS
Codec ID/Info                  : Picture based subtitle format used on BDs/HD-DVDs
Language                       : Dutch
Default                        : Yes
Forced                         : No
DURATION                       : 01:30:14.260000000

Menu
00:00:00.000                   : :chapter 1
00:03:25.246                   : :chapter 2
00:07:20.148                   : :chapter 3
00:11:46.831                   : :chapter 4
00:15:53.369                   : :chapter 5
00:19:23.537                   : :chapter 6
00:25:58.348                   : :chapter 7
00:29:22.427                   : :chapter 8
00:34:06.461                   : :chapter 9
00:39:17.438                   : :chapter 10
00:44:12.107                   : :chapter 11
00:49:34.054                   : :chapter 12
00:54:05.951                   : :chapter 13
00:57:38.204                   : :chapter 14
01:03:05.990                   : :chapter 15
01:08:14.715                   : :chapter 16
01:16:51.773                   : :chapter 17
01:19:42.194                   : :chapter 18
01:30:14.283                   : :chapter 19

Please explain "seems to hang". Does it hang or not? For how long?

Well, Megui does not actually hang (windows: not responding) It is busy seeking which takes a long time.

Meanwhile I will investigate the seeking issue.

Thank you

[admin]

Thanks for re-posting after I accidentally deleted your post.

Your initial post mentioned cloneBD. Anyway, I found that cloneBD is generating bad MKV files. They have an incorrect first cue. I used AnyDVD HD to rip the M2TS and then mkvmerge to make an MKV and everything is fine, i.e., the first cue is correct.

I have implemented a workaround. If I see the bad first cue I correct it. Please re-download 2052, update both DGIndexNV and DGDecodeNV, and report your results. I tested it with a bluray ripped with cloneBD and things appear fine, even though the MKV has a bad first cue.

If it is failing when you don't use cloneBD, please post again. I am trying now with makeMKV just out of curiosity.

[admin]

Works fine with a makeMKV-created file also.

Note that I included only the video and the English AC3 audio. I wouldn't expect things to change if you include more (DGIndexNV looks only at the video track when saving an MKV project), but please advise if you still have any problems with the updated binaries.

[bheerschop]

Thanks for re-posting after I accidentally deleted your post.
Your initial post mentioned cloneBD but now your post talks about lavf.
If it is failing when you don't use cloneBD, please post again. I am trying now with makeMKV just out of curiosity.

First, thank you for your very quick response. I did mention cloneBD in my initial post. I used CloneBD to create the mkv from a Bluray movie.
I did redownload and install DGDecnv 2052 for MeGui and it is working very fast again with no problems.
CloneBD seems to be the culprit creating bad mkv files, as you mentioned.
Many thanks you for the work around. I am now re-encoding with Megui and DGDecnv.

greetz,
Ben

[admin]

Sweet, Ben, thanks for your problem report and test results. Always happy to assist fine chaps like yourself.

What I found was that the first cue had a ridiculously large Time value (even though the Position was correct), much larger than any real timestamp in the file. So I added a check to detect that and map it back to Time=0 as it should be. Hopefully this is the only CloneBD issue, and you may want to report it to them. But the workaround should be adequate if there are no other issues.

Have a Merry Christmas and a Happy New Year. I am celebrating with my new favorite Kentucky bourbon called Larceny. It's 92 proof, which for me outweighs the smoother taste of Maker's Mark. Gonna hop in the tub and soak.

[bheerschop]

Hopefully this is the only CloneBD issue, and you may want to report it to them.

I posted a message in the CloneBD forum. I got a response form the CloneBD forum admin. The admin asked me to scan the mkv, created by clonebd, with a tool called "EBML.exe".
This seems to be a matroska viewer. After scanning the mkv this tool lists the segment clusters, cues and tags.
The time value for first cuepoint is set at 00:00:00.000 and no large Time value is shown.

I know this mkv issue is not your problem. Clonebd seems to do something wrong when creating the mkv. I just want the Clonebd forum admin to be able to find the wrong timevalue and I dont think that this EBML tool is able to find the problem.

How did you determine the time code for the first cue ?
Has it perhaps something to do with the mkv doctypeversion. Is it possible to have multiple timevalues available in one mkv for each doctypeversion?

[admin]

I broke in the Matroska parser and displayed the Cues array. It could be a parser bug but why only for CloneBD?

I'll investigate some more and then post evidence if it still looks like CloneBD.

[admin]

Here is a screenshot of my debugger window showing the problem. This comes immediately after:

Code: Select all

// Initialize matroska parser.
	mf = mkv_OpenEx(&st.base, 0, 0,	err_msg, sizeof(err_msg));
	if (mf == NULL)
		return 1;

My Matroska parser code came from the Matroska guys and I have no reason to doubt it. Also, of all my MKV files only the one made by CloneBD fails like this.

You can see in the screenshot that the Time value of the first cue is wrong. I displayed only the first three.

Can you give me the EBML.exe?

[Guest]

If you run the problematic MKV thru MKVmerge, does the resulting file have the same problem?
If not, then Clone BD is the problem
I use it for a quick remux solution but on occasion the file is, shall we say, problematic
Run it thru Mkvmerge and everything is fine
CloneBD has some bugs even if some people don't want to admit it

[admin]

Hi gonca. Thanks for your report.

Yes, I have already described in the thread that remuxing with mkvtoolnix fixes the issue. I'm pretty sure CloneBD has a problem. I can see why a player may not have a problem with it, though, as it is unlikely to seek with the first cue to start playing, rather than just reading the first frame and carrying on. DGDecNV needs random seeking and it would be silly have an exception for seeking to the start of the stream.

My work-around works well so I am not that motivated to investigate further.

Now it's time to install my 1050 Ti.

[Guest]

I have seen players have problems with those files
They "seem" to hang on loading the file
That is how I found that a remux solves that issue

Sorry about missing your info on remuxing

[admin]

Interesting to hear about your player experience. It tends to confirm my diagnosis. I suppose it depends on how they implement the start-up at frame 0.

[admin]

OK, I identified the (apparent) bug in the CloneBD file.

In the first cluster of the segment, the main Cluster Timecode is 0 as it should be, but the first SimpleBlock (element A3) gives a Timecode of 7 (relative to the Cluster Timecode) (for the MKV I made with CloneBD, it may differ, I don't know, but it is not 0). Then the Matroska parser thinks that it has to adjust all the cues back by 7, making the first cue underflow to a high number.

In all of my other MKVs, the two Timecodes are both 0. Note that an EBML viewer I have does not go deep enough to show the SimpleBlock Timecode field so maybe neither does EBML.exe, and that is why they did not see the problem. I discovered this by stepping through the parser code.

For the players it all depends on whether they use the main Cluster Timecode or the first SimpleBlock Timecode, and whether they adjust the cues based on the latter. My parser uses the SimpleBlock Timecode and adjusts the cues. This is code from the Matroska designers, so...

bheerschop, please tell the CloneBD guys about this and post again if they have any useful reply. For now, I will continue with my current workaround.

[admin]

My Matroska code is ancient versus the latest code, and this issue may arise from that. I am going to upgrade my code but it may take a while. For now, the work-around is good. Don't bug the CloneBD guys until I have the results from the upgrade. Thank you.

Thread re-opened.

[admin]

The same problem happens with the latest Matroska parser code. So go ahead and report this to CloneBD.