I am offering US$500 Bounty for OpenFL/Lime support for IOS and Android.
OpenFL API Reference shows openfl.media.Video and openfl.net.NetStream.play(). We need to have iOS/Android native video for OpenFL.
Basically, having video support on iOS and Android, and being able to use the classes openfl.media.Video and openfl.net.NetStream.* to play a video.mp4 file like we were used to do with Flash/ActionScript 3.
According to Joshua (OpenFL singmajesty), the founder of OpenFL:
“OpenFL uses the browser on HTML5 or currently Lime on native/mobile platforms to implement lower-level features such as video support.
Once Lime has video support OpenFL can support it quite quickly. Happy to discuss video support in Lime and work with anyone spear-heading that effort.”
The bounty is $250 for iOS and $250 for Android to implement (native) video support in Lime.
Hopefully you will also be interested to share that with the community, and hopefully spear-head that effort, as mentioned by Josh.
Perhaps inspired by my FITC talk at trying to hook WebM ( vpx c++ ) up to NME, was rather a failed talk as struggled with 32/64 issues on mac, and generally at giving talks, and only got as far as reading frame numbers into NME, I had never tried any c before then, but I think I entertained thew with some divtastic experiments.
Anyway apparently there is a problem with soywiz webm decoder in that video will run out of images, the image class has a version that increments with new images and eventually runs out - surprised as it seems odd as an Int should be plenty ( just /60/60/60 still reasonable number of hours! ), but maybe it’s for all images and double buffering etc…
But I am sure changing the ‘version’ property in the Image class to a Float would surely help in a large way, or just creating a new static method that uses an image variant that has ‘version’ property defined as a Float.
Float on c++ value max typically = 9007199254740992 after that it can’t increment in +1 steps.
Int on c++ value max = 2147483647
So just switching to a float and it becomes 4194304 times bigger, the maximum on hashlink is smaller by a factor of 10?
You can find details of Min / Max values for haxe here:
Obviously WebM is not ideal but certainly it seems a viable approach, since most decoders apart from WebM have licenses that are either commercial or GPL so the only way round is to use native Java or native Obj-C code. But then you have to transfer the video frames between haxe and the native platform which is likely going to be heavy unless you setup pointers or something which then could be very risky, memory volatile.
What is the objection to haxe-openfl-webm, it should be feasible to improve integration. The version property of Image could be changed, or use of a ‘VideoImage’ which is easy to swap data with ‘Image’. I believe this may work for HashLink or C++ target? I expect the webm code could be revisited, I believe from looking at Google’s VPX decoder code that quite a bit of the Webm is ready made and it’s just transfering pixels via cffi or newer approaches.
webm software decoding is a bit troublesome in regards to performance. I tried that. Kha has the code to use Android’s and iOS’s native, hardware-accelerated video-decoding. Feel free to copy it and earn some money. For Android that also requires a special fragment shader adjustment.
The bounty would make more sense if it was to add WebM to hxformat, and hxformat had approaches setup specific for android and ios, I am just not convinced that building a solution for only one toolkit is ideal?
Thank you for your input. I am not very familiar with Webm and the solution that you presented. Does it play a video.mp4 file?
I was actually thinking about something more simple. Just pass the video location to an implementation or interface that uses the native player of iOS and Android, like OpenFL uses the HTML or Flash native player; and integrate that in Lime (as it was done with HTML and Flash players). What do you think?
The bounty is still on ($500) for Lime native video support for iOS and Android (as suggested by OpenFL’s creator, Joshua). In addition, Kha’s creator, Robert Konrad, was very kind to offer Kha’s implementation to “copy/adapt in Lime” and showed the code:
Oh, I kind of gave up on cooperation. Still open to it but I don’t think the guy who only does those Haxe things in what little free time he has left next to his two full-time jobs is the right person to push that forward.
That said, the thing is at https://github.com/Kode/openfl - it works with the exception of vector graphics but it sits on an old version of openfl because its internals have been changed around again shortly after. A test project which can be build like any other Kha project ist at https://github.com/Kode/OpenFLTest
I recently started again on working on the missing vector graphics support, that’s happening at: https://github.com/RobDangerous/nanovg
Got more contribution from other sources. The bounty now is $1000 to get native video support for iOS and Android in Lime. Would you like to do it and get the next generation SuperNintendo or whatever cool video platform is out there?
Please let me know if you would like to talk about it. My skype is brunok3 - or indicate another way to communicate directly if you prefer.
Hm, I’m confused that nobody wants to tackle it, I thought I provided all the pieces. But if that’s the case and if it has time until late June (just finishing up something else right now) I’ll take care of it.