[MPlayer-dev-eng] [PATCH] rff - demux_control patch v1.2

Arpi arpi at thot.banki.hu
Sun Nov 10 21:44:01 CET 2002


Hi,

> > yes.
> > (hint: "demuxer API"... do you remember of the beginning of this thread?)
> I remember, I just thought that the template you gave was the final. Is that 
not. it was a 'do it this way, so it will be simple to convert to demuxer
api when it will be available'.

> alread decided how itt will be ? Than I could just as well write this the way 
> it will be used later.

no it is not designed yet. i'm busy with other works, and it won't be doen
before 0.90 anyway.

i have to cleanup libmpdemux first, tehre are strange calls to outside, and
between teh demuxers, some init is done in demuxer.c, some in demux_XX.c
etc. if it;s' done, then i can set up an API which will be enough to pass
all info we need, then i can update each demuxer to us ethis API and at the
same time fix it's design bugs and implement a few control's.
it will take some time.

> > this looks bad
> > - check for nAvgBytesPerSec!=0
> > - priv->numberofframes=1; will confuse control()
> > - length calc will be INACCURATE when numberofframes calced from audio rate
> You are right. Actually I cut&pasted code from demux_avi_seek.
seeking is not always enabled, but your code is not conditional.

> > > -  sh_video->i_bps=((float)sh_video->i_bps/(float)sh_video->v
> > > ideo.dwLength)*sh_video->fps;
> > > +  sh_video->i_bps=((float)sh_video->i_bps/(float)priv->numbe
> > > rofframes)*sh_video->fps;
> >
> > why?
> This is exaclty how it was calculeted before, only that number of frames
> was calculated here (the way you saw it above).
> What is your suggestion?

left it as-is, or explain why does this change needed.
i really hate changes without any reason.
i'm not against fixing bugs, if you can prove/explain it's a bug.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu



More information about the MPlayer-dev-eng mailing list