Introducing GIFV | Hacker News Reader

Introducing GIFV

imgur.com

332 pointscrabasa199 comments

"With all these improvements, Imgur will now denote converted MP4s with a .gifv extension. The intention is to signal to users throughout the Internet that these links will feature a GIF experience that incorporates all the current and future enhancements made through Project GIFV. Imgur plans to submit an accompanying specification to relevant standards organizations before the end of the year."

This is bizarre. GIFV isn't a new file format. It is just an alias for an existing format. The only reason the letters "GIF" are in this new file extension is to signal that the file was converted from a GIF, but who cares, apart from the so-called cultural connotations?

I mean, does anybody care to have a BMPJ (a JPEG file that was converted from a BMP) or a WAV3 (an MP3 that was converted from a WAV)? Or a .GIFMP4GIFMP4GIFMP4 file, which was converted back and forth a few times?

Browsers should display GIFVs without transport controls (unlike <video>), and ignore any audio tracks that are included - basically construct a limited MP4 profile and handle it appropriately. It's a useful construct imho.

We don't need to tie this behavior to a new video extension or a specific video format. A more sensible approach would be to allow video sources in <img> and restrict their profile to GIF-like behavior.

See https://bugzilla.mozilla.org/show_bug.cgi?id=895131

The extension doesn't necessarily have to just say what the file is, but it can also say how it should be used. This is done with the .apk extension. apks are zip files, the but apk extension says it should be loaded as an application in Android.

It also isn't only useful for computers. It helps people to know what they're getting into when they open a file.

An mp4 with a gifv extension makes sense to me. It says "I'll be loaded without audio and will play in a loop".

Extensions in HTTP mean jack-all. Content-types/MIME types are what actually tell you how the file should be treated.

Imgur is serving text/html in their ".gifv" files. If you tried to load a gifv in a <video> tag it would crash and burn on you because...it's serving you an HTML document with a text/html MIME type.

Imgur will happily serve you GIFs and JPEGs with incorrect extensions - for example, if you get this image with a .gif extension, it's going to serve you a JPEG, and it's going to be decoded by libjpeg. The extension doesn't provide any useful information to the client about what to do with the data.

    $ wget http://i.imgur.com/hDYj7E7.gif
    --2014-10-09 14:00:53--  http://i.imgur.com/hDYj7E7.gif
    Resolving i.imgur.com (i.imgur.com)... 23.235.47.193
    Connecting to i.imgur.com (i.imgur.com)|23.235.47.193|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 158352 (155K) [image/jpeg]
    Saving to: ‘hDYj7E7.gif’

    2014-10-09 14:00:53 (865 KB/s) - ‘hDYj7E7.gif’ saved [158352/158352]

    $ identify hDYj7E7.gif
    hDYj7E7.gif JPEG 577x1024 577x1024+0+0 8-bit DirectClass 158KB 0.000u 0:00.030

> Extensions mean jack-all

…to browsers.

You're right. I edited my post to clarify with "in HTTP". Though I'll argue that it's not really relevant in this context of this particular subject, since ".gifv" only makes sense in a browser/HTTP context. Everywhere else it's just HTML.

Yes, and the same goes for .jar extensions.

I think at some point, we do.

People like this format. GIF, gyfcat, Vine, and now this. Instagram and WebM on 4chan also have things keyed to this behavior. But the thing that GIF has on all of them is that it works everywhere. It plays in a browser, in an email, on the desktop, in an MMS message, etc..

We need a full stop replacement for the GIF that uses a modern encoder.

> We need a full stop replacement for the GIF that uses a modern encoder.

Keeping in mind that one of the big advantages of GIF is NO AUDIO.

It's just deeply anti-social to play audio in some contexts, and a file format which enforces that is a very good thing.

I agree completely, though I'd add that it's also unpleasant. There's a reason some browser and browser extensions try to help track down which tabs are producing audio.

Perhaps GIFV or equivalent should be defined as either requiring the browser not to play audio or as making audio optional, but required to default to off at start of play. The latter would require a minimal transport control, but I could live with a transparent mouseover-only volume button. There's no technical reason that a GIF successor must include or play audio. For that matter it would make a greasemonkey script or perhaps extension that forced sound off for regular mp4 much easier to write in this case.

We have a format for something like that — WebP. As a bonus, it's less processor-intensive, which makes it suited for things like tiling backgrounds, or embedding many of them on a page — a huge problem for MP4s that anyone who's enabled the on their services has no doubt already discovered.

But MP4s will play using low power on virtually every touch device today. That is a huge advantage.

Hardware decoding makes MP4 decoding lower power than decoding on the CPU. That does not make it "low power" in general, compared to simpler formats.

Indeed. I'm disappointed that the new generation of codecs (h264/webM) has won out for small internet videos because they seem to be processing-power beasts.

Full-screen mpeg-2 (DVDs) was doable with a $40 device over a decade ago. Video compression is definitely a worse-is-better space.

The heavier use of CPU allows the files to be smaller while retaining quality (or vice-versa).

As all current platforms, including mobile because of dedicated hardware, have absolutely no problem with playing H.264 video while bandwidth is still a scarce resource I think it is logical and wise that H.264 won over MPEG-2 or other older codecs.

Don't forget that larger file size also might mean more power consumption (storage and radio need to be active longer) even if less CPU is consumed.

Why not just have an attribute or two in <video> tag that sets it to be no volume and whether there should be transport controls? That sounds more useful to me and applicable across all video formats.

If you take a look at the source of the .gifv link from their blog posting it looks like this is exactly what they are doing:

    <video height="370" width="660" autoplay="" loop="" muted=""><source type="video/mp4" src="http://i.imgur.com/zvATqgs.mp4"></video>

If you open up zvATqgs.mp4 you are redirected to a .gifv file, which is an HTML document. It has a video tag that mutes the audio.

edit: This is interesting, though:

    ~/temp curl -I http://i.imgur.com/zvATqgs.mp4
    HTTP/1.1 200 OK
    Last-Modified: Fri, 26 Sep 2014 20:44:27 GMT 
    ETag: "2342c1e692a327e61be8395bf4d9109c"
    Content-Type: video/mp4

Browsers, however, are redirected to the .gifv link, while curl gets the raw mp4 file. Interesting. I was expecting a 30x response code.

Further edit: Passing a user agent to curl also causes the raw mp4 file to be returned, with no redirection. Anyone know how they are doing this redirection for browsers but not for curl?

I managed to get a 302 response code in curl by passing both a Firefox user-agent and an accept header.

Neither the accept header alone nor the user-agent alone are sufficient. It seems they are testing for both.

  curl -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -A "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0" -I http://i.imgur.com/zvATqgs.mp4

They need to get the raw MP4 file eventually so the browser can display it, it can not always redirect.

I understand that, I'm just curious as to the mechanism that they are using.

I'm not sure, and the server response from your sample certainly does not fit with this idea, but maybe it's because curl uses http/1.0?

Or is that wget that uses 1.0... Fire up wireshark ;)

Edit:

So it was the useragent and accept header that did it. Nevermind my stupid idea.

I think it's the same thing that sometimes redirects hotlinked .jpgs to a gallery representation of themselves: for anything that looks like a web browser, it checks whether the referrer is the embedding page, and if not, redirects to the embedding page.

You can't put element tags on a imgur.com/rickroll.mp4 raw file link.

An important feature of gifs is that you know they will not make noise. Videos however like to blare obnoxious music and yell at you to grab your attention.

If it somehow became a browser convention that .gifv videos will not play sound by default, then users would be much less anxious about clicking and sharing .gifv links compared to .mp4 links.

As a user, before I click a link to a file with a .gifv extension, I know in advance that there won't be any audio. I like that.

Ah, that actually makes some sense, as far as a file format specification. So GIFV would offer a subset of the functionality of a typical video file format (most notably, absence of sound). Although I would think it would make more sense to just strip out the audio, rather than instruct browsers to ignore any audio tracks.

> I would think it would make more sense to just strip out the audio, rather than instruct browsers to ignore any audio tracks.

On the server's side, yes, that would make more sense. However, the fact is that the MP4 format supports audio, and it will always be possible for a server to supply a webpage with a GIFV item that points to an MP4 file that contains audio. What should the browser do in that case? Playing the audio is probably not desired. Refusing to display the video, or displaying "Warning: this video file contains audio and isn't a valid GIFV file", would probably just confuse or irritate the user--it's probably not their responsibility to fix the server's website. The remaining option seems to be that the browser ignores the audio track, and I'd say this is the necessary conclusion.

(Cf. how browsers deal with HTML that's missing a bunch of end tags.)

One would assume the implementation does that too, for file size anyway, but it might be nice to tell the viewer that there is no need to show the controls.

Except GIFV isn't a file format then, it's a presentation profile.

GIF, MP4, JPG - these are all formats. Trying to call "GIFV" a format is just marketing fluff.

So this is actually making mp4 worse? Talk about innovation.

There are a lot of uses for dumb, audio-free video files. Web forums, for instance. You can allow users to embed them without worrying about 100 different auto-playing videos with sound on your page.

Plenty of ways to implement that and I'm not sure this is the best approach, but it's not just "worse video". More features is worse, not better, a lot of the time. Like when people used to build entire websites in Flash before the iPhone's lack of flash player finally made them stop.

>entire websites in Flash before the iPhone's lack of flash player finally made them stop

I have a setting flipped in Chrome such that I have to click to enable each plugin on a page. This made me realize that the iPhone sadly didn't stop all such website builders (rare as it is to encounter one now.)

I feel especially bad for local restaurants that have sites built all in Flash. When I look up who designed their website, it's proudly hosted on the only local dial-up ISP left in town, designed by a "company" which is really just a high schooler who took a digital media class once.

I know there is no way that site is being redone, and they're now completely at the mercy of Yelp.

100 auto-playing videos will still bring your computer to a screaming halt.

Only if they're all visible at once. Unlike GIF, which has to do CPU-bound stuff to compute its next frames even if it isn't visible in order to stay synchronized, videos that are scrolled off the screen take effectively zero resources. (Well, they'd take resources to play audio if there were an audio track, but not when they're muted like GIFVs are.) You could have e.g. a Tumblr dashboard loaded with hundreds of screens worth of an infinite scroll of GIFV-containing posts, and your computer would only be worried about the one on the screen at the moment.

Good point, hadn't thought of that. If I'm recalling the differences correctly, GIF will let you layer new frames with transparency directly over old frames basically forever, while video formats have full keyframes at regular intervals that allow you to jump to anywhere in the video by only calculating the chunk since the previous keyframe?

I haven't made any gifs since flashing "Under Construction" signs were a thing on web pages, so it's been a while. Maybe I should put some up on tilde.club.

Not as hard as 100 auto-playing gifs will

This is a marketing endeavor that is pretending to be a technical innovation.

Yep. Plus gfycat.com does that since a while now, but imgur comes as "oh look we're so innovative".

" Imgur plans to submit an accompanying specification to relevant standards organizations"

Hi we put a .gifv extension to mp4 can we HTML5 standard this non standard file extension of a standard format?!

Riite.

Twitter also followed the gfycat lead before imgur: http://blog.embed.ly/post/89265229166/what-twitter-isnt-tell...

Glad imgur is doing it though, so annoying to have to wait for gifs in 2014 and they are intense bandwidth hogs.

even 4chan does that.

whish tumblr implements it with standards and do a huge campaign calling imgur BS

No, probably not anyone who is reading hackernews, but imgur has a much wider audience.

GIFV will help communicate 2 things: 1) this file is audio free 2)this file is safe (people don't generally worry about getting a virus from a gif).

Actually, exploiting bugs in image parsers has been a classic vector. Certainly tiff, jpeg and BMP to my memory. When i worked at symbian we had an svg parser vulnerability that went underreported.

And given the slew of bugs Google keep finding fixing in libraries like ffmpeg, there are likely lots of bugs lurking in something as complex as an MP4 player...

Yup, most video code has serious bug smell.

Do they from an mp4?

If we're lucky, this also means people like Apple won't autoplay the stuff, so we actually download less data on page load.

What stops you delivering any old mp4 as a gifv?

> but who cares, apart from the so-called cultural connotations?

This whole thing is about preserving the GIF culture. So, people do care.

Besides, browsers will probably start treating GIFVs differently if this catches on and becomes a standard.

That was the first question I had after I read the article. What's the need of calling it 'gifv' when it's really mp4? Does imgur want to take credit for creating a new format when it really hasn't? Conversions happen all the time behind the scenes.

"but who cares, apart from the so-called cultural connotations?"

About 8 billion people, culture is everything to people compared to file format specifications.

Acts like a GIF, talks like a GIFs, it's a GIF(V)!

Am I misunderstanding something here? I don't see anything other than an .mp4 video served via a <video> tag from a URL that ends in .gifv. I was interested in seeing how it worked to look into supporting it for a mime type detection library I've written.

The blog post mentions submitting a specification to the relevant standards organization. Are they planning on creating a new mp4 ftyp and registering a mimetype with IANA?

Yes, why are they calling mp4 files gifv files? Is it somehow cooler?

Can I start serving .html files as .awesome files? And .js as .kicka$$ files? and .mp3 as .boomin'?

GET "index.awesome"

at this rate, why not re-write all of html so it's cooler? <body> => <b0d> <title> => <1nduk+10n>

Can I start serving .html files as .awesome files?

Sure, go ahead. Extensions in a URL have little to do with the actual type of content, and .html has long been abandoned by dynamic systems, who originally went to extensions being an implementation detail, and on many current systems being a lie (e.g. the .aspx extension that actually runs a PHP page that returns an HTML5 file).

They're using a URL extension to signal to their system what to do with the file, which in the case of GIFV is to wrap an MP4 video in a simple HTML5 container. Eh.

I can't upvote you enough. Too few people realize that the server returned mimetype actually tells the browser how to handle the content.

Oh how I wish that were true.

It's what's intended, but it's not what's true. Usually this bites on video, but it even bites on, say, SVG:

http://stackoverflow.com/questions/10261460/internet-explore...

Ostensibly, this is to protect users. Quoting TechNet:

When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:

1. File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension.

2. Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type.

3. Content-Disposition from the HTTP header.

4. Results of the MIME sniff.

-- http://technet.microsoft.com/en-us/library/cc787872(v=ws.10)...

If IE chooses to use file extension over MIME type, then it is broken and should be ignored.

Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.

It's not just IE that plays loose like this. Chrome will ignore even the Content-Type header if it can see the content is an audio or video file. For example, upload a .wav to puush and open it in FF and Chrome. FF will show a dump of the bytes interpreted as text because the server sent it with Content-Type: text/plain. Chrome will show an <audio> element.

You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.

I could see them recommend that “GIFV” be standardized as video/gifv+mp4 (and it wouldn’t need standardization if it provided it as video/vnd.imgur.gifv+mp4), which would provide the necessary signals in a fairly standards-compliant way, as well as a clear indication that mp4 is the fallback.

I believe that vnd. mimetypes do need to be registered. If you don't want to register, I think it would be video/x-gifv+mp4. http://tools.ietf.org/html/rfc2045#page-13

I made this new thing called xjson.

You upload JSON, and give you a URL that points to the same thing, except formatted as XML.

xjson!

Yeah so? If it was an actual need and solved an actual problem it would be ok.

People could not care less if it's a actually a new format or hijacks an existing one.

It does sound like they are angling for a mime type. That way the server can detect if it accepts the mime type and return a html wrapped video player if it doesnt, and the mp4 file raw if it does.

because lame marketing.

the imgurl community is always asking for more servers and bandwidth, and the imgurl team is only delivering crappy feature on top of crappy feature that only makes things worse.

their goal is not pleased users, its a big fat huge "exit". thats why new feature and buzzwords abound. it impresses investors, which is their goal.

> the imgurl community is always asking for more servers and bandwidth

They serve 2 billion images per day, and they never delete pictures that are still actively accessible from the internet. At no cost to the user.

In any case, cache is golden, and a 5 MB gifs off of their front page could be a 500kb MP4. That difference adds up superfast it's off of their front page and has 30M views.

you are replying to my comment out of context.

the post i just answered to asked what is so special about gifv if all they are doing is a video tag.

also, similar arguments where done when adding lazy loading etc... with the idea that "loading images progressively is better" etc... it all backfires in the end when done by those guys. now the user actually PERCEIVES the slow loading. before, images would take a long time, but if you waited you could see the whole album. now, thanks to lazy loading done bad, they will load AS YOU SCROLL... you get to witness all the wait! it is hell.

i-m-g-u-r pronounced "imager"

Interesting. I've always pronounced it im-gir (im as in nim, gir as in girl)

I do too honestly. But I thought I'd point out the "official" pronunciation and spelling.

heh. i always pronounced img-url... because that is what i thought the domain was :)

well, not like i would ever typed to reach it on purpose anyway. it is just reddit's image anyway.

The "convert-GIF-to-MP4" technique is the same technique that Twitter [1] and Imgur-competitior Giphy [2] uses.

[1] http://blog.embed.ly/post/89265229166/what-twitter-isnt-tell...

[2] http://www.reddit.com/r/IAmA/comments/2g0791/hey_reddit_were...

I would say that Gfycat and Mediacru.sh are actually the leading competitors in this area.

Is Mediacru.sh banned from Reddit? I just saw a thread the other day where someone said the domain was blocked by admins to prevent it from competing with their preferred service (probably Gfycat).

mediacru.sh admin here. We used to be banned, many months ago. I was talking about our past troubles in that thread.

an animated gif is not necessarily a video clip, but it seems that i'm in the minority these days.

here's a gif by nicolas sassoon, which format would you prefer?

http://i.imgur.com/fv0qgkc.gif (1.3 MB)

http://i.imgur.com/fv0qgkc.gifv (3.9 MB)

another user brought up a good point in the comments section of the imgur post:

>GIFs being lossless, editable and universally supported are a pretty big part of what spawned this “culture of the GIF”.

Sure, video editing tools exist, but I think most people would agree that GIFs are more "remix-able" than MP4s. It's important that we preserve both formats. (Or perhaps it's time for a modern lossless animation format?)

I think the point is having a proper display option. Most photographers shoot and edit in RAW, but the final product is almost always displayed as a jpg. I don't think this is meant to eliminate gif entirely, just limit it to the areas it belongs, like editing as you pointed out. The only issue I see is that there needs to be an easy option to download the original pre-converted file.

But GIF is a terrible intermediate format. It's only 'lossless' in the sense that there's no advanced compression going on. But since it can only produce 256 colors gifs tend to be extremely lossy for video-like formats, often producing awful color banding.

Sure, if you're doing things with a very small color palette like pixel art or software tutorials then the current gif is fine for your needs, but gifs are increasingly used for video which typically has a huge color range in each frame, and we need something different for these cases.

>Or perhaps it's time for a modern lossless animation format?

APNG? https://upload.wikimedia.org/wikipedia/commons/1/14/Animated...

Wow, the colors are just gutted in the mp4 version.

Yeap, YV12 colourspace doesn't really like sharp pixel-perfect colours.

h.264 streams support 4:4:4 via through the Hi444PP, but I think hardware decoder support for that is non-existent.

Right, this brings up another point: what H.264 profiles are allowed for gifv? I can't find an answer.

The name they propose is "GIF video", though. If it's not video, then you can use GIF instead. Nobody is taking GIF away from you.

Simple solution: Don't use gifv for all gifs! For a lot of gifs this will massively reduce loading times.

Gif on the right is bigger, slower, and loses a lot of color information. Really surprised to be honest.

gif2apng result: http://i.imgur.com/FiSXtwg.png (654 KB)

I think this actually in response to Gyfcat, who have been doing this exact same thing for a while, and eating up quite a lot of imgur's redditshare: https://gfycat.com/

gfycat does "the right thing", they use the free and open webm format.

Can't we just all settle for .webm?

The cancerous patented MP4/H264 combination must die.

WebM is a format nobody asked for and nobody wants.

It's claimed that WebM is patent free, but this is impossible. There's just too many patents in the video space, any one of which could surface and tank this format.

Remember GIF itself was, for a while, subject to patent problems.

At least with H264 companies like Cisco are releasing implementations with indemnity from that (http://www.openh264.org/) which I think is better than coming up with some wonky new format.

As far as I understand it, although there are many patents in the video space, they are not evenly distributed across all possible approaches and algorithms. Instead, when the next MPEG/ITC standard begins to crystalize, a bazillion companies rush to file patents on some specific, small part of the format so they can join MPEG-LA and get a passive revenue stream.

In particular, if you design a video compression format that deliberately avoids doing what MPEG4 or H.264 does, your odds of patent infringement go down drastically.

Unfortunately .webm doesn't work in IE, OSX Safari or iOS.

Though I'd far prefer these services work with both WebM and H264, and use whichever works best.

I wonder how many (huge) sites like imgur it would take saying "we're doing webm, if your browser doesn't support it you get a huge, slow GIF instead" for everyone just to settle on a single format?

The whole debate is only hurting users and developers, while lining the pockets of MPEGLA (or whoever is responsible for h264 licensing).

>I wonder how many (huge) sites like imgur it would take saying "we're doing webm, if your browser doesn't support it you get a huge, slow GIF instead" for everyone just to settle on a single format?

It's very unlikely to see that happen, since using H.264 doesn't cost a dime in royalties for sites like imgur that serve the content for free (ads don't count as per the H.264 licensing terms). The only trouble is really on Firefox and any other browser that wants to implement a built-in H.264 decoder, but nothing stops them from working around that via things like OpenH264 or by using system decoders and so on.

The same will likely happen with H.265/HEVC, as the recently published licensing terms made it completely royalty-free to use the format itself (including for commercial purposes, you have to pay royalties for that with H.264), and you only have to pay to distribute decoders & encoders.

Personally I wish browser vendors would just use whatever's installed on the user system for playing web videos, but for some reason that's not okay because "we need at least one unified always playing format for the web!" and then we don't get that anyway, as the whole WebM mess has clearly shown...

Anyway, since imgur is doing the conversion to video by themselves, there's not really any reason why they couldn't do both H.264 MP4s and VP8 WebMs... supporting only one format makes more sense if you allow direct user-encoded video uploads like 4chan does with its WebM support for example. Gotta say I don't like this whole "hey we took HTML5 video with 'autoplay loop muted' properties and branded it GIFV!" shtick, though.

How many? A lot. And in the mean time, if imgur started to do that, then it will soon start to have a "pdf link warning" in short order as masses of ios/safari/ie users basically segment themselves out of the loop.

In the meantime then the alternative sites will pick up in use because they aren't being dicks about a video format.

Additionally, what about devices that only have mpeg decoding? Basically you're saying screw you non webm supporting people and your battery life. We don't like your kind around here.

Its a great way to kill your site in short. Unless everyone does it at once and upgrades happen to support things, its at best a slow burn like firefox. But at this point webm doesn't have half the use cases as firefox did.

How well did that work for flash when apple decided it wasn't going to put it on mobile.

Quite well, I'd say. Most of the big sites have a flash-free version now, if only when you're visiting from an iOS device.

It might be a fun exercise to guess how many big sites it would take, but it's more relevant to realize that there is very little reason for any big site to deliberately not support a huge number of potential visitors.

Pretty much everything has hardware to decode h264; webm hardware decoding is still thin on the ground. Bulk encoding h264 is also typically cheaper than webm; the software encoders are faster, and hardware assists are available.

Can't we settle for .png?

The cancerous patented gif/lzw combination must die.

Why on earth would you use WebM? WebP is actually an image format and is based on the VP8 codec.

Because WebP is aimed to replace PNG, WebM can replace both MP4 and animated GIF.

Is .webm hardware-accelerated?

It is on my phone.

http://wiki.webmproject.org/hardware/devices

WebMs are truly impressive. Too bad the adoption rate is quite low.

Can't we just all settle for .webm?

This debate is partly why the web is overrun with enormous animated GIFs.

It seems pretty clear that webm isn't going to be widely supported. Time to move on.

Move on to what? The annihilation of firefox through a cheap licensing move?

Deleted comment

Firefox/OS X uses codecs from Apple

How dare you.

Firefox supports MP4, and they changed their position two years ago when Google and Adobe weren't as all in as they claimed to be. Further through an appropriate media plugins that browser should support anything the platform supports, and it was pure dogma that had it refuse early on.

Apple is never going to support WebM. This kills the format. There are hundreds of millions of devices that can hardware decode MPEG4 than can't for WebM. Nay, billions of devices. Of course WebM is always just around the corner, but this has just led to a stagnation where the scourge of animated GIFs reigned supreme.

well mp5 is right around the corner as well. Out of curiosity, what do you think the world is going to do when it's confronted with the choice between pushing out open source competitors or letting them in?

No. Just no. These are muted videos, not GIFs.

GIFs have an 8-bit palette. They're lossless. They are meant to be short and sweet, because they take up a lot of bits.

They're also easy to manipulate, easy to encode/decode (I have a single .java file which generates animated GIFs) and unequivocally patent-free.

Let us stand up against this subversion of the pure GIF format. [success_kid.gif]

Anyone try to browse images on Imgur on iOS lately? I have. It's a huge pain because M4V videos take over the entire screen when they open. This looks great on a desktop browser where the videos play right on the page, but on iOS the experience is markedly worse than before. The videos load faster, but having to tap play, watching it loop, then tapping on the video again to bring up the header/footer, then tapping Done to stop the video... How is that better than just tapping Play?

Now, I understand that this is an issue with iOS and not with Imgur, but honestly, GIFV is not a great improvement, technologically or otherwise.

Also, note that most GIF's on Imgur end up there as screen caps of various web videos. In other words the process is now M4V -> GIF -> M4V. Instead, Imgur could just build tools for better short video creation that they could then host.

I don't know if its just me, but the GIFVs embedded on the page dont load for me, unless I click on them to open them in a page on their own, and the second one doesn't play even in this case.

Firefox 32.0.3 on Linux

That's probably because Firefox on OS X (32.0.3) doesn't yet handle H.264, which is what these GIFV files really are.

FF on Windows (32.0.2) does support H.264, and the GIFV files play as expected. IIRC, FF on Android was the first version to get H.264 support, which it's had for some time now.

EDIT: You can check codec support for your current browser+platform at YouTube's HTML5 page, below. I briefly dug around in Bugzilla for this issue, but haven't found it yet.

https://www.youtube.com/html5

You're right, the page you linked shows that my browser doesn't have support for H.264... though then I'm confused as to why the first GIFV loads for me when I open it on a separate page...

They work for me, Firefox 32.0.3 on Arch Linux. You'll likely need some gstreamer packages installed (I think the package on Arch is gst-plugins-good for h264), same as for watching YouTube videos in HTML5 mode rather than Flash.

There's also an about:config option "media.gstreamer.enabled" which needs to be set to true, but I don't remember ever having to set this myself.

I'm also on Arch. I had to install the 'gst-libav' package (possibly in adition to the gst-plugins-good?) for it to work. Thanks.

It is asking for adobe flash on linux

It uses flash as a fallback if your browser doesn't support mp4 video.

works for me, chrome / windows

I'm getting the same behavior in Chromium 38.0.2125.101 (build 290379) on OSX 10.9.4.

GIFs just work. GIFVs might or might not work. That's a huge difference.

Exactly the same for me - Firefox 32.0.3 on MacOS.

Same. FireFox 32.0.3 OS X

I'm a little disappointed that they've not only created an absurd new file extension, but that they're settling on patent-encumbered H.264 video compression.

I think bhuston said it best.

>This is a marketing endeavor that is pretending to be a technical innovation.

Most of us are asking, why isn't it format X, or format Y. When they are clearly superior in quality and compression. The answer is they don't have marketing power.

GIFV is directed at increasing attention to imgur. By trying to make more sites adopt it as their image/video hosting platform. Since imgur already has the size/market dominance to spread the GIFV platform. Increasing its chance of adoption.

Rise above, support webm. Better compression, better quality, more wide spread.

>Better compression, better quality

this isn't true

The reason Imgur is doing what they're doing makes sense (downloading animated GIFs is an absurd waste of bandwidth when people just want to see really short low-quality videos in their browsers).

The way they're going about it and the way they're marketing the decision is arguably kinda silly. But the monocle-popping that is occurring in this thread is an order of magnitude sillier than anything Imgur is doing.

This is really not worthy of the volume or intensity of the hand-wringing that is occurring in this thread. This is the type of news that you either ignore completely, or skim, nod, and move on. At worst it deserves some exaggerated eye rolling or a sarcastic joke to a cow-orker during lunch.

I cannot right click and save an MP4 video in my browser.

I cannot drag and drop it into an email.

As a regular end user, I can use approved sharing features only. As a developer, yeah, I can download it myself and rehost it somewhere that hopefully supports MP4 video.

The historical pissing match over how to best do animated PNG files is sad. An animated image format that is treated differently from videos is a nice thing to have.

People have entire folders full of appropriate reaction GIFs. With how MP4 video is treated online today, such a thing is not possble.

right click -> save works in chrome canary, 39.0.2163.3 at least.

drag and drop does not, yet, but perhaps with this initiative it will be prioritized.

Dragging&dropping the video from that page into an email (Gmail) on another tab worked as expected. Don't know if Gmail is doing something special though.

I tried this on a desktop Firefox/Ubuntu. I'm actually quite surprised that it worked without any problems, considering the rough history of MP4 on Linux/OSS in general :D

Why a new extension?

Doesn't mp4 have enough extensions? .aac, .mp4, .m4a, .m4b, .mp4v, .m4p, .m4v, .mpeg4 so far.

And now .gifv? I don't get it.

A new extension everyone can use... https://xkcd.com/927/

To all of you here asking 'why not webm?' consider this -- gfycat serves both webm and h264, I'm pretty sure imgur will add that in future, so no big deal. As for support, most of you are sitting on Chrome already, so you won't have any troubles playing h264.

Cheers.

the good ol SF engineer bubble.

it must be nice to live such a sheltered life.

hint: if you only care about chrome users on every feature, and keep looking at you site access log to justify, you may find that there is a reason why your access log mostly have chrome user in the first place...

I'm not sure what you're getting at. What video codec would you pick, and what does it have to do with the SF bubble?

P.s. It is nice to live a sheltered life.

Beyond the webp/m debate that I'm sure will take place here adequately without my input:

I think one of the bigger concerns these days with "short video clips on the web" - which is what we're all trying to solve with whatever technology - is workflow. People finally understand how to make gifs even if they're super low quality, or super large, then these poorly compressed "images" are being converted into various other things. If the tools were there to create audio-less MP4 / webp/m, that would help a lot.

Is this what gfycat does?

That site actually uses the superior VP8 compression format in a WebM container.

Except for being free, WebM was not a "superior compression format" to H264 last I heard. Has it changed recently?

I think it all but caught up lately in VP8 vs h.264 performance. Google kept improving VP8 performance. However, webm has also added VP9 support recently, which is clearly superior.

This is not true. My work, written three years ago, showed that VP8 was inferior to H.264[1] at the time. A more recent paper showed that both VP8 and VP9 are inferior to both H.264 and HEVC[2].

[1]: http://blog.seancassidy.me/h264-and-vp8-compared.html

[2]: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X26...

Is VP9 in much use (compared to VP8)? I've definitely heard good things about it, but I have no idea how well supported it is or whether anybody has it in use yet.

Oh does my iPhone have a VP9 chip in it?

Not so superior...

Superior in what sense? Not quality or file size.

Well, it's patents are free to licence and with open source code, so it's superior in a way that for many (me included) believe trump the others.

Webm is superior to gif in terms of quality AND file size. (Other video formats, not so much).

Superior to GIF.

Pedantry: WebM is not a compression format. It is a container format. At the moment it appears to support VP8 video, VP9 video, Vorbis audio, and Opus audio; there is no single form of compression that WebM implies.

the link is down for me (it says page not found), here is the cached version from google http://webcache.googleusercontent.com/search?q=cache%3Aimgur...

The marketing here is a little disingenuous ("Imgur is reimagining the looping GIF video"), and a good number of Imgur users (those that have also used Gfycat, the intersection of which I presume are relatively dedicated users) will know it. Not a great move.

Oh thank god. Finally.

I've been hoping they'd do this for a while. I hate browsing Reddit and finding a link to a little 'video' that then takes minutes to download fully and still looks terrible because it's a 15MB gif.

Why can't we just deal with video without hiding it behind "GIF"?

GIF seems to have a better UX than video for its particular use case: inline, control-free, looping, audio-free.

Video can do that. In fact, video is doing this here.

As someone who runs a website with something similar, I'm hoping that Imgur is big enough to push for some open standards around this. I want embedding video to become as commonplace as embedding GIFs.

Surprised ctrl+f 'mobile' returns only one result..

gifv is broken for mobile. I have to click play, and it runs as a video. That is not gif UX.

Why not WebM?

http://en.wikipedia.org/wiki/IPhone

I dont get the trick.Is it gif or a h264 video inside a "gif" container? looking at the source code,I see a video tag.

It's a video served with the video/mp4 content-type, using the .gifv file extension.

(Well, actually, the .gifv is just a web page that holds the <video> tags for the mp4, but...)

It's an h264 video, they serve it with the .gifv extension but that's just marketing.

It's standard h.264 in mp4, GIF is only there because… marketing?

Part of the reason GIFs are so popular is because of the limited colorspace. The new colorspace and compression sort of turn this into an entirely new medium not a better GIF. Other than the sometimes better filesize I don't really understand the appeal of any of this. Especially since support is far from that of GIF.

I'm surprised nobody has mentioned this yet: why is imgur allowed to use copyrighted material to promote this new feature? I'm pretty certain they didn't get permission to use those clips from Tron or Star Wars. Does the fact that they were created by a user somehow give them immunity?

I think existing copyright law allows this kind of usage. Please refer to Copyright Act of 1976, 17 U.S.C. § 107.

http://en.wikipedia.org/wiki/Fair_use

That's exactly my point -- (editing clarification) that the Copyright Act does not consider this fair use.

From the article you referenced, "A key consideration is the extent to which the use is interpreted as <transformative>, as opposed to merely <derivative>."

These are not parodies, being used for education or being used for critical analysis of the subject.

It doesn't have to be. Parody and education are the situations where you can pretty much use the entire thing... but they're not using the entire thing.

part of the balancing test is

  the amount and substantiality of the portion used in relation to the copyrighted work as a whole;

I don't think anyone can (reasonably) claim that a 10-20 second long clip (with no sound) is an any way a substantial portion of a ninety minute film.

No immunity if you know it's copyrighted material and don't immediately remove.

Came to post this too--it's funny but will surely be DMCA taken down.

because it worked for youtube

I clicked on this story hoping to find a clever alternative to the raster path for traversing images in GIF images, when used to compress video (highly correlated images). Something that preserves the spirit of GIF, but sucks less for what kids are using it online these days. Bummer.

I wrote a service in Go to transparently transcode gif to video that you might be interested in: https://github.com/leafo/gifserver

What is the innovation here? Four mistakes in spelling 'webm'?

Not hardly. This actually uses H.264, which in all regards is inferior to WebM's VP8.

All I get is:

    Specified "type" attribute of "video/mp4" is not supported. Load of media resource http://i.imgur.com/zvATqgs.mp4 failed.

Right after I finish my mp4 to gif shell script!

https://github.com/montanaflynn/vidtogif

Great, a format for small embedded animations similar to GIFs, except that they cannot be stopped using the "Toggle animated GIFs" Firefox extension.

I heard of a HTML5-based alternative some time ago called the "ugoira HTML5 zip player". It uses a ZIP file of PNG/JPG files and renders the animation using JavaScript onto a <canvas>. There's a detailed slide deck talking about it [1] and the source code is available too [2].

[1] https://marcan.st/talks/2014_pixiv_ugoku_player/

[2] https://github.com/pixiv/zip_player

imgur manages to be behind even 4chan on featureset and performance... and now its behind on standards compliance also.

Hasn't 4chan been doing this with webm for a while?

6months or a year. the owner even did a HN AMA of sorts.

Well, someone is clearly feeling challenged by gfycat, mediacrush, etc. that did this for year(s).

So this is why Imgur randomly started to output gifs with a .jpg extension.

It broke my autogfy extension. :/

...

I can't see their new format. I can't see mp4's. I'm using firefox.

This is the future? great.

It pushes a flash viewer to FF, even though I have a plugin that handles MP4.

They also won't look like shit because of the limited colour range.

I think animated webp would have been a better choice.

Why didn't they just use webm?

Can we all agree to pronounce it 'Jiffy' (gif 'V') and end the gif/gif thing forever.

now deal with responsive images/videos

whoa nice

Ugh, MP4. Terrible choice.

I propose a new format - GIFVGIF

I can tell this thread is gonna be a gold mine for Shit HN Says

Nothing new, it's been shown before by another website.

Plus what the f* with renaming a .mp4 to a .gifv ? Two extensions for the same format ?

Reply on news.ycombinator.com