I heard recently (from a reliable source) that there are OpenFl contributors getting close to having an implementation for video playback under Windows.
Anyone working on it care to make a public statement on possible time frame?
I ask because it looks like in a couple days I will be starting on a Windows-based kiosk project that will need to play video.
I think my two best current options are:
Bite the bullet, license AIR SDK from Harman and go back(wards) to what I know
Figure out how to implement a local desktop HTML5 application with Haxe/OpenFl so I can include video playback.
A downside of #1 one is that I lose GPU performance and one requested feature (zooming in and out of very large bitmap images) will end up being less elegant.
Downsides of #2 are that I have to figure out how to do it on a tight schedule (not a web programmer so I have to figure out local server etc…) and I also have to figure out Canvas vs webGL, which I know almost nothing about, and how they work with Haxe/OpenFl (my learning curve with Haxe/OpenFl has not been exceedingly quick–strange, I didn’t used to think of myself as a complete dolt. I did manage to figure out how to make relative paths for assets [not Assets] work for Haxe cpp and HTML5 locally and when loaded on a website–but it took a long time–so maybe 50% dolt).
I realize any new openFl video solution that came out before my mid-March deadline would probably not be final project ready, but I would be more inclined to figure out a Haxe/OpenFl HTML5 local desktop implementation if video for Windows was in the near future.
Any feedback on feasibility of #2 option would be greatly appreciated!
I think I am the only one working on this afaik. There is an webm extension for OpenFL, but I do not recommend it for production use due to serious flaws and stability issues.
With that said, it is on the roadmap for this year. If anyone wants to step up and assist, it would be appreciated as my time is pretty limited.
Did you check out Electron (https://www.electronjs.org/) ? It may be a solution to your problem, using the html5 target without the server setup issues.
Unfortunately, if the WebM extension is not yet solid, I’ll have to punt on Haxe/OpenFl until there is video support that is fully ready for customer projects. I might try WebM extension, but it seems like a bad idea with my tight deadline.
I can’t believe it didn’t dawn on me that video wouldn’t play almost a year ago when I ran into trouble playing MP3 files and learned I needed to use OGG. So I guess I’m back up to the complete dolt rating.
@bruno had offered a bounty a while back for OpenFL/Lime video support for IOS and Android.
If someone starts up a video bounty again I’d chip in for Windows support and solid HTML5 support. How much? Depends on pending projects and timing.
Video does work for html5, this is because we use the browser implementations and subsequent codecs here. On the web, openfl has full support for multiple media file playback. @chokito mentioned building openfl applications with electron for windows. Electron is an html5 wrapper for desktop platforms. This is certainly a viable option and although electron is not quite as fast as the native target, it is still much faster than something like Adobe AIR.
The problem here has always been licensing. Audio and Video codecs are largely proprietary and are not compatible with the MIT license openfl ships with. The exception to this includes .ogg and .webm and their open source codecs. This is exactly why you experienced trouble getting audio to work in the past. On the audio front, mp3 patents have since expired from 2017 in the US and 2012 in EU, which open the door here to adding audio support for this format, but for video, we are left with vp8 and vp9 via webm and the recently introduced AV1.
For mobile devices, we should be able to tap into the codecs included in these systems and grant full support, but overall, it is a complicated feature to implement.
As with the majority of my contribution effort to openfl, I typically work alone, but I would love to see more contributors step up to the plate and genuinely work toward improving the openfl codebase and fill in missing features like this.
Thank you once again @Dimensionscape. I truly appreciate the responses.
I will create a test with video in HTML5 and see how I fare.
I wish I were more current with languages and development environments to be of use as a contributor for getting more video features implemented. While a K&R version of C I used for CD-i programming was my all-time favorite language to use (love pointers and typedefs when bytes of storage really matter) that was decades ago and I’ve probably written fewer than 100 lines of C++ code in my life (not counting Arduino) and my eye doesn’t decipher that code quickly.
Heck, I don’t even really understand how Haxe/Lime/OpenFl work. I just know that I was eventually able to kick out applications using both HaxeDevelop and VSCode.
I did try some searching for a video solution though (probably nothing new here).
Cisco’s open source modules get around the licensing fee–bit only if the binary is downloaded from Cisco. It does not cover the license fee for your modified your own products that utilize the source code.
Nvidia might have some helpful code that isn’t strictly Nvidia specific. They have resources that are available to anyone, and additional stuff available to those in their free developer program. However they also seem to promote the use of FFmpeg source code without mentioning any licensing issues.
They do have a set of C++ libraries with Python bindings but I’m not smart enough to know if that would be helpful:
HandBrake is an open source transcoder mentioned on an Nvidia web page. Is there decode software in there? I don’t know. It falls under GPLv2 license and they didn’t respond to one poster’s question about MPEG LA license.
Anything with a GPL license is not compatible. If we were to add GPL licensed code to openfl, openfl would also have to be GPL and anything created with openfl would have to be GPL, which is extremely restrictive.
LGPL libraries could be included via dynamic linking, otherwise examples of compatible licenses include MIT, Apache, and BSD.
Thanks @loudo. I may try mobile some day, but I can’t even get this working on PC.
I followed the instructions on GitHub and used:
haxelib install openfl-webm
The “Simple Example” has no import and I can’t figure out what the import statement should be. Tried finding documentation on using extensions (no luck), even looked at instructions for other extensions.
var sprite:Sprite = new Sprite();
sprite.scaleX = 2;
sprite.scaleY = 2;
addChild(sprite);
var io:WebmIo = new WebmIoFile("c:/projects/test.webm");
var player:WebmPlayer = new WebmPlayer(io, sprite);
player.addEventListener('play', function(e) {
trace('play!');
});
player.addEventListener('end', function(e) {
trace('end!');
});
player.addEventListener('stop', function(e) {
trace('stop!');
});
player.play();''
After much banging of my head against the wall, I sort of got the sample video program to run from VSCode!
I changed browser to firefox, which didn’t take immediately, but eventually it prompted me to install the firefox debugging extension.
The catch is that when the sample program finally worked under VSCode, I had my own test project folder open–not the sample program. I tried to HTML5 debug my program, and the sample program ran instead.
The HAP suite of codecs (BSD-2-Clause License) are another option. These are designed more for low playback overhead. The resulting files are quite large still, and quality is pretty average, so fairly niche use cases.
Focusing on VP8/VP9/AV1, as you are, I think is the way to go @Dimensionscape. These are the best options we have for a standard with a permissive license.
