0roo0roo said:
theres no way io is a bottleneck since any encoder worth a damn is reading chunks to work with at a time, if io bottlenecked us we'd be encoding as fast as the file would read, which would blow our minds
Right, as I proved by trying it from my SSD. So the question is, what
is the bottleneck, or more accurately, what is the reason it won't use all available resources at lower resolutions. Obviously if it can handle higher resolutions, it's not going to magically experience a bottleneck that wasn't there for that when doing easier work, so it's something else. My guess is it's something with the design of the codec. Whether or not they know about it, who knows. I'm gonna try one of the x264 builds and see if that has the same problem or if it's just H264.
0roo0roo said:
constant quality is better than 1 pass, but it is still making guesses which makes it unreliable for a certain file size. if you cbr to a certain quality then use that files average bitrate as the starting point for a 2 pass abr encode, the abr 2 pass should be superior since it can adjust once it takes account of the whole files needs, whereas the constant quality can't see that far ahead.
I'm not sure you understand constant quality. It makes no guesses. It simply goes through and looks at each frame individually, determining based on the complexity of that particular frame and the difference between it and the frame before and after it (I may not be 100% accurate here, but the general idea is sound) how many bits to expend on encoding it. This allows it to spend only as much data as necessary on frames that require very little, while spending as much as necessary on more demanding frames/scenes that demand it to maintain a high quality. This way, you avoid having to do 2 passes, so it's quicker, and you get a set quality that will be equivalent to a 2 pass, if not better. So there is no need to "see that far ahead," as it deals with each frame and scene on a case by case basis.
Yes, this does result in an unpredictable file size, but generally I have noticed with the efficiency of 264, they are usually quite small, except for more demanding videos, in which case I don't mind them being larger, as that means it's better quality. And as cheap as hard drive space is these days, what's another 25-50MB per movie if it means quality. Not to mention a lot of times with lower quality videos (cartoons, black and white, et cetera) it'll end up actually being smaller than if you just chose a random target size.
Basically, CQ is the same thing as 2-pass, only it takes just one pass (and is therefore much, much quicker and simpler) and allows for the resulting file size to be smaller or larger depending on the needs of the particular video, not just a randomly selected number that's always going to be a compromise. It's the same thing as VBR (vs CBR) for mp3's, which is a very old concept, and it's surprising it took so long to carry over into the realm of video.
0roo0roo said:
not sure multiple instances work, i tried and it died, guess i'll try it again later.
I'm fairly certain it can be done, but I think you have to use the CLI directly, the GUI isn't capable of it. I've never cared to do this, so I've never bothered to learn how. The HB mods claim there's little to no benefit, and while I mostly agree, I've read that 264 does have some diminishing returns when using more cores (e.g. 100% speed for 1 core, 190% for 2, 275% for 3, 360% for 4, or something to that effect). According to that, it would be faster to run multiple instances, but I don't think it's worth the extra effort, the extra clutter, and the extra hard disk access. If you're reading and/or writing numerous files at once, you're stressing the hard drive a lot more, though I'm not sure if it's enough to be concerned about, since it's not really that demanding. Ultimately, for the small potential gain of running multiple instances, I don't think it's worth it.
I also just noticed they have an option in 0.9.4 to "Enable in-GUI encode status (experimental)." I'll have to try that out.
Edit: I just tried the in-GUI status and I'm not exactly impressed. It still launches the CLI window, just doesn't show anything in it and it shows the status in the very bottom of HB instead. Pretty useless IMO. Now if they had it display in the title bar, so you could see the % complete on the taskbar, that'd be something.