文件列表:

fgs\asp\common\Debug (0, 2006-04-26)
fgs\asp\common\common.dsp (20653, 2006-04-26)
fgs\asp\common\common.plg (30521, 2006-04-26)
fgs\asp\common (0, 2006-04-26)
fgs\asp\Debug (0, 2006-04-26)
fgs\asp\dec\Debug (0, 2006-04-26)
fgs\asp\dec\dec.dsp (8387, 2006-04-26)
fgs\asp\dec\dec.plg (47049, 2006-04-26)
fgs\asp\dec\fgs1.cfg (5458, 2006-04-26)
fgs\asp\dec\fgs1_dec.ctl (794, 2006-04-26)
fgs\asp\dec\fgs2_dec.ctl (792, 2006-04-26)
fgs\asp\dec\pred_mc.seg (25344, 2006-04-26)
fgs\asp\dec (0, 2006-04-26)
fgs\asp\enc\enc.dsp (12434, 2006-04-26)
fgs\asp\enc\enc.plg (68293, 2006-04-26)
fgs\asp\enc\encode.dat (25963, 2006-04-26)
fgs\asp\enc\fgs1.bits (22065, 2006-04-26)
fgs\asp\enc\fgs1.cfg (5509, 2006-04-26)
fgs\asp\enc\fgs1_enc.ctl (504, 2006-04-26)
fgs\asp\enc\fgs2.bits (0, 2006-04-26)
fgs\asp\enc\fgs2.bits_fgs (0, 2006-04-26)
fgs\asp\enc\fgs2.cfg (5498, 2006-04-26)
fgs\asp\enc\fgs2_enc.ctl (504, 2006-04-26)
fgs\asp\enc\fgsstat.dat (1937, 2006-04-26)
fgs\asp\enc (0, 2006-04-26)
fgs\asp\asp.dsw (1092, 2006-04-26)
fgs\asp\asp.ncb (3032064, 2006-04-27)
fgs\asp\fgs1.cfg (5497, 2006-04-26)
fgs\asp\fgs1_enc.ctl (504, 2006-04-26)
fgs\asp\asp.opt (114688, 2006-04-27)
fgs\asp (0, 2006-04-26)
fgs\FGS_server\FGS_FGST_server_P_FRAMES.c (4650, 2006-04-26)
fgs\FGS_server\FGS_server.c (3259, 2006-04-26)
fgs\FGS_server\Makefile (102, 2006-04-26)
fgs\FGS_server\Makefile_debug (104, 2006-04-26)
fgs\FGS_server\Makefile_FGS_FGST_server_P_FRAMES (144, 2006-04-26)
fgs\FGS_server (0, 2006-04-26)
fgs\machines\ALPHA_options (2614, 2006-04-26)
fgs\machines\CONVEX_options (2589, 2006-04-26)
fgs\machines\HP_options (2649, 2006-04-26)
... ...

This file contains seven sections 1. About the Software 2. Compiling the Software 3. Running the Encoder Software 4. Running the Decoder Software 5. Notes/Known Bugs/Problems 6. Using Traces in the Decoder 7. Using Random Access 8. Using software for bitstream exchange 9. Basic flags used in Makefile Edited by: Noel Brady & Noel O'Connor Teltec Ireland Noel.Brady@Teltec.DCU.ie Noel.OConnor@Teltec.DCU.ie wollborn@tnt.uni-hannover.de ferran@gps.tsc.upc.es Robert.Danielsen@nta.no zhou@hhi.de Aasmund.Sandvand@nta.no beifrig@nlvl.com m-frater@adfa.oz.au jdkim97@hei.co.kr cspark@super5.hyundai.co.kr jhkweon@hei.co.kr brandau@hhi.de heising@hhi.de suehring@hhi.de benzler@tnt.uni-hannover.de ====================================================================== 1. ABOUT THE SOFTWARE ------------------------------------------------ ====================================================================== This README file accompanies the release of the MPEG-4 VM software as developed within the framework of the European ACTS project MoMuSys. The software contains an encoder and decoder compliant as much as possible with FCD. Some of these options will be included in future releases. Nevertheless, we encourage MPEG participants outside of MoMuSys to provide these modules or some new modules that may have to be implemented for future releases and we will integrate them. If you have the intention to implement any new part, state this intention by sending a mail to majordomo@research.kpn.com. It is still possible to have some hidden bugs as it is extremely difficult to check all coding possibilities the encoder has. We are continually working on the software to enhance it and to implement the MPEG-4 new capabilities. Any problems or suggestions you have for improving the software should also be sent to this reflector. To subscribe to the Software Integration (MPEG4 Visual VM integration) reflector: Send the following e-mail to majordomo@psl.com.sg : SUBSCRIBE sw_int your-email-address To unsubscribe from the Software Integration reflector: Send the following e-mail to majordomo@psl.com.sg : UNSUBSCRIBE sw_int your-email-address If you have some difficulties with subscribing/unsubscribing, please contact owner-sw_int@psl.com.sg . In general, by providing this software, we are hoping to encourage collaboration on software development within MPEG. We have provided also on the same ftp sites a document covering the data structures and programming rules which we have used within the software. Please read the header copyright attached to all files in the vm_common, vm_enc and vm_dec directories. For data structures used in MoMuSys please refer to the file vm_common/include/momusys.h. ====================================================================== 2. COMPILING THE SOFTWARE -------------------------------------------- ====================================================================== The software C sources are provided in 3 directories/modules i.e. vm_enc, vm_common, vm_dec. The vm_enc directory contains sources for implementing the encoder. The vm_common directory contains sources which are used in both encoder and decoder e.g. motion compensation. The vm_dec directory contains sources for implementing the decoder. It may be integrated into one or more of the other directories later on. Makefiles and documentation files are provided in the top level directory. The software is written to strict ANSI C rules and designed to compile under a variety of compilers. The software is compiled using the GNU make utility i.e. gmake. (Warning: the classical make does not work). During compilation, the sources within each module are compiled into a library and placed under the lib directory. Due to the module structure described above, it is necessary always to compile the vm_common library. If it is necessary only to compile the encoder for instance, delete the the word vm_dec from line 32 of the Makefile. Alternatively, the decoder executable only can be produced by deleting the word vm_enc at the same line number. The Makefiles provided are designed to maintain several library versions in parallel. That is, at any one time, the lib directory can store several library files built for different systems e.g. SOLARIS1, SOLARIS2, LINUX. Furthermore, libraries with debug information can coexist with the normal libraries. Currently, the software has been compiled and tested with the gcc compiler on several hardware platforms, see the PORTABILITY file. Some minor adjustments in the Makefiles may be required to compile with other compilers. Prior to compiling the software, one may need to edit the files in the machines directory to set up the correct paths for the compiler and other utilities. For example, if your system is running SOLARIS1 then edit the file machines/SOLARIS1_options and type > make -e SYSTEM=SOLARIS1 to begin the compilation. To view all the make options, type > make usage Here is a summary of the utilities you will require to use this software: Requirements ------------ Mandatory: cproto-3pl7 GNU make-3.74 or higher a GNU gcc compiler (see PORTABILITY file) Optional : GNU rcs-5.6.0.1 or higher for RCS revision control. GNU perl version 5.001 for automatic HTML documentation option. (and of course a HTML Web browser for this latter option) Please note: In the distributed version the prototype files are already generated. If you have any problems with them, please touch all the c-files in the source directory and they will be created again, using your local cproto tool. 2.1 AUTOMATIC PROTOTYPE GENERATION The makefiles support automatic prototype generation. For each C source file in the directory vm_enc/src, there will be one *.p file produced and placed in the vm_enc/include/proto directory. This *.p file will contain a function prototype for each function defined in the source file. It is recommended that this prototype file is included within a header file (*.h) in the vm_enc/include directory. The header file is then included within the relevant source files. To use this automatic feature, it is required that the 'cproto' utility is available on your system. The source and makefiles for this utility can be retrieved from the same ftp site where you downloaded the VM software. The file is called cproto.tar.gz. 2.2 AUTOMATIC DOCUMENT GENERATION Requirements: perl and a HTML viewer * To generate the doc: - Modify the path of perl in the first line of generate_doc.pl - Run : make doc It will create HTML files in the vm_common/doc, vm_enc/doc and vm_dec/doc directories. To view the doc , load : vm_enc/doc/vm_enc.html To produce doc from your own source files : generate_doc.pl recognizes the following keywords: HeaderBegin HeaderEnd CommentBegin CommentEnd -- Usually add a box like this on top on the file : /*************************************************HeaderBegin****************/ /* */ /* File : vop.c */ /* Module : vm */ /* */ /*************************************************HeaderEnd******************/ Enclose your own comments (anywhere in the source file) between a line containing "CommentBegin" and a line containing "CommentEnd", like this: /***********************************************CommentBegin***************** * -- VOP_CodeInter -- code one image normally or two images as a PB-frame * * put here your comments> * ***********************************************CommentEnd*******************/ The line starting with " --" will also be extracted. 2.3 SUPPORTING IMAGE FILE FORMATS The software is capable of reading and writing RAW image file formats. For example, a sequence stored in merged yuv format without headers can be read and written. Alternatively, the y, u and v data can be in separate files. The source code for this is provided in io_generic.c and io_raw.c in vm_common/src. If you wish to customise the software for use with your own specific image file format, read the next section 2.3.1 Customising the I/O Software Each new user of the software must make some small modifications to allow the software to operate with their specific image file format. This involves including new code in the file vm_common/src/io_generic.c and vm_common/include/ io_generic.h. For example, an organisation named ACME uses a file format which is unsupported. The lines #ifdef _ACMEIO_ ReadVopACME(y_file,u_file,v_file,alpha_file,number,format,curr_vop_in); #endif are added to the function ReadVopGeneric(), and the lines #ifdef _ACMEIO_ WriteVopACME(curr_vop_in,y_file,u_file,v_file,alpha_file,number, format,mode, write_alpha); #endif are added to the function WriteVopGeneric() in io_generic.c. The source for the ACME i/o functions is put in a file io_acme.c and placed in the vm_common/src directory. The corresponding header file io_acme.h is placed in the vm_common/include directory The lines #ifdef _IO_ACME_ #include "io_acme.h" #endif are added to io_generic.h in the include directory. The software must then be compiled with the directive -D_IO_ACME_. This is simply done by setting the EXTRA_CFLAGS variable in Makefile (line 54). e.g. EXTRA_CFLAGS = -D_IO_ACME_ In order to write compliant site-specific I/O routines, see the prototypes below or the HTML documentation for ReadVopGeneric() and WriteVopGeneric() i.e. doc/io_generic.c.html. The prototypes of these IO functions are: Void ReadVopGeneric(Char *y_file, Char *u_file, Char *v_file, Char *alpha_file, Int number, Char *format, Vop *vop) Void WriteVopGeneric(Vop *vop, Char *y_file, Char *u_file, Char *v_file, Char *alpha_file, Int number, Char *format, Char *mode Int write_alpha) where : y_file - name of vop Y file on disk u_file - name of vop U file on disk v_file - name of vop V file on disk alpha_file - name of vop alpha map on disk number - Temporal location of image fields (i.e. number = 0, is first frame in disk sequence, number = 1, is second, and so on) format - Partners preferred image format (defined in io_generic.h) mode - For writing, either "APPEND" or "OVERWRITE" vop - pointer to vop to be filled write_alpha - a flag to indicate whether the alpha plane of the vop is written to disk. *** n.b. *** For ReadVopGeneric(), the vop to be filled is assumed to be allocated outside this function. MoMuSys vops are allocated with the dimensions of U & V half that of Y & Alpha (when coding a vop this is assumed in numerous places). Therefore this function should fill the image fields of the vop in this manner i.e. whatever way the sequences are stored on disk, any up/down sampling should be performed within this function. ====================================================================== 3. RUNNING THE ENCODER SOFTWARE -------------------------------------- ====================================================================== The encoder is controlled by a control file and some arguments passed to it. To run : vm_enc.exe control file [stats file] control_file - Name of control file stats_file - Name of file on disk to store the encoding statistics If the user does not specify a parameter for stats file the encoding statistics will be written to the file 'encode.dat'. 3.1 CONTROL FILE The control file contains high level control information required for running the encoder. Some example control files (*.ctl) are supplied with the software. A .ctl file must contain: n1 <-- Number of Video Objects (VOs) to code n2 <-- Number of Video Objects (VTCs) to code display.y <-- The name of the composited display seq. on disk (Y comp.) display.u <-- The name of the composited display seq. on disk (U comp.) display.v <-- The name of the composited display seq. on disk (V comp.) width <-- Width in pixels of the display height <-- Height in pixels of the display 0 <-- {post-filter type: 0 - disabled, 1 - deblock, 2 - deringing, 3 - combined} BitsPerPixel <-- pixel depth VO0.cfg <-- Name of first VO configuration file . . VOn1.cfg <-- Name of N1th VO configuration file VTC0.cfg <-- Name of first VTC configuration file . . VTCn2.cfg <-- Name of N2th VTC configuration file n <-- {Type of rate control: 0-NONE, 1-VM4, 2-VM5+, 3-TM5} n|n|n|n|n|n <-- {RC String: Alg|rate_mod|dist_mod|Target|buffer|mode} 3.2 VO and VTC CONFIGURATION FILE A configuration file contains all information required for coding all Video Object Layers (VOLs) of a particular VO. Some example configuration files (*.cfg) are supplied with the software. A .cfg file must contain: ***************************************************************** * VO Configuration Information * ***************************************************************** VO Id <-- VO Id n <-- Number of layers (1, single layer coding, 2, temporally, Spatial scalable coding) ***************************************************************** * BASE VOL Configuration Information * ***************************************************************** ident <---MPEG-4 Version identifier : 1-Version1 , 2:Version2 VOL Id <-- VOL Id VOL Type <-- VOL Type indication 1-Simple, 2-Simple Scalable, 3-Core, 4-Main, etc. Frame Rate <-- VOL frame rate (Hz) M <-- Number of B-VOPs (M-1) between two consecutive P-VOPs VOL dim x <-- These are the dimensions (of Y (= Alpha)) of the VOPs VOL dim y to be used in encoding this VOL (before bounding rectangle extraction. disk seq frame rate <-- This is the frame rate of the VOL sequence (all components) on disk. alpha type <-- Type of alpha channel to be used 0-RECTANGULAR, 1-BINARY, 2-GREY LEVEL, 3- BINARY SHAPE CODING ONLY mac_enable <-- Enable MAC only if mac_enble alpha_extension <-- in case of GRAY LEVEL:video_object_layer_shape_extension (0-15), otherwise ignored OBMC disable <-- OBMC disable: 1-disable, 0 -enable} quantizer precision <-- number of bits used to transmit quantiser pixel depth <-- number of bits per pixel VOL.y <-- This is the name of the file containing the Y image data for the VOL VOL.u <-- This is the name of the file containing the U image data for the VOL VOL.v <-- This is the name of the file containing the V image data for the VOL VOL.a <-- This is the name of the file containing the alpha map for the VOL only if mac_enable and Gray Level for each VOP GREY LEVEL file VOL.a1 <-- This is the name of the file containing the VOP GREY LEVEL for the VOL write coded <-- Write the coded VOPs to disk, 0 - no write, 1 - write CODED.y <-- This is the name of the file containing the coded Y component CODED.u <-- This is the name of the file containing the coded U component CODED.v <-- This is the name of the file containing the coded V component CODED.a <-- This is the name of the file containing the coded alpha component only if mac_enable and Gray Level for each VOP GRAY LEVEL file: CODED.a1 <-- This is the name of the file containing the coded VOP GREY LEVEL VOL.bits <-- Name of bitstream file on disk for this VOL start frame <-- VOL start frame end frame <-- VOL end frame start time <-- Time (in ms) at which VOL first appears target bit-rate <-- Target bit-rate for VOL 1.|1.|1. <-- Global RC Parameters: I|P|B for UPM1, position|max_dist for UPM2 alpha th <-- Alpha coding threshold (for binary alpha mask) change_CR_disable<-- change_CR_disable: 0 - enable, 1 - disable quant type <-- VOL quant. type select: 0 - H.263 quant, 1 - MPEG2 quant. 0 <-- VOL load_intra_quant_mat: 0-no, 1-userdefined, 2-MPEG4 VM7, 3- MPEG2 Default, 4-MPEG2 TM5 iqmat.dat <-- file name for userdefined intra_quant_mat if userdefined 3 <-- VOL load_nonintra_quant_mat: 0-no, 1-userdefined, 2-MPEG4 VM7 3-MPEG2 Default 4-MPEG2 TM5 nqmat.dat <-- file name for userdefined nonintra_quant_mat if userdefined 0 <-- VOL load_gray_intra_quant_mat: 0-no, 1-userdefined, 2-MPEG4 VM7, 3-MPEG2 Default, 4-MPEG2 TM5 giqmat.dat <-- file name for userdefined gray_intra_quant_mat if userdefined 0 <-- VOL load_gray_nonintra_quant_mat: 0-no, 1-userdefined, 2-MPEG4 VM7, 3-MPEG2 Default, 4-MPEG2 TM5 gnqmat.dat <-- file name for userdefined gray_nonintra_quant_mat if userdefined quant_Intra <-- Initial value for quantizer - INTRA quant_Inter <-- Initial value for quantizer - P_VOPs quant_Inter <-- Initial value for quantizer - B_VOPs quant_GL_intra <-- Quantizer for gray level alpha maps - I-VOPS quant_GL_inter <-- Quantizer for gray level alpha maps - P-VOPS quant_GL_inter <-- Quantizer for gray level alpha maps - B-VOPS quant_GL_update <-- Quantizer update disable flag for gray level quantization rounding control<-- Flag to disable rounding control: 0 - enabled, 1 - disabled initial rounding<-- Initial value for rounding control: 0/1 error resilience<-- Flag to disable error r ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：