All webms are animations, but not all animations are webms.

I don't think it would be helpful to have 2 tags specifically for WebMs. We already have filetype:WebM, and both video and gif are also aliased. Gif is also a valid filetype, and video is ambiguous.

What Siral said, we have the metatag filetype: to allow filtering by file type. The metatag accepts all file types we allow to uploaded here, meaning you can search for webm, gif, jpg, png, and swf.

I'm actually not remembering couple things:

• Why is flash still tag?
• type:webm cannot be used for blacklisting, so people who cannot view those cannot get rid of them (one reason for forum #261460), so having it as tag would actually make bit of sense.
• We could also just have tag video, in case that new filetypes are allowed in future and to indicate that webm files are just videos.
• Why isn't .apng allowed filetype when we do have animated_png.

Well then, maybe if it's possible, file type tags should be aliased to their equivalent filetype:, if that's possible. (Similarly, if possible, filetype:gif and filetype:webm should be implicated to animated.)

Edit: Also, I didn't know about filetype: before.

is not a tag, it's a metatag, same kind of thing as date:2017-07-07 : the data is derived directly from the file and taggers cannot alter it.

Which is to say that webm neither needs to be aliased to filetype:webm, nor is it possible to do so.

IMO the correct solution would be to implement filetype: blacklisting (which would probably require a small change to the format of the items returned by /post/index/*), and then to invalidate webm

Mairo said:
I'm actually not remembering couple things:

• Why isn't .apng allowed filetype when we do have animated_png.

From what I recall KiraNoot has said, and my own knowledge of APNG:

The hackery involved in the internal structure of APNG, which can be broadly described as 'PNG file, but with multiple IDAT [image data] blocks', makes it slow to detect APNG definitively -- you can't just scan the header, you have to find certain animation-specific blocks, verify their contents actually implies an animation, and (well, this last bit may be optional) scan through the other blocks checking that there are >1 IDAT blocks.

Also, IIRC there is no canonical ordering of blocks , which means you may need to scan the whole file before you find the animation info.

This is all in the aid of 'backwards compatibility' (no APNG support? Then the application sees the file as a normal static PNG consisting of frame #0) but IMO is too clever for its own good.

With my language of choice I think I could get it fairly fast, but I don't know what KiraNoot is working with (Ruby on Rails?). I would have thought the result was cached, though...

...
It's also canonical that both '.png' and '.apng' are an acceptable extension for APNGs, so that's another way in which the spec itself fucked up. Still, e621 can probably paper over that particular problem and just insist that APNGS always get an extension of .apng .

savageorange said:

Because each section has it's size attached to it, you can skip through them fairly quickly, but it's just an additional complication to teach to the code when before it was pretty simple to skip through, find the resolution and verify that the resolution was correct, and calculate the length of the image data to verify some level of correctness. With APNG you have a series of still images, and then animation control blocks before each image. Detecting if they are APNG isn't that hard long run, it's validating them for some level of correctness that is a bunch of code to write, otherwise they look like PNG files with appended data on the end. Lots of work and testing for what amounts to some files getting an extra a at the front of their file type.

As for exposing the file type, I thought that was already being done, but now I need to go check, because it should be.