[FFmpeg-user] Is there a way to determine the level of compression

[Cecil Westerhof]

Cecil Westerhof via ffmpeg-user <ffmpeg-user at ffmpeg.org> writes:

> Cecil Westerhof via ffmpeg-user <ffmpeg-user at ffmpeg.org> writes:
>
>> Bouke / Videotoolshed <bouke at videotoolshed.com> writes:
>>
>>>> On 4 Jun 2023, at 13:48, Cecil Westerhof via ffmpeg-user <ffmpeg-user at ffmpeg.org> wrote:
>>>> 
>>>> I most of the time use:
>>>>    -vcodec libx264 -crf 26
>>>> 
>>>> Depending on the video this works great. Often the new size is between
>>>> 1/6 and 1/14 of the original file. But in certain situation the size
>>>> of the new file increases. In those cases I could better use copy. Is
>>>> much faster and creates a smaller video. Is there a way to determine
>>>> the crf value of a video? Then I could use that to determine if I
>>>> should use copy, or not.
>>>
>>> Not that I know of.
>>> But try ’slower’ and ‘fast’ with a HQ source, you’ll see it works.
>>
>> I know it can work, because I have seen files shrinking very much. But
>> sometimes the opposite happens.
>>
>>
>>> Note, on eg documentaires, some shots may come from YouTube or worse, so
>>> the quality of the input codec does not tell you anything.
>>> (If they are camera originals it’s different.)
>>
>> Everything I have been working with was captured with a camcorder, or
>> with a camera.
>>
>> I should probably dig a bit deeper. See if I can find differences
>> between videos that where compressed significantly and videos that do
>> increase.
>
> It looks like videos that are shot in the dark/inside can be
> compressed very much, while videos that are shot outside grow.
>
> Logging from something I shot inside in dark circumstances:
>
>
>
> Input was 2.1 GB output was 289.8 MB. So it was about 1/7 of the original.

By the way, in another thread I talked about '-preset veryfast' being
not only much faster, but also creating smaller files as for example
slower. I was told it was because the low quality of my videos. But
this file was significantly compressed. So I would expect slower to
compress better. Not the case: that creates a 365.3 MB file. So about
a third larger.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00007slower.log
Type: application/octet-stream
Size: 704585 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20230605/0544002a/attachment.obj>
-------------- next part --------------


-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof