sfeMovie project [v1.0 RC1 available]

[snoozer87]

Alright, your project looks really good and it would be perfect for showing an intro. However, the function movie.openFromFile(...) never seems to work, I've tried with all sorts of formats now (.avi and flv for example) and it just never loads...

I also don't get any errors or debug information... Any idea what the problem is? Do I need to doo something with ffmpeg first or is it enough to link against the sfe-movie.lib and add the .dlls to the project?

Best regards

*EDIT*

Tried an ogg file and that loads perfectly (only audio)

*EDIT2*
Video ogg works aswell, everything else fails

[Ceylo]

Hello snoozer87 !

Thanks for your interest
As you have found out, the provided sfeMovie binaries only include some decoders : ogg vorbis, ogg theora and flac.

This is because I cannot provide decoders for other formats without paying royalties. Thus if you want support for avi or flv files (note that avi and flv are just containers, not codecs), you'll have to build sfeMovie yourself and enable some or all of the decoders. To do so you can follow the explanations on the wiki.

Or if you want to keep things simple, use one of the free codecs*.

Ceylo


* since sfeMovie 1.0 rc has been released, I've found out a few more free codecs : VP8 on any OS, and WMV/WMA on Windows. These will be included in the final v1.0.

[snoozer87]

Thanks a lot for the info, I just thought about rebuilding myself, so my apologies for the rather stupid question :p.

[Ceylo]

Don't worry, you're not the first one to ask
I should make this info more visible.

Ceylo

[snoozer87]

I'm sorry to bother you again, but I just rebuild the whole project and I selected to build all the codecs (to be sure). Sadly enough, the problem persists and I cannot load avi or flv files .

I'm aware that avi and flv are containers, so maybe the underling codec is not supported .

[Ceylo]

Did you replace the FFmpeg dlls (avcodec & such) with the one you just built ?
They are in sfeMovie/deps/ffmpeg-build.


NB : one more info I should make more visible

[Ceylo]

Wiki updated.

[Ceylo]

Hello,

I'm currently working on movie seeking. It's already working quite well, but I have a question for you.

Movies are in general composed of key frames (containing a full image) and progressive images (containing only the changes from the previous frames). The interval between two key frames can be of a few seconds. Also note that when seeking to a non key (ie. progressive) frame, you'll see artifacts as the image is incomplete.

Thus I would like to know, among the following possibilities, which one you prefer :
- use key images : produces perfect images but the reached position may not be the exact one you wanted, instant seeking
- use any image : may produce incomplete images until a key frame is reached but the reached position is the one you wanted, instant seeking
- use a more complex algorithm that seek to the closest previous key frame and then load the next frames as fast as possible until the wanted position is reached. This produces perfect images and the reached position is the one you wanted, but it takes some time (usually less than one second, but it's quite noticeable)
- let the user choose which method to use among the previous ones

So what's your thought about it?

Ceylo

[Nexus]

I'd prefer exact images, because one might also use the seeking feature for previews/screenshots or the like. And I'd start with the expensive algorithm, while you can still add a default parameter in the future.

[Ceylo]

I'd prefer exact images, because one might also use the seeking feature for previews/screenshots or the like. And I'd start with the expensive algorithm, while you can still add a default parameter in the future.

Ok I understand. It's noted.

Laurent has answered on the French forum too. And he said the user should be able to choose between any of these three methods. But I'm actually trying to figure out in which cases each method would be useful.

- approximative perfect images : the use case you said but on slow computers
- incomplete images : I saw it was used in the Kdenlive video editor. But I don't really know why they didn't use the 3rd method. In order to do faster and less CPU expensive seeking? But I don't expect people to do video editing on slow computers so...
- expensive method : in common movie players and your use case

If someone had needs for the instant seeking with incomplete images, it'd be great to tell his/her use case and reasons here .

[Laurent]

You can also use the approach where you only implement what you personally find relevant, and then wait for users feedback to decide whether you must implement other methods or not.

[Ceylo]

You can also use the approach where you only implement what you personally find relevant, and then wait for users feedback to decide whether you must implement other methods or not.

Ok. I think I'll rather do this, and just do the expensive algorithm for now, as Nexus said. This is also the one that seems the most relevant to me.

Thanks for your feedback!

[N1ghtly]

Very cool library man!
I'll use this for my cutscenes

[Ceylo]

Hello N1ghtly!

I'm really pleased to know it'll be useful to you

[aNewHobby]

dose this have the abilities to use masks, either as a black and white video that plays at the same time acting as a mask or a embed channel of some kind. I know quicklime can embed a alpha channel.. I am sure there are other formates as well that can.

I'm using SFML to make a small 2D project and was wondering what options there are for playing videos at exact pixel coordinates. So say your game window is 1280x720 and you have a few videos one is say 100x100 pixels to make your still image background look like the fountain is running... stuff like that.

All (heh I say this like it would be nothing) would be to be able to loop seamlessly and just play from an exact pixel location.. either have an alpha channel or just overlay ontop of it a 2d bitmap masking out the parts you do not want.. that might be easier as you wouldn't need a video alpha but could get near the same results in most cases (unless you wanted something to move behind teh video.. scene design could make this not needed i guess.