Re: [Libcvd-members] libcvd cvd/videofilebuffer.h cvd/videofilebuffe...

[Edward Rosten]

On Tue, 23 May 2006, Ethan Eade wrote:

> Edward Rosten wrote:
> 
> >>    RawVideoFileBuffer is now a templated class. This allows the
> >>VideoFileBuffer to correctly return frames of type Rgb<byte>.
> >>    
> >>
> >
> >
> >As fas as I knew, the previous system worked with Rgb<byte> frames. Was 
> >this not the case?
> >
> >I would prefer it if the code (of which there is a large amount) is kept 
> >in the .cc file, since RawVideoFileBuffer contains almost no type 
> >dependent code.
> >
> >Essentially, at some point a cast has to happen between ffmpeg's data 
> >(uint_8) and the compile time CVD image type. In the new version, this 
> >happens on line 433 (videofilebuffer.h, version 1.12). The only other 
> >piece of type dependent code is in the allocation of a memory buffer (must 
> >be 3x bigger for Rgb). This could be allocated in VideoFileBiffer 
> >and the data passed as a void pointer, or simply 3x the memory could be 
> >allocated (the old version).
> >  
> >
> My understanding of the problem, from briefly looking at the code with 
> Colin, is that an image constructed as Image<byte> was being destructed 
> as Image<Rgb<byte> >, which is bad (and aborts because of how 
> aligned_mem registers buffers). 

OK, I figured there was some kind of problem, but I didn't know what it 
was.
 
> I suspect the type dependent code can be factored out while still 
> choosing the right destructor; I think the problem is that no one was 
> using this code in whatever configure settings Colin is currently using, 
> so the bug wasn't discovered until now, and Colin needed it to work.

Fair enough. 

So, I'm going to have a punt at rewriting it (here's where darcs would be 
nice, since that checkin could be reverted in one go in my repository, 
rather than picking out versions by hand).

I'm going to try something crazy and check it in as a different branch for 
evaluation. I've never done this before, and I don't know how it works, so 
bear with me...


The branch is:
videofilebuffer_test_23052006

so 

cvs up -r videofilebuffer_test_23052006

should get the right files, except I accidently checked in a slightly 
silly version of thread.cpp 

Unfortuntely, I can't test it. It probably won't compile because of some 
trivial compiler errors.

It's a pain. I can't access the CVS server, and I can't get the old stable
(and known working) releases (they seem to have disappeared). The only
available snapshot won't compile a working library.

Can someone test this and, if it works, merge it back in?

> Since we are already linking against a library, I agree that it's best 
> to keep as much as possible in the library instead of headers.  If it 
> were a mostly-header library, on the other hand... well, I've been known 
> to embrace 45 second compiles.

But not 7 minute compiles... :-)

-Ed