Auto indexing for DGDecode

[flossy_cake]

It seems the default d2v path is derived from the invoker's path or something, because if I launch the script from AvsPMod which resides in C:\VideoTools\AvsPMod\AvsPMod.exe then it autocreates the d2v in C:\VideoTools\AvsPMod\

But if I double click my .avs script, I've got Windows file associations set up to automatically open .avs files with C:\MPC-HC\mpc-hc64.exe and the resulting d2v path isn't C:\MPC-HC\ as you would expect but <ScriptDir>, so I'm not sure what's going on there.

In any case I was expecting mpeg2source to use some logic like

Code: Select all

if (GetFileExtension(arg["d2v"]) != ".d2v"){ 

	if (arg["indexing_path"] == undefined())
	   indexing_path = GetParentFolder(arg["d2v"])
	else
	   indexing_path = arg["indexing_path"]
}

[flossy_cake]

It seems the default d2v path is derived from the invoker's path or something, because if I launch the script from AvsPMod which resides in C:\VideoTools\AvsPMod\AvsPMod.exe then it autocreates the d2v in C:\VideoTools\AvsPMod\

Oh it seems there are 2 possible outcomes relating to the above:

1. Opening C:\VideoTools\AvsPMod.exe then going File->Open->C:\MyScripts\script.avs in , in which case the default d2v path is C:\MyScripts\

2. Creating a new blank script in AvsPMod (which hasn't been saved on disk anywhere yet) in which case default d2v path is C:\VideoTools\AvsPMod\

[Rocky]

For the path matter... I ask you again if you have a full path in the script to the video file. Please answer that directly. Give me the script!

If you do not have a full path, then the "current directory" is used. The current directory depends on things that the invoking application can change. If a full path is used, then that is where the index file will be created. So if you want to be absolutely sure about location, then use a full path. Or use the new indexing_path parameter, which is simply a form of full path.

As mentioned before, DGMPGDec and DGDecNV are coded the same and have the same behavior in this regard. And yes, I am careful with my testing.

For the sync matter... At least give me the script fragments that set up your multithreading. You cannot multithread DGSource() on the same source file. There is only one decode engine.

[flossy_cake]

If you do not have a full path, then the "current directory" is used. The current directory depends on things that the invoking application can change.

Ok that explains it, but I'm not sure why DGSource is behaving differently on my system in that regard. In any case I will just manually set my own default path in the Avisynth script and avoid the issue that way.

For the sync matter... At least give me the script fragments that set up your multithreading.

Here is a short script which reliably reproduces the issue on my system. I don't know if it will behave the same on your end as it seems to be a function of how loaded the CPU is and/or how big the prefetch buffer size is. High CPU loads and multithreading are known to create threadsafe issues in Avisynth though so it might not be your DGSource filter doing anything explicitly wrong.

Code: Select all

file = https://drive.google.com/uc?export=download&id=1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb
audio = LWLibavAudioSource(file) # or FFAudioSource(file)
video = DGSource(file) # no issue with LWLibavVideoSource(file, repeat=true) 
AudioDub(video, audio)
Bob()
Spline36Resize(720, 540)
Prefetch(4, 80) # try raising/lowering 2nd param if issue not reproducible

In my typical Avisynth usage I don't use such a large value as 80, I'm just setting it large here for demo purposes.

edit: here is what the above script produces on my system (rendered using ffmpeg.exe at the command line): https://drive.google.com/uc?export=down ... QlIdRpsHuR

[Rocky]

Here is a short script which reliably reproduces the issue on my system.

Thank you. It is an issue with DGSource() seeking in the MKV file. You can see that by first using DGIndexNV to demux the video to M2V and then running this script, when everything is fine:

Code: Select all

loadplugin("...\dgdecodenv.dll")
loadplugin("...\LSMASHSource.dll")
audio = LWLibavAudioSource("NTSC soft telecine.mkv")
video = DGSource("NTSC soft telecine.m2v")
AudioDub(video, audio)
Bob()
Spline36Resize(720, 540)
Prefetch(4, 80)

A linear encode would be fine when sourcing the MKV but multithreading causes DGSource() to receive out of order requests, which invokes seeking. I'll fix the MKV seeking problem and post again when it is ready.

[Rocky]

OK, I have a fix and will slipstream it after a little more testing.

EDIT: Slipstream released.

[flossy_cake]

OK, I have a fix and will slipstream it after a little more testing.

EDIT: Slipstream released.

Thank you it's all working perfectly on my end as well

[Rocky]

You are welcome and thank you for bringing this problem to light.

[flossy_cake]

Just thought I would report a minor thing that doesn't really need to be fixed but it properly confused me for about 10 minutes just now.

When indexing_path=undefined() (i.e blank, not set by the user) it automatically chooses a path based on the current directory.

Then, if the user happens to move the vob/mkv to another location and run the avs script again with mpeg2source(<new path>) it gives the error "could not open one of the input files" because it's still looking at the d2v file in "current directory" which points to the old path at line 3 of the d2v file.

The problem is the error message "could not open one of the input files" is generic and doesn't really give a hint what is actually going on or how to possibly fix it. I kept copying my vob back to the previous path and the new path observing it working on the previous path and not the new one and starting to question whether I'd got some kind of corruption in my file system.

Anyway just wanted to report that. It doesn't actually affect me as I'm going to be programatically creating the indexing_path in my avs file to make it point to the vob/mkv parent folder every time so mpeg2source will see there is no d2v at that location and create it anyway.

[Rocky]

I'll improve the error message for the next release. There is a "Full paths" option in the DGIndex(NV) settings that exists just for this reason. It allows you to choose whether you want to work with full or relative paths. The setting is stored in the INI file which will therefore control what happens during auto-indexing. If it was set to full paths when the index was created you could edit the paths in the D2V/DGI file if you wanted to move the source file. If I see that message I automatically check that the source file is where the index file says it is.