Texas Instruments SPRAA56 appendix Splitting the Encode and Decode CELLs

Page 8

SPRAA56

Device

 

YAfter420 720x576

bitBuf

 

414 KB

 

Driver

 

 

 

 

512 KB

 

 

 

Buffer

 

 

 

Y uv

 

 

 

 

 

 

 

3 frames

422to

 

H .263

 

420

C bAfter420

 

 

enc

 

 

 

 

Shared

 

 

 

 

 

 

C rAfter420

 

Scratch

 

 

207 KB

6 KB

92 KB

 

 

 

 

scratch1

 

Instance

 

 

14 KB = 20 lines

m em ory

 

Key

 

 

Internal Memory

DMA Read/W rite (background)

External Memory

CPU Read/W rite

 

DSP CPU Function

 

y

 

414 KB

H .263

Cr

dec

CbArrau

 

 

Cb

1.5 KB

207 KB

 

Instance

 

m em ory

 

Y uv 422to 420

scratch2 14 KB

Device

Driver

Buffer

3 frames

Figure 2. Detailed Application Data Flow Showing Memory Buffers

Note: The dotted lines in Figure 2 indicate EDMA moves, and the solid lines indicate CPU reads/writes. The application performs only CPU reads/writes from mapped internal memory, relying on the EDMA to copy working data into internal scratch buffers.

3.1Splitting the Encode and Decode CELLs

In the base example, the H.263 encoder and decoder are wrapped in sequential CELLs in a single channel. This is suitable for an example application, but in actual video systems the input to the decoder would be an encoded bitstream from an external source, and the output from the encoder would be sent to an external source such as a network stream or a hard disk drive. Splitting the encoder and decoder into separate channels better supports external sourcing or transport of the encoded bitstream. Additionally, splitting the encoder and decoder allows them to be benchmarked separately for execution time.

A separate CHAN was created and initialized for the H.263 encoder and the H.263 decoder. At run-time, a separate CHAN_execute command can be executed for each channel.

3.2Adding the Control TSK and MBX Communication

The second change to the base example was the addition of a control TSK to send control commands to the process TSK using the MBX module from DSP/BIOS. A MBX object, mbxProcess, was added in the DSP/BIOS text-based configuration file appThread.tci. That MBX object transmits control commands to the tskVideoProcess TSK to change run-time parameters such as the video frame rate and the encoder bitrate.

8

DSP/BIOS Real-Time Analysis (RTA) and Debugging Applied to a Video Application

Image 8
Contents Modifications to the Base Example RTA Techniques for Performance MeasurementViewing Benchmarks in the Instrumented Application References Appendix A. Performance ImpactImportant Benchmarks for Video Applications FiguresBase Application Overview SPRAA56TskInput DSP/BIOS and RF5 Components Used 1 LOG4 UTL 2 STS3 TRC Modifications to the Base Example Requirements for Viewing RTA BenchmarksSplitting the Encode and Decode CELLs Adding the Control TSK and MBX CommunicationTskO utput Querying the H.263 Encoder for StatusTskInput Controlling the Frame Rate RTA Techniques for Performance Measurement Measuring Function Execution Time with the UTL ModuleMeasuring Task Scheduling Latencies Measuring End-to-End LatenciesMeasuring the Frame Rate Programmatic Measurement of Total CPU Load Memory Bus Utilization 720*480 = 345,600 B 86,400 B14,400 B External memoryBitrate and Frame Type Methods for Transmitting Measured Performance Data Requirements Viewing Benchmarks in the Instrumented ApplicationApplication-Specific Control via GEL Scripts in CCStudio Running the Application Load the h263loopbackrta.out programSPRAA56 Interpreting the Benchmarks Expected Values for the STS Objects Expected and Measured STS Benchmarks Debug Mode Expected Values Delivered to the Message LogControlling the Run-Time Parameters Dynamically Expected and Measured Logged BenchmarksReferences Capture and Display Task BenchmarkingAppendix A. Performance Impact Overhead of Performance Measurement TechniquesRTA Effects on CPU Load Measured Performance of Benchmarking TechniquesMemory Footprint Memory Footprint DetailsImportant Notice