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).
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 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.
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.
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].
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.
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).
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.
>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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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?
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...
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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?
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.
204 comments
[ 4.5 ms ] story [ 113 ms ] thread[1] http://blog.embed.ly/post/89265229166/what-twitter-isnt-tell...
[2] http://www.reddit.com/r/IAmA/comments/2g0791/hey_reddit_were...
Not so superior...
[1]: http://blog.seancassidy.me/h264-and-vp8-compared.html
[2]: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X26...
The cancerous patented MP4/H264 combination must die.
Though I'd far prefer these services work with both WebM and H264, and use whichever works best.
The whole debate is only hurting users and developers, while lining the pockets of MPEGLA (or whoever is responsible for h264 licensing).
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.
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.
http://wiki.webmproject.org/hardware/devices
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.
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.
NO
The cancerous patented gif/lzw combination must die.
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.
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.
here's a gif by nicolas sassoon, which format would you prefer?
http://i.imgur.com/fv0qgkc.gif (1.3 MB)
or
http://i.imgur.com/fv0qgkc.gifv (3.9 MB)
>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?)
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.
APNG? https://upload.wikimedia.org/wikipedia/commons/1/14/Animated...
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?
Can I start serving .html files as .awesome files? And .js as .kicka$$ files? and .mp3 as .boomin'?
GET "index.awesome"
<script src='jquery.kicka$$'>
<audio src="foil.boomin'">
at this rate, why not re-write all of html so it's cooler? <body> => <b0d> <title> => <1nduk+10n>
<link rel="openid.server" href=""> => <cyb3r-jack rel=!!openid.matrix_data_cent3r" ultra_max_hyper_ref="">
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.
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)...
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.
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.
You upload JSON, and give you a URL that points to the same thing, except formatted as XML.
xjson!
People could not care less if it's a actually a new format or hijacks an existing one.
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.
well, not like i would ever typed to reach it on purpose anyway. it is just reddit's image anyway.
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.
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'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.
(Well, actually, the .gifv is just a web page that holds the <video> tags for the mp4, but...)
Firefox 32.0.3 on Linux
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
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.
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?
" 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.
whish tumblr implements it with standards and do a huge campaign calling imgur BS
Glad imgur is doing it though, so annoying to have to wait for gifs in 2014 and they are intense bandwidth hogs.
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).
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...
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.
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 know there is no way that site is being redone, and they're now completely at the mercy of Yelp.
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.
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.)
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.
edit: This is interesting, though:
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?
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.
Neither the accept header alone nor the user-agent alone are sufficient. It seems they are testing for both.
Full-screen mpeg-2 (DVDs) was doable with a $40 device over a decade ago. Video compression is definitely a worse-is-better space.
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.
See https://bugzilla.mozilla.org/show_bug.cgi?id=895131
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.
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.
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.
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".
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.
…to browsers.
GIF, MP4, JPG - these are all formats. Trying to call "GIFV" a format is just marketing fluff.
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.
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)!
Doesn't mp4 have enough extensions? .aac, .mp4, .m4a, .m4b, .mp4v, .m4p, .m4v, .mpeg4 so far.
And now .gifv? I don't get it.
>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.
this isn't true
http://en.wikipedia.org/wiki/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.