Print

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

[Kreso]

I'm thinking about resuming development of the Theora Plugin. Curently it works fine, but has performance issues, sound manager integration problems, not sure about seeking etc.

Sure, Theora codec might not be the fastest one out there, but its open-source, free and multi-platform, which makes it the perfect choice for most Ogre3D users.

Does anyone want to join in? :)


Here are some feature propoasals that I've come up with:

1) transfer YUV -> RGB conversion to a pixel shader, copying the raw YUV data to a texture, fallback-ing to an optimized C++ function
2) precaching frames (dunnno if this is possible with theora): rendering eg. 8 frames in advance and storing them in either a volume texture or 8 seperate textures
3) updating the demos
4) SVN: the new development would continue in another branch as not to break the current trunk (people are still using theora plugin as it is) and would merge it back to the trunk when it becomes reasonably stable.
5) I suggest moving the forum to OgreAddons forums
6) and some sort of a bug tracker (either sourceforge' or smtg else)

Also, I would like you to tell me what you would like to see in the new plugin, what doesn't work for you etc :)

[renegadeandy]

I am very happy you have deicded to continue this plugin project - its important to my application!

The main things i would like to see is:

Performance optimisation for high quality videos - thats the biggy.

I think another thing which is definately needed is a wiki etc for the project - I could write a lot on this wiki to help out - however in actual developmenet of the plugin I wont be so much use!

[Kreso]

Yes, indeed. I'm playing 720x450 sized movies and they are sloooow (unless played on multi-core machines, of course

I was thinking about setting up wiki pages on ogre3d's wiki.

[Kreso]

Here's the initial wiki article:

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

[renegadeandy]

720x450 ... is that 720p or am i getting wayy confused.

I had huge difficulty getting the plugin compiled so will probably try help out people with problems too!!!

I think again optimisation for very high quality videos is the next step for this plugin!

What you planning on doing first?

Andy

[pjcast]

Sounds good. But, why not leave discussion here?

Anyway, my main advice would to first compare the decoding speeds of libtheora, ffmpeg, and gstreamer for the theora codec. I think the ffmpeg decoder of theora (for example) is probably x2 faster. Also, caching frames is possible... but sure you would want to cache to ogre texture, as blitting is slowest op. Might as well just prepare a few decoded buffers to memory.

[Kreso]

Dunno, TheoraVideo is in OgreAddons SVN, it seems fitting to centralise on those forums?

@pjcast - that is a good idea, a benchmark of current plugins showing various videos. Also, we could benchmark how much does each part of theora plugin take (theora grab,yuv convert, blit to texture)

@pjcast - lol, good point, cache to a local buffer

@renegadeandy - first, I have to familiarize myself with the code, do those benchmarks and maby do some work on the demos to have a good testing ground. My priority is optimizing the rendering speed, eg. the time it takes to get a frame from theora to a texture.

[pjcast]

One other thought, is that a new plugin (based off of old) would not exactly need to be a Ogre::ExternalTexture source type of plugin. That was really made to tie it in with amterial parsing. it could, and would probably simplify use, be beneficial to make it a utility type of library/dll with simplified methods. Though, depends on how close you want to follow existing usage.

[Kreso]

I'm not sure what you mean, can you clarify a bit more? which benefits would that bring (other then simplying use);

[pjcast]

Some benefits:
* More compact, since it doesn't have to follow the interface of the texture source plugin
* Easier to use - a bit more clear in methods
* Possibly easier to developer to better handle audio/video sync issues, since you would not longer have to worry about exposed Ogre interfaces of texture source plugin...

Anyway, to really use it, you have to cast the generic texture source (in most uses) from Ogre to the TheoraVideoPlugin anyway.. So, you kind of lose the generic ogre interface anyway

[Kreso]

I dunno, I'll know when I figure out how it all works.

I have a question:

why are ptypes used? Ogre uses stl AFAIK, isn't ptypes just aditional overhead?

[pjcast]

ptypes is used for threading. Of course, this can be replaced with any thing (ie boost::threaads) or nothing, and just use posix threads and a small wrapper.

[Kreso]

I see

so, as far as I understand, the plugin launches another thread and renders frames. once a frame is ready, it is blited onto a texture in the main thread?

I was thinking about your proposal to dump the ExternalTextureSource model, but for now, I will continue on that model and see what to do from there.

[renegadeandy]

Kreso - I am happy to help you test whatever changes to make - add me on msn :

renegadeandy@hotmail.com

or what do you use?

[pjcast]

Each movie texture has it's own decoding thread. The app is responsible for calling blitFrameCheck to see if one frame is ready, which then causes it to be copied to Ogre texture in the app's main thread.