Be me

>be me
>gets mp4
>cuts it up into 10 second bits and converts to webm to post
>size 3.33 megabytes
>posts
>error: file too large
>under 4 megabytes
>try again
>error: file too large
>again
>error: file too large
>AHHHHHH

Attached: 1568104213250.jpg (109x125, 2K)

>>under 4 megabytes
3 is the max for webms, you moron. Don't ask me why it's lower than image size limit though.

90% sure I've posted webms over 3 megabytes but maybe not.
If it is limited to 3 for webms that so stupid

Attached: 1turn.webm (360x240, 657K)

Varies between boards

Been on this site 5 years never knew that.
Learn some new keks every day

/gif/ and /wsg/ the limit is 4mb + audio source

Do you know why it isn't just standard 4mb in all boards anons?

they recently increased the /wsg/ limit to 6mb so its extra confusing

1mb extra for audio; mootwo is scared of screamers on /b/

That's nice

Use this script and just vary the Qmin and CRF param until you get a decent size/quality ratio. You're welcome.

for %%f IN (*.mp4, *.mkv) do (
ffmpeg -i "%%~nf.mkv" -an -c:v libvpx -qmin 10 -crf 22 -b:v 0 -deadline good -cpu-used 0 "%%~nf.webm"
)

Pretty baste script lad, just changed crf to 40 and qmin to 30 to get webm related.

Attached: video_out.webm (640x360, 2.93M)

>>be me
get shot in the face and die

>using constant quality for a site with strict size limits
>using constant quality with only a single pass (which is pretty broken with libvpx)
>forcing a max. quality limit for low size WebMs - which will likely never be reached - instead of a min. quality to enforce a more consistent quality (provided that a mode besides constant quality is being used)
>using "%%~nf.mkv" as input, which means that abc.mp4 (%%f) will become abc.mkv
4/10

>1mb extra for audio; mootwo is scared of screamers on /b/
what a roody poo candy ass, 2^3ch has had audio webbums for years

Whoops change the "%%~nf.mkv" to "%%f"

It sounds stupid at first but it encodes better than manually entering a bitrate and ensures, you guessed it: constant quality. Basically CRF takes advantage of the lossy human visual system, more bits are applied to motion heavy stages of video like in webm related. 2 pass ABR ALSO does this but you never know what kind of quality you're going to get, you may be overshooting or undershooting the optimate bitrate for the quality you intend to get.

Attached: pillow_fight.webm (640x272, 1.14M)

>better than manually entering a bitrate
That's why most WebM scripts automatically calculate the bitrate based on the length and file size constraints.
>you guessed it: constant quality
2 problems though. Constant quality gives the best results, but produces unpredictable file sizes. That's fine for high quality encodes (although you wouldn't use VP8 or VP9 for them), but makes it usually tedious to use, when you have to aim for a specific file size. The 2nd problem is libvpx specific. Single pass encodes don't provide a reliable bitrate control, so libvpx + crf + single pass does NOT provide a constant quality.
Pic related are 2 examples from the other user's WebM. You need to use 2-pass encoding with libvpx to ensure a constant quality (especially if you want to encode VP9, which is even worse than VP8 in that regard)

Attached: 2_consecutive_frames.png (1280x720, 1020K)

What is that pulsing artifact? It only seems to happen every few seconds. Does 2 pass CRF really fix this?

>Does 2 pass CRF really fix this?
Yes, it should. It should also fix the quality degradation of the first or the first few frames of a new scene.

(number of seconds / 3,000 ) x 8 = maximum resultion allowed for a webm to be small enough to be uploaded to 4channel.

You can then use algebra if you know the resultion but need to know the length of the webm.

I'm not sure if "resultion" is the correct word here. You know the number you input then put a "K" next to it? That's what I'm talking about.
Oh this is considering a maximum dimension of 360

Data is expensive if you can limit it even a little it's better for chinkmoot

>You know the number you input then put a "K" next to it?
The word you're looking for is bitrate.
Also your math seems off. Why would a longer video duration warrant a higher bitrate? Usually you use
size_in_KB * 8 / duration_in_sec
Optionally subtract the audio bitrate if you have one.

Am I doing this right? I'm 2/3rds close to a literal retard and just duct taped a few scripts I found online together into this one.

for %%f IN (*.mp4, *.mkv, *.webm) do (
ffmpeg -i "%%f" -pass 1 -y -an -c:v libvpx -lag-in-frames 25 -qmin 30 -crf 40 -b:v 0 -deadline good -cpu-used -16 -f webm tmp-2pass-file.webm
ffmpeg -i "%%f" -pass 2 -y -an -c:v libvpx -lag-in-frames 25 -qmin 30 -crf 40 -b:v 0 -deadline good -cpu-used -16 -f webm final.webm
)

Attached: 1533566085480.png (653x726, 84K)

I'd go with something like this
FOR %%F IN (*.mp4, *.mkv, *.webm) DO (
ffmpeg -i "%%F" -pass 1 -y -an -c:v libvpx -lag-in-frames 25 -qmin 30 -crf 40 -b:v 0 -deadline good -cpu-used 5 -f null -
ffmpeg -i "%%F" -pass 2 -y -an -c:v libvpx -lag-in-frames 25 -qmin 30 -crf 40 -b:v 0 -deadline good -cpu-used 0 "%%~nF_convert.webm"
)

Hmmmmmmmmmmm

Attached: The Orc Slayer_VO WebM 360p.webm (640x272, 684K)

VP9 when

Very nice fren. I gave up trying to perform 2 pass a while ago, you just lit my heart with joy.

Attached: 50a.jpg (1280x836, 222K)