[MPlayer-dev-eng] libmp1e bugreport

David Holm dholm at telia.com
Sat Dec 8 16:59:00 CET 2001


Arpi wrote:

>Hi,
>
>>Ok, I commited some more fixes, could you try again?
>>I haven't changed the malloc.h stuff yet. I'm working on a new lib to 
>>replace libmp1e (hopefully). So I don't want to spend more time than 
>>needed to make libmp1e compile on the used platforms right now...
>>
>
>suggestion for new library API:
>
>it should have only 3 public function:
>
>init  - set resolution, fps, bitrate, mode (I-only, I+P, I+P+B frames) etc
>encode - pass a uncompressed yv12/yuy2 farem and it returns compressed mpeg frame
>uninit - close decoder, free buffers
>
>possible problem: if mp1e support B frames, it requires frame reordering.
>(it needs next PI frame to be able to encode B frames)
>
>so you should either remove B frame support (I think I-only is the fastest
>for realtime stuff, as we don't care of bitrate, just speed. and P/B
>requires I frames decoded and motion comp., so I-only is always the fastest
>mode) or change api a bit, as it may return 0 or more frames at encode()
>
>i suggest restricting this lib to I-frames only (maybe allowing P frames as
>option) to get simplest API (frame reordering will cause lots of problems
>with timestamps and a-v sync) and best speed (and worst bitrate, but who
>cares).
>
>
>A'rpi / Astral & ESP-team
>
>--
>mailto:arpi at thot.banki.hu
>http://esp-team.scene.hu
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>

Yes,
I have already started coding on this new lib and it's API is pretty 
much identical to what you are proposing (funny huh ;).
I think I will have a beta very soon, mpeg is a simple enough format 
when it comes to creating an I-frame only encoder, I want to add support 
for P-frames (at least), but the first version will have I-frames only I 
guess, considering my previous history of wanting to release new stuff 
before it's done ;).
This api will also have a MUCH cleaner way of using SIMD, libmp1e's 
support for simd sucked bigtime (I would also like to try to do some 
optimizations myself before Michael jumps in and rewrites my mess ;)... 
I've wanted to learn how to use simd efficiently for quite a while now 
and I see this as a perfect opportunity.

Don't expect updates to libmp1e other than fixes for compilation issues 
(such as this "I forgot all about freebsd" mess).
The interface will resemble rte a bit perhaps, but that is only because 
I wanted prototypes to be unique. (I'm calling prototypes rtv_<name>)
There is also support for using other formats than MPEG (MPEG1) in the 
lib, in case an upcoming card requires another format we have a 
standardized realtime encoder lib for this.
I'm calling it, librtv (realtime video)... simple enough I hope.

//David Holm




More information about the MPlayer-dev-eng mailing list