Hacker News Reader

Comment by Ezhik | Hacker News Reader

At this point, killing GIF is a UX problem, not a format problem.

I've talked about this before [0], but the big problem for me is that video is just difficult as hell. Compared to a GIF, it is just that much harder to save a video on a phone, and then upload it the same way as an image. Try to save a "GIF" from Twitter or from GIPHY - it's a /huge/ pain.

Whatever the GIF killer is will need to pass the right click test - I need to be able to just right click and save it.

[0]: https://news.ycombinator.com/item?id=14181158

View on HN

The UX for saving and sharing videos is the same as for images, including right click to save. You and I don't get that UX, though, because Twitter, Google, Facebook, Netflix, and most websites write code to fight off-site sharing and deploy it on their videos but not their images. They skip images presumably because it's easier to bypass there and because everybody knows you're user-hostile when you break image UX, whereas when you break video UX even HN users blame the browser or operating system.

So it's worse than a UX problem, it's a social problem.

Maybe as-easy-as-screenshots screen recording would go a long way toward solving it, but we've been beat to it: big tech has bent kernels, operating systems, browsers, and even most nations around the world into collaborating to refuse to take moving screenshots of video files, under the label of DRM.

So maybe the root of it all is just timing. Images were added to the web when the web was just a tool, so everybody knew what they were before big tech could set an expectations like that moving an image from memory to disk isn't a normal feature, or that wanting to is controversial, or that doing it might be illegal. Video, though, came at a time when there were big players that knew the stakes and were ready.

> including right click to save

This only works for video tags that load a single webm/mp4 file. If it's using more complex chunked/streaming/mediasource delivery mode then you can't save the whole video because it's driven by javascript that might only keep a tiny slice of it loaded at any given time and not a single downloadable file. It also auto-negotiate quality and serve you a reduced version, which is probably not what you would want if you're downloading it.

Then you need browser addons or tools like youtube-dl to get the whole thing.

> The UX for saving and sharing videos is the same as for images…

Minus drag and drop, in browsers at least.

This comment reminded me of Terry Davis, because that's exactly the kind of feature he would have deemed essential in a browser if he'd ever decided to add networking to TempleOS. RIP brother.

Videos really should be first-class entities, though.

Imagine an OS/browser-level ffmpeg implementation which would allow seamless copy/paste of videos, integrated snipping tools both for cropping and time, color adjustment, etc. with automatic imgur-style hosting of your newly edited video just a button-click away.

The dream of QuickTime back in the 90s

Yes. Just one problem I discovered recently is that no other format does looping properly.

With a GIF, you can right-click and save it, and all the looping info is inside the file. The quality is crappy, but it just works.

With all “proper” video formats, looping info is metadata, stored separately.

You can’t even go for something slightly more modern, animated PNGs, because there are warring formats and very few tools that support them.

Animated PNG support was shipped in Chromium, the last major hold out, two years ago: https://www.chromestatus.com/feature/6691520493125632

This means that once the new Chromium-based Edge ships, all major browsers will have support: https://www.caniuse.com/#feat=apng

For reference, pyAPNG works great for creating animated PNGs. If you have a sequence of static PNGs, you can assemble them with APNG.from_files() [1]. Example looping APNG (346K) [2], with alpha channel (456K) [3].

1. https://pypi.org/project/apng/ 2. https://b.thumbs.redditmedia.com/4Q-yKMEPwm2higaB8Wj1pNII60j... 3. https://a.thumbs.redditmedia.com/kSUouIZtNICOcPf4v9F8fPOrpAe...

wasn't webp supposed to have GIF like animations? As far as i know I have never seen one in the wild, just webm.

I think the problem is that GIFs are images and so displayed as such with little concept of play-control. A video format communicate that you might want to pause for example. I believe a GIF-killer will need to be considered an image as a format.

Yes, agreed. That lack of play-control is both a weakness and a strength of GIF. The strength is misunderstood and underrated by those who think videos should replace all usage of GIFs.

Play control isn't impossible for GIF. I'm using sxiv for viewing images, which is as minimal as it gets, but it does have pause, single step forward and single step backward for GIF.

Who said it was impossible?

> GIFs are images and so displayed as such with little concept of play-control

> A video format communicate that you might want to pause for example.

> I believe a GIF-killer will need to be considered an image as a format.

If we consider animated GIF to be an image, then the distinction between "image" and "video" is pretty arbitrary.

I would say the distinction isn't inherent to the format either. It's inherent to the HTML tag. There's no reason we couldn't support `<img src="foo.av1" />` or `<video src="bar.gif" />` with the appropriate UI for each.

I actually think this is a symptom of something bigger: browsers (and most other applications) shouldn't care about media formats at all; that's a low-level concern of the OS/stdlib. The Datatypes system of AmigaOS (and later BeOS) is an example of how this could be improved.

Looping is up to the video player, not the format or container. What "video formats" have looping as metadata? Gifs only have a loop flag so static images can be displayed instead of looped indefinitely as video.

GIF lets you control the loop count and playback speed. It's baked in when authored and is useful. You can simply save the file and expect it to work everywhere - dead simple.

The Internet has voted in favor of looping, "GIF-like" moving images. Platforms try to emulate this with proprietary video players. Some have sound (wanted or not), some of the video players prohibit copying, and none of the files work as simply as GIF for sharing.

We need something more modern than GIF, but that has playability baked in. Something that browsers treat as a moving image and not a video.

> You can simply save the file and expect it to work everywhere

I don't quite follow. This is because the gif is decoded and played. No different than a video. You don't need a proprietary player to loop a video, you just go back to the start of the video. For streaming, this is only problematic for large videos that can't be cached, but the same applies to large gifs. Browsers can loop video, it's just a right-click setting. HTML5 can loop video, allowing sites to serve video in e.g. a banner, replacing gifs. You can save any video file just like a gif.

> Something that browsers treat as a moving image and not a video.

The entire point of deprecating gifs is because video is superior. Gif as an image format being able to specify frame duration and looping is hardly a noteworthy feature.

Video isn't superior for sharable, loopable images.

Try downloading a video from a popular social network. Can you easily do it without inspecting the source? If it's a two second clip, does it loop on your system? Or does the video player exit / end the stream?

This is absolutely a problem that GIF doesn't have.

> You don't need a proprietary player to loop a video

> You can save any video file just like a gif.

Except social networks force you to use a locked down or DRM'd player. You can get chunks of the video sometimes. Your non-tech friends are out of luck.

> you just go back to the start of the video

"just". Yeah, how many players support that out of the box? Yours might, but there are many more that do not.

Your complaints about true video formats (vp8/vp9/x264/x265/av1 with html5 video) replacing true gifs are misplaced.

Inability to save videos/gifs isn't a format problem, it's a problem due to javascript obfuscation or DASH/HLS making it difficult because you have to find the video chunk url(s), fetch them, and if there are multiple pieces, piece the full video back together. Campaigning for a return to gif isn't going to make those sites switch back. The only sites that might switch back would be sites that already allow right-click download. They won't switch back either, though, because gifs are vastly less efficient.

Looping is a html5 video tag attribute. If a video isn't looping, it's because the site serving the video didn't add that tag attribute. Many gif-style video upload sites automatically loop videos.

Also, gifs in browsers don't support seeking which is annoying for gifs more than a few seconds long.

HTML5 video is perfectly fine, loops fine, and is easy to save if the site doesn't obfuscate it with javascript or turn it into a chunked HLS or DASH mess.

so you're saying the solution to use as a replacement is harder to use and clunkier? right, i'm sure everyone will rush to adopt it and customers won't care at all

> Try downloading a video from a popular social network.

That's the site's decision. You also cannot easily download images from Twitter if there are more than one in a tweet for example. On Instagram it is blocked all in all.

> That's the site's decision.

No it isn't. UA means user agent, not corporate agent. If the user decides to persist something that is loaded on his machine then it is his choice to make.

You were lost some where in the thread above. I totally agree but that's not what we were discussing here.

> Can you easily do it without inspecting the source?

Yes, I use Page Info (Tools menu -> Page Info) in Firefox. It lists all the media assets on the page and you can download the one you want.

The inability to right-click and save a video is less a problem with the video file itself and more a problem with how the page is structured. You can have the same right-click problem with GIFs depending on where they appear in the page structure.

... That’s far from what I would call an acceptable ux.

So make an add-on which does the same thing with whatever UX you want. It's a good project for you. I look forward to using it when you're finished.

Alternatively, use one of the media downloading add-ons which already exist.

Mass adoption doesn’t want to use addons or go in to the developer tools. That’s my point. I know how to do it but even for me it is not intuitive.

Your point doesn't address the fact that you can have the same right-click problems with GIFs as with video files. The file type doesn't matter, the page structure does.

The great mass of people don't care about saving media assets from a page. There will never be mass adoption of this, no matter how easy it is.

They do though. For example love to share memes to each other and with phone it’s as simple as pressing the image for a long time. Video formats do need the same kind of actions to compete with the ease of use of gifs.

They don't though. You're in a bubble of a minority use case.

Video formats don't need to compete with GIFs. That competition is already over. GIF files are too big to be practical at scale. Video won the file size war a long time ago, which is precisely why Twitter "GIFs" are videos.

You can't do this on mobile, though…

> Looping is up to the video player, not the format or container.

Says who? First of all, it really is debatable if animated gif even is a movie. It has no sound, is usually far shorter than the usual video clip, etc. Second, animated gifs are very often created solely for the purpose of displaying them in a short looping fashion. Third, the fact that all this can be done in a single image format makes them ideal for sharing through the web as well as private chat applications. And fifth, and this is what this is of course all about, sharing short animated gifs gives the user the possibility to share rich content not tied to any private business or entity. You can share 'em via Whatsapp, Telegram, e-mail, usb-stick, have a collection of them stored somewhere, without the need for a Facebook/Google/Amazon account and internet connectivity. You can look lovingly at them, even when your phone is in flight mode. Let's keep it that way. Let's not kill one of the nicest image formats around, and make everybody visit your website to see the embedded movie including horrid player that's supposed to be better but just isn't and never will be. Lot's of companies already did this (hi Twitter) and it's really disheartening to know that while I was able to collect a nice bunch of animated gifs over the years, my kids will probably never have that chance because the file format will just be walled off by the internet giants.

Here’s another completely different use case (I came across this while googling unsuccessfully for a way to make videos loop):

You’re setting up a booth at a convention. You want to have a video playing on a TV. It should play forever in a loop.

Apparently, with any normal “smart” TV, that’s very hard to do! You can put a video file on an SD card or something, but you probably can’t persuade the built-in video player to loop it (edit: seamlessly, anyway). You can’t just set a loop flag on the file like you can with a GIF, because proper video formats don’t have any such flag.

I guess you could set up a web page with a looping video on it? That’s more of a hassle than just putting a file on an SD card, and less reliable if the net connection is spotty.

There are companies that will literally sell you a hardware dongle just to loop videos. It’s ludicrous.

What you describe is a software limitation in the TV's video player if it doesn't have an option to loop. Right now, I can open up a video in Firefox, say a VP8 WebM, and there's a right-click option to loop it. Every noteworthy media player (VLC, MPV, etc) supports looping. Websites can tag video to loop. Likewise, you're able to loop a gif even if it doesn't have a loop flag - the loop flag doesn't need to exist, it can be external to the format be it GIF or video.

The point is that if I send you a gif, you currently don't need to tell whatever program you opened it in that it's meant to loop. When I send you a gif, I expect it to be looped on your end. It's part of the gif package that we've come to love. Of course the loop flag doesn't strictly need to exist, but if someone has to perform an extra step to do what gifs were already doing, then no one will use it as a replacement.

> What "video formats" have looping as metadata

QuickTime (MOV/MooV)

Right, in my opinion for this to work, we need an AV1 derivative that acts as a GIF:

1. Similar looping behavior 2. No audio 3. Can be put in an <img> tag

You should be able to save the file like you would a gif, and viewers should also show it as they would a gif (not a video).

Given the current direction of the industry, the most likely candidate for this in the not-so-distant future is HEIF, which has support for an image-sequence [1].

HEIF is an ISOBMFF (aka Quicktime/MP4 container)-derived container format for images, image sequences, and transformations. Its most visible use right now is Apple Live Photos, but various use-cases exist [2]. OS and application support is increasing.

Work is ongoing on defining AV1-encoded frames as a payload in HEIF [3].

[1] https://nokiatech.github.io/heif/technical.html [2] https://nokiatech.github.io/heif/examples.html [2] https://aomediacodec.github.io/av1-avif/#av1-image-sequence

Which, exactly like GIF in its very beginning, is encumbered by an infinite amount of patents. You can't replace an open format with a patented one; killing video patents is the very reason AV1 exists.

Instead of HEIF one could use AVIF which is patent-unencumbered: https://aomediacodec.github.io/av1-avif/

Which patents is HEIF itself encumbered by and who runs a patent licensing pool for HEIF?

MPEG tells [1] rightsholders to file Patent Statement and Licensing Declarations to ISO/IEC. ISO/IEC maintains [6] a spreadsheet of received documents and the relevant standards that they concern. Examining that spreadsheet, I found four declarations that concerned the HEIF standard, all four submitted by Nokia Technologies Oy. These documents [2][3][4][5] provide references to patents approved or pending.

The patent or patent application numbers, in order of their appearance in these documents:

AU 2014255577, CA 2909566, CN 201480034418.2, EP 14785343.6, IN 6931/CHENP/2015, KR 2015-7032685, RU 2015146961, US 14/254120, US 14/617266, WO PCT/FI2016/050063, US 14/618650, WO PCT/FI2016/050064, GB 1418114.3, WO PCT/FI2015/050671, WO PCT/FI2014/050582, US 14/583332, PCT/FI2014/051052, PCT PCT/FI2016/050381, US 15/578288

This is where I'd start.

Sources:

[1] https://mpeg.chiariglione.org/patents [2] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [3] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [4] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [5] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [6] https://www.iso.org/iso-standards-and-patents.html

The US patent applications in the above list resolve to the following five:

https://patents.google.com/patent/US20160234144A1/ This one seems to be about specifying a Mimetype paramater that tries to describe the cost of image transformations requested in the target file, so that clients who know they can't perform those transformations can pick a different file.

https://patents.google.com/patent/US20160232939A1/ Seems to be about image sequences and specifying such a concept with coherent metadata in the container.

https://patents.google.com/patent/US20150193494A1/ This seems to talk about the myriad ways that ISOBMFF can assert metadata about data elements within, but there aren't always good ways to ensure the metadata points back to a specific data element. This talks about ways of figuring out whether such loosely-floating metadata in the container is still valid for data items; they also propose using checksums to figure out if the data items changed.

https://patents.google.com/patent/US20180146225A1/ This is a fancy restatement of P-frames for still images, leaving open the possibility that later frames also 'enhance' the first image in various ways e.g. upscale resolution and others.

https://patents.google.com/patent/US20140314148A1/ This defines signalling to allow putting all the I-frames at the start, and all the P-frames at the end.

Nokia has licensed their HEIF patents under royalty-free terms:

https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

So that solves that problem.

Which other patents is HEIF encumbered by?

Your statement that "Nokia has licensed their HEIF patents under royalty-free terms" is not true, because the license-in-question's [1] grant is "to, use, run, modify (in a way that still complies with the Specification), and copy the Software within the Licensed Field."

Licensed Field is defined to be: "(...) the non-commercial purposes of evaluation, testing and academic research in each non-commercial case to use, run, modify (in a way that still complies with the Specification) and copy the Software to (a) generate, using one or more encoded pictures as inputs, a file complying with the Specification and including the one or more encoded pictures that were given as inputs; and/or (b) read a file complying with the Specification, resulting into one or more encoded pictures included in the file as outputs."

It is pretty clear from this reading that their patent grant is for non-commercial evaluation, testing and academic research only.

[1] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

>killing video patents is the very reason AV1 exists

Again, AV1 is royalty free, not patents free.

Safari 11.1 supports any video in <img> tag and it does all the things you want: https://calendar.perfplanet.com/2017/animated-gif-without-th...

There is a feature request for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=791658

As if developers weren't actively trying to kill regular images in the web! More and more sites serve me some blobs via some pointless js scripts, forcing me to use developer tools to just save the original image. Combined with lazy loading it results in some frustrating UX.

Which is sad because webm in browsers already passes the right click test but websites have started a trend of blocking users from saving content so they choose to share a link instead which brings in more ad views.

When I want to copy an image from Instagram I have to use the dev tools to find it.

You poor soul.

Yes. Add this to the list of problems you can't believe we still have to put up with in 2019.

I can right-click and save videos just fine. You can too, try it here: https://thumbs.gfycat.com/GregariousDevotedArachnid-mobile.m...

You just have to write some Greasemonkey script to circumvent all the crap that the video-serving websites do to prevent you from getting the normal video-in-a-browser UI. It's harder when you get this link https://gfycat.com/GregariousDevotedArachnid

On your second link I can directly right click and save, on others (like Twitter) I just have to shift right click to bypass the blocking scripts. (Firefox desktop with multiple privacy extensions)

To my knowledge you cannot save a gif from twitter. They do not provide the source data, the actual pixel-exact gif file. Only some recompressed video.

All of the clips in this article have 'Save Video As...' options for me... ?

There's already apng (animated png) which is like GIF, but with the quality of PNG. No one really seems to care, though.

I wonder why, apart from IE not supporting it? Which we just serve gif to IE user.

The issue is that very often the "good enough" solution is what sticks. Gif are good enough and the world is not in a hurry to adopt a replacement.

Gif was killed a long time ago by webm

webm killed nothing.

Last I checked my iPhone can't do webm or webp

You can support a variety of formats in Safari using WebAssembly builds of the decoders. WebAssembly for audio and image formats is more than fast enough. It's even fast enough for VP9 video.

WebP demo: https://webmproject.github.io/libwebp-demo/webp_wasm/index.h...

Theora\VP8\VP9\Opus\Vorbis demo: https://brionv.com/misc/ogv.js/demo/

ogv.js on GitHub: https://github.com/brion/ogv.js

Is it really worth it to ship a decoder to every user of your site rather than encode it once on your server?

Don't get me wrong, it's a super cool demo but anyone who does this is prod is a little nuts. The exception being a service that's write once read maybe like CCTV cameras.

You still encode the file once on the server. The decoder just happens to be implemented in WebAssembly.

Wikipedia uses ogv.js. If you've ever played audio or video on Wikipedia in Safari then you've used ogv.js.

Some Bach on Wikipedia in Safari: https://en.wikipedia.org/wiki/File:Chromatic_Fantasia_(Bach_...

It's all gravy, the javascript WebP decoders, until you convert your 20K high res photo site to WebP, then not realizing for a week, scratching your head about the bounce rate spiking, that you're crashing browsers left and right...

Reply on news.ycombinator.com