NE1 Using Nick Hope's workflow?

MikeLV wrote on 4/30/2014, 7:23 PM
Curious as to what framerate you're getting with all his default settings, only 8.5-9fps during the encoding process.. Is that normal? I have an Intel i7-2600k and nVidia GTX 570. Took 6mins and 40 secs to render a 1minute AVCHD clip (with no FX applied in Vegas)

Comments

musicvid10 wrote on 4/30/2014, 8:46 PM
Sounds really good to me. Nick's method employs a number of chained filters, many of them single-threads, I assume.

As the saying goes, "Speed, quality, size. Pick two."
MikeLV wrote on 4/30/2014, 8:54 PM
I'm very pleased with the results, but now I'm curious to try setting up the 64 bit, multi threaded versions of the tools. Is this a road I should venture down?
musicvid10 wrote on 4/30/2014, 9:23 PM
"Is this a road I should venture down?"
From what I've heard, you can expect a lot of construction work and lane closures ahead.
wwaag wrote on 4/30/2014, 9:47 PM
Is this a road I should venture down?

IMHO, definitely! I've been using the MT version of Avisynth for years now, and it does speed things up dramtically for many functions. I still get the occasional crash with QTGMC, the deinterlacer recommended by Nick Hope, but the results are far superior, especially for low resolution DV sources. For HD sources, it doesn't seem to matter as much and deinterlacers like Yadif are OK. In any case, good luck and have fun!

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia RTX4070 graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

VidMus wrote on 4/30/2014, 9:50 PM
Nick Hope's workflow seems like a serious overkill to me! Also seems like a poor use of time.

I like great quality and all but is this REALLY necessary to get it? I honestly do not think so. I do 720p with the Sony AVC and 5,000,000 bps for mp4 and the results are great every time!

No matter what the workflow is, if one starts with garbage they will end-up with garbage! I eliminate the worst part by shooting originally with 60p which means no de-interlacing needed. I know the levels of my cameras and how to compensate for them properly in Vegas, so I get the best results on levels.

The best quality in equals the best quality out. The best quality in means one does not have to use an overkill workflow.

I get speed, quality AND size!

MikeLV wrote on 4/30/2014, 10:44 PM
"I do 720p with the Sony AVC and 5,000,000 bps"

If I was uploading to Youtube, I could care less about the bitrate. With a high bitrate like that, Vegas will do a good job. But I'm shooting for less than 1mbps bitrate for long play content that will be sold in a download-to-own model. Low bitrate means less storage, less download bandwidth and faster downloads for the customers. If I get it right at the onset, then everything will be good. So, overkill or not, if it delivers what I need, then I'm all for digging in :-)
NickHope wrote on 4/30/2014, 11:08 PM
Firstly, for anyone who doesn't know, we're talking about this.

If I render to MeGUI, on my 2007 Q6600 quad core machine, I'm only getting about 1.3-1.8 fps. It's a pixel-peeper's workflow, and WAY slower than just rendering Sony AVC in Vegas. I have a compulsion to my videos look as good as they can, therefore I don't mind the sacrifice in hassle and time.

FYI that was using this AviSynth script:

SetMemoryMax(1024)

SetMTMode(3, 6)

AviSource("d:\fs.avi")

ConvertToYV12(interlaced=true, matrix="PC.709")

AssumeTFF

SetMTMode(2)

Spline36Resize(1280,height)

QTGMC( FPSDivisor=2, Preset="slower", EdiThreads=2 ) #Regular use

Spline36Resize(width,720)

AssumeFPS(29.97)


If you're source footage is progressive then great, you don't need to muck about with QTGMC or Yadif or anything (I can't wait!), and a Sony AVC render is OK, but will require a higher bitrate than x264 to look as "good".

As for 64-bit versions of AviSynth etc., I would say still to avoid them. But you should definitely be doing multi-threading. I recommend trying to end up with SEt's latest build (2013.09.28) of AviSynth 2.6 MT. There are various recent forks of AviSynth and MVTools such as VaporSynth and AviSynth+, but I doubt there is really a stable, complete alternative yet.

My tutorial definitely looks intimidating, but once everything is set up, it's not so bad. And of course because of the frameserver (which doesn't work yet in VP13) you have the benefit of not needing to render the intermediate file that Handbrake requires.

Having said that, my actual worflow these days is to render out UT Video Codec 720p intermediates and bring them back into Vegas for transitions, titles, added graphics etc., which I prefer to add in a 720p project, before doing a final render in MeGUI (which is fast without the deinterlacing). In that case I'm getting just over 2fps rendering in VirtualDub.
VidMus wrote on 4/30/2014, 11:59 PM
MikeLV said, "But I'm shooting for less than 1mbps bitrate for long play content that will be sold in a download-to-own model."

For 720p, I tried the HandBrake method with a 1 mbps bitrate and to me the quality was just barely fair but far below par. I would NEVER consider that as acceptable for a paid download-to-own model!

A bit rate of 3 mbps - 2 pass with HandBrake was absolute minimum for what I want. A bit rate of 5 mbps - 1 pass with HandBrake was exactly what I wanted. The Sony AVC mp4 is comparable to HandBrake at 4.5 mbps - 1 pass, so I decided to stop with all of the extra work and time involved and just simply use Sony AVC mp4.

Yes, it makes a larger file but when one wants to download from Vimeo, they can use the Vimeo file or my original file. The Vimeo file (approx. 3 to 4 mbps) not being quite as good but it is still just good enough.

Maybe Nick Hope's workflow will make that 1 mbps video really look good enough? Even if that is the case (considering what I want), once Vimeo and/or YouTube (Especially YouTube) gets done with it, it will no longer be acceptable. And I sincerely doubt if Nick Hope's workflow will make the 1 mbps video look good enough!

I simply want the best quality without spending hours and hours doing it. Starting with the best quality in the first place can make a much bigger difference than the workflow in the second place! In fact a HUGE difference!!!

Whatever you do, have fun doing it...

NickHope wrote on 5/1/2014, 12:46 AM
"And I sincerely doubt if Nick Hope's workflow will make the 1 mbps video look good enough!"

It depends on the content of the video. The guidelines in the tutorial for self-hosted 1280x720p video are:

"Busy" video with lots of detail / movement: 2000 Kbps
Video with little movement / plain background: 1000 Kbps
Cartoon / slideshow: 200 Kbps

Of course the results need testing and assessing, and perhaps the guidelines should be higher for videos that are actually being sold as downloads. Bandwidths are generally higher than they were in 2011 when that tutorial was written, so it's not such a problem to throw more bitrate at a video just to "make sure".

At the risk of repetition, the biggest advantage in my workflow is the deinterlacing quality, rather than the encoder efficiency.
musicvid10 wrote on 5/1/2014, 5:01 AM
Nick is quite correct, it's about content, not bitrate. MikeLV could do a lot better by using CRF encoding instead of a target bitrate. That is the only way to squeeze more quality out of such small bandwidth.

That said, you cannot make a silk purse from a sow's ear. The bitrates being sought are far more suitable for SD delivery than 720p.
MikeLV wrote on 5/1/2014, 11:26 AM
Fortunately, my source footage is crystal clear, indoor studio filmed under controlled conditions. This is the only thing that allows me to experiment with low bitrates.
MikeLV wrote on 5/6/2014, 7:33 PM
I think I have the multi-threaded working now. I'm not exactly sure where to check, but in Windows Task Manager, CPU Usage indicates 95-98% and all 8 threads realtime line graph things are at the top during the encoding. Not sure if I have everything right, but take a look at my avisynth script:



# Set maximum memory.

# Setting M:

# First try without the SetMemoryMax line.

# However, using the SetMemoryMax line and a good value for

# M might allow more threads and so give more speed.

# Particularly important for slower settings.

# Try values 400,600,800,1000 etc.

SetMemoryMax(1000)



# Set multi-threaded mode.

# Could try 5 instead of 3 for non-standard source-filter/avisynth combinations. 

# Setting X:

# Start at the number of cores in your machine.

# If it crashes, decrease 1 at a time.

# Otherwise, increase 1 at a time until CPU usage is close to 100%.

# Don't go too far or it will slow down and/or become unstable.

SetMTMode(5,0)



# Open frameserved source.

# Change path and file name as appropriate.

AviSource("s:\signpost\fs.avi")



# Convert to YV12 so filters will work.

# Use interlaced layout for conversion.

# Change "true" to false" for progressive source. 

# Use Rec.709 coefficients. Keep full range [0,255].

# Leave it out if you frameserve in YUY2 format. 

ConvertToYV12(interlaced=true, matrix="PC.709")



# Assume footage is top field first.

# If it's bottom field first then use AssumeBFF.

# Leave it out for progressive source.

AssumeTFF



# Set multi-threaded mode.

SetMTMode(2)



# Resize width by Lanczos3.

# Use 1280 for HD source.

# Use 854 for standard definition widescreen source.

# Use 640 for standard definition 4:3 source.

# Leave it out if horizontal resolution is already correct.

LanczosResize(1280,height)



# Deinterlace with QTGMC script.

# Available presets are placebo, very slow, slower,

# slow, medium, fast, faster, very fast, super fast,

# ultra fast, draft. Default is medium.

# Slower presets unnecessary for HD.

# ultra fast requires Yadif.

# Leave out FPSDivisor=2 for smoother double frame rate.

# Leave out the whole line for progressive source. 

# Setting Y:

# Start at about half number of cores and tweak upwards

# or downwards for best speed. Y=1 often works well.

# Balance this setting with X (i.e. if you increase X,

# you might need to decrease Y and vice versa).

QTGMC( Preset="faster", FPSDivisor=2, EdiThreads=2 )



# Resize height by Lanczos3.

# Use 720 for HD source.

# Use 480 for standard definition source. 

# Leave it out if vertical resolution is already correct.

LanczosResize(width,720)



# Scale levels from [0,255] to [16,235].

# Compensates for Flash Player scaling [16,235] to [0,255].

# Leave it out if you are conforming levels in your NLE.

# Leave it out if you frameserve in YUY2 format.

# See http://www.bubblevision.com/underwater-video/YouTube-Vimeo-levels-fix.htm

# ColorYUV(levels="PC->TV")



# This line may or may not be necessary.

# Try removing it and see if you get more speed. 

# Distributor()


How can I actually tell if QTGMC is functioning, or would it simply not encode if I had a wrong DLL file? One problem I have at the moment is I'm not getting any audio so something is up there. Other thing I still don't understand are the levels. If I set studio rgb in Vegas, when I play the encoded file on WMP it looks like it has more contrast than when I play it on VLC player. As I understand, I'm supposed to set the levels to 16-235 in Vegas because the players do something on playback that cause the black and white ranges to increase, don't really get it......

I'm on an i7-2600k with 8GB memory, CPU is overclocked to 4.43GHz
MikeLV wrote on 5/19/2014, 2:57 PM
I finally got a handle on this workflow. The easiest way to get good quality is to pick a slower preset and use a CRF number where the quality looks good to you. Only problem now is playback. MP4 plays back find on any computer with VLC player. WMP from computer to computer is hit and miss. One one computer, it plays, but it's totally corrupted with all kinds of flashing colors, etc - unwatchable. Similar problem playing back on Quicktime's player.
musicvid10 wrote on 5/19/2014, 3:20 PM
Post the MediaInfo for the rendered file.
Could be anything from peak bitrates to high profile "stuff" affecting playback.
NickHope wrote on 5/20/2014, 1:14 AM
MikeLV told me that to get his audio working he had to tick the box "Write audio as PCM samples in signpost AVI" on the Framserver window. I don't need to do that here but it must be required in some circumstances. Glad you got it working Mike.

As for best x264 settings for universal playback, I asked the question 3 years ago on the doom9.org forum. Some of the people replying to that thread are real gurus. My conclusion was to more or less use the default settings, but there are some ideas there for dumbing things down for more universal playback.
MikeLV wrote on 5/20/2014, 5:39 PM
It's a bit of a tricky spot because these videos will be sold online and downloaded by the customer. Customer could be using a desktop, laptop, phone, tablet, windows, mac, linux, android, etc. I suppose if a customer complains that the video isn't playing correctly, we could always recommend VLC since it's freely available for just about every platform and seems to play any H.264 you throw at it.
musicvid10 wrote on 5/20/2014, 5:52 PM
Use main profile and you should be pretty safe.
I tend to dumb down even more than that.
Specific advice will follow once we see Mediainfo.
MikeLV wrote on 5/20/2014, 6:20 PM
Hopefully this will paste ok, but here is the Mediainfo using DNxHD to Handbrake. In handbrake, I used an RF of 23, Very Slow preset, Level: Auto, Profile: Main. In testing, file played back fine in VLC and WMP. Not so pretty in Quicktime player. I also noticed in Quicktime that the video looked washed out, unlike VLC and WMP. Does quicktime not expand levels on playback?

General
Complete name : S:\signpost\tester.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 8.66 MiB
Duration : 1mn 0s
Overall bit rate mode : Variable
Overall bit rate : 1 206 Kbps

Writing application : HandBrake 0.9.9 2013052900

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 0s
Bit rate : 1 074 Kbps
Width : 960 pixels
Height : 540 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.069
Stream size : 7.71 MiB (89%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2014-05-20 23:12:45
Tagged date : UTC 2014-05-20 23:13:59
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1mn 0s
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 160 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 941 KiB (11%)

Funny thing is, I tried the handbrake command line string seen in the screen shot on this page: http://birds-are-nice.me/publications/extremex264_4.shtml and the file played fine in VLC, WMP and Quicktime, haven't tested on mobile devices yet.