[MPlayer-dev-eng] libmp1e bugreport

[David Holm]

David Holm wrote:

> 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
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>

To make it worse the include file is called rtv.h and I also have an 
rtvpriv.h, we'll just say I'm inspired by rte (which is exactly what I 
am, our goals are similar so why not? ;)

//David Holm