Hacker News Reader

Comment by xpaulbettsx | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

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?

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.

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

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.

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.

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

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.

Not as hard as 100 auto-playing gifs will

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.

Reply on news.ycombinator.com