Target size is the right interface for this. Most people don't think in CRF values, they think "it has to be under the upload limit." For README demos in particular, GitHub's cap on video attachments is the constraint I hit most, so a tool that just takes a size is handy.
Does fp do a two pass encode to land on the size, or does it calculate a bitrate and accept some overshoot? And does it drop the audio track automatically when the target is tight? For silent screen demos that's free space.
thanks and yeah that's exactly why i wanted the target size interface instead of making users deal with CRF values themselves.
currently fp uses a bounded CRF search, encoding candidates and measuring their actual output sizes rather than relying solely on bitrate calculations and it doesn't automatically drop audio when the target is tight yet but an optional --no-audio flag sounds useful especially for the screen recordings. appreciate the suggestions.
Measuring real output sizes is the right call. Bitrate math tends to miss on screen recordings because most frames barely change. For those, one more option worth considering is a frame rate cap, like 15 or 30, applied before the search. A UI walkthrough rarely needs 60, and dropping frames often keeps text sharper at the same size than raising CRF does. With that and the no-audio flag, a README clip under a size limit gets a lot easier.
DemoVexa
Target size is the right interface for this. Most people don't think in CRF values, they think "it has to be under the upload limit." For README demos in particular, GitHub's cap on video attachments is the constraint I hit most, so a tool that just takes a size is handy.
Does fp do a two pass encode to land on the size, or does it calculate a bitrate and accept some overshoot? And does it drop the audio track automatically when the target is tight? For silent screen demos that's free space.