Page 6 of 29

Re: Feature Requests

Posted: Thu Dec 17, 2015 9:12 am
by admin
That's an interesting idea. I'll lock it now. Then perhaps you can help by unsubscribing and then trying to resubscribe, and let me know the result. Thanks.

Re: Feature Requests

Posted: Thu Dec 17, 2015 2:58 pm
by Aleron Ives
The subscription link still works for me, and the binaries update notification thread now appears in my UCP in my list of subscriptions. As for you, you should find that the "LOCKED" image is actually a hyperlink that allows you to post in the thread, whereas for us peons, the link directs us to a page saying that we're not allowed to post in that thread.

Re: Feature Requests

Posted: Thu Dec 17, 2015 3:06 pm
by admin
OK, sounds good, Aleron. Let's see what happens on the next upload. Thanks again for the suggestion.

Re: Feature Requests

Posted: Tue Jan 05, 2016 1:01 am
by Aleron Ives
FYI, I just got an e-mail that you posted in the binaries update thread, so all seems well on the notification-of-posts-in-locked-threads front.

Re: Feature Requests

Posted: Tue Jan 05, 2016 7:19 am
by admin
Great. Thanks, Aleron.

Re: Feature Requests

Posted: Sun Mar 06, 2016 7:16 am
by admin
Sure, I can do that. Give me a few days to get some time for it.

DGinfo()

Posted: Sun Mar 06, 2016 3:27 pm
by sparktank
Is there any chance to call "debug=true".. um. 'outside' of "dgsource()" call?

Cropping with DGsource must be mod4, in rare circumstances, conversion to yv24 to use odd crops must be taken.
Once those measures are taken, using 'debug=true' is cropped out as well.

Maybe a DGinfo() for such occurances? :?:

Re: Feature Requests

Posted: Sun Mar 06, 2016 4:44 pm
by admin
Hi sparktank.

Oy, I wasn't aware that cropping cut off the debug output. Let me look into solutions for that. If the debug info was located within the cropped area, would that be enough for you?

Re: Feature Requests

Posted: Sun Mar 06, 2016 7:12 pm
by sparktank
I'll trust your decision. :)
Anything that wouldn't critically increase your taskload.

Re: Feature Requests

Posted: Mon Mar 07, 2016 7:15 am
by admin
sparktank wrote:Anything that wouldn't critically increase your taskload.
My kind of user. :D

Re: Feature Requests

Posted: Mon Mar 07, 2016 8:24 am
by admin
OK, I tried to duplicate this but failed. I tried both cropping in DGI and cropping using the DGDecodeNV parameters. So it seems I do not understand what you are doing. Please provide a step-by-step process to see your issue. Thank you.

Re: Feature Requests

Posted: Mon Mar 07, 2016 11:27 am
by sparktank

Code: Select all

DGsource ("movie.mkv", debug=true, crop_b=148, crop_t=140) #crop is mod4
^If crops can be done in mod4, then DGSource's crop can be used so debug info moves with the crop.

Code: Select all

DGsource ("movie.mkv", debug=true) #do not crop here since we're not doing mod4
ConvertToYV24 (matrix="Rec709") #to make crops that are mod1
 ## crop examples
 # for wallpapers and image_processing, not critical video_processing but where all picture data can be used
#Crop (0, 139, 0, -138) # top crop is mod1 # resulting height=mod1
 #for movies that are 1.85:1
#Crop (0, 21, 0, -21) # top+bottom crop is mod1 # resulting height=mod2
^ Using avs's internal crop() after DGSource() happens to crop the debug info.

Just for exapmle, clip with black bars to keep debug on clean area:

DGSource("F:\Clips\Inception\Inception CH1.dgi", debug=true)
Image

now same screenshot with mod1 crops to achieve 1.85:1 resolution (for sake of test):
DGSource("F:\Clips\Inception\Inception CH1.dgi", debug=true)
ConvertToYV24 (matrix="Rec709")
Crop(0, 21, -0, -21)
Image

The bigger the Crop() values, the more the debug info gets cropped.

Re: Feature Requests

Posted: Mon Mar 07, 2016 12:18 pm
by admin
You're cropping after DGSource() in your script and then expecting the debug info to be repositioned or something? Tell me I have missed something, because there is no way for DGSource() to know you have a crop later in the script.

Best thing I can think of is to comment out your crop line when you need to see the debug ouput. Do you have another idea?

Re: Feature Requests

Posted: Mon Mar 07, 2016 12:38 pm
by admin
Groucho2004 wrote:Don, any chance you could make DGIndexNV remember the last zoom factor, i.e. add an INI option?
Here's what I'm thinking of: Add an INI file option called Force_Zoom. It can have values 0 (default), 1, 2, or 4. If it is zero the current behavior is used, i.e., after a file is loaded a reasonable zoom factor is automatically chosen. Otherwise the specified value is forced, i.e., Force_Zoom = 2 forces zoom to be 1/2. This allows me to have my favorite auto zoom mode but allows you to force a zoom if you want to. In no case would the GUI selected Zoom be saved in the INI file; it would always be controlled by Force_Zoom. My reasoning for the auto mode is that if I load a UHD video on a 1920x1080 display I don't want to have to go into Video/Zoom to make it all visible.

Unless you refute that idea I'll go with it.

Re: Feature Requests

Posted: Mon Mar 07, 2016 1:42 pm
by sparktank
admin wrote:Do you have another idea?
I was hoping maybe for something like a separate call for the info at any time later.
Similar to Info() and FFInfo() for the frame information.

Re: Feature Requests

Posted: Mon Mar 07, 2016 1:45 pm
by admin
sparktank wrote:
admin wrote:Do you have another idea?
I was hoping maybe for something like a separate call for the info at any time later.
Similar to Info() and FFInfo() for the frame information.
Hmm, thinking... :scratch: I understand what you are asking for, and it's not unreasonable, the problem is to satisfy it. Let me sleep on it.

Re: Feature Requests

Posted: Mon Mar 07, 2016 2:15 pm
by sparktank
admin wrote:Let me sleep on it.
Keep rested. Ideas usually come best from a dream sequence. :) If you lose sleep on this, put it on the back burner until something happens in a dream. Must go deeper~

Re: Feature Requests

Posted: Mon Mar 07, 2016 2:36 pm
by admin
sparktank wrote:Must go deeper
It is deeply gratifying to contact if even so briefly such profound souls as yourself.

Re: Feature Requests

Posted: Thu Jul 21, 2016 5:06 am
by Guest 2
Please get a look http://forum.doom9.org/showthread.php?p ... ost1774770.

AVS+ is having a major upgrade and plugins can declare their MT preferred mode + other nice things.

What do you thing about recompiling DGNV and DGIM to take advantage of AVS+?

Re: Feature Requests

Posted: Thu Jul 21, 2016 6:37 am
by admin
Can you be more specific about I should do and what we would gain from doing so? Thanks.

ultim wrote:

- Avs+ will now automatically recognize source filters. If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode. This is great for source filters as in their case it rarely hurts performance and they often need mode 3 anyway.

So it seems there's nothing I need to do.

Re: Feature Requests

Posted: Thu Jul 21, 2016 9:37 am
by Guest 2
admin wrote:Can you be more specific about I should do and what we would gain from doing so? Thanks.
plugins should now be able to reliably specify their MT-mode using the SetCacheHints() mechanism (for an example, see the usage of CACHE_GET_MTMODE here)
Does DGNV dll already declare its MT-mode?

Re: Feature Requests

Posted: Thu Jul 21, 2016 9:41 am
by admin
No, so avs+ will automatically use mode 3.

Re: Feature Request for x264 lossless

Posted: Sun Jan 29, 2017 12:40 pm
by Sharc
DGDecNV currently fails to decode x264 lossless AVC format profile "High 4:4:4 Predictive Level 3".
Would it be possible to support this format in future?

Re: Feature Requests

Posted: Sun Jan 29, 2017 4:34 pm
by Aleron Ives
I could be wrong, but IIRC nVidia doesn't support it, because no user-facing content is ever lossless, so it's not something DG can fix without nVidia's help.

Re: Feature Requests

Posted: Sun Jan 29, 2017 5:27 pm
by Sharc
Well, if so it's a pity. I wanted to capture video tapes to x264 lossless for later offline conversion to lossy and filtered AVC. DGdecNV would have been convenient for quick inspection/analysis of the captured files.
Anyway, I can view these files with MPC-HC / LAV instead, or capture to quasi-transparent (say CRF=10) lossy format with a very fast x264 settings and use DGDecNV on these.