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