文件列表:

VencH264 (0, 2010-11-25)
VencH264\sd (0, 2010-11-25)
VencH264\prod (0, 2010-11-25)
VencH264\sd\avs (0, 2010-11-25)
VencH264\prod\mptk (0, 2010-11-25)
VencH264\sd\avs\vencsw (0, 2010-11-25)
VencH264\prod\mptk\apps (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps (0, 2010-11-25)
VencH264\prod\mptk\apps\exSecurity (0, 2010-11-25)
VencH264\prod\mptk\apps\exH264Codec (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282 (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264CoreIptm3282 (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264 (0, 2010-11-25)
VencH264\prod\mptk\apps\exSecurity\src (0, 2010-11-25)
VencH264\prod\mptk\apps\exSecurity\cfg (0, 2010-11-25)
VencH264\prod\mptk\apps\exH264Codec\docs (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\src (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\inc (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\ex (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264CoreIptm3282\lib (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264CoreIptm3282\inc (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264\src (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264\inc (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264\docs (0, 2010-11-25)
VencH264\prod\mptk\apps\exSecurity\src\version (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\ex\src (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\ex\inc (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\ex\bin (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264CoreIptm3282\lib\tm_5_psos_el_tm3282 (0, 2010-11-25)
VencH264\sd\avs\vencsw\comps\tmVencH264\src\version (0, 2010-11-25)
VencH264\prod\mptk\apps\exSecurity\makefile (12432, 2010-03-04)
VencH264\prod\mptk\apps\exSecurity\diversity.mk (2442, 2009-07-08)
VencH264\prod\mptk\apps\exH264Codec\sys_conf.h (36684, 2009-07-07)
VencH264\prod\mptk\apps\exH264Codec\makefile (7366, 2009-09-30)
VencH264\prod\mptk\apps\exH264Codec\exH264Codec.c (149343, 2010-02-04)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\makefile (19460, 2009-09-17)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\make3282_hw.mk (10902, 2009-10-28)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\make3282.mk (10888, 2009-09-17)
VencH264\sd\avs\vencsw\comps\tmVencH264Coretm3282\diversity.mk (961, 2009-09-17)
... ...

Readme for exSecurity April 2009 The exSecurity application is designed to demonstrate the PNX1005 operating at full capacity by encoding 8 CIF resolution streams into H2*** format. It simultaneously decodes one stream, and displays all on a 3x3 matrix in a 720p display. exSecurity provides an extremely heavy load on the pnx1005 and the program is carefully optimized to work most efficiently. Some of these things are unorthodox by TriMedia standards. If you stray too far from the "usual" mode of operation, you can lose some of this efficiency. This readme is a condensed version of the information found in the "Getting Started with Surveillance Tool Kit" section of the Getting Started manual delivered with NDK 6.0. Please refer there for more information. Please also refer to the latest release notes where any known problems might be recorded. To Build exSecurity: We most often test with an assert build. Using a trace or debug build will have a big effect on performance. We often use a TimeDoctor build, though we have noted that dumping the TimeDoctor buffer can result in a brief underrun. Note the _dh2***e diversity. This selects the H2*** decoder that is matched to the encoder. set _TMTCSHOST=WinNT set _TMTGTREL=assert set _TMDIVERSITY=_dh2***e_pnx1005_sp_ set _APP=exSecurity title %_APP% (proj=%_TMPROJECT%) - %_TMDIVERSITY% (%_TMTGTREL%) build_exeWin -gh %_TMROOT%/prod/mptk/apps/exSecurity 2>&1 | tee logs/Security_ad.txt To Run exSecurity: Be sure your hardware is up to date. exSecurity will not reach its full potential if the CPU is running at less than 400MHz or if the memory is running at less than 266MHz. The bootscript generator in NDK 6.0 is updated and those bootscripts work. As of NDK 6.0, we have not tested with PAL sources. Use NTSC sources. Key command line switches are "-ns" and "-ds". These configure the number of encoders and decoders, respectively. -ns 8 and -ds 1 is the commom case. You can specify less encoders to get a lower CPU load. A typical command line is -ns 8 -file c:\temp\test -bitrate 512000 -ds 1 Which writes the 8 encoded files to c:\temp, with the prefix "test". The 8 files are named test0.h2*** through test7.h2***. When -ds is specified, the decode waits a few seconds until a file has been written, and then it begins decoding that file. So it's typical for the decode file to be a few seconds behind the live feed. The -nofile option is interesting. It disables file writing, and hence -ds also will not work. But the command line -ns 8 -nofile is useful to isolate the operation of the encoders from the file writing system. exSecurity queries the BSL to find out about availabel inputs. On a "test" board with Techwells for input, these 8 inputs are chose. On a demo board, CVBS is the default. If you plug in an HDMI input (NTSC format), this will be used. The complete set of switches is reproduced here. Command line switches supported by exSecurity: -ns Encode N streams. 1-8. -file Output file names begin with this base, including path. -nofile Disable file output for long term testing. -videoOutMode|-mode is xx e.g. 720x480x60p e.g. 720x576x25i (PAL) Default: auto detect best match -videoInMode|-mode is xx e.g. 720x480x60p e.g. 720x576x25i (PAL) -bitrate bitrate in bits per second. -ds Number of decoders to run. -sl Sets tmTr unit to level for debugging -sf [.dsioELel12345crw]+ Sets tmDbg unit flags for debugging -verboseError Displays all component error callbacks on the console -crashOnFatal Disable interrupts and loop forever on a fatal error (useful for diagnosing errors in ISR code) -ramdisk RAM disk size, in megabytes. At least 5 MB, default is 8 MB. All options are case-insensitive How exSecurity Works: The basic requirement for exSecurity is that it must: - accept 8 D1 streams - Display them slightly scaled down in a 3x3 matrix on a 720p monitor - Encode the 8 streams to H2*** at 30fps CIF - Decode one H2*** stream, CIF resolution at 30fps. The encoder and the decoder have approximately equal loads near 40MHz each. 9 streams at 40Mhz is 360MHz, which is a 90% load on a 400MHz PNX1005. With such a heavy load, there is little room for overhead. Well known academic papers have long ago shown (Google Liu and Layland) that a system using a priority based scheduler cannot guarantee it will meet its deadlines if the load is more than 80% of the CPU. For this reason, the 8 encoders are all run deterministically in one task. We call this task the "task manager". The decoders run for a few frames on each stream before switching to another stream. After the encoding is complete, the decoder task is allowed to run. The decoder task runs at a lower priority, so if the system is starved for MHz, the decoder suffers.