Print

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

[Kreso]

well, it's not about whether it's weird or not, TheoraPlugin is in a way, belongs to Ogre, and it makes sense to me that the same coding standards should apply to the plugin as to the rest of the ogre library, however common or uncommon that may be.

[Kreso]

@pjcast: what did you mean by this block of code in TheoraVideoDriver:

Code: [Select]

[b]//Blit bitmap to texture XXX - todo - replace with lock/unlock[/b]
Box b( 0,0,0,m_Width,m_Height,1);
mTexture->getBuffer()->blitFromMemory( m_Image.getPixelBox(), b );

if I understand correctly, you were refering to directly editing pixels in a pointer recieved with lock() thus avoiding extra copying from one buffer to another?


also, a theora question: Y component is full resolution and UV channels are half?

[Kreso]

more questions

in TheoraVideoDriver::attachVideoToTextureUnit, you use mTexture = TextureManager::getSingleton().loadImage();

isn't it better to use createManual() instead? It doesn't really matter, because it doesn't take a lot of time to transfer Ogre::Image data to a texture, but still, the pixels are going to get dynamicly replaced;


I still don't understand how this UV scaling you've mentioned works, from the code in TheoraVideoDriver, a texture with non-power-of-two can be created, so what does that mean, does ogre stretch every frame to power-of-two, does it use the new features in display cards which allow having non powers-of-two textures or something else?
What I'm certain is that it doesn't just create a larger buffer and fill the upper-left portion with texels because my mesh's tex coords range from 0.0 to 1.0;

[pjcast]

Yes, Y is basically a luminescent color field (IIRC) and is full size. You could use this alone and discard UV for a black and white picture I believe. And, UV's are half. Pretty interesting format.

The comment was exactly that, lock the buffer and write to it. not sure if it really is much more faster.

In regards to scaling, the code is in the videodrive, but is commented out. Cannot recall why at the moment.

As for image creation, hard to say.. Ogre API has changed over the years not sure what was there then and here now... What ever you think might be better/faster is fine.

[pjcast]

Oh, forgot about this... Here is something you could try:
http://www.wreckedgames.com/forum/index.php/topic,339.0.html

A stated MMX YUV conversion routine. May or may not work, not sure. Another thing to note, I know you said you did some bench marking, but I didn't see if you compared the libTheora speed with ffmpeg's theora decoder. The nice thing about ffmpeg, is it has very fast pixel conversions and can easily give RGB values. Also, can pre-cache decoded frames and then render to RGB when ready. Anyway, something to think about

[Kreso]

no I haven't tried ffmpeg, might do that sooner or later, but it changes nothing, we can't safely use ffmpeg due to patent problem etc, making theora the good choice for ogre users, and what I've been able to learn so far from benchmarking is that the theora library is very fast (it takes an average of 5-6 miliseconds to decode an fullHD movie frame!), the biggest bottlnecks are tex blitting and yuv conversions and they can be fixed cobmined with frame caching, which isn't hard to do, we have a winning solution

[Kreso]

as promised, I've done some benchmarking with some interesting results

http://www.ogre3d.org/wiki/index.php/TheoraVideoPlugin_Benchmark

[Kreso]

hooray!

I've implemented precaching and running a HD movie (1280x564, luma only) runs smooth as in VLC

[Ice]

Cool! I'll test it today 

[Kreso]

I've just returned YUV->RGB code and that full HD movie still plays perfectly!

excuse my language, but FUCK YEAH!


as for testing, you can find download instructions on the wiki, and make sure to enable vsync to give the video thread as much cpu time as possible.

[Kreso]

also note that audio and seeking are probably broken, I haven't tested it yet.

[Ice]

Very nice 
After replacing GetTickCount with gettimeofday, it compiles ok (why not using ogre's timer instead?). Tested it with 720p and 1080p versions of "Big Buck Bunny" movie. 720p plays fine, no lags, but 1080p is very slow. Though sometimes 1080p is slow even in MPlayer Anyway, excellent progress!
Also tried, without success, to add SoundManager to CEGUI Demo - picture freezes on playback beginning and still no sound.
Sorry, cannot tell you time values because it always shows that decoding time is between 4000 ms and 30000 ms
P.S.: my configuration
Gentoo linux, AMD64 x2 4400+, 2GB RAM, NVIDIA 7600 GS (256MB RAM)

[Kreso]

cool, so it compiles on linux as well
I used GetTictCount cause I couldn't remember the unix equivalent and didn't think of ogre timers.
It's been a while since I used C++ (I switched to python a year ago).

anyway, the future looks good
I'm currently updating ptypes dependency and am going to try and optimize pjcast's YUV-> RGB conversion routine and then make a shader port of it.

as for audio, it is not one of my priorities at the moment, but my goal for this project is to make this plugin 100% functional and fast, on all platforms. I will implement good seeking and sound integration (focusing mainly on OgreAL), which means I'll probably have to rewrite most of the audio code in the plugin.

btw, try revision 13, it doesn't do yuv->rgb conversion, which is rougly about how fast the plugin would work on shader accelerated yuv conversion.

[pjcast]

So, you received a speedup purely from pre-caching a few frames? If I were you, I wouldn't really bother trying to optimize the C code YUV->RGB conversion, but if you are able to I'd be pretty impressed I think you get far better results using SIMD/MMX/etc assembly routines. Or just go directly to shader code now.

[Kreso]

yup, just precaching, who would've thought

I'm not going to optimize a lot, i've just noticed some unnecesary calls and multiplications in your routine I could fix. as for mmx/sse, I have no idea how to use them and if I write that code we get platform dependence or at least, with #ifdef blocks, platform preference.

if an HD movie runs smoothly on the current codebase, there's no need for further optimisations.

shaders are the next step.