Yep, it seems to have built up a fair bit of traction, mostly thanks to the Reddit crowd. There’s an API of sorts too. If Discourse did its automatic grab-the-file-and-self-host-it I suppose this might work in the short term.
I really think this kind of workaround ought to be open source though. A lot of articles I’ve read describe Gfy as a new format, which is very misleading. There’s only one way to make a “Gfy”, and that’s through Gfycat.com. Gfy is a service.
Some communities would benefit from such functionality.
Especially ones with download remote images to local setting enabled , but faster page loads alone is a good reason to think about it.
Quick hack would be to just use gfycat.com API.
Assuming one does not mirror remote images, I think it is achievable even with pure Javascript which you can add via /admin/customize/css_html. Lets say JS iterates over posts and if it finds .gif image. HTTP GET is performed: http://upload.gfycat.com/transcode?fetchUrl=i.imgur.com/jGMtJIb.gif
It downloads&converts remote image (if not already present) and returns JSON with video details. At this point you replace .gif with video in post (see section “How can I embed these or link to them?”)
Custom plugin which bakes .webm into posts via background job would be of course more elegant.
Anyway,
I don’t think they (gfycat) do anything magical beside handling hight traffic quite well.
We can replicate functionality with ffmpeg alone (see 4chan’s guide to converting GIF to WebM).
If we plan to self-host .webm it would be just an extension to already existing download remote images to local feature. We would have an additional setting replace .gifs with optimized .webm versions (we could add another setting: convert only .gifs bigger than…).
Such native functionality requires ffmpeg as a dependency and comes with additional security risks.
It does not sound like a good default for Discourse: maybe it is possible to create it as a plugin?
The cornerstone of Project GIFV is a platform-wide upgrade to automatically convert uploaded GIF files on the fly into the MP4 video format. […]
The .GIFV Extension: 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.
Exactly!
Discourse already has onebox for MP4 files.
So the only missing piece is some kind of a sidekick job that does the conversion and slight modification to the onebox to loop by default (if mp4 was created from gif).
It works for imgur.
For example something like https://i.imgur.com/mYNXTPw.gif can be requested as https://i.imgur.com/mYNXTPw.webm which gives:
It would be nice if Discourse detected .gif URLs from common providers such as imgur/gfycat
and just replaced image with looped video (already provided by site), as it saves a lot of bandwidth.
That sounds like something that could easily be done using the onebox, adding a white list either in the image or video engine. I am happy to build that, if such a PR is wanted (could also be behind a configuration setting, if needed).
Chrome does a terrible job with huge gif files, they can choke the web browser and cause all sorts of nasties not to mention mobile paying a hefty price on traffic and blowing data plans.
It’s really just a video element with a bunch of fallbacks.
I see a few actionable things we can do here:
If people hotlink anything larger than say 10mb force a “click” to actually download the image and hide it behind a preview
get ffmpeg into our base image and do the webm and mp4 conversion for all animated gifs, don’t worry about the flash fallback.
Offer an integration piece with imgur that uses imgur to do this … any gif larger than X gets sent to imgur for recompression. (or use a different service)
One thing to consider is how Slack deals with this:
http://img0.joyreactor.cc/pics/post/%D0%B3%D0%B8%D1%84%D0%BA%D0%B8-superjail-%D0%BC%D1%83%D0%BB%D1%8C%D1%82%D1%81%D0%B5%D1%80%D0%B8%D0%B0%D0%BB-%D0%A1%D0%B2%D0%BE%D1%8F-%D0%B0%D1%82%D0%BC%D0%BE%D1%81%D1%84%D0%B5%D1%80%D0%B0-1886210.gif (Not automatically expanded because 30MB is too large. You can expand it anyway or open it in a new window. You can also change your preferences to allow images of any file size to auto expand.)
Pero ninguno de estos aclara si la solución fue implementada.
La razón por la que pregunto es que, a menos que esté equivocado, el lightboxing no parece ser compatible con los GIF. Con esto me refiero a que no puedo hacer clic en un GIF para verlo en pantalla completa. Cuando el GIF contiene texto detallado, el usuario no puede hacer zoom sin abrir la imagen en otra pestaña.
Sin embargo, si el GIF se convierte a MP4 al subirlo, entonces nos beneficiamos de la funcionalidad de pantalla completa del reproductor de video existente, así como de la barra de tiempo: ¡ventajas enormes cuando estás viendo un clip breve de tutorial!
¿Ya está disponible esta posibilidad de conversión? También busqué “gif” en la configuración y encontré:
Al comparar diferentes estilos de documentación: todo texto, solo video, texto + gifs, la opción de texto + gifs fue muy superior. En consecuencia, planeamos usar gifs para demostrar cosas en las publicaciones de tutoriales. Sin embargo, si no podemos poner el gif a pantalla completa o en un lightbox, el texto escrito a menudo puede ser difícil de ver.
Y como ves, al pasar el ratón por encima, solo obtienes la opción de pausar.
Pero lo que realmente necesitamos es poder hacer el gif a tamaño completo. La solución alternativa es hacer clic derecho y abrir en una nueva pestaña, lo cual está bien para nuestros usuarios más expertos, pero no se puede esperar que el 90% restante se adapte a eso. Por lo tanto, o necesitamos una forma de que los gifs subidos utilicen lightboxing para que se vean a tamaño completo al hacer clic, o simplemente se conviertan a mp4 para que Discourse proporcione funcionalidad de pantalla completa.