@Marker 
Eh
 
Only thing it’ll only lead to is incompatibility issues
 
And x264 is supported by pretty much everything
 
But, whatever

@Rainboom Dash 
Well, because it’ll probably leads to trouble somewhere down the line. Better fix it early on.

@Marker 
Aw, why
 
You ruin all the fun :P

@Rainboom Dash 
Yeaaaah, that’s probably definitely a bug. I’ve made a post about it in the forum thread.

@Marker  
lol wtf
 
I just took the H.264 mp4 directly from clipconverter and changed the extension to webm and it accepted it
 
>>1482878

@Rainboom Dash 
Have fun with that, I’ll be interested to know if it will get accepted by Derpibooru and 4chan.

@Marker 
I’m pretty sure I could encode it as anything I want as long as it supports the MKV container format and the site would accept it lolz
 
I’ll test it later… I’ll encode something with x265 and see if it works :P
 
Hmm.. wow… no.. that would be really bad… probably do x264 to test

@Marker  
Yeah, that’s what I said
 
It’s basically an MKV with the file name changed
 
Browser’s will look at the file name and try to play it as a webm even though it’s an MKV… and I guess it works
 
But yes, it’s probably BEST to just have it be a webm
 
 
Edit: I don’t know what the fuck I’m talking about….. but so far it seems to be okay, I mean no issues so far?
 
It plays just like a webm just in the MKV container format

@Rainboom Dash  
MKV and WebM are container formats, webm may be a subset of mkv, but that doesn’t mean you can convert one to another by just changing the file extension. This is what MediaInfo shows for your upload:
 
Technically you still uploaded the clip in MKV, just with the file name changed, and browsers and media players will still treat it as mkv. I’m not sure what sort of checks Derpibooru does that let this file through, but it may not work everywhere where they are expecting the format to be webm.
 
To properly change the container from mkv to webm, you need to remux it using something like ffmpeg:  
ffmpeg -i input.mkv -codec copy output.webm
 
Personally I recommend that you use Webm for Retards as that’s specifically tailored for webm conversion, accepts GIF input, and has basic editing features like trimming, cropping, and resizing.

@Marker  
https://handbrake.fr/
 
Technically you have to encode it as a MKV and change the file name extension to webm which S L I G H T L Y reduces compatibility… but it works :P
 
It’s what I did to upload to Derpibooru
 

 
Also there’s a slight issue with it currently (it’s believed to be a libav issue) where sometimes videos will be glitched in places.. but it rarely happens.. and you can just look at the outputted video and make sure it didn’t glitch anything (the artifacts if it did glitch should be pretty noticeable)
 
 
Oh and it won’t accept gifs
 
But that’s not really an issue for me because why would you want to turn a crappy 256-color gif into a video? :P

@Rainboom Dash  
yeah, I couldn’t find a ‘qp’ anywhere in the ffmpeg documentations. What program do you use for encoding?
 
Ok, I found it here, but it’s not available for libvpx, which is the library used for VP9 encoding.

@Marker 
Best is probably similar to veryslow
 
 
That’s horrible… only three speed settings?
 
I have veryfast, faster, fast, medium, slow, slower, veryslow

@Rainboom Dash 
VP9 has 3 speed settings, but realtime doesn’t seem to work, and best slows the encoder to a crawl, so I leave it blank and use the good default.

@Marker 
I think we’re using two different methods too
 
I’m pretty sure mine is constant quality (like qp) while you’re doing CRF…

@Marker  
As I said before, I would normally do 25-30… but the quality wasn’t great to begin with and a quality setting of ~40 didn’t cut down the quality that much more
 
Also, what quality preset are you using? I was using “slow” If you’re using “veryfast” then I’m not sure how much more that would lower the quality but it could be quite a bit
 
 
In fact… I’ll test with a quality setting of 30 with veryfast
 

 
Edit:hmm…. not really… didn’t make much of a difference at all… although there isn’t any complex motion in the video… it was just the short gif with Twilight and the ball and book
 
 
Although, again… the quality of the original was already horrible… so that could be a H U G E part of why it’s not that noticeable
 
Also for me:
 
CQ of ~40 = ~2.1mb
 
CQ of ~20 = 3.04mb
 
 
So clearly something is different
 
 
And the audio is only taking ~100-200kb

@Rainboom Dash 
Alright, I did one more with the tolerance set to 10, which is what I normally use: https://a.pomf.cat/donyzm.webm (322 KB)
 
Maybe I’m just more sensitive to compression artifacts, but I still don’t believe the size trade-off is worth it.

@Marker 
Wait what
 
 
whaaaaat…
 
qmin 38, max 42
 
wow, that’s not nearly enough difference.. no fucking wonder
 
 
When I encoded with 40 (well 39, close enough) it didn’t lose that much detail at all… of course the original had already lost a lot of detail

@Marker 
True
 
I could have done 30 or 25 or something
 
Would have only been 400-600kb more
 
I mean, 40 looks pretty good.. if you looked at my examples
 
I know it’s just a screenshot of one fucking frame… but it should tell the shit it needs to tell
 
 
Maybe yours is different because 40, or even 54 with mine is pretty decent… I wouldn’t say perfect.. but definitely good

I was actually talking about encoding in VP8/VP9. 
The tool I use, Webm for Retards, which is more or less a wrapper for ffmpeg and AviSynth, allows the user to set a CRF, as well as a ‘tolerance’ value, which basically adds and subtracts from the CRF to get -qmax and -qmin, which I assume limits the quantizer used.
 
Now let’s use this >>1475777 as source (6.66 MB). Setting the CRF to 40 and leave the tolerance to the default 2 results in the following arguments passed into ffmpeg: 
-c:v libvpx-vp9 -pix_fmt yuv420p -threads 4 -slices 2 -lag-in-frames 16 -auto-alt-ref 1 -qmin 38 -crf 40 -qmax 42 -qcomp 1 -b:v 0 
And here is the output. (243 KB) 
And here with CRF changed to 20 (1.03 MB)
 
Now let’s take a look at an album comparing a single frame taken from each 3. As you can see, setting the CRF to 40 resulted in pretty significant loss of detail, especially in the background. Setting CRF to 20 incurred a roughly 4 times increase in filesize, but ended up with much closer visual quality to the source, and is still smaller than the original GIF.
 
I guess my point is, compared to what we were originally getting with GIF, I think you can afford to encode at a higher quality without making any visual sacrifices.

@Marker 
Okay, look
 
Here’s the original from clipconverter (so it’s already been recompressed a couple of times but should be VERY close to the same quality as Youtube)
 
Versus a constant quality of 39 (what I uploaded to Derpibooru)
 
And I threw in a constant quality of 54 just to show how slow the quality degrades
 
Hmm… the original picture is 1 frame off from the others… I said go to frame 480 in MPC-HC which is what I stopped the encode at… oh well
 
https://drive.google.com/drive/folders/0B1_qfl2IS3NdVHpoR2c4emM5QkU?usp=sharing

@Marker 
You said qmin/qmax
 
Did you mean CRF?
 
Because with x264 a CRF of say… 18 with not much stuff moving at all (like a static image background with barely anything changing… like…. this video)
 
Now, it’s only 44mb because I told it not to force any I-Frames (so skipping through the video is almost impossible but cut down on a lot of useless I-Frame data) and also two audio tracks, 192kbps stereo Opus and 128kbps mono Opus… So about 13mb of the data is audio… so video data is only about 30mb… wow… and it’s in 4k and encoded with a CRF of I think 17? I can’t remember what I did
 
ANYWAY, it would make the I-Frame like 8 and the P-Frame like 10 and the B-Frames like 20
 
 
With some stuff moving but not a lot it would probably be I-Frame 11, P-Frame 14, B-Frame 23… or something like that
 
And with a lot of stuff moving it would probably be I-Frame 15, P-Frame 20, B-Frame 28
 
 
Point is, CRF changes the quality setting based on how your eye sees it… if something is moving it’s a LOT harder to see the detail (as long as you don’t look too hard :P) But if you’re just watching the video normally then it should look about the same…
 
If you do qp then that specifies the quality for the P-Frames and the I and B frames would be based on a ratio… so it would be a set quality no matter what
 

 
Um… point is… did you mean qp or CRF?

NOW, if I get the original video uncompressed and then recompress it I’d do probably about 30 (probably 18-19 with H.264)… but the video was already so degraded that it just didn’t make sense to spend an extra 500kb of data to not really gain any quality

@Marker  
H.264 is different from VP9
 
VP9 goes down in quality MUCH slower… the file size difference between 39 and about 28 was 2.15>2.55mb…. yeah…
 
 
A constant quality of 40 with VP9 is equivalent to about 20 with H.264… and the video I was encoding was already poor quality due to Youtube and clipconverter and the person that uploaded it probably exported it as a standard quality H.264 file… so it probably went H.264>VP9>H.264>VP9
 
lol….
 
Point is, the quality wasn’t great and there was no reason to go higher
 

 
Now, I technically took the mp4 from clipconverter and encoded as a MKV and changed the file name extension to WebM… which is not the smartest idea
 
Basically, now the device has to support WebM AND MKV… buuuut… every device that supports WebM should also support MKV…
 
 
Just to give you an idea: it was still like ~5000kbps with a quality setting of 40

@Background Pony #B048  
And it ended up like shit
 
@Rainboom Dash  
I find 40 way too lossy, I try to aim for 20 +- 10 qmin/qmax when encoding animations. Could maybe get away with higher if it’s IRL video.

@Background Pony #B048  
Well, it’s like 240p, MAYBE 360p quality encoded as a 1080p video… that’s.. pretty bad…
 
But um, I used VP9 with a constant quality of 39 and the “slow” preset and used 192kbps stereo Opus audio
 
A constant quality of ~40 with VP9 is like ~20 with H.264? Something like that…
 
Opus>Vorbis
 
Also VP9>VP8
 
Although VP9 might require more decoding cpu power.. probably does
 
But for basic videos like these it doesn’t really matter… with high quality video game recordings, yeah.. then it does