[MPlayer-dev-eng] [PATCH] Realplayer codec support

[Florian Schneider]

Arpi wrote:
> Hi,
> 
> 
>>>I have put the codecs and an example real medai file into
>>
> 
>>but, are you sure your demuxer extensions are working and complete?
>>the sample file you uploaded plays buggy, but i don't think it's a
> 
> 
> and yes, i was wrong...
> 
> now, after several hours of debugging, i have some news.
> 
> custommessage calls can be skipped, except the 0x24 (set width/height) one!
> i've patched drv3.c wrapper to ignore all except 0x24 (return 0) and the
> realplayer8 still worked. that 0x24 call require only 2 longs (anyway the
> player sends 4 longs: w,h,w,h)

That's good, I have never tried to reduce the number of calls.


> 
> that hivemessage is not so useless as you wrote.
> it has a single input parameter (0) and fills the array (p1 points to)
> by 0,0x20000000. the player aborts if it is ignored.
> even, if i don't call the hive function of the real code, just emulate it
> (full teh array with 0,0x2000000). so it must do something...

Weird, I have disassembled the code and I've only found read instructions.

> 
> the init function uses exactly 24 bytes. no more, not less.
> (yes your struct is 24 bytes long - so it's ok :))
> 
> i've played with temp arrays, copy data to temp, call real codec function
> and if needed, copy result back. i've filled temp with 0x77 before.
> 
> finally, i'm pretty sure that the decoding problems are related to the
> transin1 structure. my first thought was it's an array of pointers to
> sub-blocks. i can see some relations between the value of
> num_sub_packets_in_block_minus_one and the numbers in transin1.
> 
> transin1[0x845d490]: {0} 0x1 (nil) 0xf90efd85 0x11 (nil) (nil) 0x845d468
[...]
> transin1[0x81e6538]: {0} 0x1 (nil) 0x28 0x19 0x40861700 0x850ec58 0x9480
>            ptr     spib-1 transin [0..6]
> 
> but those values don't seem to be pointers, but may be actual compressed
> image data. most codecs produce compressed frames with very similar start
> bytes (micro headers). and, the number of sub-packets may affect this.
> 

Maybe it's some data to reconstruct the non-key frames. I will take a 
look at it this weekend.

Regard

Flo