On 12 May 2015, at 16:32, Henk D. Schoneveld <[email protected]> wrote:
> > On 12 May 2015, at 15:50, Werner Robitza <[email protected]> wrote: > >> On Tue, May 12, 2015 at 3:16 PM, Henk D. Schoneveld <[email protected]> >> wrote: >>> >>>> On 12 May 2015, at 13:50, Werner Robitza <[email protected]> wrote: >>>> >>>> On Tue, May 12, 2015 at 11:47 AM, Henk D. Schoneveld <[email protected]> >>>> wrote: >>>>> Would you be so kind to explain why to NOT use the crf option? >>>> >>>> CRF is essentially a constant quality mode, which results in variable >>>> bitrate depending on the spatiotemporal complexity of the scenes. >>> Your goal is max quality within a given link-capacity I assume. >>> Upfront choosing an arbitrary bitrate to achieve max possible quality seems >>> sub-optimal/contradictionary to me. >>> A. to many bits for talking heads >>> B. to few bits for action dominant events. >> >> Yes, but that's still what's typically done, unless you choose a CQ >> encoding type with a max-rate (which is what libvpx recommends too). > But libvpx is much less efficient than libx264 for the same quality. >> >> You should've mentioned that you're experienced with this -- otherwise >> I would've given a different answer. > Hm what difference does it make if I know a little bit more or less to > how/what you’re answering ? > Another option to ‘optimise’ quality for a given bitrate is to use anamorphic > encoding. I know YouTube doesn’t accept that but all modern players I know of > handle it without any problem. > For 720p I use -s 880x720 which works for me pretty well. With this you’ll > get a reduction of (1280-880)/1280=31% in needed bits for very reasonable > quality. At least a lot better then reducing the bitrate by that % and using > 1:1 ie. -s 1280x720 encoding. Test results by doing as forementioned 2442734 May 12 2015 Source_Code-crf22-1280.mp4 1656672 May 12 2015 Source_Code-crf22-880.mp4 2045725 May 12 2015 Source_Code-crf23-1280.mp4 1403091 May 12 2015 Source_Code-crf23-880.mp4 This are video only files. >> >>> I see the difference between the methods, but I don’t really understand >>> what it’s trying to tel me. What does the X-axis say, total >>> stream-size/#frames/ ? >> >> It's the frame number (index) in a 3 minute sequence. >> _______________________________________________ >> ffmpeg-user mailing list >> [email protected] >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
