tripp <[EMAIL PROTECTED]> added the comment: >> i don't code.
>learn it! that puts you in a losing argument. >for 1 pass BT specifies how hard the RC code should >try to achive CBR >for 2 pass BT specifies how hard the RC code should try >to follow the ideal calculated bitrate curve. i can confirm behaviour on 1 pass, noting that bt doesn;t ever actually output cbr, and that changing bt never forces to a higher bitrate, so that, if say: ffmpeg -i input.m2v -b 8000k -bufsize 1835k -maxrate 9200k out.m2v has an output with av bitrate = 7500kbps then no value of -bt can force a bitrate higher than that, so that it aproaches target bitrate. so back to what i'd first said (paraphrased): if the tendency is to overshoot set bitrate, then by setting a lower bt, forcing RC code closer to cbr, the result will end up closer to target bitrate. However, if the tendency is to uder set bitrate, then by setting a ANY bt, forcing RC code closer to cbr, the result will NOT end up closer to target bitrate. don't know how to confirm on 2 pass. my tests show it useless. although there is alteration in bitrate distribution, most values of bt do the same to the net results of: av bitrate, peak q, peak bitrate, quality. (ok, setting bt to it's minimum is a negative) >now you can document it! (after tesiting and confirming that what i >wrote from memory is correct) sure, if it's not to be reworked, i think it best to use your definitions verbatim. just lost my original msg to this stupid tracker, trying to attach the patch, so i'll send the patch to devel. ty tripp ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue543> ______________________________________________________
