The dreaded slowdowns

jaydear

Member
VRDv6 is showing signs of improvement, but low speed encoding is still an issue. I have today disabled all the non-essential apps and drivers in my Windows 8.1 system. My system idle process is sitting at 99.1%, even with VRDv6 open. When I output a project VRDv6 shows in Process Explorer as using only around 2.5% of the CPU when doing fast frame copying which I believe is handed over to the Windows system, and around 12.5% when the internal H.264 encoder starts up to do the encoding of a few frames either side of each edit. Typically it will display a message like "encoding 1 of 11 frames" which counts down as each frame completes. The number of frames varies widely, but 11 is a number I see a fair bit.

The problem is that the frame encoding - the process that's using 12.5% of the CPU - is taking around 1.6 seconds per frame! The fast frame transfer is quicker, but still nowhere as fast as I have seen in the past, being around 4,000 to 5,000 frames per second for 720x576 25fps MPEG2 files with no huge slowdown when encoding frames. Using VRDv6, MPEG2 and h.264 TS files are running at about 1.6 seconds per frame during frame encoding and about 1200fps for fast frame transfer.

So VRDv6 is faster, in the fast frame transfer department than v5 has become, but as slow as a wet weekend when encoding frames. So why is it that Handbrake which I believe is just a front end for FFMpeg can use 90% of the CPU and get 1GB of h.264 video rendered from 1920x1080 to a 1280x720 mp4 within 17 minutes (at about 62 fps). I think I saw a mention of FFMpeg somewhere in your forums, and I assume that's what you're employing, so why the heck is it so slow?

If there is some driver or system configuration that's causing all this slowing down that I and other VRD users are complaining about we all need to combine our resources to find out what on earth is preventing VRD from running at full speed. It's a huge mega-problem, and it's seemingly only VRD that's affected.

I use other video software as well as VRD and it's all still running at impressive speed. As an example, on the same PC when I remux the same 1GB h.264 TS file made by VRD with the same content in an h.264 1280x720 240GB mp4 from Handbrake in MKVToolnixGUI in order to add subtitles from the TS file, it happens within 3 seconds! I get the same high speed for a straight 240GB USB disc to USB disc copy using Windows Explorer or TeraCopy. After doing this testing I have rebooted the PC so all the drivers and non-essentials are back and running and VRD seems unaffected, no slower, no faster. We definitely need to get to the bottom of this problem that seems to be attacking VRD.

You want the sample files I've mentioned? No problemo.
 

zhenya_hacker

New member
When vrd is running "fast frame copy" routine main bottleneck is your disk read-write speed. Based on your words it seems like other programs rely on windows feature to cache data in ram before actually writing it on disk, and it looks like vrd id forces it to not to cache it in ram, but actually write it on disk instead. Try to mux anything with TSMuxer. Does it in the same way mux it in seconds and after that wait for cache being written for several seconds?

Speaking about smartedit encoder, it is being developed for maximum possibility to create videostream as alike with original stream, but not for maximum speed encoding. For years of using it this encoder was built one-threaded, so it obviously uses only one of your eight cores. So, your cpu is 100/8=12.5% used.
 

jaydear

Member
Thanks for that info. I like the maths. I get what you're saying, but VRD used to be super-fast, now v5 crawls. V6 is a bit faster, but it shouldn't it be faster than v5 was? I'll give TSMuxer a try and report back. The Smartedit encoder is doing a good job in v6, but needs to be dragged into the 21st century. Having said that, if it was used in v5 it was faster but has lost it's moxy somehow! Something is holding it and VRD back.
 

jaydear

Member
Looks like TSMuxer can't see the subs in my TS. I can say though that MKVToolnixGUI doesn't seem to cache. Just load files, select tracks, press start, grab stopwatch, oops too late it's finished, no blinking light on USB drive, so AFAICT it writes 240MB straight to disc in a few seconds. The point to remember here is that VRD used to be that fast, then something screwed it up for lots of users. Perhaps a Windows update?
 

Danr

Administrator
Staff member
If you're having slower than expected encoding speeds email us the log file.
 

zhenya_hacker

New member
Looks like TSMuxer can't see the subs in my TS.
Yes, it does not support subtitle stream. I meant try to use it to understand what I mean speaking about OS write caching. When tsmuxer muxes, it muxes its stream and after that writes in the log "clearing cache...", and after some time when all data is really written to disk it logs "finished". Probably, VRD acts in same or at least way alike, so when VRD muxes a TS, it forcefully writes it on disk preventing TS to be cached.
 

jaydear

Member
I had another go at TSMuxer, but it is foreign to me so the (non-existent) results are of no help. I couldn't find a new *.log anywhere, so I guess it didn't write one. We all have our own way of working with our favoured s/w.

Anyway, as the best I can do with my particular computer skills, I rendered out a job in VRD6 and I was watching Task Manager as it ran and the jpg below was captured during the rendering. I'm not a programmer, but it looks like VRD is buffering to memory because it only uses a fraction of that 481.8MB when it is idling. It also appears to be writing to disk at 8.9MB/s which is a woefully slow speed to be using to write what was a 1.3GB file in this case. I took the screen grab during 'fast frame copy'. The 481.8MB of memory increased and decreased a bit during the job, but appeared to me that it was holding back unnecessarily because I have 16GB of RAM. As an 'apples and oranges' comparison, another TS editing program I use writes at about 180MB/s from the same source file. Why don't I use it then? It is not a frame accurate editor, or I would.

VRD6 save test.jpg
 
Top Bottom