Open izzytwosheds opened 5 years ago
There are multiple forks ongoing, I want to summarize the current situation first. List of ongoing forks I know (create date order):
Also note that this library is depended from https://github.com/jbavari/cordova-plugin-video-editor https://github.com/dride/cordova-plugin-video-editor , so, majority feature requests and bug reports seems to come from it.
I have added docs to the repo at natario1/Transcoder where I also list what has changed. If anyone wants to take a look and join, that would be cool!
Thanks for your work @ypresto and congrats for your 👶!
FYI mitene team is to considering take ownership of android-transcoder (as I'm already ex of the team).
I'm looking for company-grade maintenance of this lib or its successor.
First and foremost, @ypresto congratulations on a 👶! That is an amazing and very rewarding project, and it should definitely take priority! :) Also, a huge thanks for writing and open sourcing android-transcoder, it is an amazing project.
I agree 100% on stability. Our transcoder (called LiTr) is engineered for stability and is currently used in LinkedIn app, which is a very large user base. It has a very test-friendly architecture and extensive test coverage.
So the issue is that LiTr has a pretty different set of APIs from android-transcoder (they are a bit more generic), and it is architected differently internally. For example, there are several abstractions which allow MediaCodec layer to be mocked, so we can test transcoder logic using unit testing. This results in a pretty large diff between the two. If I start changing android-transcoder into LiTr, there will be a lot of pull requests, which I don't want to make you review because it will take your attention away from the baby. :)
So maybe we can do this. I can open source LiTr independently, so community can see its code and decide if that is something they can/want to work with. At that point, we can decide if it is ok to switch over to LiTr or merge it with android-transcoder. My personal goal is to have a common 1.0 version of video transcoder for Android, with production grade stability. What do you think?
Thank you all for the celebration...! It's very hard but nice project I've ever joined. 🍼
@izzytwosheds
I agree with you, we need common one.
I can open source LiTr independently, so community can see its code and decide if that is something they can/want to work with. At that point, we can decide if it is ok to switch over to LiTr or merge it with android-transcoder.
Let's go with this..! I want to see all candidates before deciding the future of this library. Could you publish code of LiTr? :)
There are so few samples of code out there for transcoding. @ypresto did an amazing job of pulling this project together. Seeing another approach would also be welcome and I look forward to having a look at the @izzytwosheds implementation of transcoding when that is open sourced.
My own fork https://github.com/selsamman/android-transcoder (docs updated now) is more of a video composer than a transcoder. I think having a simple reference implementation of a transcoder that is ultra-stable is a great idea. The video composition, multiple streams, multiple segments within streams in my fork added significant complexity. This was needed for the video editing app I am developing but is overkill for most transcoding use cases.
That being said I am happy to contribute any knowledge I have gained with my fork to other transcoding efforts going forward. I would also welcome contributors to my fork if anyone else has a need for the composition features.
First and foremost, @ypresto congratulations on a 👶! That is an amazing and very rewarding project, and it should definitely take priority! :) Also, a huge thanks for writing and open sourcing android-transcoder, it is an amazing project.
I agree 100% on stability. Our transcoder (called LiTr) is engineered for stability and is currently used in LinkedIn app, which is a very large user base. It has a very test-friendly architecture and extensive test coverage.
So the issue is that LiTr has a pretty different set of APIs from android-transcoder (they are a bit more generic), and it is architected differently internally. For example, there are several abstractions which allow MediaCodec layer to be mocked, so we can test transcoder logic using unit testing. This results in a pretty large diff between the two. If I start changing android-transcoder into LiTr, there will be a lot of pull requests, which I don't want to make you review because it will take your attention away from the baby. :)
So maybe we can do this. I can open source LiTr independently, so community can see its code and decide if that is something they can/want to work with. At that point, we can decide if it is ok to switch over to LiTr or merge it with android-transcoder. My personal goal is to have a common 1.0 version of video transcoder for Android, with production grade stability. What do you think?
Any chance you guys are still planning on open sourcing this?
Any chance you guys are still planning on open sourcing this?
Yes. I am working on it. Stay tuned, good news coming very soon.
@izzytwosheds Are you guys planning to launch it in the upcoming Demuxed event? :)
@sauravexodus Most probably we will open source it before DeMuxed, but I will be giving a talk about it there :)
Great news man! Looking forward for it.
LiTr source code is now on GitHub: https://github.com/linkedin/LiTr @ypresto @selsamman @MasayukiSuda @natario1 please take a look, let me know what you think. I did my best to make LiTr pluggable, to allow amazing complex things other devs have been doing on their forks of android-transcoder
I will be talking about LiTr tomorrow at DeMuxed. @ypresto there will be a special "thank you" to you in my presentation, I hope you are ok with that. :)
Hi,
I am an Android engineer at LinkedIn and I wrote a transcoder with functionality similar to yours. I am planning to open source it, and trying to figure out the best way to do it. One possible way is to contribute to yours, but that will cause bunch of APIs to break and a major refactor - our architecture is fairly different. Another way is to open source it "as is", with acknowledgement to you and your projects. Which way works better for you?
I will be happy to talk offline to provide more context and more details. Please email me at ibahadirov@linkedin.com for more details.
Thank you in advance!