How much work do I have to do to balance things out? There doesn't seem to be a way to drop the bitrate for an unimportant section and have HCEnc just give the resulting extra bits to something else. When I tried doing that one time, it dropped the bitrate in that area and did nothing to the rest of it, resulting in a smaller file and no boost to the non-zoned areas.
So do I have to create high-bitrate zones as well? Do the numbers need to match perfectly?
+ Reply to Thread
Results 1 to 16 of 16
Are you using bitrate based encoding? Then the other parts of the video should automatically increase in bitrate -- unless they have already reached the specified max bitrate. I ran a quick test and that's how it worked here. Keep in mind that if you only lowered the bitrate in a small section the increase in the reset of the video will be small.
But don't you only mark the start of the zone? Say I wanted the first five minutes to be lower-bitrate, so I'd enter frame zero and then a number, say 0.4. Then frame 7500, and another number, which starts the next zone. Or does entering a zone with a value of 1 mean "no zone"?
i am using hybrid, and there you choose start and end of zone. In chapters i believe you choose just and only start. Noticed zones are in hybrid only at x265, probably overlooked something.
So without end zone seems to me be weird, but of course can work.
As usual dont take my answer as 100%. Probably nor 20%
Here's what is says in the HCenc manual
parameter nr. of zones type integer
Status not required
This command raises or lowers the bitrate for parts of the video.
The example will raise the bitrate starting at frame 1200, reset to normal at frame 1500 and lowers
the bitrate starting at frame 2700.The number of zones is limited to 6400.
Right, so my question is does the "normal" at 1500 mean the bitrate entered into the average bitrate field on the main tab, or does it adjust that to allow for the other zones?
Additional question, regarding CQ encoding: which is better, low numbers or high?
I have a menu that I encoded at 4.0, which came out at 16,761 KB. Encoded at 2.3 it came out at 36,294. That implies lower numbers are better. But my main-content video encoded at 2.3 is 7,367,019 KB and at 1.5 is only 7,113,033 KB. That implies that higher numbers are better.
Lower CQ gives better quality and higher bitrates. I've never seen a lower CQ give a higher bitrate unless something else was changed.
Odd. I definitely didn't change anything.
I can't get my bitrate calculations right either. I have a few extras, a few motion menus and a main movie to put onto a disc. Step one, encode them all at different CQ values - main movie higher quality than the extras, extras higher quality than the menus.
Step two, put every video file onto one timeline in Premiere, which gives me a length of 02:32:39:11.
Step three, plug that into VideoCalc, add 100MB of extra files to give myself breathing room and add a 224kbps audio track.
VideoCalc lists a total video size of 7789.56MB.
All my CQ files currently add up to 8,721,936 KB.
For each video file, divide its size in KB by 8,721,936. This tells me what percentage of the total file size belongs to that file.
Multiply that percentage by 7789.56, round it down. This gives me the size it should be, in MB, to still fit on the disc with everything at the same relative quality.
Remove the audio track and 100MB padding from VideoCalc, set a custom disc size of however big that file is supposed to be, this gives me the target bitrate for that file in kbps.
Encode at that bitrate using HCEnc.
This way I can still get all my footage on the disc, while maximising the quality of the main movie.
Everything has come out under target. VideoCalc allowed 7789.56 MB for video, all the target sizes I calculated add up to 7781 MB. The actual generated files are all very close to, if not under, the target. One targeted 99MB and came out at 96.4, another targeted 206 and came out at 200. Total size is 7.42 GB, which is well below 7781MB. And yet, Encore reports 8.54GB used, and refuses to author my disc.
Yes, beware that some programs use K, M, and G to mean 1000, 1000000 (1000 * 1000), and 1000000000 (1000 * 1000 * 1000). Others mean 1024, 1048576 (1024 * 1024), and 1073741824 (1024 * 1024 * 1024).
8721936 is the total for the CQ encode, not the VBR encode. The CQ encode obviously isn't designed to fit on the disc, it's just to work out what the relative bitrates should be. Column D is what I'm trying to get on the disc.
Now that I'm at my computer and can see the exact numbers again:
Allowing for an extra 100MB and an audio track, VideoCalc says the video files can take up 7789.56MB of space.
According to the math, the video files should take up 7781MB of space.
According to Windows Explorer, the video files take up 7.42GiB. Which is either 7598MiB or 7967MB. If VideoCalc is also using MiB then we're 200MiB under and should have a ton of free space. If VideoCalc is using MB then it's 200MB over and we have a problem. But, since my target video size for the project, of 7789.56, was calculated in VideoCalc and the target file size of each file is also calculated in VideoCalc, it shouldn't matter what "MB" means in VideoCalc.
As it applies to the main movie file, here's the math:
After a CQ encode with CQ 1, it was 92.02% of the final output from the CQ encode. VideoCalc says I can use 7789.56MB for video. 92.02% of 7789 is 7167. VideoCalc says that to have that file be 7167MB, it must be encoded at 7066kbps, so I used HCEnc to do that.
The only place I can see an issue is if VideoCalc and HCEnc are defining "kbps" differently, so maybe I should be using 6738kbps in HCEnc? I've been encoding from VideoCalc's math with HCEnc for ages without issue, though - including a project structured almost identically to this the other day. The 7066kbps-encoded file comes out at 6.83GiB.
Windows will tell you the exact size of a file in bytes -- right click and select Properties. Also keep in mind that VOB has significant overhead compared to M2V. If I was you I'd shoot for 5 percent less than the full disc capacity. You won't see any difference in quality. And you won't have to worry about files turning out too big to fit.
As I say, I've got a 100MB buffer. Not sure what 5% is, but the fact that I'm overshooting my target by 300MB seems like a concern?
The main movie came out at 7,342,234,565 bytes. Or 7,342,235,658 bytes. Not sure what those two sizes are, or what that suggestion relates to.