[ / / / / / / / / / / / / / ] [ dir / agatha2 / animu / baaa / choroy / doomer / g / jenny / xivlg ]

/a/ - Animu & Mango

Winner of the 83rd Attention-Hungry Games
/strek/ - Remove Hasperat

May 2019 - 8chan Transparency Report
Name
Email
Subject
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 5 per post.


Welcome to /a/, please read the rules before posting.
Reminder that in the event 8ch goes down, our bunker will still be up and running.

File: b0b0bc7850d001b⋯.webm (15.83 MB, 853x480, 853:480, showdown2.webm)

 No.894499

Share and laugh.

 No.894534

File: eacac49305721b1⋯.webm (16 MB, 1280x720, 16:9, Bomber escort.webm)


 No.894561

File: 95b9e42a62049aa⋯.webm (10.3 MB, 1920x1080, 16:9, Mcdonalds tries anime.webm)


 No.894563

File: ffda11d3ca64334⋯.webm (1.65 MB, 1280x720, 16:9, Stuttering.webm)


 No.894571

File: 5e6babb2c2f416c⋯.webm (1.58 MB, 1280x720, 16:9, 5e6babb2c2f416c3f9d84538b….webm)


 No.894572

File: 86924e439e4be46⋯.webm (7.98 MB, 960x540, 16:9, 1429771159371.webm)


 No.894573

File: cc6d71e887d32d6⋯.webm (7.95 MB, 960x540, 16:9, 1429771200477.webm)


 No.894574

File: b73d7ec30a37e27⋯.webm (7.98 MB, 960x540, 16:9, 1429771411422.webm)


 No.894576

File: afc37172397f0b1⋯.webm (7.82 MB, 960x540, 16:9, 1429771641930.webm)


 No.894577

File: 04f44ade9338d33⋯.webm (7.62 MB, 960x540, 16:9, 1429771761380.webm)


 No.894578

File: e6eab30cb487aed⋯.webm (7.98 MB, 960x540, 16:9, Fatpeople.webm)


 No.894579

File: d34c4a5762d6675⋯.webm (7.96 MB, 960x540, 16:9, fatpeople2.webm)


 No.894640

>>894499

Oh shit, is this real?


 No.894652

>>894561

When do they have sex?


 No.894663

Someone sure liked Plastic Nee-san.


 No.894674

File: 9cb8de51db19324⋯.mp4 (10.08 MB, 1920x1080, 16:9, Pretty fly for a white mag….mp4)


 No.894676

File: 1a6d251ecf7a9b0⋯.webm (Spoiler Image, 3.67 MB, 852x480, 71:40, 1a6d251ecf7a9b027cc763cc7….webm)


 No.894677

File: 3d8bf6ceb59c57f⋯.mp4 (3.68 MB, 640x360, 16:9, Ojousama.mp4)

File: 1613eba6378f95f⋯.webm (3.88 MB, 640x360, 16:9, ONe punch bully.webm)


 No.894678

File: b8f3c765c9386dd⋯.mp4 (3.66 MB, 352x288, 11:9, b8f3c765c9386dd0d395f3374c….mp4)

File: 49ce8c1771aad8f⋯.webm (3.9 MB, 1280x720, 16:9, Marikka.webm)


 No.894679

File: 518a0cdec01b861⋯.webm (7.59 MB, 640x360, 16:9, 1440167543208.webm)


 No.894680

File: a8e3d90f33ce538⋯.webm (2.58 MB, 480x360, 4:3, study.webm)


 No.894682

File: 88847f2da50af83⋯.webm (11.89 MB, 720x540, 4:3, Lain OP Ascii.webm)


 No.894707

>>894682

Why is the Lain fanbase so autistic?


 No.894765

File: 5d81a8dbbed2c05⋯.mp4 (13 MB, 640x360, 16:9, angel_exercise.mp4)


 No.894779

File: cb9e8143d715870⋯.webm (3.12 MB, 640x360, 16:9, United States of UGUU.webm)


 No.894784

>>894707

It's not that bad. This video appears to be made using some ascii-video player. It's not like someone went through every single frame of the Lain OP and turned it into ASCII-art manually.

The way those work is by taking every frame, dividing it into squares that consist of multiple pixels, checking the overall brightness (and optionally colour) of each square and then picking a characteer that would fill that square with as much whiteness are required (and optionally colouring it too) to make the end result be as bright (and coloured) as the original.

You can distinguish it from normal ASCII-art by looking at the text in the beginning. Traditional ASCII-art would use / _ \ and - to portray the writing and make it a little more readable.

>>894663

It's a good shit.


 No.894916

File: e54ba4ff966253c⋯.webm (Spoiler Image, 15.39 MB, 540x360, 3:2, reichweebs.webm)


 No.894982

File: 91a67a1fcfb59c5⋯.webm (Spoiler Image, 15.84 MB, 1280x720, 16:9, 鉋台のセッティングとメンテナンス.webm)


 No.895027

File: 8ce31798ffd7ce7⋯.png (1.42 MB, 1366x768, 683:384, 1469141972104-1.png)

>>894982

I just went and watched all of this ojisan's videos on this. I never knew planes took so much work to maintain.


 No.895029

>>895027

It's the same autism as knife sharpening.


 No.895035

File: b63846e6543a910⋯.webm (2.88 MB, 1920x1080, 16:9, _a_ - Anime & Manga - 4ch….webm)

>>894563

I fucking miss Monogatari.


 No.895038

>>895035

They're still gonna be releasing new episodes this year.


 No.895040

YouTube embed. Click thumbnail to play.

>>895027

Depends on the type of plane. Commercial airliners are completely taken apart every two to four years.

Start watching from 7 minutes in.


 No.895041

File: 24c936f8382b0d6⋯.webm (163.7 KB, 853x480, 853:480, Animu whistle.webm)

>>894916

What a reception.


 No.895053

File: f69e770a9ce173e⋯.webm (15.03 MB, 640x360, 16:9, eisai_devilman.webm)


 No.895063

>>895053

As much as I enjoy the music this is still triggering my 'tisms.

No sane event engineer would shine a dozen lasers into a crowd of people. Lasers like the ones you see in this video are exclusively pointed towards a safe direction (upwards against a non-reflective ceiling or into the sky).

Whenever you see shit like this, it's a clear sign that you are in a third world shithole, and that you should probably leave the location as no though was put into the safety of the event.


 No.895117

File: 95e12f4c152e099⋯.webm (5.24 MB, 926x914, 463:457, Konohana Kitan OP.webm)


 No.895118

File: 1df7a793f459727⋯.webm (12.68 MB, 640x360, 16:9, Gokicha!! Cockroach Girls….webm)


 No.895122

File: df6ddb636764573⋯.webm (12.44 MB, 640x360, 16:9, Gokicha!! Cockroach Girls….webm)


 No.895760

File: 8a458b496178077⋯.webm (1.51 MB, 1280x720, 16:9, ayame crf 18 s4 r720h yuv….webm)


 No.895769

File: 0fc75c4a7d57043⋯.mp4 (11.87 MB, 854x478, 427:239, Pop Team Epic – Opening Th….mp4)

I unironically enjoyed this series.


 No.895773

>>894571

The least you could do was save them with their original file names and not be a fucking faggot. That kind of shit is why I don't post my webms on /a/


 No.895775

File: 2e27cfdd82163d3⋯.webm (13.76 MB, 1200x674, 600:337, Current state 2.webm)


 No.895850

File: 0e8521b0732e75c⋯.webm (7.47 MB, 1920x1080, 16:9, animeslavmusic.webm)


 No.895954

File: b9aa47114540826⋯.jpg (257.76 KB, 1280x960, 4:3, oniichan2.jpg)


 No.895963

>>895775

Is there a first part?


 No.896147

>>895769

I think we all did. S2 soon.


 No.896148

>>895775

I really hope the kind of people who agree with this aren't here.


 No.896263

>>894534

The shinden is overrated.


 No.896337

File: 8afaf02faca43e8⋯.webm (2.26 MB, 480x360, 4:3, End of Baneangelion.webm)

>>896148

What's wrong about it?


 No.896340

File: e89f240c216ba0a⋯.png (111.92 KB, 300x225, 4:3, ClipboardImage.png)

>>895775

>no pic related

One fucking job.


 No.896453

File: 8789e77dc1c9c97⋯.webm (14.47 MB, 640x360, 16:9, Grand blue.webm)


 No.896456

File: 60c18f5973f3742⋯.webm (8.62 MB, 1010x1010, 1:1, CHA-LA HEAD-CHA-LA.webm)


 No.896470

File: d95bc4771505c4d⋯.webm (8 MB, 854x480, 427:240, White_Altruism.webm)


 No.896522

File: a1f7637a4d17d16⋯.webm (15.68 MB, 480x360, 4:3, Namasensei.webm)


 No.896570

File: bfea3b1a3dc5924⋯.mp4 (7.66 MB, 640x360, 16:9, 1427184980294.mp4)


 No.896710

File: fb0304513118fbd⋯.webm (9.03 MB, 1280x720, 16:9, 'VIVE Pro Eye' Eye Tracki….webm)

>>896570

What a way we've come since then.


 No.896780

>>896570

>>896710

I like how the first one is an mp4, whie the second one is a webm


 No.896797

>>896780

Mp4 is arguably way better than webm. It has better quality and file sizes.


 No.896799

File: e96b4051d7313b1⋯.webm (7.26 MB, 640x360, 16:9, dangomahnig.webm)


 No.896803

>>896797

Are you retarded? That was years ago when webums only contained VP8 and Vorbis.

Now they contain VP9 and Opus which are both lightyears ahead. MP4s contain h264 which has worse quality/filesize especially at low bitrates.


 No.896815

File: c245ace1e0702ed⋯.mp4 (12.41 MB, 854x480, 427:240, Touhou - [7th] MMD Cup Fin….mp4)

>>896570

>That filename

Holy shit, does cuckchan have sound now?


 No.896819

File: 5aa073073c94994⋯.webm (5.35 MB, 800x600, 4:3, NIchibros.webm)

>>896815

At the beginning of 8ch they didn't have these long random scrambled letter names. Also 4chins only allows for 3-4 mb webms and sound only on two boards or so. It's amazingly bad.


 No.896822

File: 64201e1cfe9648b⋯.webm (11.79 MB, 853x480, 853:480, 64201e1cfe9648be410fc4b95….webm)


 No.896826

File: 5572d44d25fba76⋯.mp4 (78.53 KB, 640x360, 16:9, 10 rapes a second.mp4)


 No.897038

File: 6128b5243a95217⋯.webm (992.36 KB, 1280x720, 16:9, Green Shitter Gets Wrecke….webm)


 No.897050

File: 373dcfc35829257⋯.webm (13.72 MB, 1280x720, 16:9, Mahou Shoujo Tokushusen A….webm)


 No.897096

File: 7f80ecd0289deb3⋯.webm (444.77 KB, 700x700, 1:1, 2hu_why.webm)

>>896819

>800x600

>thumbnail is in 4:3 aspect ratio

>webm is in 16:9


 No.897262

File: c6cf9e1e7de73b0⋯.webm (7.8 MB, 960x720, 4:3, tfw ywn be hugged by a qt….webm)


 No.897285

File: 9d30617e075d9f3⋯.webm (7.45 MB, 960x540, 16:9, 50 seconds of concentrate….webm)


 No.897370

File: e48570f6c148ea5⋯.webm (4.61 MB, 420x315, 4:3, Holo and the East Side Bo….webm)

>>896799

I love that one.


 No.897383

File: b4b539b7f85d452⋯.mp4 (Spoiler Image, 7.62 MB, 640x360, 16:9, Japanese vines.mp4)


 No.897454

File: 615d7a4e5644f92⋯.webm (15.98 MB, 300x300, 1:1, 大空魔術~Magical Astronomy-EP….webm)


 No.897474

File: 4a38b68fc602d1d⋯.webm (2.32 MB, 1280x720, 16:9, 1545150813691.webm)

>>894499

Is this considered shit animation?


 No.897734

File: efbff769aa366cb⋯.webm (15.1 MB, 853x480, 853:480, Blossomsss.webm)

Presenting: One of Yamakans greatest hits.


 No.897736

>>897383

I think I now have 悪性腫瘍


 No.898847

File: 34c1ad5f2dd0ed2⋯.webm (Spoiler Image, 15.94 MB, 1440x720, 2:1, 手刻みの現場の建前風景をタイムラプス.webm)


 No.899092

File: fe095bd0d671c22⋯.webm (16 MB, 1280x720, 16:9, Yakusoku_no_Neverland_ED.webm)


 No.899094

File: 8c3000f9fdcca8f⋯.mp4 (2.39 MB, 1280x720, 16:9, Rururaruri Rurararirararur….mp4)


 No.899135

File: fe52a387a22a6f1⋯.webm (8.75 MB, 1920x1080, 16:9, alcohol.webm)


 No.899137

File: 0cc9370645cd4b9⋯.webm (14.96 MB, 1920x1080, 16:9, be_my_waifu.webm)


 No.899139

File: 04c58b5f90655b8⋯.webm (14.9 MB, 1280x720, 16:9, use_it_wisely.webm)

>>899137

Last one for now, might post some clips of Lanipator's parodies of it later


 No.899145

File: c7f2c7e3b1bb911⋯.mp4 (3.47 MB, 460x460, 1:1, Sadistic-grills.mp4)


 No.899156

>>899135

>>899137

>>899139

Why did you make these letterboxed?


 No.899181

File: 30718b06bc57dc4⋯.webm (10.93 MB, 314x240, 157:120, 30718b06bc57dc46752512296….webm)


 No.899183

File: a09c53b0e3545a2⋯.webm (4.17 MB, 640x480, 4:3, Azumanga cooking.webm)


 No.899184

File: f951460126d6d31⋯.webm (4.33 MB, 960x540, 16:9, Friendship power.webm)


 No.899185

File: 8823e5115f9c41f⋯.webm (7.39 MB, 960x540, 16:9, literary girl 1.webm)


 No.899227

File: 1df4fa799bdf49b⋯.webm (4.19 MB, 384x384, 1:1, funky.webm)

>>899145

Song source is "U Got That" by "Halogen". Pretty fucking gud deep house songs.

soundcloud.com/wearehalogen

>>899135

>>899137

>>899139

>dubs


 No.899231

>>899145

My first thought was the background music in FFX that plays at the part when the Guado are chasing you out of the Macalania Temple right after you kill Seymour. Same key.


 No.899538

File: 63301eaed13204e⋯.webm (7.42 MB, 420x405, 28:27, king_conga_mado.webm)

File: cbef43f28488c92⋯.png (55.05 KB, 640x434, 320:217, mplayer.png)

>>894784

Forgot to chase this up. It's actually fairly straightforward. mpv and mplayer have supported this for ages via -vo caca, at least if support for it is compiled in. There was a different one that generated the monochrome look in that Lain video, I think it's aalib but that isn't a feature in mpv, only mplayer, and also doesn't seem to have a CLI tool for generating them.

It's possible to generate a WebM with ffmpeg and img2txt (caca-based) and convert. Extract all frames to PNG, img2txt to caca'd TGA, IM convert to PNG with IM convert, then use ffmpeg's image2pipe filter with the correct framerate and some lossless video codec (ffv1) to assemble the video. Then the usual ffmpeg stuff to turn it all into VP9/Opus.

Gods it was actually harder to choose which video I wanted to demo it with. While I'm at it does anyone recognize the Miku video? I actually tried to reverse image search it, and as the thumbnail but no luck.


 No.899552

>>899181

Did Chad call his nip-bros to chase Davido-kun down in Japan?


 No.899555

File: b6c0d5fb7c0051f⋯.webm (5 MB, 640x480, 4:3, king_conga_mado_monochrom….webm)

OK found a way to do it, albeit much much slower. Monochrome looks way nicer though, not like indie pixel art.

https://gist.github.com/motiondesignstudio/9374326


 No.899581

>>899555

>>899538

Drat. Disregard those they go out-of-sync. Apparently you need to specify -r before -i just found that out with something else behaving weirdly.


 No.899597

File: b8dff8fe6925beb⋯.png (55.55 KB, 315x238, 45:34, yepyep.png)

>>899538

>Extract all frames to PNG, img2txt to caca'd TGA, IM convert to PNG with IM convert, then use ffmpeg's image2pipe filter with the correct framerate and some lossless video codec (ffv1)

I understand everything.


 No.899620

>>899597

>Extract all frames to PNG

ffmpeg's PNG output or even mpv can do this.

ffmpeg -i ../【ゆめにっき】クリプト・オブ・ザ・モノクロダンサー-rZ-L9L7q4EU.mkv -an -sn -c:v png $filename%04d.png

>img2txt

It is insanely helpful to know your way around Bash or similar even if in a hackish way.

#!/bin/sh
AAA="$1.tga"
img2txt -f tga "$1" > "$2"

And for the monochrome thing with that Python script because using it for video directly seemed to crash I did it per-frame with find(1) to run the following on all PNGs...

#!/bin/sh
AAA="$1.png"
_amm "$1" 4 12
echo "$1"
echo "$AAA"
mv ascii_photo.png "$AAA"

...then used the following to make the video.

cat *.png.png | ffmpeg -r 8 -i - -f image2pipe -c:v ffv1 -an -sn -f matroska -y t.mkv

(adjust -r to framerate desired!!!)

From that it's the standard steps to mux the video and audio. This is my script.

#!/bin/sh
FILENAME="$1"
CRF="$2"
ffmpeg -i t.mkv -i t.opus -pix_fmt yuv420p -c:v libvpx-vp9 -crf $CRF -tile-columns 0 -frame-parallel 0 -aq-mode none -row-mt 1 -auto-alt-ref 1 -lag-in-frames 25 -b:v 0 -c:a copy -f webm -pass 1 /dev/null
ffmpeg -i t.mkv -i t.opus -pix_fmt yuv420p -c:v libvpx-vp9 -crf $CRF -tile-columns 0 -frame-parallel 0 -aq-mode none -row-mt 1 -auto-alt-ref 1 -lag-in-frames 25 -b:v 0 -c:a copy -f webm -pass 2 $FILENAME


 No.899624

File: 42f499de7da8c66⋯.webm (7.65 MB, 420x405, 28:27, fixed.webm)

File: 3c53f1fedd4604a⋯.webm (5.11 MB, 640x480, 4:3, fixed_monochrome.webm)

Also fixed my mistakes I think.


 No.899667

>>899620

eenteresting. Does crf yield the best compression for ascii videos?


 No.899720

File: 99fa8e6aef48281⋯.webm (77.11 KB, 1280x720, 16:9, 99fa8e6aef4828106c433a482….webm)

>>899538

>>899620

Thank you for your efforts tech wizard.


 No.899737

File: b46cc0a48ea5af3⋯.webm (15.98 MB, 1280x720, 16:9, With doctrines like this ….webm)


 No.899813

File: d09ff1cd4b36a53⋯.webm (15.6 MB, 853x480, 853:480, 何でも言うことを聞いてくれるアカネチャン (Aka….webm)

>>899667

CRF should be used for all imageboard WebMs. I think this deserves elaboration and discussion.

>VP9 and Opus

Opus is the best lossy audio codec. VP9 is not covered by patents and competes solidly with H.264 for quality compression, though its encoding times are horrendous. With WebM I don't think you can mix H.264 with Opus, you need to use AAC, and the decent encoder fdk-aac has a really shitty license clause despite technically being free software and as a result has to be explicitly compiled into ffmpeg, not sure if all builds do. On that subject while formats don't change a lot, the encoders do improve. Make sure your ffmpeg and dependencies is up-to-date. I don't know where you get decent ffmpeg builds for Windows but I self-compile from Git fdk-aac, libopus, libx264, libvpx, libass, ffmpeg, mpv. Self-compiling also lets you set CFLAGS="-O3 -march=native" and same with CXXFLAGS to optimize it a bit further and you want all the speed you can get with VP9.

>separate audio and video files

I typically apply filters/seeking as its own step and then worry about encoding. Invocation and code, note that the intermediate video file will be large, if you aren't doing filters or seeking you can skip this.

#!/bin/sh
FILENAME="$1"
OPTS="$2"
ffmpeg -i $FILENAME $OPTS -an -sn -c:v ffv1 -f matroska t.mkv

Similarly, I encode the audio first because that informs me how much space is free for the video.

#!/bin/sh
FILENAME="$1"
OPTS="$2"
BR="$3"
ffmpeg -i $FILENAME $OPTS -vn -sn -c:a libopus -b:a $BR t.opus

>-pix_fmt yuv420p

This has to be forced because VP9 will sometimes select different ones like yuv444p and those don't play in all browsers. yuv420p is the lowest common denominator.

>-crf

While best, its main drawback is that you can't easily predict the output filesize. Valid values are 0-63, lower is better. For short videos start with 30. For longer ones and especially ones with lots of motion you may need to go higher, 40s and 50s. Thankfully you can watch ffmpeg's terminal which reports current filesize and how much it's encoded to determine early if it's likely to overshoot or seriously undershoot with the following calculation:

(16777216) * (encodedseconds / videodurationinseconds)

This says what the expected filesize in bytes is at that point but it will not go up linearly so you need to watch it, especially if the end has a lot of motion you need headroom. If it only ends up a bit over you can just cut the audio bitrate a little and re-mux it instead of doing the video over. Also preview the video occasionally and determine if it's going to look terrible and needs lower CRF or resolution. Generally 720p should be the maximum output.

>most of the VP9 parameters

Honestly these are cargo cult and I've heard some of them may be wrong. I'll look properly later.

>-f

Some intermediate codecs don't end up in a container. Generally best to specify it explicitly.

>-g

Or rather its absence. This controls how often keyframes are generated, and I've seen guides that specify 9999. This can shrink the video, but for a longer video don't use it. It ruins seeking.


 No.899814

(cont.)

>-framerate and -r

Use -framerate in most circumstances since it interpolates if for some reason you need to reduce it. Only use -r when importing raw formats, like the example with all frames as PNG and then it must be before -i. In general pay careful attention to argument ordering. Speaking of.

>fast seek

There is a trick where if you specify -ss before the input file it will not have to process everything before it. However it's a bit less precise and it will screw up subtitle sync so you need to pair it with the setpts filter, can't remember its incantation. You also then need to specify -t not -to.

>video bitrate 0

For whatever reason if you don't do this CBR will be used even if -crf is specified.

>two-pass encoding

Always do this. On Windows specify NUL instead of /dev/null

>multi-threading

I don't use this on my trash computer. Not sure what the general advice is.

>source files

A note if downloading from Youtube, use youtube-dl. Check first if using -f 43 outputs one that can be posted straight to 8chan, and if not, confirm its audio isn't already using Opus. If it is just rip it out and don't transcode unless it's too big.

Lastly, what was used for above video.

$ _ffmpeg_vid akane.mkv "-vf scale=-1:480,subtitles=akane.vtt"
$ ffmpeg -i akane.mkv -vn -sn -c:a copy -f opus t.opus
$ _ffmpeg_mux akane.webm 45
$ ffmpeg -i t.opus -c:a libopus -b:a 72K b.opus
$ ffmpeg -i b.opus -i akane.webm -c:v copy -c:a copy akane2.webm
$ ffmpeg -i akane2.webm -c:v copy -c:a copy -metadata title="何でも言うことを聞いてくれるアカネチャン (Akane-chan Will Go Along With Anything You Say) English Sub-p3cHf7eHJeE.mkv" v.webm

Tried with 720p but it was ending up with too high a CRF and fairly noticeable artifacts started appearing. Overshot the filesize a bit though and decided to just reduce the audio instead of taking another eternity. 72K instead of 128K. I wouldn't normally do it for musical WebMs.

>>899726

You have the capability to find out easily. Do it.


 No.899843

>>899813

That's a great guide, thanks for going over all those options


 No.899848

File: b80430f795eb31c⋯.webm (15.53 MB, 1280x720, 16:9, [HorribleSubs] Mini Toji ….webm)

>>899813

>CRF

>While best, its main drawback is that you can't easily predict the output filesize.

<what is constrained quality encoding

>VP9 parameters

>Cargo cult

Anon-kun, you sure you don't want multithreaded encoding via -tile-columns, -tile-rows and -row-mt?

-row-mt alone makes the video look slightly better while encoding 250% faster depending on the CPU.

>-g

AFAIK leaving that out is the same as putting in 9999 as far as libvpx goes.

The only real meme option with VP9 apart from tpl-mode is the -quality best deadline, with recent builds of the library it decreases encoding speed by over 60% while only delivering a minimal increase in SSIM.

t.

ffmpeg -i $input $opts -f yuv4mpegpipe - | vpxenc --codec=vp9 --webm -t 7 --lag-in-frames=25 --end-usage=vbr --target-bitrate=<X> --auto-alt-ref=1 --tile-columns=6 --tile-rows=2 --frame-parallel=0 --row-mt=1 --min-q=0 --max-q=63 --frame-boost=1 --cpu-used=0 --sharpness=7 --static-thresh=0 --noise-sensitivity=0 --kf-max-dist=9999 -w <X> -h <Y> --passes=2 --pass=1 --fpf=vpxpass.txt -o output -


 No.899853

>>899848

That's why I mentioned it. I'm always up for improving things. I'm also actually interested in putting together a proper text-based guide for such threads that has script fragments and info about what all the parameters do.

>constrained quality encoding

I take it that this is basically setting the average bitrate so it can get at least close to the right output file size and that it's basically variable CRF? If so I'm gonna have another go with that video so I don't have to transcode the audio. I was at that point sick of trying to figure the settings out though.

>quality best

Like with H.264 that's a game of diminishing returns. Amusingly, that names its slowest profile "placebo".

https://trac.ffmpeg.org/wiki/Encode/H.264

>AFAIK leaving that out is the same as putting in 9999 as far as libvpx goes.

When used with -c:v libvpx-vp9 it's not doing that. Without regular keyframes you cannot seek the video without it needing to read through everything from the start and that is S.L.O.W. Maybe it does if using the VPX encoder tool.

Also I've never used the VPX tools bare, reference for it.

https://www.webmproject.org/docs/encoder-parameters/


 No.899855

File: 2051ae41b6ac6ea⋯.webm (15.99 MB, 1280x720, 16:9, [MV]ジグソーパズル/まふまふ feat. 鏡音….webm)

>>899853

>I take it that this is basically setting the average bitrate so it can get at least close to the right output file size and that it's basically variable CRF?

No, that's regular variable bitrate encoding.

Constrained quality is the same as CRF but with a fixed never-exceed bitrate.

>quality best

Different from h.264's presets which enable/disable certain encoder features, the equivalent for that in libvpx and libaom would be the -cpu-used setting.

-quality sets a deadline on how much time the encoder is given per frame, -quality best sets it to unlimited while -quality good (the default) sets it to 1 fps minimum and -quality realtime sets it to a few milliseconds which makes the video look like shit.

For whatever reason -quality good benefits most from row-mt as CPU usage with 8 threads, -row-mt 1, -tile-columns 6 and -tile-rows 2 skirts around 60-90% on all cores whereas it drops to 30-50% with -quality best.

-g 9999 doesn't eliminate keyframes as without those modern video codecs wouldn't function apart from intra-frame codecs like mjpeg but that's another story, it just lets the encoder decide where to put keyframes instead of setting them every X number of frames.


 No.899861

>>899855

>Constrained quality is the same as CRF but with a fixed never-exceed bitrate.

That's not what the documentation is telling me. It's saying it's a hint on what the average bitrate should be, so putting the following reduced a tad so there's some headroom should be fine for the example video where it was spiking to 500k especially towards the end of the video. I'm about to find out, and by "about to" I mean in a couple hours.

((16⋅1024⋅1024)−4628464) / 285 / 1024 ⋅ 8 = 333.025

Also your example was somewhat confusing in that I've never tried this piped approach. More annoyingly is ffmpeg can't tell me how big the video is as it's progressing but thankfully du -b works for me. Also those encoder settings are extremely slow so I bumped CPU usage to 2 and specified --good. You have no idea how long it took to encode that first WebM on my computer. Hint: 2 threads only!


 No.899871

Yeah this is definitely a hint to the average bitrate. It came very close to the 16MiB limit and without needing to alter the source video audio at all.

$ _ffmpeg_vpx akane3.webm 310 853 480

$ ffmpeg -i akane3.webm -i t.opus -c:v copy -c:a copy -metadata title="何でも言うことを聞いてくれるアカネチャン (Akane-chan Will Go Along With Anything You Say) English Sub-p3cHf7eHJeE.mkv" v.webm

#!/bin/sh
FILENAME="$1"
BR="$2"
WIDTH="$3"
HEIGHT="$4"
ffmpeg -i t.mkv -f yuv4mpegpipe - | vpxenc --codec=vp9 --webm --good -t 2 --lag-in-frames=25 --end-usage=vbr --target-bitrate=$BR --auto-alt-ref=1 --tile-columns=6 --tile-rows=2 --frame-parallel=0 --row-mt=1 --min-q=0 --max-q=63 --frame-boost=1 --cpu-used=2 --sharpness=7 --static-thresh=0 --noise-sensitivity=0 --kf-max-dist=9999 -w $WIDTH -h $HEIGHT --passes=2 --pass=1 --fpf=vpxpass.txt - -o "$FILENAME"
ffmpeg -i t.mkv -f yuv4mpegpipe - | vpxenc --codec=vp9 --webm --good -t 2 --lag-in-frames=25 --end-usage=vbr --target-bitrate=$BR --auto-alt-ref=1 --tile-columns=6 --tile-rows=2 --frame-parallel=0 --row-mt=1 --min-q=0 --max-q=63 --frame-boost=1 --cpu-used=2 --sharpness=7 --static-thresh=0 --noise-sensitivity=0 --kf-max-dist=9999 -w $WIDTH -h $HEIGHT --passes=2 --pass=2 --fpf=vpxpass.txt - -o "$FILENAME"

Resultant script. After that you need to mux the audio into a WebM. Also resultant video without degraded audio. Also slightly annoying but this is the new formula. It's counted by frames and needs to factor in what the audio is going to require.

((16⋅1024⋅1024)−4628464) ⋅ (7000/(285⋅30))


 No.899873

File: 7f33fcd7fefc07f⋯.webm (15.05 MB, 853x480, 853:480, v.webm)

Damn it this is the video.


 No.899878

File: e08c4198da7f4b9⋯.webm (2.26 MB, 500x494, 250:247, бррмбмб.webm)

File: ff51285aba1deff⋯.webm (2.89 MB, 1024x768, 4:3, Russian anime thread.webm)

File: 7230c23c299a78b⋯.webm (2.03 MB, 480x480, 1:1, ебливая длинная.webm)

File: 2f456c1c44f58b4⋯.webm (660.89 KB, 640x360, 16:9, Hakase no GOP.webm)

File: 65fb752f9a50a6c⋯.webm (5.38 MB, 1280x720, 16:9, Syoch moi chocolat.webm)


 No.900184

File: 699fed8f8727a2e⋯.webm (8.14 MB, 1920x1080, 16:9, GACHA.webm)

File: 3c6376cacd44506⋯.webm (1.02 MB, 540x480, 9:8, 3c6376cacd44506007d78e78c….webm)

First is 1080p test because why not. VBR encoding with average bitrate hinting is truly great, went with 2000k. With vpxenc it seems you can't force the pixel format, so hopefully it always goes with yuv420p. So far so good. Second WebM isn't mine but it's yuv444p and I have seen a couple of browsers choke on it, but it hardly matters when I normally open them in a real video player anyway.

>>899848

Oh and you do not need to specify the width and height to vpxenc. ffmpeg's yuv4mpegpipe filter outputs Y4M. You only need to do that (and the framerate too) with plain YUV.

https://github.com/stoyanovgeorge/ffmpeg/wiki/Encode-Raw-Video#yuv-or-y4m


 No.900731

File: 285237898651bca⋯.webm (3.64 MB, 852x480, 71:40, 1540272802541.webm)

Shamelessly stolen.


 No.900732

>>900731

Where's his shield?


 No.900749

>>900731

To think the porcelain tags can wander Lumbridge safely and they'll never know why.


 No.900847

File: ff521d586df0100⋯.mp4 (3.65 MB, 1280x720, 16:9, Real_Diseases.mp4)

>>894561

Oh shit they made a sequel? I remember the first one.


 No.900883

File: f0344fd22063c77⋯.webm (Spoiler Image, 2.31 MB, 810x1080, 3:4, 54476244 - T督の野望~バニー鹿島編~し….webm)

File: e5f8a49380a42cc⋯.webm (Spoiler Image, 2.34 MB, 810x1080, 3:4, 54476774 - T督の野望~バニー鹿島~ポー….webm)

File: 55dc1a45cb1fd4f⋯.webm (Spoiler Image, 2.51 MB, 256x256, 1:1, 55655838 - スライムさん.webm)

Just been looking into how to do Pixiv Ugoira animations just in case something isn't on Danbooru or its quality sucks (they use VP8 by default). They're annoying because the delay between frames can vary so you can't just pipe the frames into ffmpeg for example.

So PixivUtil2 can actually download the frames and animation JS with the frame delay info in it and optionally transcodes them to various formats. By default VP9 but lossless and that takes an age to perform compared to just dumping out FFV1. Unfortunately it's all or nothing and it won't transcode Ugoiras from prior and by default doesn't dump the JS. Relevant sample part of my config:

[FFmpeg]
ffmpeg = ffmpeg
ffmpegcodec = ffv1
ffmpegparam = -pix_fmt yuv420p -f matroska
#ffmpegcodec = libvpx-vp9
#ffmpegparam = -lossless 1
webpcodec = libwebp
webpparam = -lossless 0 -q:v 90 -loop 0 -vsync 2 -r 999

[Ugoira]
writeugoirainfo = False
createugoira = True
deletezipfile = True
creategif = False
createapng = False
deleteugoira = False
createwebm = True
createwebp = False

From there transcoding to VP9-WebM is the same as any other video, only you'll get 100% more idiots saying ">soundless"


 No.900886

File: 9ff1e95d473220c⋯.mp4 (2.88 MB, 1280x720, 16:9, st.coWZiPW0nAVJ.mp4)


 No.900893

File: b676934c0d2ad81⋯.webm (234.54 KB, 1012x1080, 253:270, Angry.webm)

>>900886

I hate these retarded reaction shit videos. Just stealing shit and then plastering your own retarded face in the corner. It is talentless and is only there because some tard thinks they are smart opportunists jumping on the next new big hip trend. They truly are the replygirls of our time.


 No.900954

>>900893

Gotta get that e-fame with as little effort as possible. Fuck actually putting effort into it and making something unique. Instead I will plaster my face in the corner and make pointless remarks that lessens your overall enjoyment of what you're watching. You can thank me later.


 No.900960

File: 8952e18af4d38d0⋯.webm (7.01 MB, 500x500, 1:1, webms Without Sound.webm)

>>897474

IT's considered a soundless webm


 No.902275

File: e7e49bc657a7d4f⋯.mp4 (6.77 MB, 1280x720, 16:9, ままっままっま.mp4)


 No.902412

File: 1d4ec87e2c3946f⋯.webm (15.99 MB, 1920x1080, 16:9, Yokohama.webm)

>>899871

I set everything to single core encoding and either best or good quality and just run three or four instances of the same file. Say if the 16mb formula calculates a vbr setting 500k then I'll just simultaneously run a 495k, 500k, and 505k encode and choose the one closest to the file limit. I mean it takes a while but it's not like I'm running a commercial operation here.


 No.902705

File: 55f626fe1370e08⋯.jpg (37.09 KB, 400x447, 400:447, 1463341756668.jpg)


 No.902730

>>899848

>-Frame-boost

>-Row-mt

How come these commands and more doesn't work with my ffmpeg?


 No.902732

File: 69f3746709ae0a3⋯.mp4 (6.67 MB, 1280x720, 16:9, 69f3746709ae0a3fefa6c5bd46….mp4)

File: ce9078f65da7cdc⋯.jpg (103.67 KB, 1280x720, 16:9, mpv-shot0306.jpg)

File: 97fc975c22b290a⋯.jpg (95.66 KB, 1280x720, 16:9, mpv-shot0307.jpg)

>>902412

Yeah there's no way in hell I have that luxury. All I can do is try average bitrate calc...

((16⋅1024⋅1024)−AUDIOINBYTES) / DURATIONSEC / 1024 ⋅ 8

...then watching it mid-encode if it's looking shitty try making it higher, because I've noticed the encoder never seems to overshoot if set right, but it can dramaticaly undershoot especially with longer videos. To that end there are some additional tunables with vpxenc that look interesting: --undershoot-pct, --bias-pct, --minsection-pct and --maxsection-pct. Also for the intermediate video, hqdn3d as a filter seems interesting for some video types before passing it on to vpxenc.

I had a go at matching this but failed miserably. Larger video, more artifacts. Audio was also AAC to begin with. For something so short it was over 2 hours for the second pass when using --best --cpu-used=0 that's why I have to be selfish. At least I discovered a stupid where I was constraining maximum distance between keyframes to 10 (frames, not seconds).

>>902730

Because ffmpeg is just outputting raw Y4M to vpxenc through a pipe (a way of communicating data between programs, originates from Unix, not sure if Windows allows it), and vpxenc has its own options.

https://www.webmproject.org/docs/encoder-parameters/

The key bit of a pipe is that ffmpeg's output is - (standard output) and vpxenc input is - (standard input). The pipe | (NOT an I or an l, it's shift-backslash on QWERTY) connects the two.


 No.902748

File: 62385efe35a28a9⋯.webm (15.99 MB, 854x480, 427:240, Bad_Friends_60fps.webm)

>>902730

Is your ffmpeg not compiled against libvpx 1.7.0?

row-mt was added in that version of the encoder.


 No.902773

File: 96337acce4b5dc9⋯.webm (11.56 MB, 320x240, 4:3, curryyy.webm)

>>902748

>>902732

Forgot to specify -row-mt 1 to enable it. I am too baka for this shit.


 No.902973

File: e9a67881bee7454⋯.webm (3.71 MB, 1280x720, 16:9, yuri physics.webm)

File: 2266819a0529da5⋯.webm (7.33 MB, 960x540, 16:9, more LvB fanservice.webm)

>>902773

While not the problem, it deserves reiterating: Codecs don't change much, the encoders do. MP3 went through a phase of dogshit ones before LAME came along to put an end to it. Similarly, x264 and vpxenc continue to evolve and improve. If you aren't able to self-compile, make sure your build of ffmpeg is from a decent up-to-date source, and also includes what you need because some encoders are not built by default due to licensing problems (fdk-aac is the big one if you're doing H.264/AAC)

For this reason, the helper framework mpv-build does not rely on what different Linux versions come with as far as ffmpeg (some use that crappy libav fork) or libass (some distros have problem outdated versions). My ffmpeg_options for reference:

--enable-libass
--enable-libmp3lame
--enable-libx264
--enable-libopus
--enable-libvpx
--enable-libpulse
--enable-nonfree
--enable-gpl
--enable-libfdk-aac
--extra-cflags="-O3 -march=native"

And mpv_options:

--enable-dvdread
--enable-dvdnav


 No.903225

File: ac1bc22ea1a749c⋯.png (58.58 KB, 797x598, 797:598, AVC profiles.png)

File: 12fbb7ab95e1b4b⋯.png (49.04 KB, 937x530, 937:530, HEVC profiles.png)

File: dae65b41677d8f2⋯.png (14.21 KB, 507x214, 507:214, AV1 profiles.png)

File: 0e8ac36eac7050d⋯.mp4 (11.91 MB, 1280x720, 16:9, wise parasite.mp4)

>>902973

>Codecs don't change much, the encoders do.

The Motion Picture Experts Group are a strange bunch.


 No.903533

>>902973

>Codecs don't change much, the encoders do.

Libvp9 is the best one then, yes? I heard stuff about the AV1 encoder but apparently its way too slow at this time.


 No.903590

File: 86e0b36c39c4d8b⋯.webm (6.03 MB, 480x360, 4:3, subliminal_autism.webm)

>>903533

>Libvp9 is the best one then, yes?

That depends.

libvpx has shit tier single pass rate control and is too slow for things like recording or livestreaming, HW encoding implementations are also lacking though SW support is near-universal among device with some degree of Internet video playback capacity.

The only setting at which it reasonably outpaces x264 is -cpu-used 0, all the higher settings look worse than x264 with inferior encoding times.

On the other hand its 2-pass rate control is god tier and the codec is highly efficient in that mode, the few profiles it has also only concern bit depth and chroma subsampling options with all encoder features available on every profile.

HEVC on the other hand has the x265 encoder which is waaaay faster than libvpx.

It has a number of presets, the highest of which is more or less equivalent with libvpx at -cpu-used 0 whereas the others far outpace libvpx in video quality and encoding speed.

It's single-pass rate control is breddy gud, x265 also automatically raises the bitrate when doing CRF encoding at a faster profile, resulting in uniform video quality regardless of speed albeit at a greater filesize.

However its 2-pass mode is absolute dogshit when it comes to speed, mainly because the first pass runs at the same speed as the second pass which is asininely retarded if you want to use a slow preset.

x265 also can't do 2-pass CRF encoding and suffers from MPEG profile autism, every profile higher than Main adds various options that make the encoder more efficient while greatly fracturing the decoder landscape, which is especially bad when it comes to HW decoding implementations in embedded devices.

The codec also does not use macroblocks which results in significantly worse quality at 8ch-tier bitrates due to weird oil painting artifacts or some shit.

However all that pales in comparison to HEVC's biggest flaw:

Its hyper-kiked patent licensing clusterfuck.

Being a royalty-based botnet standard with widespread (((Industry))) support it requires the user to send shekels towards MPEG fo dem patents when hosting a Video somewhere, but instead of just paying to MPEG LA there's 20 other or so patent pools and various independent patent holders vying for royalties which has excluded the codec from (((Industry))) professionals with an army of big-nosed Lawyers/trustworthy middlemen handling the necessary backroom dealings and such the FOSS x265 encoder is only permitted to exist due to Cisco shielding it from Royalty collectors somehow.

h.264 requires royalties too but they all go to MPEG LA and are only paid per hosting instance whereas h.265 requires a small amount of shekels not only per instance but also per individual stream from said instance.

This has lead to all Browser vendors apart from Microsoft they'll depreciate support soon enough anyway to refuse the addition of h.265/HEVC to their browsers, the codec is also nonexistent in Internet streaming despite being more than capable of such things.

However its widespread (((Industry))) support coupled with some sort of rivalry between the royalty-free Jewgle-developed VP9 and the (((Industry standard))) HEVC have resulted in a completely lopsided situation when it comes HEVC and VP9 hardware support.

Many GPUs, Phones, 15$ chinkshit SoCs and whatnot of recent years have fully fledged HEVC de-and encoding ASICs supporting a variety of profiles regardless of price despite the codec being unused outside of 4K BDs and Animu piracy, whereas the comparatively ubiquitous VP9 only has a scant few HW decoding implementations on recent Nvidia+AMD GPUs with HW encoding strictly limited to Samsung phones and some Jewntel CPUs.

AV1 is the result of major HW and SW vendors getting tired of MPEG's shit and banding together with Jewgle to make their own codec.

It's currently too slow to be practical, but given the huge number of companies actively financing and endorsing it support shouldn't be much of an issue in a few years.


 No.903614

File: 9e0785cb2417d74⋯.png (26.88 KB, 1089x283, 1089:283, Toolbox.png)

File: 000d4252fa3498c⋯.webm (15.51 MB, 320x240, 4:3, warau12.webm)

Just updated everything.

>>903533

This >>903590 but in short as far as imageboard videos, AV1 isn't supported here yet anyway. Your choices come down to MP4 H.264/AAC with x264 and fdk-aac, or WebM VP9/Opus with their standard encoders. The latter has best audio codec and no patent issues, and compresses better, but trades off long encoding times. VP8 is tosh for 4chan losers.

>>903590

I didn't think you could use H.265 here anyway.


 No.903648

>>903631

This mp4 made me vomit blood.


 No.903685

File: f1e77d66d88271a⋯.webm (3.3 MB, 853x480, 853:480, scream_08bit.webm)

File: b77608733d556a5⋯.webm (3.12 MB, 853x480, 853:480, scream_10bit.webm)

File: 7a79b17981b6e69⋯.webm (3.36 MB, 853x480, 853:480, scream_12bit.webm)

Through random /tech/ support related to high bit depth and H.264, I found VP9 has it too. With H.264, ironically, it can allow for better compression and transcoding, which is why anime fansubs really ran with 10-bit encodes despite sparse support at the time. That said I don't think it's fully handled or useful in VP9 yet since 10-bit and 12-bit support needs to be explicitly compiled into libvpx, and it forces the use of --profile=2 (worse encode basically) which I did not use for the 8-bit version of the WebM. In any case, comparison WebMs and I'm curious how supported they are for playback or even uploading here given anything but yuv420p is a risk. In my case mpv plays it correctly. VLC can but on OpenGL output its colouration gets totally fucked. Chromium played it fine but Firefox couldn't.


 No.903692

File: ac8b73df62e027e⋯.mp4 (3.35 MB, 852x480, 71:40, scream_10bit.mp4)

Just for giggles, H.264/AAC 10-bit attempt since I can just copy the original AAC audio. Looks about as good, and manages to match the video size, and did not take four eternities to encode.


 No.904636

File: 9e45a227e32acc5⋯.webm (1.53 MB, 480x320, 3:2, e9333cf7e49a44f283a32a446….webm)


 No.904638

File: 3a1e5c63f502e76⋯.mp4 (9.24 MB, 426x240, 71:40, アイドルマスター 急降下爆撃~STUKA Lied2….mp4)


 No.904645

I hate to beg and not contribute, but I'm new to being a weeb, does anyone have any unedited Darling in the FranXX clips?


 No.904647

>>904645

>4. Recommendations, source, and other requests should be made on >>>/rec/.

Though actually doing it isn't likely to bear any results, I'd recommend you to just make your own. Webm for retards is easy.


 No.904669

File: 96e5bd1624ccb3e⋯.png (1.14 MB, 2400x3420, 40:57, ffmpegGUIDE.png)

>>904645

>>904647

WebM for retards is for retards.


 No.904672

>>904669

Better to have retard webms than no webms.


 No.904674

File: 622ac3b4502ba94⋯.webm (10.28 MB, 500x500, 1:1, trainloli.webm)


 No.904675

>>904647

I would never be able to bear the shame of using a program named Webm for retards.


 No.904686

>>904675

Lucky for you then that the fags at Github made it rename it. It's for bakas now.

>>904669

I definitely need to consider a new guide that is text-based. Images don't let you copy text.


 No.904752

>>904686

.pdf

I see the guy who made this on githb used photoshop (.psd) to make it. PS can directly export to PDF, and there should be an option to keep text as text instead of converting to pixel graphics.


 No.904764

File: e07626bc4e34137⋯.webm (1.64 MB, 640x360, 16:9, 1412866642564.webm)

File: 4fa04e7d3cd25c0⋯.webm (91.51 KB, 230x364, 115:182, 1416259225441.webm)

>>904752

Oh neat the guy uses Git, but in a suboptimal way by renaming the files like that. Not that it matters since it was last updated a while ago, but the way I arranged it on the Vita general threads is that the info is hosted on Gitgud and linked to, not posted in the thread, so that way they'd update without needing to change things in the thread, and making it a lot harder for old images to keep showing up, like happens with certain other charts. Git also tracks full change history (best with text guides) and allows easy forking.

For WebM encoding my methodology is a lot different thanks to some other guy. Notably, I separate it to steps:

- Cut video without transcoding. If using filters or editing software output ffv1 and/or flac codec. You can sometimes do encoding in the editing software but I'd rather trust external ffmpeg.

- Encode audio first. Opus codec, try 64K for longer videos, 128K generally, 192K for music videos. Bare minimum is 32K.

- Knowing audio size, encode to VP9 with appropriate settings. VBR generally, but CRF sometimes produces better output. I will see how to do it in ffmpeg rather than outsourcing it to vpxenc.

- While encoding, monitor it in mpv, and its disk usage to hopefully catch in time if it looks bad or is going to be too big.

- If it's a little under, consider re-encoding the audio a bit higher bitrate to fit 16MB. Don't just use the space because it's there though, most short videos can be small so you can post more than one at a time.

I'll have a think about it.


 No.904766

>>904645

I just watched this and it seems to be exactly what you're looking for though? >>903225


 No.905060

File: 5b620d266dc2cad⋯.webm (15.93 MB, 960x720, 4:3, Men's Dreams.webm)


 No.905437

>>902275

Is this glitch hop?


 No.905488

File: 7dac0b29635da4e⋯.webm (Spoiler Image, 9.65 MB, 816x1080, 34:45, boatslut_impreg.webm)


 No.905584

File: 2856ec840b50482⋯.jpg (33.87 KB, 704x476, 176:119, mpvsnap-Dream Hunter Rem -….jpg)

Another encoder autist here. The kind of guy who uses a purely commandline gentoo system.

For encoding starters, the best advice I can give is READ THE FUCKING MANUAL. Your waifu cries every time you boot up windows, but if you use windows, then whatever software you use for treating video/audio/subs/etc was probably made with linux first in mind anyway, in which case a manual should be available in this page http://manpages.ubuntu.com/ .

That is the web-accessible manual repository of the ubuntu linux distribution, it's not windows, but unless something in the manual is linux/unix-specific, it'll also apply to windows. Make sure to read the specific program's own website, since it may contain information not present on manuals. For instance I use this irc client called irssi which is otherwise nice, but the manual page is incomplete, and they make you go to their website to learn how to use it.

You will find most of the time you'll be using nothing but ffmpeg to do these things, it's a great program although it has some dodgy spots. One of the dodgy spots is its at times incomplete documentation, so don't be afraid to ask stupid questions, other ffmpeg users went through what you are going through and will be happy to ansawer.

For further reading, places with good information are the hydrogenaudio forums and its wiki, doom9 forums, and ffmpeg's website which does include information not on ffmpeg's manual.

Avoid the hi-fi forums in absolutely any circumstance. That's a hellhole where they sell snake oil to jew people looking for better audio solutions out of their money, and propagate harmful pseudoscience.

These aren't the only websites on the internet obviously, just what I know.

Another piece of advice is just encode, if it goes wrong, figure out why and learn from it.

If you read a term you don't understand, look it up, and use good judgement and cross references to figure out its meaning and what is better than what.

And the third is completely optional and irrelevant to the subject at hand, but I find it helpful. There's a program called chocolatey which manages software for you on windows, like a package manager you'd have on linux. Imagine it like a windows store, but not shit, and commandline. It can install things like youtube-dl and ffmpeg for you and have it available in any folder you have CMD open without you having to mess with things like your %PATH% variable, and it makes updating and installing a simple matter of knowing the commands that do it instead of browsing webpages and running autoupdaters.

https://chocolatey.org/

I'm not advocating for mindlessly updating everything since we've all seen it go wrong these days, but it's a reasonable thing to do when it comes to encoding/decoding/etc software, as their kind has consistently improved with releases in the past.


 No.905585

File: 72de1dad5336cb9⋯.jpg (29.79 KB, 704x476, 176:119, mpvsnap-Dream Hunter Rem -….jpg)

>>899814

>fast seek

>broken

That was fixed with ffmpeg 2.1, which released in 2013.

https://github.com/FFmpeg/FFmpeg/blob/master/Changelog

@line 584:

- when transcoding with ffmpeg (i.e. not streamcopying), -ss is now accurate
even when used as an input option. Previous behavior can be restored with
the -noaccurate_seek option.

Always specify it on the input file so you don't have to decode the entire file.

>video bitrate 0

>For whatever reason if you don't do this CBR will be used even if -crf is specified.

No idea what you're on m8. Usually you do CBR with ffmpeg with encoder-specific options or you set -b, -minrate and -maxrate to the same number.

>Check first if using -f 43 outputs one that can be posted straight to 8chan,

I can one-up this.

youtube-dl -f "(bestvideo+bestaudio)[ext=webm][filesize<16M]" <ytlink>

Replace <ytlink> with your youtube link obviously. This will use some basic youtube-dl logic to download a combination of the best webm video plus the best webm audio which togheter fit under 16 mebibytes (8chan's maximum uploaded file size). Very often however, you're better off reencoding the absolute best quality youtube offers yourself, but if you just want something quick this is the way to do it.

The quotes in the command itself should be kept and are there so that your commandline doesn't interpret some characters (such as []+() ) which are very often special characters in command lines. I really don't know if that also applies to cmd.exe on windows, so a windowsfag will have to come over and tell me if it works.

>>multi-threading

>>I don't use this on my trash computer. Not sure what the general advice is.

It lowers quality in most codecs (usually talking in the ballpark of 1-3% here) while almost linearly scaling with the amount of cores you're using as far as encoding speed is concerned. Sometimes you can afford to, sometimes you have to, and sometimes you don't care. But most of the time it's best left at the default.

I have a really shitty cooling setup for my CPU (quad core, but maxing 2 cores already makes it go over 90c), so I usually use this to avoid using an uglier fix like cpulimit or fixing the damn thing.

>-framerate and not -r

-framerate and -r control the same thing, but they're different options with different purposes. Best explained by the ffmpeg manual page, which I've copypasted to here if any of you tards use windows:

https://paste.pound-python.org/raw/IBgeAwSH0qhUxBcZ9u2Q/


 No.905586

File: 32e59126a866220⋯.jpg (36.92 KB, 704x476, 176:119, mpvsnap-Dream Hunter Rem -….jpg)

>>899813

>While best, its main drawback is that you can't easily predict the output filesize

CRF serves 2 purposes:

<speed up encoding

2 pass is slow, crf is faster

<consistent quality across multiple encodes (say, every episode of an anime)

Because if you use bitrate, then the bitrate is constant, but an episode may require more bitrate than the other, and one episode looking notably different than the other is much worse than they all looking the same in terms of image quality.

Specifying a bitrate ensures you get approximately that bitrate, specifying a CRF ensures you get approximately that constant quality. However, it is wrong to say the image quality of 2 pass or CRF is better than one or the other. They're simply different ways of getting the filesize/quality ratio you want out of your encoder.

You will find that in most encoders, any 2 pass setting they have, actually just does some black magic to figure out a crf value that happens to be the overall bitrate you want. So in fact, you can even say VBR is actually CRF, depending on the encoder.

>>-f

>>Some intermediate codecs don't end up in a container. Generally best to specify it explicitly.

What -f does is specify which muxer gets used. It's usually guessed by extension if you don't use it, but with -f you can have any extension with any muxer you want, and you can use some muxers with no associated extension (like image2pipe).

You can get a list of muxers with "ffmpeg -muxers"

>-g

This is a ffmpeg wrapper to encoder specific options. Its meaning varies slightly for each encoder. In most cases it doesn't decide on absolute GOP size, but instead it decides on the maximum GOP size which the encoder is allowed to use. No matter what you set it to, it doesn't necessarily mean the video will have a single keyframe at the start and none after.

>VP9

Actually a H.265 competitor and not a h264 one. It quite clearly beats h264 even if only by 10 to 20% when we're talking h264 10-bit.

Early benchmarks favored H.265, but it seems like everyone gave up on benchmarking them early on, and the encoders for either changed a lot since then, so it's difficult to speak. Either way 8chan only allows vp9 and h264 anyway, so your pick should be vp9.

>With WebM I don't think you can mix H.264 with Opus, you need to use AAC

WEBM doesn't allow H.264 nor AAC. You can however post h264 video with aac audio on 8chan, you just need to use the mp4 container instead of webm.

Anyway that's just what I felt like saying for the moment, the avatarfagging was just so you know the posts are related.


 No.905613

File: e1d162215d50cb5⋯.webm (Spoiler Image, 1.2 MB, 640x360, 16:9, 1413642544990.webm)

>>905584

>>905585

>>905586

I'll add to that a few things since I did in fact go full autistic. WIP. I avoided too much aggressive tweaking since some of the options I don't fully understand and need to be set per-PC. Mostly the rows/columns one.

https://gitgud.io/8vitagen/hackpaste/blob/master/guides/videnc.md

>fast seek

I'm erring on the side of caution there, and also it's illustrative of argument ordering and that it can cause issues with hard-subbing without setpts.

>video bitrate 0

I may have meant VBR, but the point is it won't use CRF if you don't specify that. vpxenc isn't quite as stupid.

>youtube-dl

That's helpful!

>-r and -framerate

I actually figured that one out through a recent video conversion. You need the fps or framerate filter (usually FPS, interpolating frames often looks like shit and should only be used with odd framerate conversions.)

>CRF

I was testing 4chan posting limits for reasons and found that with a video I was using VP8 CRF was producing better output than than VP9 VBR (on top of them not even allowing VP9) at the same size, so it's more that sometimes you'll get a better video but VBR is best to start with since it's easier and also usually works well. CRF encoding for a specific filesize is educated guesswork.

>-f

I should specify this can be used for input specification too, notably for pipe-based input of images which is how I did Ugoiras before finding the better way. Again, order-dependent arguments are a big thing in FFmpeg.

>-g

Didn't know that was encoder-specific but for the purposes of VP9 it's to control keyframe generation and I generally discourage videos that allow too large a gap because I hate videos that don't allow seeking.

>VP9

Insofar as 8chan are concerned it competes with H.264 because it's the other option and while it doesn't compress as well, it does better than VP8 usually, and VP9's encode times are nothing to sneeze at.


 No.905663

>>894561

This sequel basically confirms that the fist one is the greatest con never told.

Imagine yourself as Sempai. You're a capable worker, diligent, beautiful and still in your prime...but you work at McDonalds. Granted you're a manager, but that doesn't amount to much except a slightly shorter shower since you don't have to wash off as much of a stench of french fries and shame. You've basically resigned yourself to becoming like your sempai: a bitter husk of an old woman still working here in her forties and with some dumpy salaryman you had to settle for.

Then comes a bright-eyed kid. About the same age as you when you first joined in...someone you can train.

Someone who can replace you.

So you watch her daily routine to see how often she passes by, and one day you just "happen to be nearby" when she's checking out the poster. You invite her to work there, aided by your unseen backing, and proceed to groom the eventual sacrifice to the altar of the unholy clown you serve. She's clumsy, scatterbrained, and more than once you've had to bail her out. But it'll be worth it i the end. Off the clock you're already pushing to get into the true management position; comfy office jobs with absolutely no chance of coming into contact with ketchup or fryer oil unless you want to. You're more than happy being an office lady because you know you won't be for long, as long as you can get out of here.

On the day it finally happens, you begin putting in the final touches on your ward, as well as planning your "retirement". It goes off flawlessly, with the crew giving a tear-filled goodbye and with you already looking forward to your new job.

So we flash forward a few months to the sequel. As you expected, your sacrifice was accepted into the void you created, and has become a shiny new cog in an old machine. You still come by sometimes, because when you don't have to see them every day you can actually appreciate the look and smell of fries from time to time. You don't see her often, but when you do she's still go that bright and cheery expression of someone who has yet to realize they're going to lose their soul to that place. You just to push a little bit more, and make sure she has no reason to quit.

That's why we see the side by side of the Sempai and the Rookie: one flower is blooming while another slowly withers.


 No.905800

File: 5d08b9d5e5d99be⋯.webm (15.96 MB, 1280x720, 16:9, Cyborg Ojii-san.webm)


 No.905803

File: 19d38be099a4d55⋯.webm (8.75 MB, 1280x720, 16:9, nep_flat.webm)

Not great but fun, much like the rest of the series.


 No.905806

>>905585

>package manager for windows

I was just thinking the other day why nobody had bothered making something like that yet.


 No.905832

File: 40b6fd48c396535⋯.webm (15.31 MB, 1280x720, 16:9, nep_keikaku.webm)

It's ridiculous what an extra 60Kkps makes when you don't miscalculate the video length.

>>905806

Because in their culture it's called an "app store".


 No.905883

>>905832

Macfags practically invented the app store culture and they've got a very popular package manager in Homebrew.


 No.905888

File: 17527e67f8312bd⋯.webm (Spoiler Image, 15.65 MB, 640x480, 4:3, Insert dick to continue.webm)


 No.905914

>>905888

>Fate stay night Ilya castle mana transfer.webm


 No.905918

File: cec723611b4be7a⋯.webm (8.68 MB, 352x262, 176:131, evangelion 98.webm)

>>905888

Call President Abe, I have a solution for the economy.


 No.905959

File: ef9fe3c18066ee3⋯.webm (5.42 MB, 640x360, 16:9, Fist of the North Star - ….webm)


 No.906124

File: 30c4f7ae77825f6⋯.webm (13.06 MB, 1440x1080, 4:3, Enishi OP.webm)


 No.906695

>>905832

>"app store"

Which no one uses. Everyone just downloads installers and runs those in order to install software from anywhere. That's Windows culture.


 No.906702

File: 727b8b65411a46f⋯.png (346.91 KB, 513x720, 57:80, sauce.png)

File: 99e26f23dff59b5⋯.png (507.93 KB, 850x464, 425:232, really_mate.png)

>>904669

Really shit guide. One should just use 2 pass constant quality settings.

Here's a new one:

ffmpeg -i "filename" -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 32 -speed 1 -an out.webm

ffmpeg -i "filename" -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 32 (0-60, lower is better quality) -speed 1 -c:a libopus (-b:a _k default is 96k) out.webm

Passing default values to the encoder is just a waste of time.

>muh the defaults may change

So does the codec. If better quality is achievable they'll change the defaults and I don't know why this is a problem.

If the size is too large you can scale the video with -vf scale=x:y , change the framerate with r:Hz or lower the quality with -crf x.

Note that you should keep in mind to find the sweetspot between quality and resolution. Higher resolution can still contain less details and details can be confined by low resolution.

>>905888

Is Buttobi CPU if anyone else cares. Watched it. Was really enjoyable. Only active torrent I found is https://nyaa.si/view/186127

Post last edited at

 No.906726

>>906702

>dead shit place like >>>/rec/

That specific webm's source was just recently posted on /rec/, but can also be fairly easily sourced from the webm itself.


 No.906733

File: ba383e3bc5bcf2a⋯.jpg (48.58 KB, 640x480, 4:3, [Seichi]_Chibi_Maruko_Movi….jpg)

>>906702

>Using crf

>So new he doesn't understand the no rec rule.

I'm convinced there was a different reason you got banned, or you were just really obnoxious about it.


 No.906736

>>906726

>but can also be fairly easily sourced from the webm itself.

What did you use?

After he complained I tested trace.moe and it didn't get it.


 No.906738

File: e0edebf44799183⋯.png (96.04 KB, 963x165, 321:55, Untitled.png)

>>906702

>>906726

>>906736

I got it in about 3 seconds. Save a snapshot of the webm and then use saucenao.

Give a man a fish, etc. etc.


 No.906740

>>906736

The character names. There are only so many hentai out there.


 No.906777

File: f54651932560ee2⋯.webm (1.98 MB, 600x337, 600:337, beito.webm)

>>906702

>If better quality is achievable they'll change the defaults

How are those AV1 encodes at default settings coming along?


 No.906862

File: 069c176083c53ed⋯.webm (818.39 KB, 853x480, 853:480, punishment.webm)

>>906733

To be fair I was using that further up until learning of VBR, and it's also a fact that CRF can produce superior results sometimes and works well for short video clips and music WebMs. The problem is that it's really hard to predict the output filesize for longer clips, so unless you're a real autist prepared to trial and error what setting to use for a given limit, and for something as slow to encode as VP9, using VBR is by far the simpler method that most people should use as a default.

>>906777

That is not a good comparison when the codec and encoders are still a work in progress.


 No.906884

File: c2fd2f2a31b3868⋯.webm (Spoiler Image, 7.04 MB, 960x544, 30:17, spin.webm)

File: 0e03b39c9ff8c14⋯.png (283.56 KB, 698x498, 349:249, pat skill.PNG)

>>906881

I knew I had it somewhere.


 No.906886

>>906881

>>906884

This one is pretty good too.

https://ecchi.iwara.tv/videos/dggjktgnws7jdm9y


 No.906889

File: e73e2663b2a02b9⋯.jpg (42.9 KB, 702x493, 702:493, Snapchat-683893542.jpg)

>>906886

>>906884

Appreciated.


 No.906891

>>906886

For reference, youtube-dl works on many sites including that one.


 No.906892

>>906891

You can also download the source file directly from iwara with the ダウンロード button.


 No.906919

>>894534

God that movie gives me such an airforce stiffy.


 No.906921

>>906889

>Snapchat[...].jpg

>Tiny resolution

I'm judging you, anon.


 No.906922

File: a98447fee93a8a4⋯.jpg (4.13 MB, 3508x2480, 877:620, __original_drawn_by_nanana….jpg)

File: 0ec0115575dabb9⋯.webm (5.9 MB, 720x720, 1:1, 0ec0115575dabb924b27d8320….webm)

File: 8bb48d30a049472⋯.webm (5.6 MB, 726x720, 121:120, 8bb48d30a0494722c9fc27e9e….webm)

>>906921

You judge, but don't rectify.

>>906892

Well that's nice of them. Most video sites don't allow that luxury.


 No.906927

File: b9df38b64b79951⋯.webm (11.99 MB, 640x360, 16:9, Killer_Queen.webm)


 No.906928

File: 159fb86881bd5f5⋯.webm (10.61 MB, 640x360, 16:9, Another_One_Bites_The_Dus….webm)


 No.906929

File: ff5e7c27204c9b4⋯.webm (271.49 KB, 640x360, 16:9, Avdol.webm)

>>899145

Best girl.


 No.906941

File: 1bc3ef55220c13f⋯.webm (15.47 MB, 716x480, 179:120, chirin's red pill.webm)

>>906702

>>906736

>>906738

>>906740

The source was also in the metadata.


 No.906971

File: 1e53fe3d70accdb⋯.webm (15.74 MB, 960x540, 16:9, Only my Railgun Wotagei.webm)


 No.906973

>>906941

Thank you Hitlerwolf.


 No.906986

File: a819316460daea9⋯.webm (Spoiler Image, 15.97 MB, 1080x606, 180:101, raymoo_2hu.webm)

>>906884

Here's one with higher quality.


 No.907081

>>899145

Longer at

https://www.youtube.com/watch?v=uuBETyA_yxc

also its pronounced obsessive not fucking sadistic get the filename right, although that wouldn't be a bad thing.


 No.907082

File: b7677e7596c0266⋯.webm (15.95 MB, 1920x1080, 16:9, b7677e7596c0266785ee35c84….webm)

>>907081

Not my WebM but have this.


 No.907093

>>896456

Jokes on you Anon, I love that song.


 No.907101

File: 6bd49a087a22f36⋯.webm (4.22 MB, 1280x720, 16:9, I adore her (≧◡≦).webm)

File: c3771c26f4596b1⋯.webm (2.11 MB, 1280x720, 16:9, kon.webm)

>>907082

I wish that guy would produce more content. He has a pretty gud taste in music.


 No.907852

File: f7ad8e291844e36⋯.webm (Spoiler Image, 15.91 MB, 1280x720, 16:9, Wakayama - 瀞峡.webm)


 No.907955

File: 3094ecaa228f1a6⋯.png (9.56 KB, 1064x724, 266:181, Screenshot_2019-02-22_15-5….png)

File: e64e0bcaf634ee3⋯.png (31.24 KB, 1110x635, 222:127, Screenshot_2019-02-22_15-5….png)

>>907852

This would be a good time to mention two of the helper programs with FFmpeg. FFprobe (can get information about a particular file's streams and also notably, per-frame statistics) and plotframes (Perl script to use this to subsequently use GNU Plot to display bitrate over time, and also where the keyframes are, first pic). Why? Because this is the plot for that video and it shows why -g 9999 is a terrible idea for a longer video, because without regular keyframes seeking the video is painful! In this case the very first frame isn't visible but that's the one pushing the scale up to 1400K while most of the rest isn't even 100K.

It's for that reason, the image guide is bad for specifying -g 9999 in its example that people will cargo cult copy. It's fine for a really short video, but for a long one? I recommend at most 20 seconds between keyframes, so take the video's framerate and multiply by 20. That's your -g spot.

There's also plotbitrate.py (Python script, second pic) but it doesn't have the plot scales correct, I have no idea what's up with that. I've also tried using a combination of grep with FFprobe to import the data into Excel/GNU Octave for plotting but that was producing its own weird differences where H.264 >>903692 had a much higher mean bitrate than any of the VP9 examples from >>903685 despite being very similar filesizes. ~7000 for H.264 and ~4500 for VP9.

$ ffprobe -show_frames t10.mp4 | grep pkt_size | cut -d '=' -f 2 > 10h264f.txt


 No.907982

File: 69ab481fcb0618f⋯.mp4 (9.15 MB, 1280x720, 16:9, u got that gunt.mp4)


 No.907989

File: 2f79a7f2f0d495a⋯.webm (3.6 MB, 500x500, 1:1, moe shop-love taste.webm)

>>907101

The original of the song in "I adore her (≧◡≦).webm".

Quite nice actually.


 No.907993

>>907982

I hope you realise that's the third time this was posted in this thread. Also, >mp4


 No.908007

File: fb8ddfdfbd83c13⋯.png (25.87 KB, 1280x775, 256:155, overview.png)

File: 19034817681b2d9⋯.png (57.76 KB, 1280x775, 256:155, zoomin.png)

>>907955

Add conversion to CSV and then using grep to filter it to keyframes and not.

#!/bin/sh
ffprobe -show_frames "$1" | grep -A 15 "media_type=video" | grep "pkt_pts=" | cut -d '=' -f 2 > "$1".pts.txt
ffprobe -show_frames "$1" | grep -A 15 "media_type=video" | grep "pkt_size=" | cut -d '=' -f 2 > "$1".br.txt
ffprobe -show_frames "$1" | grep -A 15 "media_type=video" | grep "key_frame=" > "$1".kf.txt

I hate GNU Octave.

plot(kx,ky,"or;keyframes;",nx,ny,"g;frames;") ; xlabel("PTS") ; ylabel("Bytes")

But yeah. Two whole keyframes in that 2+ minute video. If I want to seek, it has to process from the beginning which takes a non-trivial amount of time. NEVER make videos that do this!


 No.908009

Just kill me now. Spoiler warning for Danganronpa for real this time.


 No.908010

File: 62af850d68527bc⋯.webm (Spoiler Image, 7.07 MB, 720x340, 36:17, 62af850d68527bc472d805076….webm)

Gods. Just smug me to death.


 No.908237

File: 29769c093865a3e⋯.webm (7.97 MB, 640x360, 16:9, Ashita no Nadja Gachimuch….webm)


 No.908369

File: 39db39ca39e01f5⋯.webm (Spoiler Image, 15.97 MB, 3840x2160, 16:9, Obuchi Sasaba and Mt. Fuj….webm)

>>908007

>keyframes

>not cramming as much video QUALITY into 16Mb as you possibly can

Compromises must be made.


 No.908413

File: bb5ac3d8ee2b5b7⋯.png (12.91 KB, 1047x737, 1047:737, whoops.png)

>>908369

A broken video is a bad compromise. You can also post 10-bit H.264 here which compresses better sometimes. But try actually playing it in most browsers, it usually won't. It will not hurt that majorly to have a few scattered throughout a video like that. What WILL hurt is if you stuff up and assume keyframe interval is measured in seconds. I've done that. Video in question is the park battle from Police Story 2 so I won't post it here.


 No.908449

File: 360180b3df1b9e9⋯.webm (5.3 MB, 1024x576, 16:9, kc tism.webm)


 No.908454

>>907993

The end was different on the one he posted, to be fair.


 No.908471

>>900893

>>900954

The anime clip wasn't the original footage. The clip was from a game that showed a rabbit coming out of its burrow in a snowy forest, her saying it was cute, and then the rabbit got skewered by a bolt a second later and a hunter got it.


 No.908801

File: b59089604ef3bdd⋯.webm (15.24 MB, 512x212, 128:53, TheTale of Heike.webm)


 No.909195

File: a876a049f2dfb51⋯.webm (2.55 MB, 1920x1080, 16:9, 2D Promotional Video.webm)

>>897038

Wish this had gotten the budget for a proper anime style adaptation, the manga is so good. Fuck 3DCG shit man.


 No.909197

>>909195

Well, 3dcg is actually more expensive and has higher potential than 2d.


 No.909214

File: 377cb49bdb07eb9⋯.jpg (18.05 KB, 250x250, 1:1, 91d954108047159c3d19d89d5e….jpg)

>>909211

You should be ashamed for not knowing.


 No.909219

>>909197

Jesus christ where do you apologists come from?

>>3dcg is actually more expensive

Bullshit, not the kind used in the tv series. In 99.99% of circumstances, animating in 3D is easier. I know i'm a fucking CG animator.

>>higher potential than 2d

stop talking out of your ass.


 No.909221

>>909214

Dude my memory stopped working a long time ago, I just know that I've heard it before.


 No.909222

File: 07a988cd86fddd3⋯.jpg (109.79 KB, 488x647, 488:647, 07a988cd86fddd3f41c2b7d49b….jpg)

>>909221

>after school es time

How long ago did you save it?


 No.909224

>>909222

45 minutes ago


 No.909229


 No.909243

File: 183b02e9a440a16⋯.webm (13.34 MB, 480x360, 4:3, キューティーハニー pilot.webm)


 No.909256

File: 74f66be618f5966⋯.webm (7.34 MB, 856x480, 107:60, top quality.webm)


 No.909260

>>909237

I'll take a look in my old video project folder.


 No.909262

File: feda59a37ca33fe⋯.webm (10.49 MB, 853x480, 853:480, Grumpy jiisan alice.webm)

>>909237

Well it was still there, surprisingly. Unless you were actually referring to something else and if so please accept this grumpy jii-san video anyways.


 No.909264

File: c7fb89290d81667⋯.webm (6.54 MB, 480x270, 16:9, 1421897652297.webm)


 No.909265

File: 8f1bc0beabe37c5⋯.webm (Spoiler Image, 2.65 MB, 640x360, 16:9, AWOOO.webm)


 No.909266

File: 42b3dbcaa8255d3⋯.webm (6.31 MB, 1280x714, 640:357, Carrot loves you.webm)


 No.909267

File: 2c15dffc4a28d33⋯.webm (7.86 MB, 480x360, 4:3, Castleshikigami.webm)


 No.909269

File: 50bc1371345f993⋯.webm (4.9 MB, 1280x720, 16:9, cowfee.webm)


 No.909274

File: b1ca2aec9a7f587⋯.webm (6.38 MB, 640x360, 16:9, druggedcats.webm)


 No.909276


 No.909277

>>909269

Kawaii.


 No.909278

>>909195

Woaw that looks gorgeous.


 No.909283

>>909262

That's the one, thanks. Sorry, I mixed up the name.


 No.909284

File: 8812bbb538e9418⋯.webm (Spoiler Image, 2.21 MB, 854x480, 427:240, goofy becomes a magical g….webm)


 No.909289

File: 3b95b05a8d98294⋯.webm (4.7 MB, 640x360, 16:9, Mio.webm)


 No.909300

>>909195

>>909197

I doubt the CGI in animu is more expensive than hand drawing. They use simple models, render few frames, animations aren't that great, and the texturing is super simple along with the lighting/shading. Most of the work involved in making a scene using those tools is the initial setup of the assets and the rigging/animating, once those are done, it's far cheaper on a per frame basis than hand drawing, especially if they're using interpolation or repeating frames.

As a fan of CG and 3D modeling, from my view, the one critical problem with CGI in anime isn't that it can't look good. It could look amazing. But absolutely nobody fucking bothers, no one wants to spend the resources or the time on doing so. The two reasons, by a landslide, that anime CGI looks so bad is 1) using low framerate for the rendered objects [though the framerate of the source project itself is obviously the maximum, and depending on the animation of the assets, that may not be enough], which makes them look extremely jerky, janky, and massively out of place compared to drawn objects, and 2) skeletal animation quality. If you can't properly rig and animate your 3D model correctly, it doesn't matter if it's god-tier in the looks department with a high framerate. It will look absolutely horrendous and awkward with stilted, jumpy movements that essentially translates to "uncanny valley" but for motion.

CGI does have great potential, but you are completely out of your mind if you think that potential will be fully realized in any animu show.


 No.909330

YouTube embed. Click thumbnail to play.

>>909300

Some anime do have god tier 3d animation. Even if you forget FF movie, there is this.


 No.909331

File: e0d3115e3b38f53⋯.webm (14.81 MB, 256x171, 256:171, アオス.webm)


 No.909335

File: 5fc42414c788a9b⋯.webm (2.94 MB, 640x360, 16:9, Madoka kazoo.webm)


 No.909348

>>909330

That is actually pretty good. I haven't seen that. And the reason that's as good as it is is because it deals precisely with the two major issues I highlighted: animation quality and framerate. Those are clearly animated by motion capture, and that's rendered at what looks like at least twice or three times the number of frames you see in shit like the Overlord CGI generated armies, for example.

> Even if you forget FF movie

No no, the movies don't count. Those are photorealistic 3D renders with budgets behind them, those don't suffer from the problems that make people hate animu CGI (I'm assuming you're talking about the old FF movie from 2000 something, unless there was some cartoonish version that came out in the past few years). When people in current year complain about CGI looking like absolute garbage, they're talking about the cel-shaded jerky-moving assets you see in shows. Movies like Space Pirate Captain Harlock aren't the issue.


 No.909351

>>909348

>Overlord CGI generated armies

I don't think that should even count as 3DCG when we talk about it in the context of anime. Examples like that are done out of misguided laziness, not as any sort of deliberate artistic choice. I think people are willing to accept the faux-2D low framerate 3DCG animation as long as it's consistent and the entire show is done like that. Inserting 3DCG suddenly into an otherwise entirely 2D show just because you don't want to animate hundreds of background characters or a spaceship is jarring as fuck and ends up looking much worse than if you just skimped on the animation but kept it 2D. Hell, it's not like those examples even have complex 3D animation either since that would defeat the purpose.

I think this is another of the rules that the animation industry needs to drill into their heads: 3D and 2D don't go together. Either make something entirely 2D or 3D, or do something like Etotama where there's a clear boundary between the 3DCG scenes and the classic 2D animation. The massive difference in shading alone is what keeps 3DCG from ever blending naturally into a 2D sequence. You can use 2D that's drawn to look like a 3D render to fill the gaps in a 3DCG show and it will look seamless if done right, but the reverse is extremely difficult if not impossible to do.


 No.909385

>>909330

This isn't good though. It's garbage compared to the 2D animation in it's own show. Are you pretending to be retarded on purpose? They're literally using CEL shaded CG to imitate the look of 2D anime but they're failing because it doesn't look exactly like 2D anime. Their second rate animators don't have the skills to do this by hand.


 No.909386

>>909300

>But absolutely nobody fucking bothers

That's because the CGI in anime is only used to cut costs. They're using it because they don't want to sped the money to animate that stuff in 2D. Of course the CGI is going to be garbage. It's a cancer that's killing traditional anime.

> using low framerate for the rendered objects

It's done to try and imitate anime's limited animation style. That's why full 3DCG like the shit Polygon do also has it's frame rate cut.


 No.909387

>>909348

>That is actually pretty good.

It's unacceptable, it's no where near as good as the hand drawn cuts.


 No.909388

>>909351

>I think people are willing to accept the faux-2D low framerate 3DCG animation as long as it's consistent and the entire show is done like that.

Fuck that shit. Why settle for a cheap imitation?


 No.909397

>>909388

Money don't grow on trees. Either we have cheap imitations, or we don't have anime at all. Be sure, that creators want to make anime as good possible, but they are limited with the money, people and time, so sacrifices have to be made.


 No.909401

File: 34652493509d281⋯.webm (5.56 MB, 960x540, 16:9, dinozaki.webm)


 No.909402

>>909397

>Either we have cheap imitations, or we don't have anime at all.

This is only the case for the worst of the worst garbage that would never be greenlit otherwise. The problem is that too many anime in the last few years have very egregiously been abusing CGI as a means to avoid drawing something difficult. CGI has already killed mecha. The economic imbalance will kill the traditional anime we all know and love.


 No.909404

File: c20aae95435bc60⋯.webm (6.68 MB, 960x540, 16:9, only my railgun group wot….webm)


 No.909405

File: 9c07292d06099b5⋯.webm (2.56 MB, 320x240, 4:3, Neet is ok.webm)


 No.909616

File: fa6f9916438178b⋯.webm (14.77 MB, 960x540, 16:9, Aqours - MY 舞☆TONIGHT.webm)


 No.911185

File: 9236837e2894423⋯.mp4 (1.87 MB, 640x360, 16:9, Chu Chu.mp4)


 No.911314

File: 11d6d8eaf55e15d⋯.webm (Spoiler Image, 3.82 MB, 1414x1397, 1414:1397, bongo bong.webm)

>>909266

Reminds me of webm related. Sage/spoiler because not entirely 2D related.


 No.911431

>>907101

>He has a pretty gud taste in music

No he does not. When the clip was shorter other people were posting his work with that song and he pulled a DMCA on all of them. The superior version is shorter but he never made the short version.


 No.911617

File: 33f089765240ecb⋯.jpg (101.45 KB, 1920x1080, 16:9, 33f089765240ecb7dff5a169d1….jpg)

>>907101

>wubwubwub electronicshit

>good taste in music

Anon...


 No.912008

File: ac7d9844d1954f2⋯.webm (15.83 MB, 1920x1080, 16:9, 手技TEWAZA「井波彫刻.webm)


 No.914467

>>912008

Comfy. I wonder how soft/hard that wood/metal is.


 No.915129

File: 4d3007a7e38cfa5⋯.webm (5.16 MB, 640x360, 16:9, mizkan.webm)




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / agatha2 / animu / baaa / choroy / doomer / g / jenny / xivlg ]