Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing GIFV

imgur.com

Post reply on HN
Print view View original

181–190 of 205 posts

Re: Introducing GIFV

#181

Post by simoncion »

Terretta wrote: post #163
Supermighty wrote: post #82

Earlier quoted context omitted.

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

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.

Re: Introducing GIFV

#182

Post by cheald »

jonny_eh wrote: post #154
eamsen wrote: 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'…

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

Re: Introducing GIFV

#183

Post by jonny_eh »

cheald wrote: post #182
jonny_eh wrote: post #154

Earlier quoted context omitted.

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

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

> Extensions mean jack-all

…to browsers.

Re: Introducing GIFV

#184

Post by cheald »

jonny_eh wrote: post #183
cheald wrote: post #182

Earlier quoted context omitted.

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

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

Re: Introducing GIFV

#185

Post by derefr »

revscat wrote: post #113
bhouston wrote: post #102

Earlier quoted context omitted.

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

Re: Introducing GIFV

#186

Post by derefr »

Pxtl wrote: post #120
wlesieutre wrote: post #58

Earlier quoted context omitted.

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

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.

Re: Introducing GIFV

#187

Post by Arnavion »

simoncion wrote: post #181
Terretta wrote: post #163

Earlier quoted context omitted.

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

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

Re: Introducing GIFV

#188

Post by JamesSwift »

darkstar999 wrote: post #166
gcb0 wrote: 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.

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

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

Re: Introducing GIFV

#189

Post by thristian »

astrodust wrote: post #111
sauere wrote: post #8

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

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.

Post reply on HN