[MPlayer-users] QT Cinepak Decoding

[Arpi]

Hi,

> > you only have to call your codec from dec_audio.c or dec_video.c.
> > the only thing you have to implement is init and decode frame functions,
> > and optinally sync and skip frame for seeking. it's very easy.
> 
> 	Okay, I just took a brief tour through the code and I see where I
> would drop in the new init() and decode() routines. I'm guessing that I
> would also need to add VFM_CVID to the codebase and also do some other
> type of initialization so that the switch variable gets set to VFM_CVID in
> the first place, right?

yes.
you should add VFM_CVID define to codec-cfg.h and "cvid" (codec name) at
~ codec-cfg.c:227

to use this codec, create a new entry at codecs.conf containing codec
parameters (fourcc, output formats, name, status etc). "driver" should
be the codec name in codec-cfg.c.
"dll" and others are optinal, it's passed to codec to select sub-codec if any.

> > the preferred output of video codecs is YV12 planes (provide 3 char* pointer
> > to Y,U,V planes and bytes_per_line values of the 3 planes) and 16-bit
> > mono/stereo of audio codecs, but any other formats are accepted.
> 
> 	Sounds simple enough, though Cinepak uses a "simplified" YUV
> format, which is laid out like YV12, only entirely integer-based so that
> conversion to RGB space is done completely with simple add/subtract and
> bit shifts. But I think it's okay to output that into a YV12 space. Then
my xanim codec wrapper catches YV12 pixel drawing calls from xa's cvid
codec, so i think it really uses YV12.

YV12 is preferred, because
- hardware colorspace and scaling support (most hw supports only YV12 and
  YUY2 color spaces)
- libvo has fast mmx yv12->rgb/bgr 15/16/24/32 converters, so it's easier
  and faster than doing it in C per-pixel in every codec.
- there is very fast high-quality software scaler for yv12
- there are various postprocessing filters for YV12
- under-development encoding feature also requires yv12, as most new-wave
  codec (mpeg 1/2/4 divx etc) requires it as input, so we can avoid
  double yuv->rgb and rgb->yv12 conversion and its quality loss

> there's Sorenson; it apparently uses YVU9. How does that fit into the
> existing color spaces?

YVU9 is Y 4x4 U 1x1 V 1x1, used by Indeo codecs too. It's not a problem,
I can either add new IMGFMT_YVU9 (is there any video card supporting it by
hw?) or convert it to rgb or YV12. swscaler can be extended to handle it
without conversion.

btw currently rgb/bgr 15,16,24,32, planar YUV 4:2:0 (YV12,IYUV==I42) and
packed YUV 4:2:2 (YUY2,YUYV etc) are supported.

> 	BTW, as a warmup, we should implement Microsoft's Video-1 (fourcc
> of 'CRAM' or 'WHAM', outputs RGB555 data). It's exceptionally simple and I
good idea - we have only win32 vfw dll for cram, but it's very buggy and
limited.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu