Comments

SomeAMan wrote on 3/18/2020, 12:56 AM

Thank you very Much

alifftudm95 wrote on 3/18/2020, 5:57 AM

But if you're rendering for commercials/clients, you should render in Proress 422 or DNxHD

michael-harrison wrote on 3/18/2020, 5:12 PM

@john_dennis why AVC rather than HEVC?

The question comes from a place of knowing enough about the various codecs to be dangerous to myself.

john_dennis wrote on 3/18/2020, 6:37 PM

AVC/AAC is broadly accepted. While HEVC might be better at a comparable file size, it will likely take longer to render.

Notice I said “Start here.”

lenard-p wrote on 3/18/2020, 11:06 PM

That would be an interesting ttest to try, hevc vs AVC - time until all encode resolutions are finished. My guess is Youtube only allows you a certain amount of cpu for encoding, so HEVC to AVC encode will take longer. I know it to be true of another site I use

john_dennis wrote on 3/19/2020, 12:30 AM

Here is a comparison of time to render and picture quality done with Wayne Waag's Render Quality Metrics Tool.

I used 8 Mbps target with 24 Mbps maximum per youtube bit rate recommendations.

Magix AVC/AAC (Mainconcept vs AMD VCE)

Magix HEVC (Mainconcept vs AMD VCE)

Observations

1) No sane person would ever upload 8 Mbps video if the complexity was higher than a white on black credit roll.

2) If one has a hardware encoder, render times can be much faster at roughly the same quality and bit rate.

3) None of my old Blu-ray players will play HEVC though two out of three of my TV's do.

4) Mainconcept HEVC did poorly on the test because the rendered video output lead the source project by three frames. The audio was properly aligned at the start and finish of the 30 second video clip.

Edit: 2020-03-19

Mainconcept HEVC renders don't have the proper precision. The 30 second, 899 frame source file is not faithfully reproduced. The resulting output is three frames shorter than the source and the audio is delayed from the video by three frames. Thus, a frame for frame comparison technique gives irrational results.

I shifted the video by three frames and ran the measurement again with much more reasonable results. It's up to the user whether the shifts are a deal-killer. I suspect it might be for someone who makes 30 second commercials for broadcast, but those folks probably won't be using HEVC to deliver their files.

Howard-Vigorita wrote on 3/19/2020, 3:02 AM

I used 8 Mbps target with 24 Mbps maximum per youtube bit rate recommendations.

One of their listed mp4 requirements is: "moov atom at the front of the file (Fast Start)." If absent, youtube always re-encodes my 720p and 1080p uploads. Which I've noticed seems to happen whenever I do not use Mainconcept AVC with the "enable progressive download" checkbox enabled in Vegas Magix AVC templates. That checkbox is otherwise grayed out in which case Youtube exhibits a re-encoding processing delay after upload. For 2K and higher uploads, however, I think youtube always re-encodes unless the mp4 comes in VP9 which is not supported by Magix AVC.

Cameras: Canon XF305, JVC GV-LS2, Canon 6D w/L-glass line.
Laptop: Dell XPS15-9570; i7-8750h 32gb (integrated Intel UHD-630 & Nvidia GTX-1050Ti)
Road: Intel NUC i7 8809g 32gb (integrated AMD VegaM 4gb graphics and Intel HD630)
Workstation: i9 9900k 32 gb (Sapphire AMD Radeon VII 16gb graphics and integrated Intel UHD630)
Workstation2: e5 1650v4 128 gb (Sapphire Nitro+ RX580 8gb graphics)
Workstation3: i7-980X 24gb (Sapphire RX480 4gb graphics)
currently Vegas 17.421

lenard-p wrote on 3/19/2020, 4:04 AM

. For 2K and higher uploads, however, I think youtube always re-encodes unless the mp4 comes in VP9 which is not supported by Magix AVC.

Mkv and Flv encode the fastest along with the mp4 technique you talk about, but it's still being re-encoded You see the much longer delays for 1440P and above because as you said it's having to encode VP9, which likely takes up as much cpu as having to encode in HEVC. 1080p and below faster due to the first encode being AVC then it does VP9 .

john_dennis wrote on 3/19/2020, 6:41 PM

I ran the test for Magix HEVC Mainconcept renders to correct for the imprecise alignment of of frames causing audio misalignment and measurement errors.

Link:https://www.vegascreativesoftware.info/us/forum/what-is-the-best-format-to-choose-for-youtube-when-do-video-rendering--119333/#ca744728

Musicvid wrote on 3/19/2020, 6:58 PM

The purpose of putting the moov atom at front (progressive download) is to enable Youtube to start processing immediately rather than at the completion of uploading.

Youtube always re-encodes the same way. It just takes about twice as long if you don't enable progressive download.

andyrpsmith wrote on 3/20/2020, 2:50 PM

Played about with the Magix templates and the Happy Otter Render options. OK but not as good as the sony for smooth block free result for upload to YouTube.

john_dennis wrote on 3/20/2020, 2:54 PM

"OK but not as good as the sony for smooth block free result for upload to YouTube."

What Sony?

andyrpsmith wrote on 3/20/2020, 3:08 PM

Sony AVC/MVF Internet 1920x1080 30p template. As my timeline was 24p I just changed the framerate in the template to match. Magix template took about 14mins CPU, 6 mins GPU, Sony took 9 mins (with use GPU if available option). Video 4K down to 1080 24p 6 mins.

john_dennis wrote on 3/20/2020, 4:53 PM

@andyrpsmith

"Played about with the Magix templates and the Happy Otter Render options. OK but not as good as the sony for smooth block free result for upload to YouTube."

Science doesn't support your assertion.

Perhaps you should round-trip Sony AVC/MVC Internet rendered files and any other likely candidates up to youtube, download their re-rendered files and see for yourself by using measurement tools.

With my eyes, I'm finished with the emotional, touchy-feely stuff. Give me data.

andyrpsmith wrote on 3/20/2020, 7:31 PM

The most important thing is just how it looks and playing back the clips rendered with a range of settings the Sony template provided me with the best looking result. The Magix template rendered with CPU came a close second but with a longer render time.

Musicvid wrote on 3/20/2020, 9:27 PM

the best looking result

For whom? I think that is the only question @john_dennis is asking, and lacking a large polling sample, a subjective consensus of agreement is impossible.

By asking for data, j_d is asking for numbers, not votes to support your impressions, the most useful being those supported by the RQM tool and other metrics.

Howard-Vigorita wrote on 3/22/2020, 8:59 PM

Generally speaking, encodes at High profile yield better looking results for a given file size than Main but are more computationally intense. The Sony encode was done at High while the Magix one was done Main. Try doing both at High and compare that. Might want to also match audio bitrates because that can influence perception too.

Last changed by Howard-Vigorita on 3/22/2020, 9:00 PM, changed a total of 1 times.

Cameras: Canon XF305, JVC GV-LS2, Canon 6D w/L-glass line.
Laptop: Dell XPS15-9570; i7-8750h 32gb (integrated Intel UHD-630 & Nvidia GTX-1050Ti)
Road: Intel NUC i7 8809g 32gb (integrated AMD VegaM 4gb graphics and Intel HD630)
Workstation: i9 9900k 32 gb (Sapphire AMD Radeon VII 16gb graphics and integrated Intel UHD630)
Workstation2: e5 1650v4 128 gb (Sapphire Nitro+ RX580 8gb graphics)
Workstation3: i7-980X 24gb (Sapphire RX480 4gb graphics)
currently Vegas 17.421

Musicvid wrote on 3/22/2020, 9:12 PM

Generally speaking, encodes at High profile yield better looking results for a given file size than Main but are more computationally intense.

Only if the bitrate is less than needed for optimal quality. Useful for streaming.

High Profile yields the same quality at a slightly better compression factor (smaller size) than Main, assuming ≥ optimal bitrates. You are correct that High comes at a price of more processing load.

 

john_dennis wrote on 3/22/2020, 10:06 PM

@Howard-Vigorita

Did you notice that I controlled for final rendered bit rate without regard to the numbers that had to be entered in the template to achieve 13.6 Mbps - 2 Mbps? Even so, the AMD VCE render at Main was better than the Sony at High.

Howard-Vigorita wrote on 3/24/2020, 11:34 AM

I agree with @andyrpsmith that the Sony encode @ High, in accordance with Youtube guidelines, looks better to me on Youtube than Magix rendered @ Main. But that's true regardless of the encoder used. Fwiw, I can't detect any visual difference between the encoders when the profiles, hardware, and bitrates match. I used the Sony encoder for years before switching to the Magix one because it was faster with more resolution and hardware encoding options... but for Youtube I just continue to set the profile to High. The fact that @john_dennis measured a High profile file with a higher error rate suggests to me that it might be achieving more pleasing results by incorporating dither diffusion.

Cameras: Canon XF305, JVC GV-LS2, Canon 6D w/L-glass line.
Laptop: Dell XPS15-9570; i7-8750h 32gb (integrated Intel UHD-630 & Nvidia GTX-1050Ti)
Road: Intel NUC i7 8809g 32gb (integrated AMD VegaM 4gb graphics and Intel HD630)
Workstation: i9 9900k 32 gb (Sapphire AMD Radeon VII 16gb graphics and integrated Intel UHD630)
Workstation2: e5 1650v4 128 gb (Sapphire Nitro+ RX580 8gb graphics)
Workstation3: i7-980X 24gb (Sapphire RX480 4gb graphics)
currently Vegas 17.421

Musicvid wrote on 3/24/2020, 11:51 AM

High Profile relies on a bundle of compression tricks that may have a negative residual effect on quality, depending on source and settings. Theoretically Main should be "better" given an optimal Bandwidth/Quality state, but the encoders are so good now that it rarely makes a difference.