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.