Hi, I know that the video issue is raised from time to time around here… While checking some older posts about it I found some interesting info, but I would like to check out how things are right now.
There is a codec licensing problem to overcome in order to have a single solution for all supported platforms, right? What about the webm one? There is support for it on Chrome and Firefox already and I believe I saw somewhere it may come to Edge as well. The codec would have to be built into only for the other platforms (except Flash, of course, since I believe we’ll need to live with flv for that). I’ve been working with video for media applications for years and this codec issue is, indeed, a major one with virtually no solution at the moment if you do not keep using Flash/AIR with flv only (AIR can’t play mp4 videos as child elements of the display list on iOS devices).
I saw here on the forums that there is a workaround with this project: https://github.com/soywiz/haxe-openfl-webm but are there plans to have it working directly from openfl on all platforms to be used as standard display objects?
I’m open to suggestions, at the moment, VP8 or VP9 support seems like the best bet for desktop? I forget what the state was for hardware-accelerated mobile support
Quick answer: no hardware-accelerated support on mobile, but even considering that, Android playback is ok from ICS. On iOS, however, there is not even a basic support for VP9, but i don’t believe we’ll have any for this kind of open source codec… On thing that might change the scenario is that YouTube is, indeed, converting its videos to the VP9 format for the browser playback.
We’ve strides for Lime-within-Lime (Limeception?) support – this would enable better support for host Java applications with embedded C++ applications inside, or perhaps we could find another way of sensible management of a video layer outside the ordinary GL surface SDL uses for rendering
Yeah, VP9 seems like a good bet if someone works on it. Perhaps iOS will perform well enough for certain needs, without hardware acceleration? Or we have to pipe in special APIs for OS hardware video?
Here I go again asking some video question: I’m able to play a mp4 video correctly on flash and html5 targets, but when I try to use webgl (-dwebgl) on html5 target, I only get the sound output, not the video one. Is this expected?
I figured out a quick fix for my problem, but I had to add some lines to the Video.hx class of the openfl.media package - a thing I didn’t want to do… On this file, I add these lines to have working “videoWidth” and “videoHeight” properties on HTML5 video:
#if html5
public var videoWidth(get, null):Float;
public var videoHeight(get, null):Float;
public function get_videoWidth():Float {
if (this.__stream != null) {
return (__stream.__video.videoWidth);
} else {
return (0);
}
}
public function get_videoHeight():Float {
if (this.__stream != null) {
return (__stream.__video.videoHeight);
} else {
return (0);
}
}
#end
Then I created my own “VideoSprite” class, extending sprite, and add an openfl.media.Video object to it. I add these lines to it to handle the video size set on HTML5:
#if html5
// HTML5 size set fix
override public function set_width(value:Float):Float {
this._widthSet = value;
if (this._video.videoWidth != 0) {
this._video.scaleX = value / this._video.videoWidth;
}
return (value);
}
override public function get_width():Float {
return (this._widthSet);
}
override public function set_height(value:Float):Float {
this._heightSet = value;
if (this._video.videoHeight != 0) {
this._video.scaleY = value / this._video.videoHeight;
}
return (value);
}
override public function get_height():Float {
return (this._heightSet);
}
#end
openfl.media.Video is already a DisplayObject. Is there a way we can handle the width, height, bounds or other aspects better in order to make it behave as it should?
The problem is that if we don’t use -Ddom, on HTML5, setting width and height produces no effect, thats . One interesting issue is that the clickable area of the video does respect the width/height setting, but not the display.
