/webm/ - WebM

>>1693
why the fuck would you use mp4 instead of webm?

>>1710
I don't know, faster to encode, better quality with x264, perfect bitrate control so you can fit your videos in the 8MB limit, much better tools to convert, ability to export from any video editing software, you name it.

>>1715
>a container has better quality
oookay, bud.

>>1722
Don't play dumb, I was obviously talking about H.264, which is the whole point of using MP4.

>>1715

> perfect bitrate control so you can fit your videos in the 8MB limit

Someone doesn't know how to encode.

>>1839
Is that right? Teach me how to make VP9 to respect the bitrate in 2 passes, like x264 does.

FFmpeg parameters, please.

>>1854
>Lets make this clear, WEBM is a container, VP9 is a video compression standard.

No shit

>VP9 is complete garbage because of it's crazy long encode times; don't use it.
True, but VP8 is just too shitty compared to any decent h.264 encoder.
So yeah, maybe you can get a decent bitrate control in VP8, but shitty in-loop deblocking. Why not both?

And VP9 does NOT respect the target bitrate in 2-pass mode.

>Here's how you encode for a target filesize without fucking up the quality too bad:

I can use a calculator, thank you.

The script relies on a decent 2-pass bitrate control, wich VP9 doesn't have. Switch libvpx to libvpx-vp9 and watch it fails miserably

>>1854
Wait, I just saw the script tries to encode the file multiple times until it reaches the target size.

THIS IS INSANE

And proves my point. Any decent encoder should respect the target bitrate in 2-pass mode, that's the major point on doing 2 passes in the first place.

>>1856
>Wait, I just saw the script tries to encode the file multiple times until it reaches the target size.

>THIS IS INSANE

So neuter the script. If you remove the bits that attempt to maximize the usage of the filesize limit, it typically produces a usable, decent encodes the first time.

Since your too stupid to figure out the core of the entire thing:

bitrate=$( ($filesize * 8192) / $time) - $audio_bitrate - 10 )


quality_decrease=2.5
source_bpp=$( ($source_bitrate / $source_area ) / $quality_decrease )
resize_area=$( $bitrate / $source_bpp )
resize_height=$( $source_height * ($resize_area / $source_area) )
if [ "$resize_height" -ge "$source_height" ]
then
resize_height=$source_height
fi
resize="-vf scale=-1:${resize_height}"




ffmpeg -y -i "$source" -c:v libvpx -threads $thread_number -auto-alt-ref 1 -slices 1 -lag-in-frames 16 -cpu-used 0 -keyint_min 0 -g 360 -qmin 4 -qmax 63 -quality good -minrate ${bitrate / 10}k -maxrate ${bitrate * 4}k -b:v ${bitrate}k ${resize} -an -pass 1 -f webm /dev/null

ffmpeg -y -i "$source" -c:v libvpx -threads $thread_number -auto-alt-ref 1 -slices 1 -lag-in-frames 16 -cpu-used 0 -keyint_min 0 -g 360 -qmin 4 -qmax 63 -quality good -minrate ${bitrate / 10}k -maxrate ${bitrate * 4}k -b:v ${bitrate}k ${resize} -codec:a libvorbis -b:a ${audio_bitrate}k -ac 2 -clev 3dB -slev -6dB -pass 2 -f webm "$output"


resize_height=$source_height
fi
resize="-vf scale=-1:${resize_height}"




ffmpeg -y -i "$source" -c:v libvpx -threads $thread_number -auto-alt-ref 1 -slices 1 -lag-in-frames 16 -cpu-used 0 -keyint_min 0 -g 360 -qmin 4 -qmax 63 -quality good -minrate ${bitrate / 10}k -maxrate ${bitrate * 4}k -b:v ${bitrate}k ${resize} -an -pass 1 -f webm /dev/null

ffmpeg -y -i "$source" -c:v libvpx -threads $thread_number -auto-alt-ref 1 -slices 1 -lag-in-frames 16 -cpu-used 0 -keyint_min 0 -g 360 -qmin 4 -qmax 63 -quality good -minrate ${bitrate / 10}k -maxrate ${bitrate * 4}k -b:v ${bitrate}k ${resize} -codec:a libvorbis -b:a ${audio_bitrate}k -ac 2 -clev 3dB -slev -6dB -pass 2 -f webm "$output"



That should handle everything first attempt.

>>1857
Then it's pointless and proves my point.

In x264 you can throw a 4 minute 720p video and get a 8MB video. Of course it will look like shit, but the encoder does the job.

That's what a decent bitrate control does. FFS, even Xvid does that.

Using a script for that is fucking retarded, unless you do A LOT of encodings.

>Since your too stupid
"you're"

Let me show you an example:

>>1772
>>1764

I did both in for a request. It's a tricky video to encode, a lot scene changes. Neither look good, but the MP4 i got in one try in x264, withou messing with the framerate.

The webm/VP9 one I got after 2 tries, and had to reduce the framerate (resizing wouldn`t do shit, as it is already in a low resolution).

Haven't tried VP8, my guess is that it would be impossible.

>>1858
> Using a script for that is fucking retarded, unless you do A LOT of encodings.

Who says I don't?

This video you posted >>1854 is a pretty easy case. You can set VP9 to 380k and vorbis to q 2, it will look decent even in 720p (getting 7. something megabytes)

>>1860
Well, it's a good script, I give you that. But I really can't stand VP8, and in VP9 it would probably take a week.

VP9 is not THAT slow on -cpu-used 1 and still looks much better than VP8.

>bitrate=$( ($filesize * 8192) / $time) - $audio_bitrate - 10 )

That's not a great idea for vorbis (or any VBR audio encoder).

Vorbis will NOT produce a exact bitrate stream unless you use constrained VBR (stupid).

It usually works because in most videos it will produce a smaller stream than the nominal bitrate. This would not be truth in a music video, for instance.

It would be much better just encode audio first with -q and use the resulting filesize in calculations.