Why is WebM for Retards so fucking shit? >set 4 mb limit

>>59481265
It's ffmpeg that does it, not WebM for Retards.
This program adds arguments based on your input and runs ffmpeg with 'em.

In this case, -fs <bytes>

>>59481456
Well then ffmpeg devs are fucking shit.

>target filesize:
(50 MB * 8192 [converts MB to kilobits]) / 600 seconds = ~683 kilobits/s total bitrate

Two-Pass

This method is generally used if you are targeting a specific output file size and output quality from frame to frame is of less importance. This is best explained with an example. Your video is 10 minutes (600 seconds) long and an output of 50 MB is desired. Since bitrate = file size / duration:
(50 MB * 8192 [converts MB to kilobits]) / 600 seconds = ~683 kilobits/s total bitrate
683k - 128k (desired audio bitrate) = 555k video bitrate

2 pass example:

ffmpeg -y -i input -c:v libx264 -preset medium -b:v 555k -pass 1 -c:a aac -b:a 128k -f mp4 /dev/null && \
ffmpeg -i input -c:v libx264 -preset medium -b:v 555k -pass 2 -c:a aac -b:a 128k output.mp4

The above copypaste is not my opinions, it's straight out of the ffmpeg documentation, so don't give me any (You)s.

>>59481641
Well Webm for retards keeps ramping up bitrate towards the end instead of trying to stay constant. Even if you select 500 bitrate, it will still scale up towards 750+ at the end.

Not sure why it's so shit.

>>59481469

They're not. You just don't know what the fuck you're talking about.

-i "input" -pass 2 -c:v libvpx -an -sn -quality best -cpu-used 0 -auto-alt-ref 1 -lag-in-frames 16 -b:v xxxx "output.webm"
what's better than this?

>>59481916
Well either Webm for retards is shit or ffmpeg devs are shit. If I specify a file size limit, it should fucking adhere to it, not cut something off at the end.

>>59481817
I had same experience with newer versions of libvpx compiled with ffmpeg. Somehow only an old ass ffmpeg 2.8.4 binary shipped with imagemagick keeps the bitrate in check and I can match the filesize exactly. I think it has libvpx 1.4.0 there. Maybe something older, can't even see

>>59481955

Except when the -qmax and -qmin switches don't allow for any further reduction in quality, meaning it HAS to cut off the filesize, or you've specified constant bitrate. The default is 4-63 meaning that it pretty much has free reign in how low it can go in quality, though I'm not sure what WebM for Retards does with that. Also, don't enable CRF (constant quality) if you don't want it to cut filesize.

>>59482065
Maybe I should try something older then.

>>59482089
I also tried an older build from zeranoe and that however didn't work. Would be best to try compiling yourself to actually see what's going on.

>>59482088

 -an -c:v libvpx -pix_fmt yuv420p -threads 4 -slices 4 -metadata title="title" -lag-in-frames 16 -auto-alt-ref 1 -minrate:v 703k -b:v 703k -maxrate:v 703k -bufsize 421k -rc_init_occupancy 2812k -qcomp 0 -fs 3135242

This is the args Webm for retard uses when I specify 3 MB limit. Tell me I was asking for it, I DARE you!

>>59482170

Looks like constant bitrate.

>>59482276
Yeah can't set file size limit in variable mode.

>>59482302

Then that's your problem. Reduce the bitrate then.

You obviously DID ask for it then. Of course it'd cut it off when you're putting impossible constraints on its filesize. The encoder literally cannot achieve what you're going for, so reduce the bitrate.

File: file.png (8KB, 2228x72px) Image search: [Google]

8KB, 2228x72px

>>59482380
Jesus christ you're retarded.

>choose constant bitrate
>set file size limit
>leave bitrate blank so it's up to Webm for retards to pick one
>it goes over the file size limit
>IT'S YOUR FAULT

>>59481935
you need to ackshully run two passes. Not just add -pass 2 to you're command

ffmpeg -hide_banner -i infile -c:v libvpx -quality good -cpu-used 0 -threads 3 -b:v 1200k -maxrate 1200k -bufsize 1200k -qmin 0 -qmax 63 -an -pass 1 -passlogfile /tmp/ffmpegpasslog -f rawvideo -y /dev/null

ffmpeg -hide_banner -i infile -c:v libvpx -quality good -cpu-used 0 -threads 3 -b:v 1200k -maxrate 1200k -bufsize 1200k -qmin 0 -qmax 63 -an -pass 2 -passlogfile /tmp/ffmpegpasslog -f webm -y outfile.webm

>>59482427

You didn't EVER make it clear that you had set no bitrate. What's more, it's also impossible to help you because you haven't specified what resolution your webm should be, nor the duration or anything like that.

>>59482522
I never actually asked for help.

But you're right, I never did say I didn't put a bitrate.

However, in my mind, if I set a limit on file size, and a specific duration and resolution, then Webm for retards should scale bitrate down enough that it should be under the file size limit, which doesn't happen.

>>59481265
>>59481469
Isn't ffmpeg just using libvpx? Even after all the work put into it it's just utter garbage compared to x264; rate control is all over the place, can't detect subtle but highly relevant motion worth shit and somehow it's even slower.

I guess this isn't so surprising when one considers that the codec originally came from Google buying On2 Technologies, a company basically known for ripping off MPEG codecs by replacing patented parts with their own hacks and then implementing the resulting abomination of a "spec" so badly it's barely competitive with previous gen MPEG tech.

Let's hope NETVC will save us from this fail.

File: 1480372745383.jpg (117KB, 782x835px) Image search: [Google]

117KB, 782x835px

>>59481265
>>59482427
>use program called "webm for retards"
>still too retarded to use it correctly

>>59482573

You're right about that. It seems to instead have a default bitrate, instead of calculating it.

>>59482603
Well I think it tries to, it just fails. For example, >>59481817 happens.

>>59482593
VP8 performs better at low sub-300kbps bitrates than x264, provided x264 is used in a mainstream way, aka not placebo, not high profile, not single keyframe.

File: Australians.webm (3MB, 1280x720px) Image search: [Google]

3MB, 1280x720px

>>59481265

>>59482593

The problem is that VP8 is generally a mess and as a codec performs far worse than x264. libvpx is fine, it's the codec itself that is the problem.

Because weebm is shit made for retards.

File: berlin-a-fat-girl-eats-a-pie-CWDDBC.jpg (149KB, 1300x955px) Image search: [Google]

149KB, 1300x955px

>>59482689
bs

>provided x264 is used in a mainstream way
I would bet x264 would still beat VP8, even if you cripple it, like you suggest.

However VP9 can certainly beat x264.

>>59482598
kek

>>59482593
>>59481641
2 pass encoding also improves quality...less artifacts in static backgrounds n shit....in the case of webm...according to ffmpeg documentation.
Again:
2 pass encoding is primarily for file size control.
First pass generates a log file which the second pass reads.
and target_filesize/time=bitrate.
>>59482444 this template will create a decent quality vid at a pretty low bitrate.
you can save a bit more space by specifying a lower framerate. -r 14
using -ss 00:00:00 -t 00:00:00 # start stop time parameters in hr/min/seconds.
Using time parameters to cut sections from a vid then stitching them together again:

Concatenation of files with same codecs:
create a file mylist.txt with all the files you want to have concatenated.

#This list is named mylist.txt
file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'

ffmpeg -f concat -safe 0 -i mylist.txt -c copy output
# -safe 0 is not required if the paths are relative.

Playing with time params and catting multiple files is a lot faster using -c:v copy -c:a copy btw.

>>59481916
The encoding is handled by google software, libvpx. And yeah, it is utter garbage.

>>59482772
>However VP9 can certainly beat x264.
With those encoding times it would be a shameful display if it didn't.

File: 7nJaKlM.jpg (106KB, 720x960px) Image search: [Google]

106KB, 720x960px

>>59482908
VP9 is pretty nice, and give x265 a good run for its money. Just be sure VP9 is using all your cores, or set the thread count manually. I upload to youtube with VP9 videos as youtube seems to have an embargo on accepting HEVC videos.

>>59481265
sounds like you're doing it wrong

File: 1484934191095.webm (3MB, 640x360px) Image search: [Google]

3MB, 640x360px

Encoding is easy.

>>59483331
Do people like anime because it's just softcore porn?

>>59483506
Only some of it.