Re: Theora integration question

Hi Benjamin, thanks for the response.

You are correct, I am abusing the code a bit (a lot?) The design philosophy
of Theora makes perfect sense as is. I am using it in unintended ways.

One example we have used Theora in is a soccer game like you'd see at Chuck
E Cheese. The kids are kicking balls at targets, and the video screen shows
5-10 second clips in reaction. The reaction needs to be almost
instantaneous, so a few milliseconds shouldn't matter, but over 10-20 and I
have some problems.

We also decode to texture memory for use with 3D graphics, which is how we
originally started with Theora. Like a 3D environment with video monitors,
each playing a different movie.

Anyway, I admit freely that I'm abusing the code ;) I also wasn't paying
enough attention to the memory footprint. Our internal system does not use
malloc at all - I have my own heap for that.

So we do have situations where 10 small videos can be playing simultaneously
on different areas on the screen, and also situations where I know there is
just one video, like full-screen, and sharing is OK.

You and Ralph have given me some excellent insight on how to better
integrate Theora into our engine for the future, but as a quick fix, do you
foresee any issues (crash issues!) with allowing the fullscreen movies to
share memory space for ref_frame_data and dct_tokens?


> On Mon, Oct 15, 2012 at 12:52 PM, Engineering <[email protected]>
> wrote:
> > As long as I remember to update the movie at frame 0 before use, I
> > don't see any issues, but am I inviting disaster? Doing this gets me
> > from 1.2GB to 0.2GB of RAM usage.
> 
> It's hard to see what you're doing, but I suspect your thinking here is
> 180 degrees opposite to ours.  We typically expect that users will only
> have a single theora decoder in memory, and that when the user requests
> to change the movie, software that uses libtheora will (1) deallocate
> all Theora-related memory and (2) allocate and initialize a new decoder
> from scratch.  Even at 1080p, the decoder shouldn't require more than
> about 20 MB of memory, and should initialize in milliseconds.
> 
> The only reason I can think of to keep lots of decoders sitting around
> in memory is if you're trying to maintain seek state, so you can pick
> up where you left off in the middle of a movie ... and even then, it's
> probably not the right solution.
>