diff options
Diffstat (limited to 'DOCS/OUTDATED-tech/libmpcodecs.txt')
| -rw-r--r-- | DOCS/OUTDATED-tech/libmpcodecs.txt | 383 |
1 files changed, 0 insertions, 383 deletions
diff --git a/DOCS/OUTDATED-tech/libmpcodecs.txt b/DOCS/OUTDATED-tech/libmpcodecs.txt deleted file mode 100644 index 9b627ced50..0000000000 --- a/DOCS/OUTDATED-tech/libmpcodecs.txt +++ /dev/null @@ -1,383 +0,0 @@ -NOTE: If you want to implement a new native codec, please add it to -libavcodec. libmpcodecs is considered mostly deprecated, except for wrappers -around external libraries and codecs requiring binary support. - -The libMPcodecs API details, hints - by A'rpi -================================== - -See also: colorspaces.txt, codec-devel.txt, dr-methods.txt, codecs.conf.txt - -The VIDEO path: -=============== - - [MPlayer core] - | (1) - ______V______ (2) /~~~~~~~~~~\ (3,4) |~~~~~~| - | | -----> | vd_XXX.c | -------> | vd.c | - | dec_video | \__________/ <-(3a)-- |______| - | | -----, ,.............(3a,4a).....: - ~~~~~~~~~~~~~ (6) V V - /~~~~~~~~\ /~~~~~~~~\ (8) - | vf_X.c | --> | vf_Y.c | ----> vf_vo.c / ve_XXX.c - \________/ \________/ - | ^ - (7) | |~~~~~~| : (7a) - `-> | vf.c |...: - |______| - -Short description of video path: -1. MPlayer/MEncoder core requests the decoding of a compressed video frame: - calls dec_video.c::decode_video(). - -2. decode_video() calls the video codec previously selected in init_video(). - (vd_XXX.c file, where XXX == vfm name, see the 'driver' line of codecs.conf) - -3. The codec should initialize the output device before decoding the first - frame. It may happen in init() or at the middle of the first decode(), see - 3a. It means calling vd.c::mpcodecs_config_vo() with the image dimensions, - and the _preferred_ (meaning: internal, native, best) colorspace. - NOTE: This colorspace may not be equal to the colorspace that is actually - used. It's just a _hint_ for the colorspace matching algorithm and mainly - used as input format of the converter, but _only_ when colorspace - conversion is required, - -3a. Selecting the best output colorspace: - The vd.c::mpcodecs_config_vo() function will go through the outfmt list - defined by the 'out' lines in codecs.conf and query both vd (codec) and - vo (output device/filter/encoder) if the format is supported or not. - - For the vo, it calls the query_format() function of vf_XXX.c or ve_XXX.c. - It should return a set of feature flags, the most important ones for this - stage are: VFCAP_CSP_SUPPORTED (colorspace supported directly or by - conversion) and VFCAP_CSP_SUPPORTED_BY_HW (colorspace supported - WITHOUT any conversion). - - For the vd (codec), control() with VDCTRL_QUERY_FORMAT will be called. - If it does not implement VDCTRL_QUERY_FORMAT, (i.e. answers CONTROL_UNKNOWN - or CONTROL_NA), it is assumed to be CONTROL_TRUE (colorspace supported)! - - So, by default, if the list of supported colorspaces is constant and does - not depend on the actual file/stream header, then it is enough to list the - formats in codecs.conf ('out' field) and not implement VDCTRL_QUERY_FORMAT. - This is the case for most codecs. - - If the supported colorspace list depends on the file being decoded, list - the possible out formats (colorspaces) in codecs.conf and implement the - VDCTRL_QUERY_FORMAT to test the availability of the given colorspace for - the given video file/stream. - - The vd.c core will find the best matching colorspace, depending on the - VFCAP_CSP_SUPPORTED_BY_HW flag (see vfcap.h). If no match can be found, - it will try again with the 'scale' filter inserted between vd and vo. - If this is unsuccessful, it will fail :( - -4. Requesting buffer for the decoded frame: - The codec has to call mpcodecs_get_image() with proper imgtype & imgflag. - It will find the optimal buffering setup (preferred stride, alignment etc) - and return a pointer to the allocated and filled up mpi (mp_image_t*) struct. - The 'imgtype' controls the buffering setup, i.e. STATIC (just one buffer that - 'remembers' its content between frames), TEMP (write-only, full update), - EXPORT (memory allocation is done by the codec, not recommended) and so on. - The 'imgflags' set up the limits for the buffer, i.e. stride limitations, - readability, remembering content etc. See mp_image.h for the short - description. See dr-methods.txt for the explanation of buffer - importing and mpi imgtypes. - - Always try to implement stride support! (stride == bytes per line) - If no stride support, then stride==bytes_per_pixel*image_width. - If you have stride support in your decoder, use the mpi->stride[] value - for the byte_per_line for each plane. - Also take care of other imgflags, like MP_IMGFLAG_PRESERVE and - MP_IMGFLAG_READABLE, MP_IMGFLAG_COMMON_STRIDE and MP_IMGFLAG_COMMON_PLANE! - The file mp_image.h contains flag descriptions in comments, read it! - Ask for help on dev-eng, describing the behavior of your codec, if unsure. - -4.a. buffer allocation, vd.c::mpcodecs_get_image(): - If the requested buffer imgtype!=EXPORT, then vd.c will try to do - direct rendering, i.e. ask the next filter/vo for the buffer allocation. - It's done by calling get_image() of the vf_XXX.c file. - If it was successful, the imgflag MP_IMGFLAG_DIRECT will be set, and one - memcpy() will be saved when passing the data from vd to the next filter/vo. - See dr-methods.txt for details and examples. - -5. Decode the frame, to the mpi structure requested in 4., then return the mpi - to decvideo.c. Return NULL if the decoding failed or skipped the frame. - -6. decvideo.c::decode_video() will now pass the 'mpi' to the next filter (vf_X). - -7. The filter's (vf_X) put_image() then requests a new mpi buffer by calling - vf.c::vf_get_image(). - -7.a. vf.c::vf_get_image() will try to get direct rendering by asking the - next filter to do the buffer allocation (calls vf_Y's get_image()). - If it fails, it will fall back on normal system memory allocation. - -8. When we're past the whole filter chain (multiple filters can be connected, - even the same filter multiple times) then the last, 'leaf' filters will be - called. The only difference between leaf and non-leaf filters is that leaf - filters have to implement the whole filter API. - Currently leaf filters are: vf_vo.c (wrapper over libvo) and ve_XXX.c - (video encoders used by MEncoder). - - -Video Filters -============= - -Video filters are plugin-like code modules implementing the interface -defined in vf.h. - -Basically it means video output manipulation, i.e. these plugins can -modify the image and the image properties (size, colorspace, etc) between -the video decoders (vd.h) and the output layer (libvo or video encoders). - -The actual API is a mixture of the video decoder (vd.h) and libvo -(video_out.h) APIs. - -main differences: -- vf plugins may be "loaded" multiple times, with different parameters - and context - it's new in MPlayer, old APIs weren't reentrant. -- vf plugins don't have to implement all functions - all functions have a - 'fallback' version, so the plugins only override these if wanted. -- Each vf plugin has its own get_image context, and they can interchange - images/buffers using these get_image/put_image calls. - - -The VIDEO FILTER API: -===================== -filename: vf_FILTERNAME.c - -vf_info_t* info; - pointer to the filter description structure: - - const char *info; // description of the filter - const char *name; // short name of the filter, must be FILTERNAME - const char *author; // name and email/URL of the author(s) - const char *comment; // comment, URL to papers describing algorithm etc. - int (*open)(struct vf_instance *vf,char* args); - // pointer to the open() function: - -Sample: - -vf_info_t vf_info_foobar = { - "Universal Foo and Bar filter", - "foobar", - "Ms. Foo Bar", - "based on algorithm described at http://www.foo-bar.org", - open -}; - -The open() function: - - open() is called when the filter is appended/inserted in the filter chain. - It'll receive the handler (vf) and the optional filter parameters as - char* string. Note that encoders (ve_*) and vo wrapper (vf_vo.c) have - non-string arg, but it's specially handled by MPlayer/MEncoder. - - The open() function should fill the vf_instance_t structure with the - implemented functions' pointers (see below). - It can optionally allocate memory for its internal data (vf_priv_t) and - store the pointer in vf->priv. - - The open() function should parse (or at least check syntax of) parameters, - and fail (return 0) on error. - -Sample: - -static int open(vf_instance_t *vf, char* args) -{ - vf->query_format = query_format; - vf->config = config; - vf->put_image = put_image; - // allocate local storage: - vf->priv = malloc(sizeof(struct vf_priv_s)); - vf->priv->w = - vf->priv->h = -1; - if(args) // parse args: - if(sscanf(args, "%d:%d", &vf->priv->w, &vf->priv->h)!=2) return 0; - return 1; -} - -Functions in vf_instance: - -NOTE: All these are optional, their function pointer is either NULL or points -to a default implementation. If you implement them, don't forget to set -vf->FUNCNAME in your open() ! - - int (*query_format)(struct vf_instance *vf, unsigned int fmt); - -The query_format() function is called one or more times before the config(), -to find out the capabilities and/or support status of a given colorspace (fmt). -For the return values, see vfcap.h! -Normally, a filter should return at least VFCAP_CSP_SUPPORTED for all supported -colorspaces it accepts as input, and 0 for the unsupported ones. -If your filter does linear conversion, it should query the next filter, -and merge in its capability flags. Note: You should always ensure that the -next filter will accept at least one of your possible output colorspaces! - -Sample: - -static int query_format(struct vf_instance *vf, unsigned int fmt) -{ - switch(fmt){ - case IMGFMT_YV12: - case IMGFMT_I420: - case IMGFMT_IYUV: - case IMGFMT_422P: - return vf_next_query_format(vf,IMGFMT_YUY2) & (~VFCAP_CSP_SUPPORTED_BY_HW); - } - return 0; -} - -For the more complex case, when you have an N -> M colorspace mapping matrix, -see vf_scale or vf_format for examples. - - - int (*config)(struct vf_instance *vf, - int width, int height, int d_width, int d_height, - unsigned int flags, unsigned int outfmt); - -The config() is called to initialize/configure the filter before using it. -Its parameters are already well-known from libvo: - width, height: size of the coded image - d_width, d_height: wanted display size (usually aspect corrected w/h) - Filters should use width, height as input image dimension, but the - resizing filters (crop, expand, scale, rotate, etc) should update - d_width/d_height (display size) to preserve the correct aspect ratio! - Filters should not rely on d_width, d_height as input parameters, - the only exception is when a filter replaces some libvo functionality - (like -vf scale with -zoom, or OSD rendering with -vf expand). - flags: the "good" old libvo flag set: - 0x01 - force fullscreen (-fs) - 0x02 - allow mode switching (-vm) - 0x04 - allow software scaling (-zoom) - 0x08 - flipping (-flip) - (Usually you don't have to worry about flags, just pass it to next config.) - outfmt: the selected colorspace/pixelformat. You'll receive images in this - format. - -Sample: - -static int config(struct vf_instance *vf, - int width, int height, int d_width, int d_height, - unsigned int flags, unsigned int outfmt) -{ - // use d_width/d_height if not set by the user: - if (vf->priv->w == -1) - vf->priv->w = d_width; - if (vf->priv->h == -1) - vf->priv->h = d_height; - // initialize your filter code - ... - // OK now config the rest of the filter chain, with our output parameters: - return vf_next_config(vf,vf->priv->w,vf->priv->h,d_width,d_height,flags,outfmt); -} - - void (*uninit)(struct vf_instance *vf); - -Okay, uninit() is the simplest, it's called at the end. You can free your -private buffers etc here. - - int (*put_image)(struct vf_instance *vf, mp_image_t *mpi); - -Ah, put_image(). This is the main filter function, it should convert/filter/ -transform the image data from one format/size/color/whatever to another. -Its input parameter is an mpi (mplayer image) structure, see mp_image.h. -Your filter has to request a new image buffer for the output, using the -vf_get_image() function. NOTE: Even if you don't want to modify the image, -just pass it to the next filter, you have to either -- not implement put_image() at all - then it will be skipped -- request a new image with type==EXPORT and copy the pointers -NEVER pass the mpi as-is, it's local to the filters and may cause trouble. - -If you completely copy/transform the image, then you probably want this: - - dmpi = vf_get_image(vf->next,mpi->imgfmt, MP_IMGTYPE_TEMP, - MP_IMGFLAG_ACCEPT_STRIDE, vf->priv->w, vf->priv->h); - -It will allocate a new image and return an mp_image structure filled by -buffer pointers and stride (bytes per line) values, in size of vf->priv->w -times vf->priv->h. If your filter cannot handle stride, then leave out -MP_IMGFLAG_ACCEPT_STRIDE. Note that you can do this, but it isn't recommended, -the whole video path is designed to use strides to get optimal throughput. -If your filter allocates output image buffers, then use MP_IMGTYPE_EXPORT -and fill the returned dmpi's planes[], stride[] with your buffer parameters. -Note, it is not recommended (no direct rendering), so if you can, use -vf_get_image() for buffer allocation! -For other image types and flags see mp_image.h, it has comments. -If you are unsure, feel free to ask on the dev-eng mailing list. Please -describe the behavior of your filter, and its limitations, so we can -suggest the optimal buffer type + flags for your code. - -Now that you have the input (mpi) and output (dmpi) buffers, you can do -the conversion. If you didn't notice yet, mp_image has some useful info -fields. They may help you a lot creating if() or for() structures: - flags: MP_IMGFLAG_PLANAR, MP_IMGFLAG_YUV, MP_IMGFLAG_SWAPPED - helps you to handle various pixel formats in single code. - bpp: bits per pixel - WARNING! It's number of bits _allocated_ to store a pixel, - it is not the number of bits actually used to keep colors! - So it's 16 for both 15 and 16 bit color depth, and is 32 for - 32bpp (actually 24 bit color depth) mode! - It's 1 for 1bpp, 9 for YVU9, and is 12 for YV12 mode. Get it? - For planar formats, you also have chroma_width, chroma_height and - chroma_x_shift, chroma_y_shift too, they specify the chroma subsampling - for YUV formats: - chroma_width = luma_width >> chroma_x_shift; - chroma_height = luma_height >> chroma_y_shift; - -If you're done, call the rest of the filter chain to process your output -image: - return vf_next_put_image(vf,dmpi); - - -Ok, the rest is for advanced functionality only: - - int (*control)(struct vf_instance *vf, int request, void* data); - -You can control the filter at runtime from MPlayer/MEncoder/dec_video: -#define VFCTRL_QUERY_MAX_PP_LEVEL 4 /* test for postprocessing support (max level) */ -#define VFCTRL_SET_PP_LEVEL 5 /* set postprocessing level */ -#define VFCTRL_SET_EQUALIZER 6 /* set color options (brightness,contrast etc) */ -#define VFCTRL_GET_EQUALIZER 8 /* get color options (brightness,contrast etc) */ -#define VFCTRL_DRAW_OSD 7 - - - void (*get_image)(struct vf_instance *vf, mp_image_t *mpi); - -This is for direct rendering support, works the same way as in libvo drivers. -It makes in-place pixel modifications possible. -If you implement it (vf->get_image!=NULL), then it will be called to do the -buffer allocation. You SHOULD check the buffer restrictions (stride, type, -readability etc) and if everything is OK, then allocate the requested buffer -using the vf_get_image() function and copying the buffer pointers. - -NOTE: You HAVE TO save the dmpi pointer, as you'll need it in put_image() -later on. It is not guaranteed that you'll get the same mpi for put_image() as -in get_image() (think of out-of-order decoding, get_image is called in decoding -order, while put_image is called for display) so the only safe place to save -it is in the mpi struct itself: mpi->priv=(void*)dmpi; - - - void (*draw_slice)(struct vf_instance *vf, unsigned char** src, - int* stride, int w,int h, int x, int y); - -It's the good old draw_slice callback, already known from libvo. -If your filter can operate on partial images, you can implement this one -to improve performance (cache utilization). - -Ah, and there are two sets of capability/requirement flags (vfcap.h type) -in vf_instance_t, used by the default query_format() implementation, and by -the automatic colorspace/stride matching code (vf_next_config()). - - // caps: - unsigned int default_caps; // used by default query_format() - unsigned int default_reqs; // used by default config() - -BTW, you should avoid using global or static variables to store filter instance -specific stuff, as filters might be used multiple times and in the future even -multiple streams might be possible. - - -The AUDIO path: -=============== -TODO!!! |