[FFmpeg-user] Fast encoding

Henk D. Schoneveld belcampo at zonnet.nl
Fri Aug 14 15:30:14 CEST 2015


On 14 Aug 2015, at 15:07, Robin Lery <robinlery at gmail.com> wrote:

> Hello sir, I am sorry I am very new at this. Would you please elaborate
> more, I didn't get you.
For a program where 2 persons are talking an a studio, 80% of the screen stays the same, low bitrate is fine
If it’s a sports-event like baseball, every changes constantly, high bitrate is needed.
What’s needed depends. If you chose a low bitrate it’s too low for sport, if you choose High it’s too much, in the sense of wasted, for the ‘talking heads.
Exactly this solves CRF/Constant quality.
CRF can also be lowered or heightened by choosing another then the default value of 23.
Lower numbers give higher quality, counter intuitive but that’s how it works.
Try some examples and see what your outcome bitrates will become. Further the amount if bits you ’spend’ on audio depends, is it a good quality music peace or just 2 persons talking with each other.
Trying wil help you understand how these things work. Happy learning.  
> On 14 Aug 2015 18:28, "Henk D. Schoneveld" <belcampo at zonnet.nl> wrote:
> 
>> 
>> On 14 Aug 2015, at 14:46, Robin Lery <robinlery at gmail.com> wrote:
>> 
>>> Hello,
>>> Thank you for your guidance. Actual the videos that I'll be encoding are
>>> for web video, so I think the bit rate matters. And as for the threads I
>>> want to use all the threads possible. I think -threads 0 balance the
>> loads
>>> across all the cores automatically. What would be the best ffmpeg command
>>> in your opinion for fast encoding with constant specified bit rates (i.e
>>> 500k and 1000k)?
>> ConstantBitrate is too much or too little
>> CRF/ConstantQuality is ….
>>> 
>>> Thank you.
>>> 
>>> On Thu, Aug 13, 2015 at 7:43 PM, Moritz Barsnick <barsnick at gmx.net>
>> wrote:
>>> 
>>>> On Thu, Aug 13, 2015 at 09:03:48 -0500, Steve Boyer wrote:
>>>>> On Wed, Aug 12, 2015 at 11:03 PM, Robin Lery <robinlery at gmail.com>
>>>> wrote:
>>>>>> I know about presets but faster presets lose the video quality. Are
>>>> there
>>>>> 
>>>>> It's my experience that CRF more directly affects the quality, and
>>>>> presets more influence filesize and encoding speed; a preset of slow
>>>>> will be ABOUT the same quality as veryfast but the bitrate between the
>>>>> two would be drastically different (in my opinion and eyes).
>>>> 
>>>> The presets were designed to trade off speed versus size, using the
>>>> same CRF and thereby (approximately) the same quality. But Robin is
>>>> using:
>>>> 
>>>>> -maxrate 1000k
>>>> 
>>>> thereby limiting what the encoder can achieve in terms of quality.
>>>> 
>>>>> I've used -threads=1 successfully after input, before output file name.
>>>> 
>>>> Did Robin want to use more threads, or less? I understand ffmpeg
>>>> automatically tries to choose the right amount of threads.
>>>> 
>>>> (That said, my libx264 claims: "Threading capabilities: no", but I read
>>>> differing stuff on that.)
>>>> 
>>>> Moritz
>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> ffmpeg-user at ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>> 
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> ffmpeg-user at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> 
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> 
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user



More information about the ffmpeg-user mailing list