UCI misc
Steve Lhomme <[email protected]> Sun, 22 Sep 2002 16:07:47 +0200
| Newsgroups | gmane.comp.video.mcf.general |
|---|---|
| Message-ID | <[email protected]> |
Here are the questions that pop in my mind while I read the spec on
http://uci.sourceforge.net/
- What is the difference between the API and the CPI (Codec Programming
Interface)
- You say you don't handle filters and stuff like that, but I guess you
allow combination of 1 input type to 1 output type, the could be in some
case the same. Is that correct ?
- Can you allow an input of 1 type and 2 output of different types
(audio + video), like for decoding DV data; unless you see DV data as a
container, stored in a container (AVI, MCF, whatever)
- I also see that you plan to use the BSD license. Is it subject to
change ? We have chosen LGPL on libmcf for different reasons. One is
that we want to avoid public forks of the library. The viral aspect of
LGPL being a good thing too.
- in this example CODEC_PARAMDEF_INT_RANGE("bitrate", "Output bitrate
(kbps)", 1800, 100, 64000), you say "a bitrate value (in kbps), which
must be between 100 and 64000, and defaults to 1800". But adding a step
value could help (like every 10).
- "codec_type_name.extension", where type indicates the type of codec
(currently defined types are "audio" and "video")
You could at least add AV (see DV), effect, title, subtitle, control
(MCF specific). See the enum CodecType on
http://mcf.sourceforge.net/transor/transor-API.html
- for video encode_supported_formats must output RGB or YUV only. But it
could decode to... MPEG (could be usefull for DV and then chaining
codecs, even though I don't know if MPEG is used in DV). And no mention
of audio :'(
- according to the codec_type parameter, I assume this is very
monolithic. ie you couldn't have audio on input and output video.
- in the *codec_format_info* structure, what is the *id* field for ?
- in the same structure, fourcc might only be usefull for VfW video
codec and QT codec. Not at all for audio. For ACM, it is a 16 bit ID.
Maybe this should be a union depending on video or audio.
- The binary data that the codec output (on encoding) or input (on
decoding) from the container, it depends on the input/output used (VfW,
DShow, MCF, whatever). The current CPI is not clear on this (or maybe
doesn't support this).
- on a programming note, as you know I like C++. Especially because you
use SO many pointers -> the way to allow bugs.
- There is no timecode mention on encode or decode. I strongly advise
you that there should be one ! This is the basis for good containers.
- Nor there is a mention of latency of the codec (as found on BeOS)
which can help the system to better handle buffers and minimize latency.
- On the same level, there is no way of choosing between 2 codec that
both handle MPEG4 decoding. (like a priority number)
- "# Transparently perform some common data conversions to allow various
applications to interact with various codecs easily" I suggest not to
use anything transparent. Or at least not customisable. Because it can
be good to have different transformation "filters" that would be either
fast or best quality (for example). Chaining of codecs (you can call
that filters if you prefer) is better and more flexible.
BTW, this API (ie not the CPI) is something good that we haven't worked
yet on Transors. Good start :)
PS: if you're not subscribed to the MCF-General mailing list, I invite
you to do so (or use the GMANE newsgroup facility)
PS: I prefer to use the web board of CoreCodec for discussion (even
though email is OK) Because I can access it from work (not the rest). So
if you're all OK, we could switch the discussion there.
PS: Your web pages seem to be very poor HTML : no <html>, no <body>, no
<head>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf