[XviD-devel] api 3.0 branch

[Christoph Lampert]

Hi,


On Sun, 22 Sep 2002, peter ross wrote:
> it seems the cvs head is now fairly stable, clean and copyrights
> corrected.
> 
> i think it makes sense to branch the cvs head now (even though it lacks
> bframes), apply api3.0 stuff, and THEN manually bring over the bframe
> stuff? i get the feeling api-dev-3 branch is pretty "dirty".

We would need someone who has enough time to spend on this, because it's
not really possible to do that with several people. Or would it? 

Somehow I think the time would be spend better if we clean API-3.0
like we did with cvs head, because then several people can work on
it: Clean copyrights (easy, many files are functionally identical to
head), remove #BFRAME-defines to make it default... 
The "ugliest" part is encoder.c, I think, the rest isn't too bad. 

CVS changelog can help to find other changes. 

I'm afraid if we tried to re-implement bframes on the cvs head, it would
not be finished until several weeks from now and there would be much more
bugs. It's no read fun to re-implement already working features into a
almost identical code background...


> the new api's auto width/height detection code works rather well; ive
> modified the dshow frontend to support the ligos .mp4 splitter. the
> splitter only supports certain .mp4 types, urgh, but its a start.

Is there an API description already? I was waiting for this feature
for xvid-raw decoder.

> this leads me to another question (well its already been mentioned):
> i think its time we implement buffer underrun detection. eg. when the
> decoder runs out of bits when decoding an image/header. it shouldnt be
> too difficult to implement using setjmps,etc.

Yes, would be a good idea.

gruel