diff options
author | 2010-04-26 18:25:34 +0300 | |
---|---|---|
committer | 2010-04-26 18:25:34 +0300 | |
commit | 7795726e0f8c70edd6ecde7fd2137214af302f4f (patch) | |
tree | 87a087e69a0e2912183736de409676f824fb2248 /DOCS/tech | |
parent | ba3b65b92f3f822fa75b0210b841557f5b20f6d1 (diff) | |
parent | e16f02fe4001f3056b8efd1a099a563569b73f5d (diff) |
Merge svn changes up to r31033
Diffstat (limited to 'DOCS/tech')
-rw-r--r-- | DOCS/tech/codec-devel.txt | 2 | ||||
-rw-r--r-- | DOCS/tech/colorspaces.txt | 6 | ||||
-rw-r--r-- | DOCS/tech/general.txt | 252 | ||||
-rw-r--r-- | DOCS/tech/hwac3.txt | 6 | ||||
-rw-r--r-- | DOCS/tech/libvo.txt | 232 | ||||
-rw-r--r-- | DOCS/tech/mirrors/mirror_howto.txt | 4 | ||||
-rw-r--r-- | DOCS/tech/mpdsf.txt | 26 | ||||
-rw-r--r-- | DOCS/tech/mpsub.sub | 14 | ||||
-rw-r--r-- | DOCS/tech/osd.txt | 54 | ||||
-rw-r--r-- | DOCS/tech/realcodecs/audio-codecs.txt | 28 | ||||
-rw-r--r-- | DOCS/tech/realcodecs/streaming.txt | 4 | ||||
-rw-r--r-- | DOCS/tech/realcodecs/video-codecs.txt | 96 | ||||
-rw-r--r-- | DOCS/tech/slave.txt | 15 | ||||
-rw-r--r-- | DOCS/tech/subcp.txt | 14 | ||||
-rw-r--r-- | DOCS/tech/swscaler_filters.txt | 8 | ||||
-rw-r--r-- | DOCS/tech/swscaler_methods.txt | 64 | ||||
-rw-r--r-- | DOCS/tech/vidix.txt | 78 |
17 files changed, 459 insertions, 444 deletions
diff --git a/DOCS/tech/codec-devel.txt b/DOCS/tech/codec-devel.txt index 765bf1c281..bc968c9499 100644 --- a/DOCS/tech/codec-devel.txt +++ b/DOCS/tech/codec-devel.txt @@ -43,7 +43,7 @@ understand, then you will either need to somehow convert the format to a media file format that the program does understand, or write your own MPlayer file demuxer that can handle the data. Writing a file demuxer is beyond the scope of this document. - Try to obtain media that stresses all possible modes of a + Try to obtain media that stresses all possible modes of a decoder. If an audio codec is known to work with both mono and stereo data, search for sample media of both types. If a video codec is known to work at 7 different bit depths, then, as painful as it may be, do what you diff --git a/DOCS/tech/colorspaces.txt b/DOCS/tech/colorspaces.txt index 291a435f30..eaf9d221e4 100644 --- a/DOCS/tech/colorspaces.txt +++ b/DOCS/tech/colorspaces.txt @@ -66,9 +66,9 @@ The most misunderstood thingie... In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it doesn't matter what the order of the planes in the memory is: for mp_image_t and libvo's draw_slice(): - planes[0] = Y = luminance - planes[1] = U = Cb = blue - planes[2] = V = Cr = red + planes[0] = Y = luminance + planes[1] = U = Cb = blue + planes[2] = V = Cr = red Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC (YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers (not only the first one) normally supports YV12 and I420 (=IYUV), too! diff --git a/DOCS/tech/general.txt b/DOCS/tech/general.txt index 631ee3f9de..4ca3671cf3 100644 --- a/DOCS/tech/general.txt +++ b/DOCS/tech/general.txt @@ -14,64 +14,64 @@ The main modules: 2. demuxer.c: this does the demultiplexing (separating) of the input to audio, video or dvdsub channels, and their reading by buffered packages. - The demuxer.c is basically a framework, which is the same for all the - input formats, and there are parsers for each of them (mpeg-es, - mpeg-ps, avi, avi-ni, asf), these are in the demux_*.c files. - The structure is the demuxer_t. There is only one demuxer. + The demuxer.c is basically a framework, which is the same for all the + input formats, and there are parsers for each of them (mpeg-es, + mpeg-ps, avi, avi-ni, asf), these are in the demux_*.c files. + The structure is the demuxer_t. There is only one demuxer. 2.a. demux_packet_t, that is DP. Contains one chunk (avi) or packet (asf,mpg). They are stored in memory as - in linked list, cause of their different size. + in linked list, cause of their different size. 2.b. demuxer stream, that is DS. Struct: demux_stream_t Every channel (a/v/s) has one. This contains the packets for the stream (see 2.a). For now, there can be 3 for each demuxer : - - audio (d_audio) - - video (d_video) - - DVD subtitle (d_dvdsub) + - audio (d_audio) + - video (d_video) + - DVD subtitle (d_dvdsub) 2.c. stream header. There are 2 types (for now): sh_audio_t and sh_video_t This contains every parameter essential for decoding, such as input/output - buffers, chosen codec, fps, etc. There are each for every stream in - the file. At least one for video, if sound is present then another, - but if there are more, then there'll be one structure for each. - These are filled according to the header (avi/asf), or demux_mpg.c - does it (mpg) if it founds a new stream. If a new stream is found, - the ====> Found audio/video stream: <id> messages is displayed. - - The chosen stream header and its demuxer are connected together - (ds->sh and sh->ds) to simplify the usage. So it's enough to pass the - ds or the sh, depending on the function. - - For example: we have an asf file, 6 streams inside it, 1 audio, 5 - video. During the reading of the header, 6 sh structs are created, 1 - audio and 5 video. When it starts reading the packet, it chooses the - stream for the first found audio & video packet, and sets the sh - pointers of d_audio and d_video according to them. So later it reads - only these streams. Of course the user can force choosing a specific - stream with - -vid and -aid switches. - A good example for this is the DVD, where the english stream is not - always the first, so every VOB has different language :) - That's when we have to use for example the -aid 128 switch. + buffers, chosen codec, fps, etc. There are each for every stream in + the file. At least one for video, if sound is present then another, + but if there are more, then there'll be one structure for each. + These are filled according to the header (avi/asf), or demux_mpg.c + does it (mpg) if it founds a new stream. If a new stream is found, + the ====> Found audio/video stream: <id> messages is displayed. + + The chosen stream header and its demuxer are connected together + (ds->sh and sh->ds) to simplify the usage. So it's enough to pass the + ds or the sh, depending on the function. + + For example: we have an asf file, 6 streams inside it, 1 audio, 5 + video. During the reading of the header, 6 sh structs are created, 1 + audio and 5 video. When it starts reading the packet, it chooses the + stream for the first found audio & video packet, and sets the sh + pointers of d_audio and d_video according to them. So later it reads + only these streams. Of course the user can force choosing a specific + stream with + -vid and -aid switches. + A good example for this is the DVD, where the english stream is not + always the first, so every VOB has different language :) + That's when we have to use for example the -aid 128 switch. Now, how this reading works? - - demuxer.c/demux_read_data() is called, it gets how many bytes, - and where (memory address), would we like to read, and from which + - demuxer.c/demux_read_data() is called, it gets how many bytes, + and where (memory address), would we like to read, and from which DS. The codecs call this. - - this checks if the given DS's buffer contains something, if so, it - reads from there as much as needed. If there isn't enough, it calls - ds_fill_buffer(), which: - - checks if the given DS has buffered packages (DP's), if so, it moves - the oldest to the buffer, and reads on. If the list is empty, it - calls demux_fill_buffer() : - - this calls the parser for the input format, which reads the file - onward, and moves the found packages to their buffers. - Well it we'd like an audio package, but only a bunch of video - packages are available, then sooner or later the: - DEMUXER: Too many (%d in %d bytes) audio packets in the buffer - error shows up. + - this checks if the given DS's buffer contains something, if so, it + reads from there as much as needed. If there isn't enough, it calls + ds_fill_buffer(), which: + - checks if the given DS has buffered packages (DP's), if so, it moves + the oldest to the buffer, and reads on. If the list is empty, it + calls demux_fill_buffer() : + - this calls the parser for the input format, which reads the file + onward, and moves the found packages to their buffers. + Well it we'd like an audio package, but only a bunch of video + packages are available, then sooner or later the: + DEMUXER: Too many (%d in %d bytes) audio packets in the buffer + error shows up. 2.d. video.c: this file/function handle the reading and assembling of the video frames. each call to video_read_frame() should read and return a @@ -101,7 +101,7 @@ Now, go on: The given stream's actual position is in the 'timer' field of the corresponding stream header (sh_audio / sh_video). - The structure of the playing loop : + The structure of the playing loop : while(not EOF) { fill audio buffer (read & decode audio) + increase a_frame read & decode a single video frame + increase v_frame @@ -111,89 +111,89 @@ Now, go on: handle events (keys,lirc etc) -> pause,seek,... } - When playing (a/v), it increases the variables by the duration of the - played a/v. - - with audio this is played bytes / sh_audio->o_bps - Note: i_bps = number of compressed bytes for one second of audio - o_bps = number of uncompressed bytes for one second of audio - (this is = bps*samplerate*channels) - - with video this is usually == 1.0/fps, but I have to note that - fps doesn't really matters at video, for example asf doesn't have that, - instead there is "duration" and it can change per frame. - MPEG2 has "repeat_count" which delays the frame by 1-2.5 ... - Maybe only AVI and MPEG1 has fixed fps. - - So everything works right until the audio and video are in perfect - synchronity, since the audio goes, it gives the timing, and if the - time of a frame passed, the next frame is displayed. - But what if these two aren't synchronized in the input file? - PTS correction kicks in. The input demuxers read the PTS (presentation - timestamp) of the packages, and with it we can see if the streams - are synchronized. Then MPlayer can correct the a_frame, within - a given maximal bounder (see -mc option). The summary of the - corrections can be found in c_total . - - Of course this is not everything, several things suck. - For example the soundcards delay, which has to be corrected by - MPlayer! The audio delay is the sum of all these: - - bytes read since the last timestamp: - t1 = d_audio->pts_bytes/sh_audio->i_bps - - if Win32/ACM then the bytes stored in audio input buffer - t2 = a_in_buffer_len/sh_audio->i_bps - - uncompressed bytes in audio out buffer - t3 = a_buffer_len/sh_audio->o_bps - - not yet played bytes stored in the soundcard's (or DMA's) buffer - t4 = get_audio_delay()/sh_audio->o_bps - - From this we can calculate what PTS we need for the just played - audio, then after we compare this with the video's PTS, we have - the difference! - - Life didn't get simpler with AVI. There's the "official" timing - method, the BPS-based, so the header contains how many compressed - audio bytes or chunks belong to one second of frames. - In the AVI stream header there are 2 important fields, the - dwSampleSize, and dwRate/dwScale pairs: - - If the dwSampleSize is 0, then it's VBR stream, so its bitrate - isn't constant. It means that 1 chunk stores 1 sample, and - dwRate/dwScale gives the chunks/sec value. - - If the dwSampleSize is >0, then it's constant bitrate, and the - time can be measured this way: time = (bytepos/dwSampleSize) / - (dwRate/dwScale) (so the sample's number is divided with the - samplerate). Now the audio can be handled as a stream, which can - be cut to chunks, but can be one chunk also. - - The other method can be used only for interleaved files: from - the order of the chunks, a timestamp (PTS) value can be calculated. - The PTS of the video chunks are simple: chunk number * fps - The audio is the same as the previous video chunk was. - We have to pay attention to the so called "audio preload", that is, - there is a delay between the audio and video streams. This is - usually 0.5-1.0 sec, but can be totally different. - The exact value was measured until now, but now the demux_avi.c - handles it: at the audio chunk after the first video, it calculates - the A/V difference, and take this as a measure for audio preload. + When playing (a/v), it increases the variables by the duration of the + played a/v. + - with audio this is played bytes / sh_audio->o_bps + Note: i_bps = number of compressed bytes for one second of audio + o_bps = number of uncompressed bytes for one second of audio + (this is = bps*samplerate*channels) + - with video this is usually == 1.0/fps, but I have to note that + fps doesn't really matters at video, for example asf doesn't have that, + instead there is "duration" and it can change per frame. + MPEG2 has "repeat_count" which delays the frame by 1-2.5 ... + Maybe only AVI and MPEG1 has fixed fps. + + So everything works right until the audio and video are in perfect + synchronity, since the audio goes, it gives the timing, and if the + time of a frame passed, the next frame is displayed. + But what if these two aren't synchronized in the input file? + PTS correction kicks in. The input demuxers read the PTS (presentation + timestamp) of the packages, and with it we can see if the streams + are synchronized. Then MPlayer can correct the a_frame, within + a given maximal bounder (see -mc option). The summary of the + corrections can be found in c_total . + + Of course this is not everything, several things suck. + For example the soundcards delay, which has to be corrected by + MPlayer! The audio delay is the sum of all these: + - bytes read since the last timestamp: + t1 = d_audio->pts_bytes/sh_audio->i_bps + - if Win32/ACM then the bytes stored in audio input buffer + t2 = a_in_buffer_len/sh_audio->i_bps + - uncompressed bytes in audio out buffer + t3 = a_buffer_len/sh_audio->o_bps + - not yet played bytes stored in the soundcard's (or DMA's) buffer + t4 = get_audio_delay()/sh_audio->o_bps + + From this we can calculate what PTS we need for the just played + audio, then after we compare this with the video's PTS, we have + the difference! + + Life didn't get simpler with AVI. There's the "official" timing + method, the BPS-based, so the header contains how many compressed + audio bytes or chunks belong to one second of frames. + In the AVI stream header there are 2 important fields, the + dwSampleSize, and dwRate/dwScale pairs: + - If the dwSampleSize is 0, then it's VBR stream, so its bitrate + isn't constant. It means that 1 chunk stores 1 sample, and + dwRate/dwScale gives the chunks/sec value. + - If the dwSampleSize is >0, then it's constant bitrate, and the + time can be measured this way: time = (bytepos/dwSampleSize) / + (dwRate/dwScale) (so the sample's number is divided with the + samplerate). Now the audio can be handled as a stream, which can + be cut to chunks, but can be one chunk also. + + The other method can be used only for interleaved files: from + the order of the chunks, a timestamp (PTS) value can be calculated. + The PTS of the video chunks are simple: chunk number * fps + The audio is the same as the previous video chunk was. + We have to pay attention to the so called "audio preload", that is, + there is a delay between the audio and video streams. This is + usually 0.5-1.0 sec, but can be totally different. + The exact value was measured until now, but now the demux_avi.c + handles it: at the audio chunk after the first video, it calculates + the A/V difference, and take this as a measure for audio preload. 3.a. audio playback: - Some words on audio playback: - Not the playing is hard, but: - 1. knowing when to write into the buffer, without blocking - 2. knowing how much was played of what we wrote into - The first is needed for audio decoding, and to keep the buffer - full (so the audio will never skip). And the second is needed for - correct timing, because some soundcards delay even 3-7 seconds, - which can't be forgotten about. - To solve this, the OSS gives several possibilities: - - ioctl(SNDCTL_DSP_GETODELAY): tells how many unplayed bytes are in - the soundcard's buffer -> perfect for timing, but not all drivers - support it :( - - ioctl(SNDCTL_DSP_GETOSPACE): tells how much can we write into the - soundcard's buffer, without blocking. If the driver doesn't - support GETODELAY, we can use this to know how much the delay is. - - select(): should tell if we can write into the buffer without - blocking. Unfortunately it doesn't say how much we could :(( - Also, doesn't/badly works with some drivers. - Only used if none of the above works. + Some words on audio playback: + Not the playing is hard, but: + 1. knowing when to write into the buffer, without blocking + 2. knowing how much was played of what we wrote into + The first is needed for audio decoding, and to keep the buffer + full (so the audio will never skip). And the second is needed for + correct timing, because some soundcards delay even 3-7 seconds, + which can't be forgotten about. + To solve this, the OSS gives several possibilities: + - ioctl(SNDCTL_DSP_GETODELAY): tells how many unplayed bytes are in + the soundcard's buffer -> perfect for timing, but not all drivers + support it :( + - ioctl(SNDCTL_DSP_GETOSPACE): tells how much can we write into the + soundcard's buffer, without blocking. If the driver doesn't + support GETODELAY, we can use this to know how much the delay is. + - select(): should tell if we can write into the buffer without + blocking. Unfortunately it doesn't say how much we could :(( + Also, doesn't/badly works with some drivers. + Only used if none of the above works. 4. Codecs. Consists of libmpcodecs/* and separate files or libs, for example liba52, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib. diff --git a/DOCS/tech/hwac3.txt b/DOCS/tech/hwac3.txt index 9ae5a4f136..25a2c5bc7a 100644 --- a/DOCS/tech/hwac3.txt +++ b/DOCS/tech/hwac3.txt @@ -131,9 +131,9 @@ configure mplayer to use adsp instead of dsp. The samplerate constrain is no big deal here since movies usually are in 48Khz anyway. The configuration in '/etc/modules.conf' is no big deal also: -alias snd-card-0 snd-card-cmipci # insert your card here -alias snd-card-1 snd-pcm-oss # load OSS emulation -options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=2 # do the mapping +alias snd-card-0 snd-card-cmipci # insert your card here +alias snd-card-1 snd-pcm-oss # load OSS emulation +options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=2 # do the mapping This works flawlessly in combination with alsa's native SysVrc-init-script 'alsasound'. Be sure to disable any distribution diff --git a/DOCS/tech/libvo.txt b/DOCS/tech/libvo.txt index 945aeab952..245d29eade 100644 --- a/DOCS/tech/libvo.txt +++ b/DOCS/tech/libvo.txt @@ -17,7 +17,7 @@ approaches closer to the sometimes convoluted way DirectX works. Each vo driver _has_ to implement these: preinit(): - init the video system (to support querying for supported formats) + init the video system (to support querying for supported formats) uninit(): Uninit the whole system, this is on the same "level" as preinit. @@ -26,95 +26,95 @@ Each vo driver _has_ to implement these: Current controls (VOCTRL_QUERY_FORMAT must be implemented, VOCTRL_DRAW_IMAGE, VOCTRL_FULLSCREEN, VOCTRL_UPDATE_SCREENINFO should be implemented): - VOCTRL_QUERY_FORMAT - queries if a given pixelformat is supported. - It also returns various flags decsirbing the capabilities - of the driver with teh given mode. for the flags, see - file vfcaps.h ! - the most important flags, every driver must properly report - these: - 0x1 - supported (with or without conversion) - 0x2 - supported without conversion (define 0x1 too!) - 0x100 - driver/hardware handles timing (blocking) - also SET sw/hw scaling and osd support flags, and flip, - and accept_stride if you implement VOCTRL_DRAW_IMAGE (see bellow) - NOTE: VOCTRL_QUERY_FORMAT may be called _before_ first config() - but is always called between preinit() and uninit() - VOCTRL_GET_IMAGE - libmpcodecs Direct Rendering interface - You need to update mpi (mp_image.h) structure, for example, - look at vo_x11, vo_sdl, vo_xv or mga_common. - VOCTRL_DRAW_IMAGE - replacement for the current draw_slice/draw_frame way of - passing video frames. by implementing SET_IMAGE, you'll get - image in mp_image struct instead of by calling draw_*. - unless you return VO_TRUE for VOCTRL_DRAW_IMAGE call, the - old-style draw_* functils will be called! - Note: draw_slice is still mandatory, for per-slice rendering! - VOCTRL_RESET - reset the video device - This is sent on seeking and similar and is useful if you are - using a device which prebuffers frames that need to flush them - before refilling audio/video buffers. - VOCTRL_PAUSE - VOCTRL_RESUME - VOCTRL_GUISUPPORT - return true only if driver supports co-operation with - MPlayer's GUI (not yet used by GUI) - VOCTRL_SET_EQUALIZER - set the video equalizer to the given values - two arguments are provided: item and value - item is a string, the possible values are (currently): - brightness, contrast, saturation, hue - VOCTRL_GET_EQUALIZER - get the current video equalizer values - two arguments are provided: item and value - item is a string, the possible values are (currently): - brightness, contrast, saturation, hue - VOCTRL_ONTOP - Makes the player window stay-on-top. Only supported (currently) - by drivers which use X11, except SDL, as well as directx and - gl2 under Windows. - VOCTRL_BORDER - Makes the player window borderless. - VOCTRL_FULLSCREEN - Switch from and to fullscreen mode - VOCTRL_GET_PANSCAN - VOCTRL_SET_PANSCAN + VOCTRL_QUERY_FORMAT - queries if a given pixelformat is supported. + It also returns various flags decsirbing the capabilities + of the driver with teh given mode. for the flags, see + file vfcaps.h ! + the most important flags, every driver must properly report + these: + 0x1 - supported (with or without conversion) + 0x2 - supported without conversion (define 0x1 too!) + 0x100 - driver/hardware handles timing (blocking) + also SET sw/hw scaling and osd support flags, and flip, + and accept_stride if you implement VOCTRL_DRAW_IMAGE (see bellow) + NOTE: VOCTRL_QUERY_FORMAT may be called _before_ first config() + but is always called between preinit() and uninit() + VOCTRL_GET_IMAGE + libmpcodecs Direct Rendering interface + You need to update mpi (mp_image.h) structure, for example, + look at vo_x11, vo_sdl, vo_xv or mga_common. + VOCTRL_DRAW_IMAGE + replacement for the current draw_slice/draw_frame way of + passing video frames. by implementing SET_IMAGE, you'll get + image in mp_image struct instead of by calling draw_*. + unless you return VO_TRUE for VOCTRL_DRAW_IMAGE call, the + old-style draw_* functils will be called! + Note: draw_slice is still mandatory, for per-slice rendering! + VOCTRL_RESET - reset the video device + This is sent on seeking and similar and is useful if you are + using a device which prebuffers frames that need to flush them + before refilling audio/video buffers. + VOCTRL_PAUSE + VOCTRL_RESUME + VOCTRL_GUISUPPORT + return true only if driver supports co-operation with + MPlayer's GUI (not yet used by GUI) + VOCTRL_SET_EQUALIZER + set the video equalizer to the given values + two arguments are provided: item and value + item is a string, the possible values are (currently): + brightness, contrast, saturation, hue + VOCTRL_GET_EQUALIZER + get the current video equalizer values + two arguments are provided: item and value + item is a string, the possible values are (currently): + brightness, contrast, saturation, hue + VOCTRL_ONTOP + Makes the player window stay-on-top. Only supported (currently) + by drivers which use X11, except SDL, as well as directx and + gl2 under Windows. + VOCTRL_BORDER + Makes the player window borderless. + VOCTRL_FULLSCREEN + Switch from and to fullscreen mode + VOCTRL_GET_PANSCAN + VOCTRL_SET_PANSCAN Needed to implement pan-scan support ('w' and 'e' keys during - playback in fullscreen mode) - VOCTRL_START_SLICE - Called before the first draw_slice of each frame, useful if - you need to do some set-up work. - VOCTRL_DRAW_EOSD - Required for EOSD (ASS subtitle) support. Provides all - information necessary to draw the EOSD for the current video - frame. - VOCTRL_GET_EOSD_RES - Required for EOSD (ASS subtitle) support. Informs the ASS - renderer about the properties of the drawing area (size, - borders). - VOCTRL_SET_DEINTERLACE - VOCTRL_GET_DEINTERLACE - Get or set deinterlacing status for VOs that support some kind - of deinterlacing. - VOCTRL_UPDATE_SCREENINFO - Should set the xinerama_x, xinerama_y, vo_screenwidth and - vo_screenheight appropriately for the currently used - monitor and -xineramascreen option. - Usually should simply call the w32_update_xinerama_info or - update_xinerama_info function. - By supporting this, the VO also requests the newer API - that sets vo_dx, vo_dy etc. appropriately before config() - is called. + playback in fullscreen mode) + VOCTRL_START_SLICE + Called before the first draw_slice of each frame, useful if + you need to do some set-up work. + VOCTRL_DRAW_EOSD + Required for EOSD (ASS subtitle) support. Provides all + information necessary to draw the EOSD for the current video + frame. + VOCTRL_GET_EOSD_RES + Required for EOSD (ASS subtitle) support. Informs the ASS + renderer about the properties of the drawing area (size, + borders). + VOCTRL_SET_DEINTERLACE + VOCTRL_GET_DEINTERLACE + Get or set deinterlacing status for VOs that support some kind + of deinterlacing. + VOCTRL_UPDATE_SCREENINFO + Should set the xinerama_x, xinerama_y, vo_screenwidth and + vo_screenheight appropriately for the currently used + monitor and -xineramascreen option. + Usually should simply call the w32_update_xinerama_info or + update_xinerama_info function. + By supporting this, the VO also requests the newer API + that sets vo_dx, vo_dy etc. appropriately before config() + is called. config(): Set up the video system. You get the dimensions and flags. width, height: size of the source image d_width, d_height: wanted scaled/display size (it's a hint) Flags: - 0x01 - force fullscreen (-fs) - 0x02 - allow mode switching (-vm) - 0x04 - allow software scaling (-zoom) - 0x08 - flipping (-flip) + 0x01 - force fullscreen (-fs) + 0x02 - allow mode switching (-vm) + 0x04 - allow software scaling (-zoom) + 0x08 - flipping (-flip) They're defined as VOFLAG_* (see libvo/video_out.h) IMPORTANT NOTE: config() may be called 0 (zero), 1 or more (2,3...) @@ -132,42 +132,42 @@ Each vo driver _has_ to implement these: support multi-monitor setups (if based on x11_common, w32_common). draw_slice(): this displays YV12 pictures (3 planes, one full sized that - contains brightness (Y), and 2 quarter-sized which the colour-info - (U,V). MPEG codecs (libmpeg2, opendivx) use this. This doesn't have - to display the whole frame, only update small parts of it. - If this is not supported, it must be signaled in QUERY_FORMAT with - VOCAP_NOSLICES. + contains brightness (Y), and 2 quarter-sized which the colour-info + (U,V). MPEG codecs (libmpeg2, opendivx) use this. This doesn't have + to display the whole frame, only update small parts of it. + If this is not supported, it must be signaled in QUERY_FORMAT with + VOCAP_NOSLICES. draw_frame(): this is the older interface, this displays only complete - frames, and can do only packed format (YUY2, RGB/BGR). - Win32 codecs use this (DivX, Indeo, etc). - If you implement VOCTRL_DRAW_IMAGE, you do not need to implement draw_frame. + frames, and can do only packed format (YUY2, RGB/BGR). + Win32 codecs use this (DivX, Indeo, etc). + If you implement VOCTRL_DRAW_IMAGE, you do not need to implement draw_frame. draw_osd(): this displays subtitles and OSD. - It's a bit tricky to use it, since it's a callback-style stuff. - It should call vo_draw_text() with screen dimension and your - draw_alpha implementation for the pixelformat (function pointer). - The vo_draw_text() checks the characters to draw, and calls - draw_alpha() for each. As a help, osd.c contains draw_alpha for - each pixelformats, use this if possible! - Note that if you do not draw directly onto the video you should - use vo_draw_text_ext() which allows you to specify the border - values etc. needed to draw DVD menu highlights at the correct place. - If you do not want to implement this, you can still use -vf - expand=osd=1 to draw the OSD, or even implement code to insert - this filter automatically. - Make sure you set VFCAP_OSD depending on whether you implemented it - or not. - - NOTE: This one will be obsolete soon! But it's still useful when - you want to do tricks, like rendering osd _after_ hardware scaling - (tdfxfb) or render subtitles under of the image (vo_mpegpes, sdl) - - NOTE2: above NOTE is probably wrong, there are currently no plans to - obsolete draw_osd, though there is the more advanced EOSD support for - ASS subtitles. + It's a bit tricky to use it, since it's a callback-style stuff. + It should call vo_draw_text() with screen dimension and your + draw_alpha implementation for the pixelformat (function pointer). + The vo_draw_text() checks the characters to draw, and calls + draw_alpha() for each. As a help, osd.c contains draw_alpha for + each pixelformats, use this if possible! + Note that if you do not draw directly onto the video you should + use vo_draw_text_ext() which allows you to specify the border + values etc. needed to draw DVD menu highlights at the correct place. + If you do not want to implement this, you can still use -vf + expand=osd=1 to draw the OSD, or even implement code to insert + this filter automatically. + Make sure you set VFCAP_OSD depending on whether you implemented it + or not. + + NOTE: This one will be obsolete soon! But it's still useful when + you want to do tricks, like rendering osd _after_ hardware scaling + (tdfxfb) or render subtitles under of the image (vo_mpegpes, sdl) + + NOTE2: above NOTE is probably wrong, there are currently no plans to + obsolete draw_osd, though there is the more advanced EOSD support for + ASS subtitles. flip_page(): this is called after each frame, this displays the buffer for - real. This is 'swapbuffers' when doublebuffering. - Try to do as little work here as possible, since that affect jitter/ - A-V sync. + real. This is 'swapbuffers' when doublebuffering. + Try to do as little work here as possible, since that affect jitter/ + A-V sync. diff --git a/DOCS/tech/mirrors/mirror_howto.txt b/DOCS/tech/mirrors/mirror_howto.txt index 37a3d9cdfd..72116e8490 100644 --- a/DOCS/tech/mirrors/mirror_howto.txt +++ b/DOCS/tech/mirrors/mirror_howto.txt @@ -1,6 +1,6 @@ - ------------------------------ + ------------------------------ How to build an MPlayer mirror - ------------------------------ + ------------------------------ This document might be inacurate or even incomplete, please send feedback + corrections to the mplayer-mirror mailing list. diff --git a/DOCS/tech/mpdsf.txt b/DOCS/tech/mpdsf.txt index 1ed86edf94..27b51a7dff 100644 --- a/DOCS/tech/mpdsf.txt +++ b/DOCS/tech/mpdsf.txt @@ -6,17 +6,17 @@ Designed by Alex & Arpi The file starts with a variable size header: -------------------------------------------- -32-bit Stream format fourcc (MPVS or MPAS) - MPVS = MPlayer Video Stream - MPAS = MPlayer Audio Stream -8-bit Demuxer type (AVI,MOV,ASF,REAL,...) -8-bit Flags (marks dumped headers) - Values: 0x1: WAVEFORMATEX - 0x2: Audio extra codec data - 0x4: BITMAPINFOHEADER - 0x8: QT's ImageDesc - 0x16: indicates 32-bit chunk size before every data chunk -16-bit Length of headers +32-bit Stream format fourcc (MPVS or MPAS) + MPVS = MPlayer Video Stream + MPAS = MPlayer Audio Stream +8-bit Demuxer type (AVI,MOV,ASF,REAL,...) +8-bit Flags (marks dumped headers) + Values: 0x1: WAVEFORMATEX + 0x2: Audio extra codec data + 0x4: BITMAPINFOHEADER + 0x8: QT's ImageDesc + 0x16: indicates 32-bit chunk size before every data chunk +16-bit Length of headers There's strict rule in the follow-up of the codec-headers. Depending on flags, @@ -24,5 +24,5 @@ Depending on flags, Data chunks: ------------ -32-bit Optional 32-bit chunk size -... Data +32-bit Optional 32-bit chunk size +... Data diff --git a/DOCS/tech/mpsub.sub b/DOCS/tech/mpsub.sub index 8beaf8ef3d..df09438211 100644 --- a/DOCS/tech/mpsub.sub +++ b/DOCS/tech/mpsub.sub @@ -1,12 +1,12 @@ TITLE=Weird Al Yankovic - The Saga Begins (clip) - # just to be informative (maybe future - # use?) -FILE=14233792,7972c637f619e01854ecb453b7339e3f # size,md5 + # just to be informative (maybe future + # use?) +FILE=14233792,7972c637f619e01854ecb453b7339e3f # size,md5 AUTHOR=Gabucino -TYPE=VIDEO # maybe AUDIO in future (for displaying - # mp3 lyrics while playing or whatever) -FORMAT=TIME # this file contains measures based on - # TIME, not frames. +TYPE=VIDEO # maybe AUDIO in future (for displaying + # mp3 lyrics while playing or whatever) +FORMAT=TIME # this file contains measures based on + # TIME, not frames. # if FORMAT is a number, then it's frame based, i.e.: # FORMAT=25 diff --git a/DOCS/tech/osd.txt b/DOCS/tech/osd.txt index e4af53fe09..7e7376745f 100644 --- a/DOCS/tech/osd.txt +++ b/DOCS/tech/osd.txt @@ -51,36 +51,36 @@ typedef struct mp_osd_obj_s { unsigned char type; unsigned char alignment; // 2 bits: x;y percentages, 2 bits: x;y relative to parent; 2 bits: alignment left/right/center unsigned short flags; - int x,y; // coords + int x,y; // coords unsigned char color[4]; // YUVA mp_osd_bbox_t bbox; // bounding box unsigned int start,duration; // PTS union { - struct { - int x1,y1,x2,y2; - } line; - struct { - int x,y,w,h; - } rect; - struct { - char* text; - mp_font_t* font; - } text; - struct { - int symbol; // unicode - mp_font_t* font; - } symbol; - struct { - float value; - mp_font_t* font; - } pbar; - struct { - int w,h; - unsigned char* image; - unsigned int* palette; - } spu; // FIXME! - struct { - struct mp_osd_obj_s* children; - } group; + struct { + int x1,y1,x2,y2; + } line; + struct { + int x,y,w,h; + } rect; + struct { + char* text; + mp_font_t* font; + } text; + struct { + int symbol; // unicode + mp_font_t* font; + } symbol; + struct { + float value; + mp_font_t* font; + } pbar; + struct { + int w,h; + unsigned char* image; + unsigned int* palette; + } spu; // FIXME! + struct { + struct mp_osd_obj_s* children; + } group; } params; } mp_osd_obj_t; diff --git a/DOCS/tech/realcodecs/audio-codecs.txt b/DOCS/tech/realcodecs/audio-codecs.txt index 8a0d958354..fd28ab2a16 100644 --- a/DOCS/tech/realcodecs/audio-codecs.txt +++ b/DOCS/tech/realcodecs/audio-codecs.txt @@ -38,17 +38,17 @@ ulong result=RAOpenCodec2(ra_main_t *raMain); ulong result=RAInitDecoder(ra_main_t *raMain, ra_init_struct *raInit); struct ra_init_struct { - ulong sample_rate; - ushort bits_per_sample; // unused by RAInitDecoder - ushort number_of_channels; - ushort unknown1; // 0 - ushort unknown2; // also unused (100) - ulong leaf_size; // leaf size (used for interleaving, but - // exists in audio stream description header (ASDH)) - ulong block_align; // packet size - ulong bits_per_sample; // unused (always 16) - char *ext_data; // 16 bytes located at the end of the - // ASDH + ulong sample_rate; + ushort bits_per_sample; // unused by RAInitDecoder + ushort number_of_channels; + ushort unknown1; // 0 + ushort unknown2; // also unused (100) + ulong leaf_size; // leaf size (used for interleaving, but + // exists in audio stream description header (ASDH)) + ulong block_align; // packet size + ulong bits_per_sample; // unused (always 16) + char *ext_data; // 16 bytes located at the end of the + // ASDH }; There are some information missing that you usually need for playback, @@ -61,7 +61,7 @@ following command: void *GetRAFlavorProperty(ra_main_t *raMain, ulong flavor, ulong property, - short *property_length_in_bytes); + short *property_length_in_bytes); returns property data for a specific data This is not important, because it's just a read only function. @@ -69,8 +69,8 @@ These flavor properties don't seem to exist in ulong RADecode(ra_main_t *raMain, char *input_buffer, - ulong input_buffer_size, char *output_buffer, - ulong *decoded_bytes, ulong p6=-1); + ulong input_buffer_size, char *output_buffer, + ulong *decoded_bytes, ulong p6=-1); RAFreeDecoder(ra_main_t *); diff --git a/DOCS/tech/realcodecs/streaming.txt b/DOCS/tech/realcodecs/streaming.txt index 091d0d671f..a4af485b9b 100644 --- a/DOCS/tech/realcodecs/streaming.txt +++ b/DOCS/tech/realcodecs/streaming.txt @@ -38,8 +38,8 @@ cccc: mask 3FFF: _total_ length of the packet dddd: when it's 0, {} exists (only in this case) mask 3FFF: offset of fragment inside the whole packet. it's counted from the beginning of the packet, except when hdr&0x80, - hten it's relative to the _end_ of the packet, so it's - equal to fragment size! + hten it's relative to the _end_ of the packet, so it's + equal to fragment size! mask C000: like cccc, except the first case (always 4000) when it's all 0000, it indicates value >=0x4000, you should read {eeee} and use all 16 bits of it. dunno what happens when length>=65536... diff --git a/DOCS/tech/realcodecs/video-codecs.txt b/DOCS/tech/realcodecs/video-codecs.txt index 2bef957172..af2152061a 100644 --- a/DOCS/tech/realcodecs/video-codecs.txt +++ b/DOCS/tech/realcodecs/video-codecs.txt @@ -40,12 +40,12 @@ anything and is only called in the beginning. result=RV20toYUV420Init(struct init_data *, struct rvyuvMain **); struct init_data { - short constant=0xb; - short width, height; - short 0, 0, 0; - ulong format1; - long 1; - ulong format2; + short constant=0xb; + short width, height; + short 0, 0, 0; + ulong format1; + long 1; + ulong format2; }; format1 and format2 are stored in the .rm file's stream headers. @@ -53,22 +53,22 @@ format1 and format2 are stored in the .rm file's stream headers. it's the only difference between low and high bitrate files. result=RV20toYUV420Transform(char *input_stream, char *output_data, - struct transin *, struct transout *, struct rvyuvMain *); + struct transin *, struct transout *, struct rvyuvMain *); struct transin { - ulong length_of_input_data; - ulong null; - ulong num_sub_packets_in_block_minus_one; - ulong *sub_packets_list; - ulong another_null; - ulong timestamp_from_stream; + ulong length_of_input_data; + ulong null; + ulong num_sub_packets_in_block_minus_one; + ulong *sub_packets_list; + ulong another_null; + ulong timestamp_from_stream; }; struct transout { - ulong flag1; // ((var_94&2!=0)&&(result==0))?1:0 - ulong flag2; // 4 LBS from var_94 - ulong zero; - ulong width, height; + ulong flag1; // ((var_94&2!=0)&&(result==0))?1:0 + ulong flag2; // 4 LBS from var_94 + ulong zero; + ulong width, height; }; The length of output_stream is 1.5*width*height (I420 planar yuv 4:2:0). @@ -131,37 +131,37 @@ DWORDS (the entries are not always constant) there are two w/h pairs at 05C. the first is the size of the unscaled video stream, the second possibly image size -000 1 6 3 1 -010 1 0 AEBFC0D1(magic) 0 -020 0 ptr->? 0 0 -030 0 0 ->rvyuvMain+0x050 ? -040 width height 0x17 0x479 -050 ->rvyuvMain 0x17 0x17 width -060 height width height 0 -070 0 1 0 0 -080 0 0xb w h -090 w h 0 0 -0A0 1 0xb0(w?) 0x58 0x58 -0B0 ptr->? 0 0 1 -0C0 0x32 1 0 0 -0D0 0 0 0 0 -0E0 0 0 0 0 -0F0 0 0 0 0 -100 0 0 0 0 -110 p p p p p are pointers to several function, for -120 p p p p example to the actual public functions -130 p p p p (except init, the others are some kind of -140 p p p p interfaces) -150 p 0 0 0 -160 0 0x2000 1 0 -170 0 0 0 0 -180 1 1 0 0 -190 0 0 0 0 -1A0 0 0 0 0 -1B0 1 0 ptr->? ptr->? -1C0 1 0 0 0 -1D0 0 0 0 0 -1E0 0 0 0 0 +000 1 6 3 1 +010 1 0 AEBFC0D1(magic) 0 +020 0 ptr->? 0 0 +030 0 0 ->rvyuvMain+0x050 ? +040 width height 0x17 0x479 +050 ->rvyuvMain 0x17 0x17 width +060 height width height 0 +070 0 1 0 0 +080 0 0xb w h +090 w h 0 0 +0A0 1 0xb0(w?) 0x58 0x58 +0B0 ptr->? 0 0 1 +0C0 0x32 1 0 0 +0D0 0 0 0 0 +0E0 0 0 0 0 +0F0 0 0 0 0 +100 0 0 0 0 +110 p p p p p are pointers to several function, for +120 p p p p example to the actual public functions +130 p p p p (except init, the others are some kind of +140 p p p p interfaces) +150 p 0 0 0 +160 0 0x2000 1 0 +170 0 0 0 0 +180 1 1 0 0 +190 0 0 0 0 +1A0 0 0 0 0 +1B0 1 0 ptr->? ptr->? +1C0 1 0 0 0 +1D0 0 0 0 0 +1E0 0 0 0 0 ... diff --git a/DOCS/tech/slave.txt b/DOCS/tech/slave.txt index 96badf539f..f03339aac3 100644 --- a/DOCS/tech/slave.txt +++ b/DOCS/tech/slave.txt @@ -45,6 +45,17 @@ Various tips and tricks (please help expand it!): Available commands ('mplayer -input cmdlist' will print a list): +af_add <filter_arguments_list> (comma separated list of audio filters with parameters) + (experimental) Load the given list of audio filters. + +af_clr + (experimental) Unload all loaded audio filters. + +af_del <filter_name_list> (comma separated list of audio filter's names) + (experimental) Unload the first occurrence of the filters, if loaded. + +af_switch <filter_arguments_list> (comma separated list of audio filters with parameters) + (experimental) Remove all the audio filters and replace them with the given list. alt_src_step <value> (ASX playlist only) When more than one source is available it selects the next/previous one. @@ -201,6 +212,10 @@ mute [value] osd [level] Toggle OSD mode or set it to [level] when [level] >= 0. +osd_show_progression + Show the progression bar, the elapsed time and the total duration of the + movie on the OSD. + osd_show_property_text <string> [duration] [level] Show an expanded property string on the OSD, see -playing-msg for a description of the available expansions. If [duration] is >= 0 the text diff --git a/DOCS/tech/subcp.txt b/DOCS/tech/subcp.txt index 60c370771c..50d9cc69f9 100644 --- a/DOCS/tech/subcp.txt +++ b/DOCS/tech/subcp.txt @@ -7,21 +7,21 @@ summarize it here. There are 2 approaches: 1. (preferred) You can generate Unicode subtitles with: - subfont --unicode <signle-byte encoding known by iconv> ... + subfont --unicode <signle-byte encoding known by iconv> ... or - subfont --unicode <path to custom encoding file> ... - (this custom encoding file could list all iso-8859-* characters to create + subfont --unicode <path to custom encoding file> ... + (this custom encoding file could list all iso-8859-* characters to create single font file for common encodings) and then run mplayer this way (-subcp and -utf8 expect Unicode font!): - mplayer -subcp <any encoding known by iconv> ... + mplayer -subcp <any encoding known by iconv> ... or - mplayer -utf8 ... + mplayer -utf8 ... 2. (current) Generate subtitles for some specific encoding with: - subfont <signle-byte encoding known by iconv> ... + subfont <signle-byte encoding known by iconv> ... or - subfont <path to custom signle-byte or EUC encoding file> ... + subfont <path to custom signle-byte or EUC encoding file> ... and then run mplayer without any encoding options for signle-byte encodings, or with -unicode option for EUC (and the like) encodings diff --git a/DOCS/tech/swscaler_filters.txt b/DOCS/tech/swscaler_filters.txt index b63ecc1ae2..11e2aa4017 100644 --- a/DOCS/tech/swscaler_filters.txt +++ b/DOCS/tech/swscaler_filters.txt @@ -1,18 +1,18 @@ software scaler filter docs -ssf cgb=<float> chrominance gaussian blur - useful for videos with some chroma (color) noise (TV captures, VHS, ...) + useful for videos with some chroma (color) noise (TV captures, VHS, ...) -ssf lgb=<float> -> luminance gaussian blur - hmm, mostly special effect, could be used as lame noise reducer though + hmm, mostly special effect, could be used as lame noise reducer though -ssf chs=<int> -> shift chrominance horizontally -ssf cvs=<int> -> shift chrominance vertically - useful if the luma & chroma are not aligned exactly + useful if the luma & chroma are not aligned exactly -ssf cs=<float> -> chrominance sharpen -ssf ls=<float> -> luminance sharpen - simple sharpening filter + simple sharpening filter note: these will only work if the swscaler is used at all (use -vf scale) diff --git a/DOCS/tech/swscaler_methods.txt b/DOCS/tech/swscaler_methods.txt index b2c7077652..24d2b11835 100644 --- a/DOCS/tech/swscaler_methods.txt +++ b/DOCS/tech/swscaler_methods.txt @@ -2,29 +2,29 @@ artifact types: --------------------------------------------------------------------- ringing - wave or noise like patterns around sharp edges - bad: sinc, lanczos (with high filter length) - acceptable: lanczos (with low filter length), cubic, spline - ok: area, (fast)blinear, gauss, point + wave or noise like patterns around sharp edges + bad: sinc, lanczos (with high filter length) + acceptable: lanczos (with low filter length), cubic, spline + ok: area, (fast)blinear, gauss, point blur - loss of detail / high frequency - bad: gauss with high variance - acceptable: (fast)bilinear, area - ok: others + loss of detail / high frequency + bad: gauss with high variance + acceptable: (fast)bilinear, area + ok: others aliasing (only downscale) - straight lines look like staircases - areas of high detail look worse - regular patterns turn into a funny looking mess (moire patterns) - bad: fast bilinear, point, gauss with low variance - acceptable: area - ok: others + straight lines look like staircases + areas of high detail look worse + regular patterns turn into a funny looking mess (moire patterns) + bad: fast bilinear, point, gauss with low variance + acceptable: area + ok: others blocky (upscale only) - looks like the image is made of rectangular blocks like a mosaic - bad: point - ok: others + looks like the image is made of rectangular blocks like a mosaic + bad: point + ok: others recommendations: (based upon my personal opinion many ppl might disagree ...) --------------------------------------------------------------------- @@ -49,20 +49,20 @@ b blurry a aliasing (downscale only) m mosaic (blocky) (upscale only) --sws 0 fast bilinear bA --sws 1 bilinear b --sws 2 bicubic high sharpness r - low sharpness b --sws 3 experimental ???? --sws 4 nearest neighbour AM --sws 5 area ba --sws 6 luma bicubic / chroma bilinear r --sws 7 gauss low sharpness B - high sharpness AM --sws 8 sinc R --sws 9 lanczos long filter R - short filter b --sws 10 bicubic spline r +-sws 0 fast bilinear bA +-sws 1 bilinear b +-sws 2 bicubic high sharpness r + low sharpness b +-sws 3 experimental ???? +-sws 4 nearest neighbour AM +-sws 5 area ba +-sws 6 luma bicubic / chroma bilinear r +-sws 7 gauss low sharpness B + high sharpness AM +-sws 8 sinc R +-sws 9 lanczos long filter R + short filter b +-sws 10 bicubic spline r Notes: - area upscale is identical to bilinear + area upscale is identical to bilinear diff --git a/DOCS/tech/vidix.txt b/DOCS/tech/vidix.txt index 71409be69d..7308dde184 100644 --- a/DOCS/tech/vidix.txt +++ b/DOCS/tech/vidix.txt @@ -1,5 +1,5 @@ - VIDIX - VIDeo Interface for *niX - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + VIDIX - VIDeo Interface for *niX + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This interface was designed and introduced as interface to userspace drivers to provide DGA everywhere where it's possible (unline X11). @@ -40,43 +40,43 @@ So any suggestions, reports, criticism are gladly accepted. 7) APP calls vixConfigPlayback. Driver should prepare BES on this call. APP pass to driver following info: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - vidix_playback_t.fourcc - contains fourcc of movie - vidix_playback_t.capability - currently contsinas copy of vidix_capability_t.flags + vidix_playback_t.fourcc - contains fourcc of movie + vidix_playback_t.capability - currently contsinas copy of vidix_capability_t.flags vidix_playback_t.blend_factor- currently unused - vidix_playback_t.src - x,y,w,h fields contain original movie size - (in pixels) x and y often are nulls. + vidix_playback_t.src - x,y,w,h fields contain original movie size + (in pixels) x and y often are nulls. vidix_playback_t.src.pitch.y These fields contain source pitches vidix_playback_t.src.pitch.u - for each Y,U,V plane in bytes. vidix_playback_t.src.pitch.v (For packed fourcc only Y value is used) - They are hints for driver to use same destinition - pitches as in source memory (to speed up - memcpy process). - Note: when source pitches are unknown or - variable these field will be filled into 0. - vidix_playback_t.dest - x,y,w,h fields contains destinition rectange - on the screen in pixels. + They are hints for driver to use same destinition + pitches as in source memory (to speed up + memcpy process). + Note: when source pitches are unknown or + variable these field will be filled into 0. + vidix_playback_t.dest - x,y,w,h fields contains destinition rectange + on the screen in pixels. vidix_playback_t.num_frames - maximal # of frames which can be used by APP. - (Currently 10). + (Currently 10). Driver should fill following fields: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vidix_playback_t.num_frames - real # of frames which will be used by driver. - (Should be less or equal to app's num_frames). + (Should be less or equal to app's num_frames). vidix_playback_t.dest.pitch.y These fields should contain alignment vidix_playback_t.dest.pitch.u - for each Y,U,V plane in bytes. vidix_playback_t.dest.pitch.v (For packed fourcc only Y value is used) - vidix_playback_t.frame_size - Driver should tell to app which size of - source frame (src.w and src.h) should - use APP (according to pitches and offsets) + vidix_playback_t.frame_size - Driver should tell to app which size of + source frame (src.w and src.h) should + use APP (according to pitches and offsets) - vidix_playback_t.offsets - offsets from begin of BES memory for each frame + vidix_playback_t.offsets - offsets from begin of BES memory for each frame - vidix_playback_t.offset.y These field should contain offset - vidix_playback_t.offset.u - for each Y,U,V plane within frame. - vidix_playback_t.offset.v (For packed fourcc only Y value is used) + vidix_playback_t.offset.y These field should contain offset + vidix_playback_t.offset.u - for each Y,U,V plane within frame. + vidix_playback_t.offset.v (For packed fourcc only Y value is used) - vidix_playback_t.dga_addr - Address of BES memory. + vidix_playback_t.dga_addr - Address of BES memory. Also see this picture: @@ -85,9 +85,9 @@ VIDEO MEMORY layout: | | v v [ RGB memory | YUV memory | UNDEF ] - ^ - | - +---- begin of BES memory + ^ + | + +---- begin of BES memory BES MEMORY layout: +-------- begin of BES memory @@ -109,22 +109,22 @@ offset of Y plane != offset of first frame But often: vidix_playback_t.offsets[0] = vidix_playback_t.offset.y = 0; Formula: (For Y plane) copy source to: - vidix_playback_t.dga_addr + - vidix_playback_t.offsets[i] + - vidix_playback_t.offset.y + vidix_playback_t.dga_addr + + vidix_playback_t.offsets[i] + + vidix_playback_t.offset.y 8) APP calls vixPlaybackOn. Driver should activate BES on this call. 9) PLAYBACK. Driver should sleep here ;) But during playback can be called: vixFrameSelect (if this function is exported) - Driver should prepare and activate corresponded frame. - This function is used only for double and trilpe buffering and - never used for single buffering playback. + Driver should prepare and activate corresponded frame. + This function is used only for double and trilpe buffering and + never used for single buffering playback. vixGet(Set)GrKeys (if this function is exported) - This interface should be tuned but intriduced for overlapped playback - and video effects (TYPE_FX) + This interface should be tuned but intriduced for overlapped playback + and video effects (TYPE_FX) vixPlaybackGet(Set)Eq (if this function is exported) - For color correction. + For color correction. 10) APP calls vixPlaybackOff. Driver should deactivate BES on this call. 11) If vixDestroy is defined APP calls this function before unloading driver from memory. @@ -144,10 +144,10 @@ All other functions are optionaly. Useful links: ~~~~~~~~~~~~~ -Guide to DTV http://www.digitaltelevision.com/dtvbook/toc.shtml -Fourcc http://www.webartz.com/fourcc/ -MPEG http://www.mpeg.org/MPEG/index.html -Analog colors http://www.miranda.com/en/app_notes/TN/TN-05/TN-05.htm +Guide to DTV http://www.digitaltelevision.com/dtvbook/toc.shtml +Fourcc http://www.webartz.com/fourcc/ +MPEG http://www.mpeg.org/MPEG/index.html +Analog colors http://www.miranda.com/en/app_notes/TN/TN-05/TN-05.htm Please send your suggestions, reports, feedback to mplayer-dev-eng@mplayerhq.hu Best regards! Nick Kurshev. |