Openfl.media.Video

Help
#42

Could You try removing in file lime/project/lib/theora/files.xml line, about 33

<file name="${NATIVE_TOOLKIT_PATH}/theora/lib/x86_vc/x86enc.c"/>

Generally I don’t use visual studio, on windows I’m compiling with MINGW and it has different preprocessor defs and different files are needed to build library. Unfortunately I could check and eventually fix those issues in home, now I can just guess which files are missing.
Other option is to add every .c file in lib folder to files in files.xml, and it should work, but lib will be bigger then ;/

#43

No worries - you were absolutely right! That fixed it :slightly_smiling:

OK wow, so that works great! If its helpful I can try and build this on Mac as well?

Is sound on the agenda as well? :slight_smile: Thanks for working on all this and being so kind to share

#44

I’m glad someone tested it, thanks :slightly_smiling:
I don’t have a mac unfortunately, but I think it will need just selecting proper files and preprocessor defs. Maybe, with some luck, it will no need any tweaking at all and work. If You could check it and give error messages, it would be great :slight_smile:

And sound could be easy to program, but hard to do in smart way, since I don’t know haxe well :confused: there is work done in AudioBuffer, but it is putting all samples to ram into one OAL buffer, and I think it would lead to problems with sync audio/video. With a little time I think that it will be done (at least working).

Thanks a lot!

#45

Great!

I just tested on mac and when rebuilding lime I got this

Screen Shot 2016-02-08 at 13.43.00.png1108×108 20.8 KB

"Error: clang: error: unknown argument: ‘-fforce-addr’

#46

Could You swap in files.xml

<compilerflag value="-fforce-addr"/>

into

<compilerflag value="-fforce-addr" unless="mac || iphone"/>
#47

And do You have in commandline output for mmxfrag.c -DHXCPP_M64 or -DHXCPP_M32 ?

Edit: ok, I can see there is 64 bit build - maybe try also changing:

<compilerflag value="-DOC_X86_ASM" unless="android"/>

into

<compilerflag value="-DOC_X86_ASM" unless="android || HXCPP_M64"/>
#48

Yes, that did the job! I am now able to compile and run video in mac!

How can I check if the commandline output for mmxfrag.c -DHXCPP_M64 or -DHXCPP_M32 ? Is that something I will see in the terminal? Do I need to run something?

#49

It is define that is added to targets (for 32 and 64 bits respectively). 64bit asm is (or may be) different than 32 bit, and it might generate some errors when building on 64 bit target.
You can check it by looking at full command line output, if this string is somewhere in the defines. I think it should be just before -DHXCPP_VISIT_ALLOCS in Your mac printscreen.

Glad it works on mac also :slight_smile: great news

Ah, and it is just the beginning, there is lack of proper quitting, so just one movie could be played now :confused:

#50

OK it says “-DHXCPP_M64” so I guess it is a 64 bit build :slightly_smiling: Thanks for explaining that.

Haha that’s true, is it possible to expand this? I know its not completed yet, but it is very exciting and encouraging :slight_smile:

#51

Yes, there should be VideoBuffer.cpp file tweaked to remove videobuffer after movie has ended, and written some haxe linkage with cpp code. Generally, there is few options of what could be done with it, whether managing of videobuffers should be done inside lime.ndll or in executable, or how audio should be handled.
And a lot of code is redundant, clearing it a little should also be done.
I’ll post my progress, but if You want to tweak it a little, two cpp files that are handling video are /project/src/video/format/OGV.cpp and /project/src/video/VideoBuffer.cpp.

#52

@JayMaxArmstrong could You also have the possibility to build for iOS device? I built for android but got black screen, no movie is shown. Since I got problems with debugging android apps, I don’t know where error could be (or is using SDL texture possible on android device).

#53

I tried to ‘rebuild lime ios’ but I got a lot of errors:

Screen Shot 2016-02-15 at 12.23.08.png1180×92 12.4 KB

Screen Shot 2016-02-15 at 12.23.22.png1278×1456 141 KB

Are there things that need to be removed from the files.xml?

Let me know and I can try again :slight_smile:

Any luck with the other areas (stopping/starting and sound?)

1 Like
#54

Hi:)
I think You could swap

            <compilerflag value="-mmmx" unless="android"/>
            <compilerflag value="-msse" unless="android"/>
            <compilerflag value="-msse2" unless="android"/>
            <compilerflag value="-DOC_X86_ASM" unless="android"/>

into

            <compilerflag value="-mmmx" unless="android || iphone"/>
            <compilerflag value="-msse" unless="android || iphone"/>
            <compilerflag value="-msse2" unless="android || iphone"/>
            <compilerflag value="-DOC_X86_ASM" unless="android || iphone"/>

Since video should be better integrated into haxe itself (now it’s just two functions mapped to c++), and threading would be helpful, I’ve decided to run quickly with Haxe manual first, so vids could be actually usable in normal work :slightly_smiling:

#55

This is by no means a replacement solution for Theora, unfortunately the license has some conditions that I expect would make it unfeasible in many cases. But it might be useful for someone looking for a hardware accelerated option, in deployments they control, like internal company apps.

Cisco have open sourced their implementation of H264 with OpenH264. Importantly, when using Cisco’s precompiled binaries (not source), Cisco will cover the royalties that would apply to that binary module under MPEG LA’s AVC/H.264 patent pool.

The license condition that I think rules this out as a widely used video solution for OpenFL is (source):

  1. The Cisco-provided binary is separately downloaded to an end user’s device, and not integrated into or combined with third party software prior to being downloaded to the end user’s device;

OpenH264 Binaries download

#56

@Retard Sorry for the slow reply!

I wondered whether you’d had more progress? If I was to add this to the latest Lime what are the things I would need to transfer across?

#57

@Retard every time after I run a video, the renderer becomes quite scrambled. Is there a way to unload the video and run it and safely return to the application? Thanks

#58

Hi! I’ ve manage to do some progress in videos (got working video with sound almost synced), but problem is - as You pointed - renderer error after playback. It seems that renderer is damaged after first call to RenderCopy, when texture is in YUV format, and I’ve tried to tackle it in various ways without any success (creating new renderers, switching renderers etc.)… Which is weird, because in normal c++ app SDL renderer is working - movie is ended and app is being able to show textures in other pixel formats :confused:

Here are sources, maybe someone could fix this error ^^ If not, there are OGV cpp and h files, they could be used in other apps with SDL2 and OpenAL:
–link is in next post–

Here is working app in neko (far quicker to compile, and it is displaying move and shows the problem -> lime texture should be visible after movie ends):

And here is just cpp version of movie player sources with compiled exe to check that after movie is ended bitmap is displayed correctly in cpp:

#edit
Well, it is not working on linux :confused: renderer is badly rendered from the start, and app crashes after movie is finished but I do not have a clue where error could be.

Generally drawing functions in sdl needs a pointer to texture and renderer. I got renderer pointer from function I added to lime/graphics/Renderer.hx:

	public function getBackend ():Dynamic {
		
		return backend.handle;
		
	}

I assume it is a pointer to SDLRenderer object from lime.ndll.
It is passed as Dynamic to lime, casted to void* and passed to OGV constructor, and finally pointers to SDL_Renderer and SDL_Window are extracted from it (SDL_Windows is needed for setting proper scale boundaries). Window dimension are readed properly, so I think pointers are correct.
In ExternalInterface I added two functions - lime_video_load and lime_video_load_frame.
If somebody could check it/help, I would be appreciated :wink:
cheers:)

#59

Hi!

That’s great you’ve been making progress on this! I’m still very interested in this as well so I’m pleased that you are having some success.

I found that after I returned from a video the pixels were all offset so with some help I was able to reset

				renderSession.gl.depthRange(0, 1);
				renderSession.gl.clearDepth(1);
				renderSession.gl.depthMask(true);
				renderSession.gl.colorMask(true,true,true,true);
				renderSession.gl.disable(renderSession.gl.DEPTH_TEST);
				renderSession.gl.frontFace(renderSession.gl.CCW);
				renderSession.gl.enable( renderSession.gl.BLEND );
				renderSession.gl.blendFunc(renderSession.gl.SRC_ALPHA, renderSession.gl.ONE_MINUS_SRC_ALPHA);
				renderSession.gl.disable(renderSession.gl.CULL_FACE);
				renderSession.gl.disable(renderSession.gl.SCISSOR_TEST);
				renderSession.gl.disable(renderSession.gl.SAMPLE_ALPHA_TO_COVERAGE);
				if ( renderSession.gl.MAX_TEXTURE_IMAGE_UNITS == 0) renderSession.gl.MAX_TEXTURE_IMAGE_UNITS = renderSession.gl.getParameter(renderSession.gl.MAX_TEXTURE_IMAGE_UNITS);
				
				for (i in 0...renderSession.gl.MAX_TEXTURE_IMAGE_UNITS) {
					renderSession.gl.activeTexture(renderSession.gl.TEXTURE0 + i);
					renderSession.gl.bindTexture(renderSession.gl.TEXTURE_CUBE_MAP, null);
					renderSession.gl.bindTexture(renderSession.gl.TEXTURE_2D, null);
				}
				renderSession.gl.bindBuffer(renderSession.gl.ARRAY_BUFFER, null);
				renderSession.gl.bindBuffer(renderSession.gl.ELEMENT_ARRAY_BUFFER, null);
				renderSession.gl.clear(1);
				renderSession.gl.clearColor(1, 1, 1, 1);
				
				renderSession.gl.pixelStorei(renderSession.gl.UNPACK_ALIGNMENT, 0);
				renderSession.gl.pixelStorei(0x0CF2, 0);
				
				
				renderSession.gl.useProgram(null); `

Very messy I know! But it solved the problem and I was able to return to game rendering after that.

Is that helpful for your issue?

I don’t have a Linux environment yet so can’t offer anything useful in regards to that at this stage.

#60

Hi!
I’ve been able to do a linux working version and it seems that You have found a solution to graphic messup.
On lime, adding just

renderSession.gl.pixelStorei(0x0CF2, 0);

after movie fixes graphic (in SimpleImage source, when OpenGL is being setup). Could You check this? There are new lime sources with modified lime SimpleImage sources (shows video, and then lime.png file)?

#61

Generally I’m still working on this, but for now changes are following:

  1. added few functions in project/src/backend/sdl/sdlRenderer.cpp and sdlRenderer.h (added new SDLTexture to class and methods to init/deinit/update it)
  2. added 2 functions in project/src/ExternalInterface.cpp (exposing functions from project/src/video/OGV.cpp
  3. added folder project/src/video and files inside (cpp theora decoding functions)
  4. added few theora related lines in project/build.xml (location of OGV.cpp and theora decoder lib files)
  5. added folder lime/video and file inside (haxe connection with lime.ndll)
  6. edited lime/graphics/Renderer.hx - added getBackend function (OGV class need this pointer)
  7. added project/lib/theora with files (theora decoder lib)