Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kreso]

I see.

What are the primary usage scenarios of videos in 3d apps? other then playing a fullscreen video sequence, I see little other use.

The only thing that comes to mind other then playing videos is using a small video file for eg, a tv in a game, or a longer animation that would take too much space if put in a volume texture or seperate textures.

oh, and anoter question, this is probably doable but I have to ask: can I load an ogg file in ram and stream it from there (to avoid disk swapping?)

My long term plan is to integrate the plugin with ogre as much as possible, so one can specify movie parameters in a eg. material script, and a couple of good options come to mind

[pjcast]

Usage can vary between project to project. The plugin should be able to deocde / sync / and seek would be nice to work 100%. Than, it would fit with any usage.

As for loading an Ogg from memory. Not sure what you are asking. The plugin already uses Ogre's data stream classes to get data where ever Ogre got it from (memory, zip file, etc).

[Kreso]

I see

sorry for the 'stupid' questions, I'm still working out how the whole thing works, so please bear with me.
But the good thing to come from these questions is documentation. I'm documenting every bit of information relevant to usage and development of this plugin on the wiki.
I believe that good documentation is a foundation for a successful project

[Ice]

That's great! I was planning to do the same thing and I like your idea   
I would be happy to help you in testing it on Windows XP and x86_64 Gentoo Linux. BTW, I wrote some CMake scripts to build current version of plugin (tested only with gcc on linux and mingw on windows, but it should be possible to generate VC solution files with cmake). You can download it here: http://berks.narod.ru/ogre-theora_with_cmake.tar.gz

[Kreso]

great to hear it I should have a presentable version in a week or two (hopefully) so there'll be lots of testing;

at the moment I'll work on windows, but I plan to switch to either cmake or scons later on.

[pjcast]

I actually think something like cmake/scons is overkill - especially for a small project - since maintaining 3 build systems (Win32/Linux/Mac) is really not so bad but, to each their own. I just hate having to include separate downloads, separate build steps, etc just to get a project file Much easier for me to get a new project and go right to the VC solution file, or xcode project file, etc.

[Ice]

Yes, you are right. Good example is EditableTerrainManager (http://www.oddbeat.de/wiki/etm). Is uses simple makefiles, VC solution and CodeBlocks project.

[OvermindDL1]

I personally like something where I can just drop the h/hpp/c/cpp files directly in my app and just compile, no weird configure muddling, no defines that need to be set, just drop-and-go.

[Kreso]

yes, I agree, for a small project like this, it's really overkill.

anyway, I was planning to do some benchmarking today, so stay tuned on http://www.ogre3d.org/wiki/index.php/TheoraVideoPlugin if you're interested

[Kreso]

in TheoraVideoDriver.cpp: function decodeYtoTexture

What does it do? Why would anyone want to decode Y to a texture's alpha channel?

[pjcast]

Just some experimentation... Like, masking one color in a movie (such as black or blue) as an alpha rejection color. So you could, for instance, make an animated character from a movie and only show the non-alpha areas (since, video formats generally carry no real alpha data).

[Kreso]

I see, good idea, as some sort of color key. Only in a lossy encoded movie, one would have to specify a range of RGB values to mark as transparent;

Although on the other hand, one can do that in a shader;

[pjcast]

Yup and yup The plan was always to do the YUV decoding in shaders. As well as the alpha function. And, of course the range idea is needed just because of the lossyness of compression. Just was never implemented.

[Kreso]

Well, I've done a fair bit of hacking and am already quite familliar with the code, I have to congratulate you on very well written and understandable code

I just finished writing the benchmark code and will make the analysis on the wiki tonight.
So far I can draw a few conclusions (tested on a 2year old laptop, single core)

1)  it takes about 25 miliseconds on average to render a frame (decode, yuv convert and blit), which gives a potential of decoding about 50 frames per second
2) some frames take more time then others
3) precaching a few frames in advance could solve most frame dropping problems
4) transfering YUV conversion code to a shader can significantly boost performance.


I have a few ideas that I'm going to implement and could use your opinion:

1) all your member variables begin with 'm_' and ogre's begin with 'm', which makes the coding convention inconsistent. I'll rename all of them to 'm' convention.

[OvermindDL1]

"m_" is more consistent in the world (blame Microsoft for that convention, but I like it...).  The first place I saw just "m" used was in Ogre actually, thought it was weird...