[GEM-dev] pix_video again

[Erich Berger]

hi chris/james,

i will see the specific patch/machine on monday, then i can give more
specific info about codec etc.

but just to make it clear for me:
is pix_film unloading the previous film from the memory when a new one is
loaded or does it remain in memory ?

best + thx

erich



---------------------
http://randomseed.org

On Thu, 11 May 2006, james tittle wrote:

> On May 11, 2006, at 1:20 PM, chris clepper wrote:
>> I'm not sure if any of that matters.  I haven't seen any problems with
>> the pix_film object and my testing is up to several million files and
>> many thousands of hours.
>> 
>> At this point problems are likely to be Quicktime issues related to
>> specific codecs.
>
> ...yeh, closer inspection shows that prepareTexture() is only used 
> pix_movie-derivatives, or else is an empty function...and of course I 
> mis-read the "#ifndef", so I was thinking we were double-requesting 
> buffers...however, the cache stuff is real, and a simple fix, but not 
> probably germaine to the problem here...
>
> ...I'll try to set up some testing overnight here, and see if I can see any 
> of this problem...
>
> sigh,
> jamie
>
>> On 5/11/06, james tittle <tigital at mac.com> wrote:
>>> ...hmm, I'm looking at [pix_film] and whaddaya know?  There seems to
>>> be all kinds of stuff going weird with createBuffer(), deleteBuffer
>>> (), and prepareTexture() :-(  First off, pix_film::openMess() has:
>>> 
>>> #ifndef __APPLE__
>>>    createBuffer();
>>>    prepareTexture();
>>> #endif
>>> 
>>> ...this may be a relic/hack from waaaay back?
>>> 
>>> ...but this occurs AFTER pix_film::openMess() calls realOpen(), which
>>> is in pix_filmDarwin.cpp...this may be significant because in
>>> pix_filmDarwin::realOpen() we call the same things (or not) based on
>>> the value of m_colorspace (BGRA or other)...
>>> 
>>> ...also, pix_film::createBuffer() will never cache the buffer because
>>> oldx and oldy aren't member variables AND they're always set to 0, so
>>> we always hit this:
>>> 
>>> if (neededXSize != oldx || neededYSize != oldy)
>>> {
>>> deleteBuffer();
>>> ...
>>> }
>>> 
>>> ...um, and that's as far as I've gotten:  I'll give some of these
>>> ideas a test, but won't have much time until, uh, later...
>>> 
>>> jamie
>>> 
>
>