Keyframes: Delivering scalable, high-quality animations to mobile clients(code.facebook.com) |
Keyframes: Delivering scalable, high-quality animations to mobile clients(code.facebook.com) |
I'm one of the developers at Facebook who worked on this library since its conception! Really excited to be able to share this library today! I'll be checking up here periodically and can help answer any technical questions that you have!
> provided Your Software does not consist solely of the Software
Why didn't you guys choose MIT or BSD? It feels like the custom Facebook license is close to the intent of these, but it has that mysterious gotcha.
In any case, thanks for the software! It looks really slick, and I definitely have a use case for using it to replace the sprite sheet I used for Donald Trump on jungle.horse.
[1] https://github.com/facebookincubator/Keyframes/blob/master/L...
[0] https://help.github.com/articles/github-terms-of-service/#f-... Section F.1: "By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."
Software = Keyframes software.
Your Software = Whatever you are releasing.
So basically they are saying you can't redistribute just the Keyframes software library by itself. Which also means, if I understand this right, you can't fork it and modify it either.
I agree however, not a good license.
(in that case, they even used it to distribute a patch to ffmpeg, which is LGPL)
> Word of warning: while I'm not a vampire, I may or may not be a night owl.
That totally sounds absolutely non-suspicious... Also, you may or may not be having a HN-driven traffic spike.
> We actively welcome your pull requests. Fork the repo and create your branch from master.
Thanks.
Presumably, if blender formats the composition in the supported structure and doesn't drift outside what the library recognizes and supports, it should work.
https://github.com/facebookincubator/Keyframes/blob/master/d...
http://www.nytimes.com/2016/11/22/technology/facebook-censor...
The license [1] doesn't look to be as encumbered as some of Facebook's other open source licenses, but does include a clause I found to be strange:
> provided Your Software does not consist solely of the Software
So if I'm reading this correctly, it means only Facebook can redistribute this software? Wat.
[1] https://github.com/facebookincubator/Keyframes/blob/master/L...
Huh?
Didn't I just read a whole blog post saying that one of their requirements was fast loading from disk, small bandwidth usage, etc? And that's what justified creating an entirely new image format from scratch, not something the internet is really suffering a shortage of already?
I know JSON is fashionable but that ending just seems kind of ridiculous. What's wrong with a binary format? Use Cap'n'Proto and mmap it! Saying numbers represented as text compresses well was the icing on the cake. No shit!
Previous options were exporting SVG animations, rendering to bitmap spritesheets or png sequences - or having to write a spec for the AE animation and recreate it in iOS/Android.
Since Adobe moved quite some effort away from Flash and towards HTML I'm pretty sure that they would now also support exporting keyframe animations from one of their standard tools into a native browser format.
Have you tried font-iconification services like http://fontastic.me/ ?
This should be wrappable by a React Native Component, it really is screaming for somebody to do that...
It means nothing
> A library for converting Adobe AE shape based animations to a data format and play it back on Android and iOS devices.
You still need to be able to produce the animation at first place.
Does it represent a lot of work by skilled technicians? Undoubtedly. Is it interesting in it's own right? Frankly I think not.
The surrounding question of the socialization of the internet is interesting, to be sure, but at the end of the day these are just animated emojis...
still interesting though. gonna check it out.
Just saying.
I don't mean to be unpleasant (really!), but I don't understand what kind of answer you are expecting to get.
The only non-trivial answer one can give is also the most obvious: Facebook doesn't want to make free software.
Stated differently: why the assumption that Facebook is in the business of Free software? Or are you just expressing the desire for all companies to produce Free (in the Stallmanian sense) software? Or are you reacting to the implication that Facebook's software qualifies as free?
I only bring this up because these kinds of loaded questions have a way of devolving into flame-wars.
Presumably if you added a unique feature it might not "consist solely of the Software". But that clause isn't the troublesome one -- "modify the Software for your own internal use" makes it crystal clear that this is absolutely not Open Source.
Question: I assume you have some corpus of the recorded speeches of DT. How are you mapping those to words? A broader discussion about how you implemented jungle.horse would be interesting...
Thanks!
Also I think you have to pick something human readable here. One of the great things about SVG is that it's in XML so you can read it, tweak it, etc. It's super handy when you want to make small changes that only affect the image. So I see using JSON as pretty handy.
Don't forget there are many types of formats out there that have 2 types: a binary and human readable type. One used typically during debugging and one used for optimal over-the-wire transport. I don't see why this couldn't be possible at a later time.
Edit: I don't understand the downvotes. Over-optimizing is a thing. For a one time download I don't see the handfuls of milliseconds you're saving mattering. In either case of receiving a binary or JSON you will store it in an optimal format on the device...
With gzip sizing is about the same, but processing speed wise it is not.
Fields are serialized to tag numbers instead of field names in the binary format, so it's easy to rename fields. This also saves a ton of space versus JSON.
Proto "messages", analagous to structs in other languages, are typesafe, negating the need for a separate schema definition language. They support optional and sum types too.
So many languages have great protobuf libraries available. (I'm hoping one becomes available for Rust soon--as well as gRPC.) It would be amazing if the browser vendors would come together and standardize it as a first class browser serializarion format. It'd save so much bandwidth to emit protos instead of JSON.
Cap'n'Proto has pretty great support for Rust, from what I hear.
You don't think having an easy way to create high quality animations for any purpose that work on multiple platforms is interesting...? You might not find the current application of it interesting but that's like saying React isn't interesting because someone used it to make another Flappy Bird game.
I see neither.
Analogously: TCP is pretty amazing, but I don't expect an app that uses a simple TCP socket to self-aggrandize on the pretext of technological innovation.
It would be more if they'd have created an extension to the SVG standard that they'd just parse out via JS. Then it'd just be a polyfill, and could easily be integrated natively in the future, and gain support on other platforms, too.
This will change the world for a few months, modifying the standard would change it for years.
The purpose of an analog is not to be exactly identical, otherwise it would be called an equality.
I really don't see what there is to write home about. This article reads as a PR announcement (which is okay) disguised as a technical achievement (which it isn't).
They're "just" animations.
The web world only slowly catched up, and I think it took until the current gen of frameworks (angular2, etc.) to be at the same level. However the good thing (as you also pointed out) is that the new variants are based on standards.
Facebook's post explicitly states they view this as an open source library. So, while I agree that we cannot assume Facebook is in the business of free software, their post says they are releasing an open source library under a license that does not appear to follow OSI definition of open source.
btw, I love all the work you do for Rust, Steve! :)
Why not say something like "We're asking the legal team to consider whether we can still publish our projects on GitHub"
I generally would assume that if someone makes that comment, and you can verify that they are who they say they are, that they will in fact, be able to accomplish what they say.
It's a cool implementation but it feels like they are claiming to have broken amazing new ground. To people that don't understand much of the background technology that's exactly how it reads.
Snark aside, if you have a native mobile app it is a much, much nicer experience to have native animations integrated rather than trying to mash an HTML view into the app just for some animations.
*Because programmers are the worst kind of pedants: Yes I know sometimes you can't afford to write native apps, sometimes a partial solution is better than no solution, etc. Just don't lie and tell me a web app is as good as (or better than) a native app, or that Cordova is a great way to write mobile apps. Those are compromises. Sometimes you make compromises to get shit done. It doesn't magically transform a compromise into an ideal solution.
That's another approach which has it's own pros and cons. The approach from the article is obviously good if you have Affect Effects experts on hand. I'm not understanding why this isn't interesting to programmers who on a daily basis have to weigh up the pros and cons of different technology/library choices.
Perhaps I'm showing my age, but this feels like this problem was solved a long time ago, forgotten or unused to a large extent and now re-invented. Flash was the clever web version back in the day but I can't see anything really new in this.
I could absolutely be missing the point though. I never count that out.
Same with csv data, for download size it really pays off to preprocess and pack into arrays of binary structs before compression.
This is part of a bigger class of effects in preprocessing data before compression, it is often surprisingly effective. For example delta coding or columnar format (SoA vs AoS) can yield big improvements depending on data.
With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is just related to the initial download and caching. Beyond that you'd keep it in whatever structure is more efficient for the app to re-use.
Why would you pull in data from one format and keep it in the same format forever if it's not optimal for the device AND it doesn't need to be modified and sent back? Whenever I work on mobile apps and I have to cache data coming over as JSON or XML I store it where I can quickly re-access and NOT in its original format.
This thread seems like a conversation about how you can shoot yourself in the foot when it's very easy to avoid.
> I haven't heard of SVG renderers storing SVG XML files in a more efficient format.
Me neither. Sounds like it could be doable. Not sure how this related to our conversation though.
This license seems to directly contradict GitHub's Terms of Service. It says:
> [...] you are hereby granted a non-exclusive, worldwide, royalty-free copyright license to (1) use and copy the Software; and (2) reproduce and distribute the Software as part of your own software ("Your Software"), provided Your Software does not consist solely of the Software; and (3) modify the Software for your own internal use. Facebook reserves all rights not expressly granted to you in this license agreement.
Where as GitHub's Terms of Service state:
> By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
It seems impossible for me to fork this software without violating Facebook's license. To fork it on GitHub would require that I make the repo public (meaning I would be distributing the Software as "My Software" even though it consists solely of the Software). And any commits I made to the forked repo would violate their license because I am only licensed to modify the Software for my own "internal use".
"reproduce and distribute the Software as part of your own software ("Your Software"), provided Your Software does not consist solely of the Software;"
Seems like a clear abuse of GitHub's goodwill towards real open-source projects, though. Luckily, it looks like they're going to change the license: https://github.com/facebookincubator/Keyframes/issues/24
The TL;DR is: You can't grant more rights than you have or can sublicense, no matter what the TOS does.
The same is true of most property. You can't gain an interest greater than the one the person who gave it to you had.
Otherwise, you'd be able to create greater title out of thin air (IE a guy with a life interest can't grant you a fee simple)
Imagine instead github's TOS said "by uploading, you grant the right to use the software under the BSD license". Bob, who has no rights at all, uploads your commercial software. Is it suddenly BSD licensed? No, because Bob didn't have the right to grant "the right to use the software under the BSD license". Even if Github made Bob sign the contract with his blood, it doesn't give away any rights Bob doesn't own.
Here's the truth table version. Note: We assume the validity and bindingness of the TOS, which would certainly be a serious issue in any litigation.
A has necessary rights to grant right to fork. A uploads thing to github with license that prevents forks.
end result -> You probably have right to fork.
A has does not have necessary rights to grant right to fork. A uploads thing to github with license that prevents forks.
end result -> You probably do not have right to fork. Any TOS violation is a separate contractual issue.
A has necessary rights to grant right to fork. A uploads thing to github with license that is silent on forks.
end result -> You probably have right to fork.
A does not have necessary rights to grant right to fork. A uploads thing to github with license that is silent on forks.
end result -> gray area. You probably do not have right to fork. You may or may not be able to argue an implicit license.
Note that this gets even more complex if A is a member of a corporation, as you have actual and apparent authority issues.
Hell. I just clicked the 'fork' button. Where's my cease and desist?
Open Source need not be free as in beer, nor as in freedom.
We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive. Ironically, we were partly a victim of our own success in bringing the `open source' concept into the mainstream.
https://news.slashdot.org/story/99/06/17/0213251/esr-on-the-...
"Open source" as a term or development methodology is older than both the OSI definition and the Debian manual it is based on.
"Initially, we looked at common static image formats such as PNG sequences and GIFs, as well as even more compressed formats like WebP. It quickly became clear that these wouldn't work without drastically simplifying the animations for file size, and that we'd have to accept the drawback of static images not scaling up or down very well."
So, reading between the lines, they've made what they think is a better GIF. And perhaps it is, and if so, that's big business[1], and so having a first-mover advantage on mobile could be highly profitable. (They're a public A-corporation, after all.)
But who knows; I could be reading too far into it or just flat-out wrong, too!
[1] http://www.popularmechanics.com/technology/a21457/the-gif-is...
Keyframes competes with animated SVGs, but not GIF/APNG/WebP.