Best lossless codec to render small files in Quad HD, UHD (4K, 8K,...)

fr0sty wrote on 7/7/2019, 12:47 PM

Youtube only accepts certain formats, so you need to keep that in mind when choosing your intermediate.

.MOV (This is vague, as it is a wrapper format that can contain a number of codecs that won't all necessarily work.)

.MPEG4

.MP4(This is vague, as it is a wrapper format that can contain a number of codecs that won't all necessarily work.)

.AVI (This is vague, as it is a wrapper format that can contain a number of codecs that won't all necessarily work.)

.WMV

.MPEGPS

.FLV

3GPP

WebM

DNxHR - Good Choice

ProRes - Magix Intermediate is the Vegas flavor, not sure if it will work.

CineForm - Good choice

HEVC (h265)

john_dennis wrote on 7/7/2019, 1:01 PM

"my goal is to render with the least possible compression to upload the video to youtube."

Get the Happy Otter Scripts extension for Vegas Pro. Render to x264 at a CRF that suits your level of pain for file size and render time vs. Video Quality.

Inside of Vegas Pro 15 and above, I use AMD VCE for quick renders that youtue is going to destroy anyway.

john_dennis wrote on 7/7/2019, 1:09 PM

You asked the same question in 2018, but HOS had not been announced then. Consider building custom scripts to further slice and dice the number of P and B Frames and Group of Pictures. I'm sure you'll find all kind of things to worry about when you open that box.

Musicvid wrote on 7/7/2019, 4:41 PM

Uploading "least compression" or "largest file size" to YouTube is not a goal, because Youtube mangles everything it is given to exactly the same mediocre quality. YouTube upload

recommendation for 4k 50-60p is 60 Mbps. Proof is here:

https://www.vegascreativesoftware.info/us/forum/wagging-the-dog-effects-of-hyperoptimal-youtube-upload-bitrates--114098/

You are entirely safe with @john_dennis advice, without wasting all that rendering, upload and processing time.

That said, here is the software intermediate shootout. I can't tell you which, if any of these encoders can be digested by YouTube.

fr0sty wrote on 7/7/2019, 9:27 PM

While Youtube is going to crunch it down to the same bitrate regardless of input signal, I can still understand the want to make that input signal as clean as it can possibly be. Why add more artifacts than there already will be added by Youtube if it can be avoided? That said, it'll take a magnifying glass and some luck to spot the difference, most likely. I usually stick with VCE unless it is a high profile project that I want to look as perfect as possible.

Musicvid wrote on 7/7/2019, 9:36 PM

One will probably not see shadow noise above 30 PSNR [corrected]. Everything we're talking about is hyperoptimal.

oscarleethr25 wrote on 7/8/2019, 3:53 PM

Hi. My main problem was that I could not export in 4K. My project was very complex and had a lot of effects on the clips and the master channel. My only solution was to make prerenders in new tracks grouped by regions and mix everything in a new project. It was the only solution with which I could export 4K using the GrassValley HQX codec. It does not hurt to mention that my computer is a garbage. I leave the final result if you want to watch it; it would be an honor. I actually uploaded the .avi file coded with Grassvalley (3gb). The render and uploaded took me 20 minutes. Greetings.

Edit* I rendered it in Quad HD (2560x1440), not in 4K. The original video was filmed in 4K. If QHD gave me a lot of problems, I do not want to imagine 4K rendering.

Musicvid wrote on 7/8/2019, 4:03 PM

Use HEVC for 4k rendering.

Former user wrote on 7/8/2019, 4:27 PM

oscarleethr25, I see many black frames in the video. Are these part of the creative? Specifically around 53 seconds.

oscarleethr25 wrote on 7/8/2019, 5:57 PM

oscarleethr25, I see many black frames in the video. Are these part of the creative? Specifically around 53 seconds.

Its part of the creative. The black frames follow the percussion

Use HEVC for 4k rendering.

Thanks for the advise. ¿Magix HEVC its ok? It offers me two encoding modes: Intel QSV and Mainconcept HEVC. ¿Wich one is best? ¿Is there any difference?

oscarleethr25 wrote on 7/8/2019, 6:20 PM

That said, here is the software intermediate shootout. I can't tell you which, if any of these encoders can be digested by YouTube.

Until now I have uploaded to Youtube files encoded with Magic YUV, Sony YUV and GrassValley to Youtube without any problem.

Uploading "least compression" or "largest file size" to YouTube is not a goal, because Youtube mangles everything it is given to exactly the same mediocre quality. YouTube upload

recommendation for 4k 50-60p is 60 Mbps. Proof is here:

I will be honest, I know absolutely nothing of programming, computer science and other technical questions related to video formats, their coding, compression, etc. I'm just a normal guy who likes to make music videos: transitions, color correction (I actually know how to use scopes, and that's a miracle), etc. The reason why I ask these questions about format, codecs, etc. is because I like to give the viewer the best possible visual quality.

I do not understand absolutely anything about the image you share (the proof), nothing at all. The worst thing is that I almost do not know English and I'm using Google to try to translate what I want to express and translate what you write.

What I am about to say is merely subjective, but I like the final visual result more (I repeat, this is merely subjective) when I use an intermediary codec to upload my files to YouTube than when I use h.264 (even at high rates of bitrate). Maybe this will change when I understand whta you talking about ¡Jajajajaja!

Musicvid wrote on 7/8/2019, 6:33 PM

Not Rocket Science. There is a legend for the color coding.

Yellow is relative file size.

Maroon is PSNR (also known as Shadow Noise). Anything over 30 you will never see a difference. 422 is relatively lower because it uses more compression, thus smaller file size.

Blue is SSIM (accuracy aka "quality.")

The only way any of us ever learned a thing is by making lots of mistakes! Go for it and make your own choices. They will not be worse than anyone else's choices! Good luck.

Here's a basic vocab and tutorial you should become familiar with.

https://www.vegascreativesoftware.info/us/forum/speaking-good-video-a-beginner-s-guide--104463/

fifonik wrote on 7/8/2019, 8:05 PM

Maroon is SSIM (accuracy aka "quality.") Anything over 30 you will never see a difference.

I'm probably missing something, but by its formulas SSIM measured -1 to 1 (1 -- they are exactly the same)

https://en.wikipedia.org/wiki/Structural_similarity

In order to evaluate the image quality, this formula is usually applied only on luma, although it may also be applied on color (e.g., RGB) values or chromatic (e.g. YCbCr) values. The resultant SSIM index is a decimal value between -1 and 1, and value 1 is only reachable in the case of two identical sets of data and therefore indicates perfect structural similarity. A value of 0 indicates no structural similarity.

Original paper: http://www.compression.ru/video/quality_measure/ssim.pdf

30(%? how -1 to - 1 range was converted to percent?) is extremely bad and almost everyone will notice different with so low SSIM value.

You can check images d, e, f on page 3 in original paper. All are with with SSIM > 0.6

Musicvid wrote on 7/8/2019, 8:28 PM

Pardon the loose reference and misattribution. Corrected. Of course I meant PSNR >30%, which is about where 4:2:0 comes in. On my chart, numbers are in % for uniformity, not 0-1.0 decimal.

fifonik wrote on 7/8/2019, 8:43 PM

PSNR is measured in dB (not %) and 30dB is also quite low for noticing differences.

https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio

See the 4th image with PSNR = 31db. I bet majority will notice something strange in the image.

P.S. Could you please edit your fist message about SSIM as well and it is really misleading.

Musicvid wrote on 7/8/2019, 9:07 PM

Done. If you can make a better graph, showing relative differences on a uniform scale factor, using your own original test data, feel free to upload it, in the spirit of the inquiry (OP seems pretty forgiving...)

"On my chart, numbers are in % for uniformity."

Former user wrote on 7/9/2019, 3:06 AM

Here are some different file types and quality comparisons.

Musicvid wrote on 7/9/2019, 8:22 AM

Thank You,, @Former user !

oscarleethr25 wrote on 7/9/2019, 9:02 AM

Sorry to botter you.

Does someone know how to codify when using Magic HEVC? Shoul I use Mainconcept HEVC or Intel QSV?

Musicvid wrote on 7/9/2019, 9:09 AM

I think the nod goes to Intel QSV.

oscarleethr25 wrote on 7/9/2019, 9:14 AM

Thanks for all the good talk. I promise to read "Speaking Good Video - A Beginner's Guide".

rraud wrote on 7/9/2019, 11:02 AM

Does someone know how to codify when using Magic HEVC? Shoul I use Mainconcept HEVC or Intel QSV?

On my laptop (Dell 9550), with a 15 sec title page file, the HEVC MainConcept encoder was 'slightly' faster.. and but the file size was about 2x that of the Intel QVS. The QVC codec flicked some with the MPC player, but played back fine with Video LAN... whereas the MC file on the LAN player was totally out of whack in terms of size, aspect ratio and color.
All the render parameters were identical (except the codec of course) The vbr bit rate was set @ 30,000,000 x 15,000,000 mbps

oscarleethr25 wrote on 7/9/2019, 11:49 AM

On my laptop (Dell 9550), with a 15 sec title page file, the HEVC MainConcept encoder was 'slightly' faster.. and but the file size was about 2x that of the Intel QVS. The QVC codec flicked some with the MPC player, but played back fine with Video LAN... whereas the MC file on the LAN player was totally out of whack in terms of size, aspect ratio and color.
All the render parameters were identical (except the codec of course) The vbr bit rate was set @ 30,000,000 x 15,000,000 mbps

I actually try to render an .avi file coded with Grassvalley using Intel QSV, but I didnt make it. The result was a corrupt file, with bad audio and errors in the image. Then I use Mainconcept HEVC and problem solved.

I want to add something:

When I render using Grassvalley HQX, the render is much faster than when I render using h.264 or h.265 at high bit rates. I do not know if this has to do with the amount of compression applied to the file. After that, the delay is uploading the file to YouTube; a three-minute QHD video rendered with Grassvalley, and with a weight of 3GB, took between 15 and 20 minutes to upload. Even with this delay, I find it much faster to use Grassvalley HQX to upload material to Youtube, than to do a rendering using h.264, because the time I saved in uploading the file to YouTube using h.264, actually triples at the time of rendering with that codec. Of course, we must bear in mind that it is a very personal experience and that my internet and computer speed influence everything. Im only sharing my personal experience.

Musicvid wrote on 7/9/2019, 12:17 PM

You have referred many times to Grass Valley HQX. It is an INTRAFRAME (ALL-I) encoder, so valid comparisons would be to ProRes 4:2:2, XAVC-I, DNxHD, Magic YUV 422, UT 422, Sony YUV, and the like.

One thing to avoid is comparing apples with oranges. H264, h265, HEVC, VP9, are all INTERFRAME Long-GOP solutions, so any comparisons with regard to speed and size are completely meaningless, because of the different compression methods used.

Also, Long-GOP interframe encoders are not generally considered good candidates for intermediates, because of encoding and generational losses. These are usually considered as good DELIVERY codecs.

So it may help to keep your focus on Intraframe solutions, such as you are used to, and should be using for your intermediates. Leave the playback codecs in a separate place, and use them for their mainstream purpose.

That said, Grass Valley (Edius) codecs were excluded from my tests owing to compatibility (ffmpeg, libav) issues and lower-than-average Chroma Subsampling accuracy compared to the other intraframe solutions tested. This was quite a while back.