[MPlayer-dev-eng] [PATCH] realmedia fixes

Balatoni Denes pnis at coder.hu
Mon Feb 10 23:39:41 CET 2003


Hi!

> > So here is a new patch. Take a look I don't claim it is perfect or
> > beutifull,
>
> but at least looks much better than the previous try :)
hehe:)

> btw feel free to ignore my mails, since i dropped mainatinance of the devel
> tree, i'm interested only in critical fixes only for 0.90...
btw I would say it is good for 0.90 - more rm files work with this than before
IMHO (that for(;;) part is a trivial fix for sure)

> > +static int calcts(int kf, int ts, int error){
> > +    int tmp=kf;
> > +    tmp+=error;
> > +    tmp+=ts&(~0x1fff);	// combine with packet timestamp
> > +    if(tmp<ts-4096) tmp+=8192; else // workaround wrap-around problems
> > +    if(tmp>ts+4096) tmp-=8192;
> > +    return tmp;
> > +}
>
> i think this +error causes the discontuinity for you.
> at least the real timestamps seems to be similar to the mpeg4 ones (see
> Michael's mail about them, maybe at ffmpeg-devel i don't remember).
> there is an inaccurate timestamp coded at demuxer level (for each packet)
> and there is an accurate one inside the video packet headers but it's just
> a few bits so it wraprs around quite often. you have to combine them (it
> seems you understood that part since your last patch :)) and at least for
yes I realized the reason of all that after some looking :) it's nice you
could rev.engineer that too

but in this case I have found that the stream timestamp is always accurate
to a certain precission, and it seems at times stream timestamp=frame 
timestamp - well at least it should be. So on those occasions when they 
should be equal (imho) the two are synced. And it works, the video jumps 
ahead 2 secs, but the video timestamp keeps monotoniously increasing with a 
fixed amount and when a-v sync gets to 0 the movie is playing fine for these 
few movies at least (and with -mc 5 nothing can be noticed).


> > +	&& (s[0]!=0x74) && (s[0]!=0x73) && (s[0]!=0x72) && (s[0]!=0x71) &&
> > (s[0]!=0x70)
> > +	&& (s[0]!=0x75) && (s[0]!=0x76) && (s[0]!=0x77)) ){
>
> wtf? i can't believe that this is the simplest method ...
> you should find that 2-3 bits which does matter and mask out the rest.
:] it is not the nicest, but I looked into the streams and found these values.
It will take more time to clean it up and make it nice.

So imho this is just a bugfix for 0.90 - and if needed I will clean that long 
if up. But that is entirely up to you/other developers.

>
> A'rpi / Astral & ESP-team

bye
Denes




More information about the MPlayer-dev-eng mailing list