Do m.2 drives drastically reduce render time?

[DualVCR]

Thinking about taking the plunge on an m.2 drive for convenience, but I'd like to an estimate on how much it would actually reduce times in my current workflow. Drives I'm looking at are 3500MB/s write and 3000MB/s read. Everything is currently stored on external HDDs throughout the workflow as my OS m.2 drive is only 500 gigs. I'm mostly working with DVDs that don't seem likely to receive a BD release and filtering/uprezing to bring it in line with my personal preferences.

Specs:
Ryzen 3900X
Red Devil RX 580 Golden (planning on getting RTX 3080/3090/40something when prices eventually get back to retail)
32GB 3200 RAM
Win 10 Enterprise

Current times for my workflow look like this for about 25 minutes of footage:
-deinterlace with QTGMC with bob and everything set to placebo/highest quality settings, export to PNG - 30ish minutes
-various settings applied in Davinci Resolve with Neat Video, Samurai Sharpen and Beauty Box 4, export to uncompressed 10-bit AVI - 4-10 hours, depending on how much is being done
-upscale with Video Enhance AI - ~5 hours for 200% or 10+ hours for 400%, export to 16-bit TIFF
-import the new TIFFs into Resolve and render as 10-bit uncompressed AVI - 10 hours
-h.265 encode in Handbrake with placebo/highest quality settings - 24+ hours

Obviously I'm trading longer render times for the highest possible final quality and smallest file size. When I test something with h264 it renders in less than 2 hours so at a minimum write speed is an issue there. Obviously I don't expect an exact answer for the time difference. I see data transfers on my HDDs run about 100MB/s but I'm not expecting the above times be divided by 30. Cutting times to about half, about a quarter, about a tenth, that's the kind of estimate I'm looking for.

A related question - is there something faster than Resolve to render the TIFFs into uncompressed video (or encode straight to h265)? I've tried Virtualdub but the output always plays at double speed or faster no matter what settings I've used. Handbrake processes each TIFF as its own title which takes longer than rendering to AVI in Resolve.

[october262]

according to this - https://forums.chaosgroup.com/forum/v-ray-for-sketchup-forums/v-ray-for-sketchup-gener...ct-render-time
it won't make much difference. also see this youtube video - https://www.youtube.com/watch?v=TmVquu3aDkE

[poisondeathray]

Current times for my workflow look like this for about 25 minutes of footage:
-deinterlace with QTGMC with bob and everything set to placebo/highest quality settings, export to PNG - 30ish minutes
-various settings applied in Davinci Resolve with Neat Video, Samurai Sharpen and Beauty Box 4, export to uncompressed 10-bit AVI - 4-10 hours, depending on how much is being done
-upscale with Video Enhance AI - ~5 hours for 200% or 10+ hours for 400%, export to 16-bit TIFF
-import the new TIFFs into Resolve and render as 10-bit uncompressed AVI - 10 hours
-h.265 encode in Handbrake with placebo/highest quality settings - 24+ hours

Not much difference - because nothing you are doing is limited by transfer I/O. You have other bottlenecks

Pure 10bit uncompressed transfer rates can be a bottleneck on a single mechanical HDD - but not when coupled with all those filters like Neat Video, etc.. The filters are the bottleneck

When I test something with h264 it renders in less than 2 hours so at a minimum write speed is an issue there.

You arrived at the wrong conclusion - write speed is not the bottleneck. h264 is encodes faster then h265. Nothing to do with I/O transfer rates



TIFF sequence to Resolve to Uncompressed AVI to Handbrake is a few extra wasted steps and going to be slower than say using ffmpeg directly on the TIFF sequence to encode h265

[DualVCR]

You arrived at the wrong conclusion - write speed is not the bottleneck. h264 is encodes faster then h265. Nothing to do with I/O transfer rates

Yes, but that is not the comparison I was making. h264 was much faster than uncompressed AVI, and I would expect something with no compression overhead to be faster. Likewise, VEAI's h264 output is much faster than its TIFF output.

The main areas I'm looking to speed up through m.2 are the upscale in VEAI and the h265 encode at the end. Anything that processes TIFFs from my external drive has been excruciatingly slow. I gave up on opening a TIFF sequence of about 90000 images in Handbrake after it passed the 9 hour mark (just to open it, not actually encode anything).

ffmpeg would eliminate a step I'm doing now so I'll try that. I pieced this syntax together from a few different articles. Does it look right? Things I read on different sites gave contradictory answers for using 00000.png or %03d.png so I'm really not sure on that part of it. If I'm understanding this correctly the main10 switch is all I need to create 10-bit output as long as the source isn't 8-bit.

ffmpeg -framerate 50 -i 00000.png -c:v libx265 -crf 16 -x265-params -preset placebo -profile:v main10 -tune animation output.mp4

[poisondeathray]

ffmpeg would eliminate a step I'm doing now so I'll try that. I pieced this syntax together from a few different articles. Does it look right? Things I read on different sites gave contradictory answers for using 00000.png or %03d.png so I'm really not sure on that part of it. If I'm understanding this correctly the main10 switch is all I need to create 10-bit output as long as the source isn't 8-bit.

ffmpeg -framerate 50 -i 00000.png -c:v libx265 -crf 16 -x265-params -preset placebo -profile:v main10 -tune animation output.mp4

What pixel type? what kind of 10bit hevc ? 4:2:0 subsampling ?

Assuming you used Rec601 to convert to the PNGs at the 1st step, you'd normally use Rec709 to convert TIFF/PNG input back to YUV, because now it's upscaled

You would also need to specify

-vf scale=out_color_matrix=bt709,format=yuv420p10le

You use the number of place holder digits for %

if your files were

00000.png
00001.png
00002.png
.
.
.

It would be "%05d.png" , because "5" digits

So it would look something like this

ffmpeg -framerate 50 -i %05d.png -vf scale=out_color_matrix=bt709,format=yuv420p10le -c:v libx265 -crf 16 -preset:v placebo -profile:v main10 -tune animation -x265-params colormatrix=bt709 output.mp4

(BTW, Placebo is a waste of time)

[butterw]

Thinking about taking the plunge on an m.2 drive for convenience, but I'd like to an estimate on how much it would actually reduce times in my current workflow. Drives I'm looking at are 3500MB/s write and 3000MB/s read. Everything is currently stored on external HDDs throughout the workflow as my OS m.2 drive is only 500 gigs.

If your typical encodes take hours, I would assume filtering/encoding is the bottleneck.

You already have a m.2 drive, why not try it out on a short clip to convince yourself ?

[sophisticles]

(BTW, Placebo is a waste of time)

I would say that everything he is doing is a complete waste of time.