Oh shit, is this real?
When do they have sex?
Someone sure liked Plastic Nee-san.
Why is the Lain fanbase so autistic?
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.
It's a good shit.
I just went and watched all of this ojisan's videos on this. I never knew planes took so much work to maintain.
It's the same autism as knife sharpening.
I fucking miss Monogatari.
They're still gonna be releasing new episodes this year.
YouTube embed. Click thumbnail to play.
Depends on the type of plane. Commercial airliners are completely taken apart every two to four years.
Start watching from 7 minutes in.
What a reception.
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.
I unironically enjoyed this series.
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/
Is there a first part?
I think we all did. S2 soon.
I really hope the kind of people who agree with this aren't here.
The shinden is overrated.
What's wrong about it?
>no pic related
One fucking job.
What a way we've come since then.
I like how the first one is an mp4, whie the second one is a webm
Mp4 is arguably way better than webm. It has better quality and file sizes.
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.
Holy shit, does cuckchan have sound now?
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.
>thumbnail is in 4:3 aspect ratio
>webm is in 16:9
Is this considered shit animation?
Presenting: One of Yamakans greatest hits.
I think I now have 悪性腫瘍
Last one for now, might post some clips of Lanipator's parodies of it later
Why did you make these letterboxed?
Song source is "U Got That" by "Halogen". Pretty fucking gud deep house songs.
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.
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.
Did Chad call his nip-bros to chase Davido-kun down in Japan?
OK found a way to do it, albeit much much slower. Monochrome looks way nicer though, not like indie pixel art.
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.
>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.
>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
It is insanely helpful to know your way around Bash or similar even if in a hackish way.
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...
_amm "$1" 4 12
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.
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
Also fixed my mistakes I think.
eenteresting. Does crf yield the best compression for ascii videos?
Thank you for your efforts tech wizard.
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.
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.
ffmpeg -i $FILENAME $OPTS -vn -sn -c:a libopus -b:a $BR t.opus
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.
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.
Some intermediate codecs don't end up in a container. Generally best to specify it explicitly.
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.
>-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.
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.
Always do this. On Windows specify NUL instead of /dev/null
I don't use this on my trash computer. Not sure what the general advice is.
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.
You have the capability to find out easily. Do it.
That's a great guide, thanks for going over all those options
>While best, its main drawback is that you can't easily predict the output filesize.
<what is constrained quality encoding
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.
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.
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 -
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.
Like with H.264 that's a game of diminishing returns. Amusingly, that names its slowest profile "placebo".
>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.
>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.
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.
>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!
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
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))
Damn it this is the video.
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.
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.
Where's his shield?
To think the porcelain tags can wander Lumbridge safely and they'll never know why.
Oh shit they made a sequel? I remember the first one.
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
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
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"
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.
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.
IT's considered a soundless webm
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.
How come these commands and more doesn't work with my ffmpeg?
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).
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.
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.
Is your ffmpeg not compiled against libvpx 1.7.0?
row-mt was added in that version of the encoder.
Forgot to specify -row-mt 1 to enable it. I am too baka for this shit.
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:
>Codecs don't change much, the encoders do.
The Motion Picture Experts Group are a strange bunch.
>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.
>Libvp9 is the best one then, yes?
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.
Just updated everything.
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.
I didn't think you could use H.265 here anyway.
This mp4 made me vomit blood.
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.
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.
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?
>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.
WebM for retards is for retards.
Better to have retard webms than no webms.
I would never be able to bear the shame of using a program named Webm for retards.
Lucky for you then that the fags at Github made it rename it. It's for bakas now.
I definitely need to consider a new guide that is text-based. Images don't let you copy text.
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.
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.
I just watched this and it seems to be exactly what you're looking for though? >>903225
Is this glitch hop?
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.
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.
That was fixed with ffmpeg 2.1, which released in 2013.
- 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.
>>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:
>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.
>>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"
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.
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.
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.
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.
>-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.)
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.
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.
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.
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.
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.
Not great but fun, much like the rest of the series.
>package manager for windows
I was just thinking the other day why nobody had bothered making something like that yet.
It's ridiculous what an extra 60Kkps makes when you don't miscalculate the video length.
Because in their culture it's called an "app store".
Macfags practically invented the app store culture and they've got a very popular package manager in Homebrew.
>Fate stay night Ilya castle mana transfer.webm
Call President Abe, I have a solution for the economy.
Which no one uses. Everyone just downloads installers and runs those in order to install software from anywhere. That's Windows culture.
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.
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
>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.
>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.
>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.
I got it in about 3 seconds. Save a snapshot of the webm and then use saucenao.
Give a man a fish, etc. etc.
The character names. There are only so many hentai out there.
>If better quality is achievable they'll change the defaults
How are those AV1 encodes at default settings coming along?
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.
That is not a good comparison when the codec and encoders are still a work in progress.
I knew I had it somewhere.
For reference, youtube-dl works on many sites including that one.
You can also download the source file directly from iwara with the ダウンロード button.
God that movie gives me such an airforce stiffy.
I'm judging you, anon.
You judge, but don't rectify.
Well that's nice of them. Most video sites don't allow that luxury.
The source was also in the metadata.
Thank you Hitlerwolf.
Here's one with higher quality.
also its pronounced obsessive not fucking sadistic get the filename right, although that wouldn't be a bad thing.
Not my WebM but have this.
Jokes on you Anon, I love that song.
I wish that guy would produce more content. He has a pretty gud taste in music.
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
The original of the song in "I adore her (≧◡≦).webm".
Quite nice actually.
I hope you realise that's the third time this was posted in this thread. Also, >mp4
Add conversion to CSV and then using grep to filter it to keyframes and not.
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!
Just kill me now. Spoiler warning for Danganronpa for real this time.
Gods. Just smug me to death.
>not cramming as much video QUALITY into 16Mb as you possibly can
Compromises must be made.
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.
The end was different on the one he posted, to be fair.
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.
Wish this had gotten the budget for a proper anime style adaptation, the manga is so good. Fuck 3DCG shit man.
Well, 3dcg is actually more expensive and has higher potential than 2d.
You should be ashamed for not knowing.
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.
Dude my memory stopped working a long time ago, I just know that I've heard it before.
>after school es time
How long ago did you save it?
I'll take a look in my old video project folder.
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.
Woaw that looks gorgeous.
That's the one, thanks. Sorry, I mixed up the name.
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.
YouTube embed. Click thumbnail to play.
Some anime do have god tier 3d animation. Even if you forget FF movie, there is this.
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.
>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.
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.
>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.
>That is actually pretty good.
It's unacceptable, it's no where near as good as the hand drawn cuts.
>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?
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.
>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.
Reminds me of webm related. Sage/spoiler because not entirely 2D related.
>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.
>good taste in music
Comfy. I wonder how soft/hard that wood/metal is.