
This is the highly recommended route which is slower but more reliable. render out to lossless image sequences (say pngs) and use an external app to encode to a delivery codec and mux video and audio. This is the route I usually take and have had no problems with it so far. You can then use some external app (say FFmpeg, Avidemux etc) to encode the original HuffyUV video to a delivery codec of your choice, setting the bitrate to whatever you like. In this case, rendering will usually be lightning fast (as it’s not heavily compressed). render out to a lossless codec such as HuffyUV. If you feel that rendering is limiting whatever you want to produce there are two main solutions:

AVIDEMUX BITRATE TOO LOW FULL
SD footage at 30mbps? Sure, if it is uncompressed or something.Įven the max bitrate for Blue Ray is 25 mbps and that at a full HD resolution which is 6 times more than the SD resolution.ītw, my 550D records at 43 mbps but that’s 25 fps at full HD. For example, SD DVD video is typically at about 5 mbps (and can go up to 10mbps). I’m not sure if you realize just how high a bitrate that is. the max bitrate that can be set is ~14mbps but this is the delivery codec we’re talking about here. So, this answers my question :) Sadly no GPU-encoding for me, although much faster, the quality is not useable in my opinion.Your observation is correct, i.e. The GPU-encoded quality is really blocky, the software-encoded is totally fine.
AVIDEMUX BITRATE TOO LOW SOFTWARE
When using the Apple VideoToolbox vs the software encoder (-x265) with the same bitrate (2500kbps) the software encoder is significantly slower (although still about twice as fast as Handbrake) but creates much better quality. I investigated further and the quality seems to depend heavily on the encoder (GPU vs software). And your usecase is different (BR as source). But you made your research, I dont need to know in detail. I had good results with Handbrake and constant quality (RF20.5), files are noticeably smaller than the source (high bitrate h264 for me) and still had a good quality. But why it is better than constant quality is not obvious to me (even after reading your FAQ) since it is in my understanding basically the same as ABR with even more freedom to allocate more bitrate in demanding scenes. I understand that ABR is much better than CBR of course. Of course this will degrade the quality a little, but with high bitrate h264 as the source and enough bitrate for h265 this is usually nearly invisible to me and ok for the size benefit. I want to convert h264 to h265 since it saves around 40%-50% space. I mistyped the first h264, sorry (edited now).

This means that the encoder is allowed to adjust bitrate allocation to accomodate complexity and mitigate the risk of blockiness or other artifacts. Rather than limiting the maximum bitrate to the same value as the target, the other-transcode tool selects an average bitrate (ABR) ratecontrol system. And color banding is actually much more noticeable than artifacts like blockiness in high-motion scenes.


It seems counterintuitive, but targeting a specific bitrate makes it much more likely that in those low-motion scenes where the eye can linger, that enough bits are allocated to prevent color banding. This is because using a fixed quality level can result in output larger than its input or, worse, output too low in quality to be mistaken for that input. The ratecontrol systems used by the other-transcode tool target a specific bitrate rather than a fixed quality level. Selecting the best system and then properly configuring it is key to high-quality video transcoding. Most encoders have more than one ratecontrol system available. Ratecontrol is how a video encoder decides on the amount of bits to allocate for a specific frame. The ratecontrol systems used by the other-transcode tool are designed to minimize that as I explain here:
AVIDEMUX BITRATE TOO LOW 1080P
This is because neither FFmpeg nor HandBrake will retain that HDR data.Īnd, frankly, if you already have a 1080p video at 5000 Kbps, why would you ever want to re-transcode it? This is just a waste of time.Īlso realize that you will always degrade quality when transcoding. Transcoding HEVC to HEVC again is never a good idea if the original HEVC content contains HDR color information.
