Encoding; do some editors go overboard or not?

[Possessed]

I think having multiple encodes at different sizes for different peoples needs is a good idea. For some people a "streaming" size is sufficient, and for others a bluray sized render is worth it.

 

[Hal9000]

Having mostly focused on Star Wars after years of hyperfixation on minutia of the original trilogy and maximizing LaserDisc source material, I have kept ProRes outputs of my projects so that in theory someone could pick them up and carry forward the task of endlessly messing with them.
I've also made sure to export at maximum BluRay quality in order to make them as suitable as possible for exhibiting in a theater, even though I know that won't ever happen. But I do provide much smaller file options in addition.

 

[Possessed]

Having mostly focused on Star Wars after years of hyperfixation on minutia of the original trilogy and maximizing LaserDisc source material, I have kept ProRes outputs of my projects so that in theory someone could pick them up and carry forward the task of endlessly messing with them.
I've also made sure to export at maximum BluRay quality in order to make them as suitable as possible for exhibiting in a theater, even though I know that won't ever happen. But I do provide much smaller file options in addition.

Hey if it makes you feel better I've watched your prequel edits in my theater and they looked great It's only 120 inches on the screen but it is a dlp cinema projector so for a living room can't complain. And your edits looked good on it

 

[Hal9000]

Well hey, that’s what’s it’s all about. lol

 

[catferoze]

It should be noted bitrate alone is not the answer. NLE's suck at encoding to H264 and H265. Some videos, no matter how high you adjust the quality in the Non Linear Editor (NLE,) it will have major blockiness in dark scenes in smooth areas of the picture or the background. Resolve, Premiere, and FCPX are all guilty of this. They have not built a quality encoder like Handbrake has. I'd imagine Vegas is probably in the same boat as well. Best practice is to use the highest quality Prores you are willing to use or even better yet Cineform (Film 2) as the codec for exporting from the NLE.

This was most helpful! I was still sometimes getting blocky dark scenes exporting h264 at 20-30 Mbps from Premiere/Media Encoder and getting almost 30GB file sizes. Exporting as ProRes and encoding with Handbrake to h264 produced superior results with less than 1/3 the size! Thank you!

So you can use zones in the command line to set a quality of crf 20 for the whole movie, but during exegol scenes it raises the crf quality to something like 13.

Went through the Handbrake documentation but couldn't figure out how to do this. Can I get a hint?

 

[krausfadr]

@catferoze I'm glad this helped!

Zones can be used with a lot of adjustable parameters in H264. Decent but not quite as robust in H265. I did use it in Handbrake when encoding Dune the Mindkiller Cut in H265 though.

Here was my workflow: I made a test encode in Handbrake with crf of probably 20 which looked great for 98% of the movie. I viewed the test encode for artifacts and found the following three scenes had unacceptable blocking in dark/flat areas, and I made the following notes:

01:24:39 - 01:28:26 thopter night, green, base burns
01:29:07 - 01:29:14 night sands (after baron eating)... stop inside tent.
02:01:18 - 02:10:49 after sandwalk lesson NIGHT DESERT. end on sunrise after " I accept her champion"

Based on the above timecodes I converted these figures to frames. The math looks like this: 01:24:39 = 5,079 seconds. 5079 x 23.976 = 121,774 frames

My command line in Handbrake looked like this (typically I reduce the first frame by one and increase the second frame by one):

zones=121773,127218,b=3/128199,128369,b=3/174496,188189,b=3

The above command created three zones to use an increased bitrate. The numbers are frames. So the first zone is from frame 121773 to frame 127218. b=3 means to increase the bitrate 3X for those zones. H265 can only use a bitrate mutiplier (b) in the command line.

When zones are used in H264 then the parameter b can be used as a bitrate multiplier. Also in H264 crf can be used instead of b to change the quality; let's say the main encoder is set to 20, you can zone those three parts with a crf of 13. It would look like this:

zones=121773,127218,crf=13/128199,128369,crf=13/174496,188189,crf=13

I made a spreadsheet which will automatically calculate frames based on timecodes, if anyone is interested, PM me..

: )

 

[DigModiFicaTion]

@catferoze I'm glad this helped!

Zones can be used with a lot of adjustable parameters in H264. Decent but not quite as robust in H265. I did use it in Handbrake when encoding Dune the Mindkiller Cut in H265 though.

Here was my workflow: I made a test encode in Handbrake with crf of probably 20 which looked great for 98% of the movie. I viewed the test encode for artifacts and found the following three scenes had unacceptable blocking in dark/flat areas, and I made the following notes:

01:24:39 - 01:28:26 thopter night, green, base burns
01:29:07 - 01:29:14 night sands (after baron eating)... stop inside tent.
02:01:18 - 02:10:49 after sandwalk lesson NIGHT DESERT. end on sunrise after " I accept her champion"

Based on the above timecodes I converted these figures to frames. The math looks like this: 01:24:39 = 5,079 seconds. 5079 x 23.976 = 121,774 frames

My command line in Handbrake looked like this (typically I reduce the first frame by one and increase the second frame by one):

zones=121773,127218,b=3/128199,128369,b=3/174496,188189,b=3

The above command created three zones to use an increased bitrate. The numbers are frames. So the first zone is from frame 121773 to frame 127218. b=3 means to increase the bitrate 3X for those zones. H265 can only use a bitrate mutiplier (b) in the command line.

When zones are used in H264 then the parameter b can be used as a bitrate multiplier. Also in H264 crf can be used instead of b to change the quality; let's say the main encoder is set to 20, you can zone those three parts with a crf of 13. It would look like this:

zones=121773,127218,crf=13/128199,128369,crf=13/174496,188189,crf=13

I made a spreadsheet which will automatically calculate frames based on timecodes, if anyone is interested, PM me..

: )

Krausfadr (left), DigModiFicaTion (right)

 

[Wraith]

For me it is nowhere close to enough.

All of my edits have final versions that are 25 Mbps or higher to fill up BD-25 (usually 21-23 GB) which I always burn on the disc.
Versions released are usually 8-12 GB, so the bitrate is lower. I've shared some full size versions of my edits but people usually didn't care so I stopped doing that. But for my personal needs it is always full blu-ray and it needs to be fully compatible with the standard, so no cropping black bars, ac3 audio (stereo or 5.1).

Ditto on all of the above.

I make some of my larger files available, but demand for them is low and they take up a lot space on Service Provider's drives. I then render a conversion to about 7.5mbps for the MP4...which I agree that 4mbps is suffcient, but it does help especially if a movie is dark, has a lot of red or smoke/fog/mist...these are especially prone to pixelation.

I also usually edit the raw M2TS and render using the same specs as the source...incredibly, this can be quite varried for what should be a consistant Blu Ray standard.

 

[Bailey]

Krausfadr (left), DigModiFicaTion (right)

Me too, Dig, me too...

 

[Silver Screen Samurai]

I tend to follow what streaming sites use as their delivery as a guide. Depending on which service you download from, industry range/standard for 1080p seems to be between 6000kbps and 12000kbps for video and at least 320kbps AC3 audio files. Even at 6000kbps, you still have an inferior encoding vs a 1:1 bitrate with a source disc. For Blu Ray sources I tend to encode final renders at 10000kbps or 15000kbps for video and match or max aac 5.1 bitrate.

In my experience, I just checked the specs at Blu-Ray.com and went with that. For example, "The Wolverine" was encoded to disc at 35.69 MBits (35,690 Kbs). So I encoded it at this same bitrate, and exported the final file at this same bitrate.