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

101–110 of 205 posts

Re: Introducing GIFV

#101

Post by smeyer »

wlesieutre wrote: post #58
u124556 wrote: post #48

Earlier quoted context omitted.

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

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

Re: Introducing GIFV

#102

Post by bhouston »

revscat wrote: post #97
bhouston wrote: post #55

Earlier quoted context omitted.

Why not just have an attribute or two in 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.

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: 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: "2342c1e692a327…

They need to get the raw MP4 file eventually so the browser can display it, it can not always redirect.

Re: Introducing GIFV

#103

Post by gcb0 »

hmage wrote: post #88

To all of you here asking 'why not webm?' consider this -- gfycat serves both webm and h264, I'm pretty sure imgur will add that in future, so no big deal. As for support, most of you are sitting on Chrome already, so you won't have any troubles playing h264. Cheers.

the good ol SF engineer bubble.

it must be nice to live such a sheltered life.

hint: if you only care about chrome users on every feature, and keep looking at you site access log to justify, you may find that there is a reason why your access log mostly have chrome user in the first place...

Re: Introducing GIFV

#104

Post by gcb0 »

karl_gluck wrote: post #59

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?

because it worked for youtube

Re: Introducing GIFV

#105

Post by gcb0 »

imgur manages to be behind even 4chan on featureset and performance... and now its behind on standards compliance also.

Re: Introducing GIFV

#106

Post by Dylan16807 »

karl_gluck wrote: post #77
bbayer wrote: post #64

Earlier quoted context omitted.

I think existing copyright law allows this kind of usage. Please refer to Copyright Act of 1976, 17 U.S.C. § 107. http://en.wikipedia.org/wiki/Fair_use

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 , as opposed to merely ." 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.

Re: Introducing GIFV

#107

Post by wbond »

halostatue wrote: post #98
personZ wrote: post #67

Earlier quoted context omitted.

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

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.

I believe that vnd. mimetypes do need to be registered. If you don't want to register, I think it would be video/x-gifv+mp4. http://tools.ietf.org/html/rfc2045#page-13

Re: Introducing GIFV

#108

Post by jarnix »

Nothing new, it's been shown before by another website.

Plus what the f* with renaming a .mp4 to a .gifv ? Two extensions for the same format ?

Re: Introducing GIFV

#109

Post by EvilTrout »

Recoil42 wrote: post #95
xpaulbettsx wrote: post #43

Earlier quoted context omitted.

Browsers should display GIFVs without transport controls (unlike ), 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 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.

Re: Introducing GIFV

#110

Post by [deleted] »

Recoil42 wrote: post #95
xpaulbettsx wrote: post #43

Earlier quoted context omitted.

Browsers should display GIFVs without transport controls (unlike ), 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 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.

[deleted]
Post reply on HN