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

[Arpi]

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 rc4 flamecounter. i have been watching these streams for the last ten 
> hours, so some flaming would really help me release the steam now. maybe not.
:)

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

> +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 mpeg4 it
doesn't mean pts_msb+error+pts_lsb just pts_msb+pts_lsb.
(actually lsb and msb are masked/shifted bitmasks)

> -  if(format==0x30335652){ // RV30 timestamps:
> +  if((format==0x30335652) || (format==0x30345652)){ // RV30/RV40 timestamps:
> +    if (format==0x30345652) kf=4*(((s[1]&15)<<8)+s[2]); 
> +    else if (format==0x30335652) kf=2*(((s[1]&15)<<8)+s[2]); // 12-bit
hmm, nice

> timestamp from frame header
> +    mp_msg(MSGT_DEMUX,MSGL_V,"ts in packet: %d  \n",kf);
> +    if( (!(s[0]&0x8) || s[0]==8 || s[0]==9 || s[0]==0x0a
> +	|| s[0]==0x0b || s[0]==0x0c || s[0]==0x0d || s[0]==0x0e || s[0]==0x0f
> +	|| s[0]==0x48 || s[0]==0x49 || s[0]==0x4a || s[0]==0x4b 
> +	|| s[0]==0x4c || s[0]==0x4d || s[0]==0x4e || s[0]==0x4f)
> +	&& ((s[0]!=0x61) && (s[0]!=0x62) && (s[0]!=0x63) && (s[0]!=0x64) &&
> (s[0]!=0x65) 
> +	&& (s[0]!=0x66) && (s[0]!=0x67) && (s[0]!=0x68) && (s[0]!=0x69) &&
> (s[0]!=0x6a) && (s[0]!=0x6b) 
> +	&& (s[0]!=0x6c) && (s[0]!=0x6d) && (s[0]!=0x6e) && (s[0]!=0x6f)
> +	&& (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.

> +	if ((priv->kf_pts==65536) || s[0]==0 || s[0]==1) {
> +	    priv->kf_pts_error=(timestamp&0x1fff)-kf;
hmm, strange, but may be ok :)

> +    if (priv->v_pts>=kf) mp_msg(MSGT_DEMUX,MSGL_WARN,"Timestamp is not
> monotoniously increasing!\n");

maybe MSGL_WARN is too hard here, it will create popup window with gui :)
_INFO or _V should be enough imho

>      /* parse chunks */
> -    for (i = 1; i < num_of_headers; i++)
> +    for (;;)
>      {
ok


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino