Page 7 of 13

DGDecNV (linux)

Posted: Mon Jun 14, 2021 6:05 am
by Rocky
OK, thank you DJ. It's working! I'll sort out the library path stuff first, then address your other matters and further ones as they arise.

DGDecNV (linux)

Posted: Mon Jun 14, 2021 11:23 am
by Rocky
Hey DJ, where did you put libcuda.so and libnvcuvid.so? I'm thinking of having them in /usr/local/lib using -L to specify that path. libmp4v2.so will go there too. libdgdecodenv.so can be anywhere that Vapoursynth can find. I usually load plugins explicitly in the script.

DGDecNV (linux)

Posted: Mon Jun 14, 2021 12:01 pm
by DJATOM
I already had cuda stuff installed in /usr/lib, so didn't confirm for overwrite.
I think it's ok to put into /usr/local/lib, alternatively you can build static libmp4v2 and link against that static lib :) .

DGDecNV (linux)

Posted: Mon Jun 14, 2021 1:59 pm
by Rocky
Good idea, I'll do that. Thank you.

DGDecNV (linux)

Posted: Tue Jun 15, 2021 7:43 pm
by Rocky
Have another snafu that is causing relative paths on linux to be problematic.

On Windows, if I open a vpy script and do GetCurrentDirectory(), it shows the path of the DGI file in DGSource(). However, if I do getcwd() on linux, it shows the path of the libdgdecodenv executable. I'm confused but still investigating.

Would it be horrible to require full paths in the DGI file and script, i.e., ditch Full_Path_In_Files = 0?

The mp4v2 library is now static.

DGDecNV (linux)

Posted: Wed Jun 16, 2021 4:31 am
by DJATOM
Since I don't rely onto relative path thing, it's fine to ditch by me. I'm storing files on different drives and making simlinks for easier access at the project directory, so relative paths usually not required.

DGDecNV (linux)

Posted: Wed Jun 16, 2021 5:15 am
by Rocky
Thank you for the feedback, DJ. I'll probably just ditch it. The original intent was to simplify moving things to a different directory but how often does that really happen after an index is made? And it's not so hard to edit a DGI file if needed.

I'll make a new test release today with the library situation sorted out. Then I will address the documented limitations.

Did your encode go OK and what did you use for encoding?

DGDecNV (linux)

Posted: Wed Jun 16, 2021 5:18 am
by DJATOM
I have a deadline this friday, not even tried to encode yet. Will try this night...

DGDecNV (linux)

Posted: Wed Jun 16, 2021 5:49 am
by Rocky
No problem, no hurry.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 6:44 am
by Rocky
Uploaded a new release:

http://rationalqm.us/dgdecnv/binaries/dgdecnv_linux.zip

The MP4V2 library is now static and the cuda/cuvid libraries are removed as they will be used from the installed nVidia driver. The user manuals are updated.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 7:41 am
by DJATOM
Then I will test now with new version, since I worked to 1 a.m. yesterday and had no stamina to arrange some encode job before sleep.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 9:20 am
by DJATOM
Few tests made. It looks ok for me, just a small issue with dirty last frame which I encountered in windows version. It's non-deterministic, so I don't know if it can be fixed at all, I simply trim dark frames in the end to deal with those glitches.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:02 am
by Rocky
Thank you, DJ. If it matches the Windows version then the design goal was met. Nevertheless, if you want to cut the last 50MB of the stream for me I'd be willing to investigate the last frame issue. There are several possible explanations.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:17 am
by DJATOM
I have uploaded entire m2ts.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:27 am
by Rocky
Thank you!

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:36 am
by Rocky
The 23 black frames at the end appear to be encoded in the stream. They show up with MPC-HC as well.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:42 am
by DJATOM
Sometimes I get last frame black (expected behavior) and sometimes last frame contains glitches, frame with empty luma and repeated UV / full repeat from last non-black frame (that's wrong)

DGDecNV (linux)

Posted: Thu Jun 17, 2021 10:46 am
by DJATOM
Apparently it only happens when frames requested asynchronously.
Linear scroll "frame-by-frame" is fine for some reason.

DGDecNV (linux)

Posted: Thu Jun 17, 2021 11:06 am
by Rocky
Gotcha, thanks. I'll look into that.

DGDecNV (linux)

Posted: Fri Jun 18, 2021 9:15 pm
by Rocky
Can't see any issue with it. I put Reverse() in the script so that every frame is accessed randomly. Never saw a glitch.

DGDecNV (linux)

Posted: Sat Jun 19, 2021 1:17 am
by DJATOM
Then just leave it as is. It might be a cuvid thing, so nothing to do with plugin itself.

DGDecNV (linux)

Posted: Mon Jun 21, 2021 7:32 pm
by Rocky
Got all the FPS detection fixed up. Well, at least I think so. Gonna make a new release but want to sort out the INI file situation first. We may not even need one for linux. But putting dgindexnv in a root directory, such as /usr/local/bin is currently an issue, as the INI file is not writable there.

Then need to get back to Windows to catch up on some trouble reports and enhancements.

DGDecNV (linux)

Posted: Tue Jun 22, 2021 1:17 am
by DJATOM
As for settings, you might want to check ~/.config/dgtools/dgindexnv.ini (per user config) or try second time for /etc/dgtools/dgindexnv.ini (global config directory). If nothing found, fallback to write new config into user dir.

DGDecNV (linux)

Posted: Tue Jun 22, 2021 5:38 am
by Rocky
There is no need for an INI file so I removed it. All the settings affected only things that were stripped out. I'll keep your suggestion in mind if the need for settings re-arises.

Gonna release a new test version shortly.

DGDecNV (linux)

Posted: Tue Jun 22, 2021 5:49 am
by Rocky