Enabling/Disabling config file

[nfries88]

@nfries88: I don't really understand your explanation... actually, as the image changes every frame, you'll always need to send the new data to the GPU. But well... with a definition of 1280x800 and 30 FPS there are only 120 MB of data sent each second, which is really small compared to the maximum transfer rate (several GB/s).

Unless I am misunderstanding that sf::Image is a wrapper around a GLint that refers to a texture, then the image's pixels are sent to the GPU only during construction and a call to sf::Image::UpdatePixels().
So by creating a separate instance of sf::Image for each frame, you decrease the amount of transfer between CPU and GPU during video play, but increase it while loading.

IE:

Code: [Select]


std::vector<sf::Image> frames;
load_frames(frames);

std::vector<sf::Image>::iterator frame = frames.begin();
sf::Sprite sprite = sf::Sprite((*frame));
while(frame != frames.end())
{
     if(m_Movie->IsUpdated()){
          ++frame;
          sprite((*frame));
     }
     window.Draw(sprite);
     window.Display();
}


or... are you suggesting that transfer time is not the issue?

[Ceylo]

So by creating a separate instance of sf::Image for each frame, you decrease the amount of transfer between CPU and GPU during video play, but increase it while loading.

Oookay, I understood. But do you really think it's a good idea to load the whole movie pictures at the beginning ?

Well, actually it would indeed avoid later GPU transfers but... if the transfer is already too slow to be done while playing, how long do you think it'll take if you want to do the whole loading BEFORE starting to play ? Logically.. more than the duration of the whole movie :/. By the way, keeping a whole decoded movie (especially with high definition) in the RAM may not be a good idea.

Consider a 1920x1080 definition with 30 FPS (which is the definition being discussed here). 4 bytes per pixels (RGBA pixel format). It would mean almost 15 GB of decoded data stored in your GPU for an only 1 minute long movie (and as the image is also keeped in the RAM, it would mean as much data for it). Still a good idea ?

[nfries88]

So by creating a separate instance of sf::Image for each frame, you decrease the amount of transfer between CPU and GPU during video play, but increase it while loading.

Oookay, I understood. But do you really think it's a good idea to load the whole movie pictures at the beginning ?

Well, actually it would indeed avoid later GPU transfers but... if the transfer is already too slow to be done while playing, how long do you think it'll take if you want to do the whole loading BEFORE starting to play ? Logically.. more than the duration of the whole movie :/. By the way, keeping a whole decoded movie (especially with high definition) in the RAM may not be a good idea.

Consider a 1920x1080 definition with 30 FPS (which is the definition being discussed here). 4 bytes per pixels (RGBA pixel format). It would mean almost 15 GB of decoded data stored in your GPU for an only 1 minute long movie (and as the image is also keeped in the RAM, it would mean as much data for it). Still a good idea ?

Of course not. You'd probably want to cache maybe a second worth of video (that'd be roughly 240MB), and load more as you advance in the video.
Splitting the frame into quarters and loading each quarter separately may also be a good idea, since this will separate loading periods (any apparent lag caused by transfer time is likely due to the fact that it happens all at once -- the human eye sees frames at about 60fps, so if it takes more than 1/60 of a second to convert it to RGBA and upload to the GPU, there may be a "skip" in the video).

[Ceylo]

Actually, I don't really understand the benefit you could get with this.

If the decoding and transfer is fast enough, doing this while playing the movie will work fine. And decoding the video one second earlier will work too, as the movie will never catch up with the decoding.

But if not, it means that decoding is done in more that 1/30 second. Thus even if you load a half second worth of video one second earlier and store the images in a list, the movie will catch up with the decoding a bit latter, but it will, at some time. Whatever you try to do (actually you can consider decoding in several different threads at the same time, but it's another thing).


Anyway, I suggest golgoth to try out the sfe::Movie class and tell us whether it works fine with 1080p definition movies. If it does not, then he may consider having a look at this class (it's a better start point as it already support audio and a few other things), and try to find a way to get better results.

[golgoth]

If the decoding and transfer is fast enough, doing this while playing the movie will work fine. And decoding the video one second earlier will work too, as the movie will never catch up with the decoding.

Unless we can figure out the optimal buffering amount before reaching the end of the movie… but still, I`m not crazy about this idea either.

Anyway, I suggest golgoth to try out the sfe::Movie class and tell us whether it works fine with 1080p definition movies. If it does not, then he may consider having a look at this class (it's a better start point as it already support audio and a few other things), and try to find a way to get better results.

I definitely will and keep you posted on this, hopefully I`ll have better result with your approach.

Thx for all your inputs, greatly appreciated.

[Ceylo]

I've been doing some testing on my school's computers running Windows XP with a movie with a 2048x872 definition (Sintel if you wish to give it a try) and... it absolutely does not play smoothly :mrgreen: .

But what's surprising is that it does not seem to be because of the decoding. Decoding represents about 10% of the time spent in DecodeFrontFrame(), same for conversion from YUV to RGBA, and same for loading the pixels to the GPU, thus I'm looking for the origin of this slowness. More investigation needed.

It mays be because of the locks, and sf::Sprite::Render() seems to take much time too.

[nfries88]

It mays be because of the locks, and sf::Sprite::Render() seems to take much time too.

Windows will use a software implementation of OpenGL included by Microsoft unless you install your graphics card's OpenGL drivers. Since these aren't your personal computer, it may be why sf::Sprite::Render(...) is taking too long.

[golgoth]

Ceylo,

I’m trying to compile your movie player with the latest release on windows 7 and VS 2010. After a few tweaks, I still have one thing I‘m having serious doubt about:

error C2259: 'sfe::Movie' : cannot instantiate abstract class

int main()
{
    sfe::Movie movie;
...

I'm compiling with SFML 2.0 and regarding to Laurent's work, you are trying to instantiate sf::SoundStream whish has abstract functions. Any workaround comes to mind for this?

[Laurent]

I think his code is for SFML 1.6. You have to override OnSeek(float) from sf::SoundStream to make it compile (leave it empty).

[golgoth]

also,

void Render(sf::RenderTarget& target, sf::Renderer& renderer) const {}

needs to be override, hopefully it won’t mess up anything.

[golgoth]

Hi again,

when running Ceylo sfe::Movie I’m getting audio but black frames for the video. Anyone managed to make Ceylo movies work with SFML 2.0?

[golgoth]

Alright, never mind the last post I got it to work... unfortunately, the frame rate with 1080p is unusable… I’m back to square one.

[Ceylo]

As the first beta of SFML for Mac is available on the SVN repository I've been doing some testing and I noticed a surprising point :

sf::Image::UpdatePixels() is much slower that sf::Image::LoadFromPixels(). I don't know whether you got the same results, you should try to keep LoadFromPixels() until I find out what's wrong.

As for the missing video, I had this issue too, the point was only there was no active OpenGL context in the video decoding thread.

So.. still some work to be done .

[Laurent]

sf::Image::UpdatePixels() is much slower that sf::Image::LoadFromPixels()

No way :shock:
Unless you call UpdatePixels multiple times for one call to Draw()? But that shouldn't happen.

[Ceylo]

sf::Image::UpdatePixels() is much slower that sf::Image::LoadFromPixels()

No way :shock:
Unless you call UpdatePixels multiple times for one call to Draw()? But that shouldn't happen.

I didn't say I understand why I get these results, but UpdatePixels() takes approximatively 15% of the execution time whereas LoadFromPixels() takes about 1-2% (vs 8% with SFML 1.x).


Thus that "may" explain why golgoth got such bad results.

Edit: I only do one UpdatePixels().