Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st October 2017, 21:35 | #3681 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I'm not aware of any way to extract that information. For a compiled plugin DLL you can query the type and the version (C 2.0, C 2.5, CPP 2.0, CPP 2.5, CPP 2.6) by checking the DLL exports but that's about it.
__________________
Groucho's Avisynth Stuff |
21st October 2017, 22:07 | #3682 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Is that actually strictly necessary in practice? Most plugins tend to check for the colorspaces they can handle in the constructor, and I think the colorspace checking functions in 2.6 won't misdetect new stuff as something old, although 2.5 plugins will pretty much think everything is YV12 AFAIK.
|
22nd October 2017, 00:03 | #3683 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
Quote:
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
24th October 2017, 07:50 | #3684 | Link | |||
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
Code:
int __stdcall SetCacheHints(int cachehints, int frame_range) override { return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0; } Quote:
Quote:
No. Nor have I studied that part of avs+ in deep. I don't know whether ultim treated them as a finalized chapter in avs+ development, but since he left the scene, we'll never know. |
|||
24th October 2017, 09:23 | #3686 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
Quote:
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
25th October 2017, 21:37 | #3688 | Link | |
Registered User
Join Date: Dec 2011
Posts: 23
|
can I ask why the thread count of avisynth+ is always at 37? I don't use MT in the script and on avs meter why my CPU usage is only 2%? I used avisynth MT too and the CPU usage is only 8% max>
script: Quote:
I'm frameserving from Sony Vegas 15. It uses all the cores 99% with no speed benefit (with MT when using MEGUI). I even used the ultrafast preset on x264 same 49fps. Is this a bug? PS: when I used Prefetch(4) the thread count goes to 41 Last edited by sausuke; 25th October 2017 at 21:39. |
|
26th October 2017, 11:27 | #3691 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
It's not always 37 threads, just in your specific scenario.
I think that Vegas simply doesn't serve frames to Avisynth fast enough and therefore creating a bottleneck. That also explains the low CPU usage.
__________________
Groucho's Avisynth Stuff |
26th October 2017, 12:19 | #3692 | Link | ||
Registered User
Join Date: Dec 2011
Posts: 23
|
Quote:
the thing is all the avisynth I used (MT,avs+MT) I need to push the Queue button on MEGUI many times (1x to 3x) to get a fast FPS, when I pushed it and the video is slow they have the same cpu usage too, so I abort again and push then pray that it will be fast (40fps=slow 75fps=fast) here's the screenshot using this script with avsmeter: script: Quote:
same scenario on avsmeter, in that screenshot that is the fastest, I first drag the script and it only have 50fps so I close avsmeter and drag again then that's the fastest (I always look on Vegas Preview too and the frameserver percentage). Dunno if it's the architecture of the threadripper though first time experiencing this. EDIT: here's what I'm saying Slow: 30+ FPS Fast: 70+ FPS (too lazy to wait) xD That's the two scenario when I want to encode either get the 30fps one or the 70fps one. When using the normal avisynth always 40fps PS: Look also the jobs, 11 to 13 hence I aborted in Job 12 'cause I get the same slow fps and get the fast FPS in Job 13 Last edited by sausuke; 26th October 2017 at 12:42. |
||
26th October 2017, 12:44 | #3693 | Link |
Registered User
Join Date: Oct 2011
Posts: 275
|
What is the pixel format for the ouput , 8bits or 32bits floating ?
Also if not already done disable the preview rendering in vegas before frameserving, this make it run like a turtle when frameserving. I don't have this CPU ( 3770k@4Ghz here) but I frameserve from vegas14 my output file directly to a 4GB Ramdisk , vegas temp folder is also set on the Ramdrive. On AVSmeter I usually get around 10-12% CPU usage for 1080p60fps footage and 20-25% CPU usage for 720p30FPS footage with average 250frames output according to avsmeter. When i have the possibility, when it's not too big i put my source video on the Ramdisk too and work from there on vegas and also output to the ramdrive the frameseved and avisynth created files, wish i had more RAM to make bigger ramdisk tho. Edit: took me time to answer with window opened, just seen the previous post after i sent mine. Last edited by Yanak; 26th October 2017 at 22:35. |
26th October 2017, 12:59 | #3694 | Link | |
Registered User
Join Date: Dec 2011
Posts: 23
|
Quote:
Gonna test that preview rendering thank you EDIT: Same even the preview rendering is disabled. It goes slow or fast fps when encoding. Last edited by sausuke; 26th October 2017 at 14:42. |
|
26th October 2017, 18:24 | #3695 | Link |
Registered User
Join Date: Oct 2011
Posts: 275
|
I don't know what is the bottleneck for you, preview screw up my speed on my system :/
Made a quick test and using aviynth x64 that is not compatible with the frame-server output format from debugmodeserver but under MP_Pipeline and a win32 process inside it i got this for the cpu usage: Was a short 1080p video, stored on the ramdisk and debugmodeframserver was outputting it at 211% speed into avisynth. Like Groucho said i think the problem is not avisynth itself, or not totally at least, maybe the HDD speed vs me using a Ramdisk mostly, or some vegas performances parameters maybe, hard to say more on this. Edit : forgot i had megui installed on my machine, using only Staxrip since a while, but made a test in native x86 with it : Output from frameserver was 230 to 238% ... Last edited by Yanak; 22nd January 2018 at 23:47. |
26th October 2017, 21:06 | #3696 | Link |
Registered User
Join Date: Dec 2011
Posts: 23
|
hmm I've tried a normal avi and the normal speed is 400fps (not frame serving) but I've tried my nvenc codec recordings and it will not have preview on megui so I can't test (megui crashing). Maybe the nvenc codec is the bottleneck problem? I can't try the avi on sony vegas 'cause it can't accept now which is weird.
EDIT: oh my it seems the nvenc codec (in MP4) is the bottleneck, I run a test using avi file and it's so fast in sony vegas (frameserver/avisynth+without mt), the problem is now I will use AVI on my recordings on bandicam though (have problems in sounds) will test the other option though EDIT: Finally solved it, it seems the source is the culprit all along (should have read the bandicam faq) I've been using H264 on the settings all these years and not X264 in FourCC code options. Thank you guys for the comments, Groucho2004 for avsmeter (helps alot), Yanak (got the idea of using other source because of your screenshots) xD EDIT: Can I ask if avsmeter preset is the ultrafast of x264 which why is it fast? thank you Last edited by sausuke; 27th October 2017 at 03:08. |
27th October 2017, 08:39 | #3697 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
AVSMeter simply reads the frames from your script, there's no encoding involved. It measures how fast Avisynth can serve frames to your encoder (x264).
__________________
Groucho's Avisynth Stuff |
27th October 2017, 11:21 | #3698 | Link | |
Registered User
Join Date: Dec 2011
Posts: 23
|
Quote:
now it's either the Sony vegas or my computer, dunno if my it's my ram or my overclock, the speed is random when encoding (more on fast now) I always check avsmeter it's always on that speed so I already have fast frameserver. what did I do: Increased Sony vegas 15 threads to 48 (already tried only 1 and the encoding slows down) I've already done the ramdisk and the slow fps does happen too so I think I don't have bottleneck on my HDD, I checked the taskmanager too Gonna reset all the parameters on BIOS if it will help EDIT: Alright I finally know what the cause, 100% fix. This is all about the ram. I thought my 1 of my 4 ram is busted (can't boot with XMP on) so I've removed it then my computer runs in triple channel (2666Mhz XMP On). Yesterday I'm googling about threadripper performance problem and it said that low speed and not quad channel ram causes performance decrease up to 50% and infinity fabric relies on faster ram speed. So I put again my 1 8gb ram (for quadchannel again), overclock all my 32gb to 3000Mhz and it boots. I test it on all my .veg files with MEGUI and wallahh: always fast encoding, no more abort and pray to be faster. It seems the ram speed needed to communicate to the processor, I have feeling about this though cause why sometimes it only uses the other half of the die Hope this will help who gonna buy Ryzen or Threadrippers, buy high speed rams or overclock it (if you want to save money with previous ram). Didn't know this can affect the CPU performance that match in AMD (first time using AMD) haven't research much about this I always thought it's the same with intel, all about CPU not affecting by ram specification Last edited by sausuke; 29th October 2017 at 22:17. |
|
31st October 2017, 16:26 | #3699 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Continuing the discussion from here, let's talk about those nasty memory offsets again.
In avisynth.h from 2.6: Code:
size_t (VideoFrameBuffer::*GetDataSize)() const; Code:
size_t (VideoFrame::*GetOffset)(int plane) const; Code:
class VideoFrameBuffer { BYTE* const data; const size_t data_size; (...) protected: VideoFrameBuffer(size_t size); (...) public: size_t GetDataSize() const AVS_BakedCode( return AVS_LinkCall(GetDataSize)() ) Code:
class VideoFrame { (...) const size_t offset; const int pitch, row_size, height; const size_t offsetU, offsetV; // U&V offsets are from top of picture. (...) VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height); VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height, size_t _offsetU, size_t _offsetV, int _pitchUV, int _row_sizeUV, int _heightUV); void* operator new(size_t size); // generally you shouldn't use these three (...) size_t GetOffset(int plane=0) const AVS_BakedCode( return AVS_LinkCall(GetOffset)(plane) ) Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue. Last edited by TheFluff; 31st October 2017 at 16:36. |
31st October 2017, 19:32 | #3700 | Link |
Registered User
Join Date: May 2017
Posts: 8
|
r2508 RGB->Y8 conversion problem
r2508 RGB->Y8 [incorrect]
r2508 RGB->YV24->Y8 [correct] 2.6MT RGB->Y8 [correct] OS: Win10 CU CPU:i7-4702MQ(Haswell) Code:
function LumaBlock(int n){ return BlankClip(width=60,height=400,pixel_type="RGB32",color=n*(65536+256+1)).Subtitle(String(n),align=2).KillAudio() } StackHorizontal( LumaBlock(0), LumaBlock(8), LumaBlock(16), LumaBlock(32), LumaBlock(64), LumaBlock(96), LumaBlock(128), \ LumaBlock(160), LumaBlock(192), LumaBlock(224), LumaBlock(235), LumaBlock(245), LumaBlock(255) ) # Avisynth+ r2508 needs ConvertToYV24() # ConvertToYV24() ConvertToY8() Subtitle(VersionString,align=9) # Show Histogram ConvertToYV24() Histogram("levels") Subtitle("r2508 RGB32------->Y8",align=7) #Subtitle("r2508 RGB32->YV24->Y8",align=7) #Subtitle("2.6MT RGB32------->Y8",align=7) ConvertToRGB() Last edited by enctac; 31st October 2017 at 20:17. |
Thread Tools | Search this Thread |
Display Modes | |
|
|