[MPlayer-dev-eng] Native codecs from libavcodecs

[Roberto Togni]

On 2003.10.05 23:43, Arpi wrote:
> Hi,
> 
> > Hi all!
[...]
> 
> but please be sure that the lavc version of codecs (esp. ones  
> "ported"
> by
> melanson) are good enough, i mean in colorspaces support,
> directrender,
> etc. than the original.
Ok. I'm almost done getting conditional replenishmenst (update only)  
frame support in libavcodec. I'll try to implement draw_horiz_band  
where possible, but that isn't supported even by current MPlayer  
implementation of those codecs.

> afair the multiple csp support was finally commited to lavc, but the
> mplayer
> side (vd_ffmpeg) was not yet implemented (i mean get_format() or so).
I'm looking into it. get_format is useful only when a codec can output  
a frame in more than one colorspace.
Most codecs support different colorspaces with the same fourcc: the  
codec will return the right one, and all the available colorspaces will  
be listed in codecs.conf with the "query" flag (just as it's done now).
As for outputting a frame with a colorspace different from the native  
one, i'd like to support only trivial conversions (example: RGB24 to  
RGB32). Now some codecs supports more colorspaces, but i'd like to  
remove all unnecessary colorspace conversion code from the codecs  
(unless native format is non standard). Sometimes this could hurt  
performance a bit (a codec could do fewer conversions), but since we're  
talking abut stuff designed for a 486 class pc (or even less) i think  
it's not a problem.

I'd expecially like to support only RGB8 for all formats with a palette ,  
and avoid RGB15/16->RGB32 conversions.

Still have to decide what to do with <8bpp formats (RGB4 and  
monochrome),

> 
> you know, lavc is not so strong in rgb/bgr formats, there are unclean
> things
> around byteorders and 15 vs 16, and 24 vs 32 bpp formats.
>
Everyting is stored in cpu endianness except 24bit rgb, that have two  
explicit formats RGB24 and BGR24 :(((

> > Audio codecs will come later.
> 
> first lavc should get an usable audio codec api. the current one is
> horrible
> 
> 
> A'rpi / Astral & ESP-team
>
Ciao,
 Roberto