[XviD-devel] api 3.0 branch

[Michael Militzer]

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?

?? Why should we want to do this. Sure api-dev-3 is maybe not as clean as
CVS head, but that's the reason why we branched off. I don't quite see why
it should be desirable to clean dev-api-3 (or do a new branch) and
reimplement b-frames again. This could take long, also the b-frame
implementation isn't really finished yet (SysKin's variable B-frames have to
be add etc.), so we are in danger that the reimplementation becomes messy
again. I'd be in favour to concentrate on dev-api-3 branch now, finish
b-frames, add SysKin ME (if it's not already there, but I don't remember
having read an announcement...) and add qpel. These steps should have
highest priority now. After those features have been added and also have
been somehow finished, we could concentrate on clean-ups and on making the
dev-api-3 code look "nice".

I also think that we shouldn't spend that much time on CVS head: I thought
we agreed that not much should be changed anyway for CVS head. Sure lots of
things are not "nice" and we have reentrancy problems. But: The CVS head
code has worked well for 99% of all users and has been tested for a long
time. Therefore it's near to call it stable. If we change too much the
danger is that new bugs are introduced (which already happened) and that we
can't really say anymore that CVS head is stable (because the changes
haven't been really well tested). Moreover CVS head will be replaced by API
3 code sooner or later (hopefully soon) and will be obsolete then. Therefore
I think it would be better to mainly concentrate on the dev-api-3 branch and
do changes there: For example the xvidcore.dll (or libxvidcore.dll) idea for
windows is good. But the current xvid.dll structure has been thouroughly
tested and works well for a long time now. Changing this may introduce new
problems whereas the change is not really needed (it's just nicer).
Therefore do it for dev-api-3.

Also it's true that it would be nicer if the huge vlc runtime tables would
be const, but obviously the speed gain from this wouldn't be really
noticeable but instead the const introduces problems on some platforms
(windows + MSVC). So I think it wasn't really needed to change this for CVS
head (well, those users simply have to live with worse memory
management...), whereas I of course have to admit that noone could have
known that adding a static works with gcc and makes MSVC code crash...
Additionally, dev-api-3 will sooner or later include Skal's smaller vlc
tables anyway, so the insanely huge tables will be gone then as well as this
whole ugly static problem...

> 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.

cleaning copyrights and other minor changes are also not important currently
for dev-api-3. A lot will change anyway (I have rewritten the whole
interpolate8x8.c code, including the whole mmx code and wide parts of the
xmm and 3dnow code for qpel...). So copyright things should be done at last
if everything else is finished (also the headers have to be changed...).

> > 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.

let's also include API 3.0 draft into dev-api-3 branch asap. It could be
tested and further improved then...

> > 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.

agreed

bye,
Michael