So a lightweight version of ffmpeg/mencoder, but what is meant by "lightweight" in terms of stream video processing? Does it perform conversions from one codec to another using less CPU cycles.
Lightweight in terms of new code on top of existing codecs: we kept it compact, meaning small binary, fast execution, and easier to add to a mobile app for instance. (ffmpeg gets big very quickly).
Also, there aren't any extra memory management system, buffer pools etc: it's all done through C++11.
We basically thinly rearchitectured around the media technologies used today in 99% of cases: mp4, mpeg ts, jpg, GIFs, VPX/WebM, WebP, ...
It still uses x264, vpx etc to do decode & encode. It's lightweight in the sense that it's a shallow wrapper around these libraries and it doesn't consume unnecessary memory or CPU cycles on it's own.
I'll give the devs here the benefit of the doubt that the original project repo has more history than that, but what might be the reason it wasn't preserved when the GitHub repo was created? Copyright reasons? Or someone just couldn't be bothered?
The project is relatively mature at Twitter and has indeed a much longer commit history. Per our internal policies, the repo had to be cleaned before we could release it to public, and thus we erased the history before putting it on github. An exciting fresh new page in the project history.
It's mostly related to properly complying with OSS licenses of other projects and we also had some pieces of code that were for Twitter specific use cases.
8 comments
[ 7.4 ms ] story [ 29.9 ms ] threadI'll give the devs here the benefit of the doubt that the original project repo has more history than that, but what might be the reason it wasn't preserved when the GitHub repo was created? Copyright reasons? Or someone just couldn't be bothered?
Not trying to be critical here. Just curious.