Live data from Hacker News

Introducing GIFV

imgur.com

191–200 of 205 posts

Re: Introducing GIFV

#191
post #116

Earlier quoted context omitted.

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 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'…

Yes, and the same goes for .jar extensions.

Re: Introducing GIFV

#192
post #171
post #100

Earlier quoted context omitted.

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.

Re: Introducing GIFV

#193

Earlier quoted context omitted.

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.

Re: Introducing GIFV

#194
post #81

Earlier quoted context omitted.

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.

Re: Introducing GIFV

#196
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.

Re: Introducing GIFV

#197
post #69

Earlier quoted context omitted.

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?

How dare you.

Re: Introducing GIFV

#198

Earlier quoted context omitted.

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.

Re: Introducing GIFV

#199
post #74
post #10

Earlier quoted context omitted.

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).

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.

Re: Introducing GIFV

#200

Earlier quoted context omitted.

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? => => =>

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.

Post reply on HN