12-6	Pass-Through Mode for Progressive Frames	UG-VIPSUITE
			2015.01.23

Pass-Through Mode for Progressive Frames

In its default configuration, the Deinterlacing IP cores discard progressive frames.

Change this behavior if you want a datapath compatible with both progressive and interlaced inputs and where run-time switching between the two types of input is allowed. When the Deinterlacing IP cores let progressive frames pass through, the deinterlacing algorithm in use (bob, weave or motion-adaptive) propagates progressive frames unchanged. The function maintains the double or triple-buffering function while propagating progressive frames.

Note: Enabling the propagation of progressive frames impacts memory usage in all the parameterizations of the bob algorithm that use buffering.

Frame Buffering

The Deinterlacing IP cores allow frame buffering in external RAM, which you can configure at compile time.

Altera Corporation	Deinterlacing IP Cores

Send Feedback

UG-VIPSUITE 2015.01.23

Frame Buffering

12-7

•Deinterlacer IP core

•When using either of the two bob algorithm subtypes, you can select no buffering, doublebuffering, or triple-buffering.

•The weave and motion-adaptive algorithms require some external frame buffering, and in those cases only select double-buffering or triple-buffering.

•Deinterlacer II and Broadcast Deinterlacer IP cores

•The motion-adaptive algorithms require some external frame buffering, and does not support triple-buffering.

When you chose no buffering, input pixels flow into the Deinterlacing IP core through its input port and, after some delay, calculated output pixels flow out through the output port. When you select double-buffering, external RAM uses two frame buffers. Input pixels flow through the input port and into one buffer while pixels are read from the other buffer, processed and output. When both the input and output sides have finished processing a frame, the buffers swap roles so that the frame that the output can use the frame that you have just input. You can overwrite the frame that the function uses to create the output with a fresh input.

The motion-adaptive algorithm uses four fields to build a progressive output frame and the output side has to read pixels from two frame buffers rather than one. Consequently, the motion-adaptive algorithm actually uses three frame buffers in external RAM when you select double-buffering. When the input and output sides finish processing a frame, the output side exchanges its buffer containing the oldest frame, frame n-2, with the frame it receives at the input side, frame n. It keeps frame n-1 for one extra iteration because it uses it with frame n to produce the next output.

When triple-buffering is in use, external RAM usually uses three frame buffers. The function uses four frame buffers when you select the motion-adaptive algorithm. At any time, one buffer is in use by the input and one (two for the motion adaptive case) is (are) in use by the output in the same way as the double-buffering case. The last frame buffer is spare.

This configuration allows the input and output sides to swap asynchronously. When the input finishes, it swaps with the spare frame if the spare frame contains data that the output frame uses. Otherwise the function drops the frame which you have just wrote and the function writes a fresh frame over the dropped frame.

When the output finishes, it also swaps with the spare frame and continues if the spare frame contains fresh data from the input side. Otherwise it does not swap and just repeats the last frame.

Triple-buffering allows simple frame rate conversion. For example, suppose you connect the Deinter lacing IP core’s input to a HDTV video stream in 1080i60 format and connect its output i to a 1080p50 monitor. The input has 60 interlaced fields per second, but the output tries to pull 50 progressive frames per second.

If you configure the Deinterlacing IP cores to output one frame for each input field, it produces 60 frames of output per second. If you enable triple-buffering, on average the function drops one frame in six so that it produces 50 frames per second. If you chose one frame output for every pair of fields input, the Deinterlacing IP cores produce 30 frames per second output and triple-buffering leads to the function repeating two out of every three frames on average.

When you select double or triple-buffering, the Deinterlacing IP cores have two or more Avalon-MM master ports. These must be connected to an external memory with enough space for all of the frame buffers required. The amount of space varies depending on the type of buffering and algorithm selected. An estimate of the required memory is shown in the Deinterlacing IP cores parameter editor.

If the external memory in your system runs at a different clock rate to the Deinterlacing IP cores, you

Deinterlacing IP Cores Altera Corporation can turn on an option to use a separate clock for the Avalon-MM master interfaces and use the

Send Feedbackmemory clock to drive these interfaces.

To prevent memory read and write bursts from being spread across two adjacent memory rows, you can turn on an option to align the initial address of each read and write burst to a multiple of the burst target used for the read and write masters (or the maximum of the read and write burst targets if using

	12-8	Frame Rate Conversion	UG-VIPSUITE
			2015.01.23

Frame Rate Conversion

When you select triple-buffering, the decision to drop and repeat frames is based on the status of the spare buffer. Because the input and output sides are not tightly synchronized, the behavior of the Deinterlacer is not completely deterministic and can be affected by the burstiness of the data in the video system. This may cause undesirable glitches or jerky motion in the video output.

By using a double-buffer and controlling the dropping/repeating behavior, the input and output can be kept synchronized. For example, if the input has 60 interlaced fields per second, but the output requires 50 progressive frames per second (fps), setting the input frame rate to 30 fps and the output frame rate at 50 fps guarantees that exactly one frame in six is dropped.

To control the dropping/repeating behavior and to synchronize the input and output sides, you must select double-buffering mode and turn on Run-time control for locked frame rate conversion in the Parameter Settings tab of the parameter editor. The input and output rates can be selected and changed at run time. Table 15–5 on page 15–15 lists the control register map.

The rate conversion algorithm is fully compatible with a progressive input stream when the progressive passthrough mode is enabled but it cannot be enabled simultaneously with the run-time override of the motion-adaptive algorithm.

Note: Only Deinterlacer IP core supports triple-buffering.

Bandwidth Requirement Calculations for 10-bit YCbCr Video

Because the memory subsystem packs 20-bit colors in 256-bit data words, some of the bits in a data word are unused. These bits must be factored into the bandwidth requirement calculations.

The bandwidth calculation slightly differs for the Deinterlacer II and Broadcast Deinterlacer IP cores.

Altera Corporation	Deinterlacing IP Cores

Send Feedback

UG-VIPSUITE 2015.01.23

Behavior When Unexpected Fields are Received

12-9

•Deinterlacer II processing 1080i60 input data

•Phase 1: Read 2 lines = 1920 × 10 bits × 2 (YCbCr) × 2 × 1.0665 (inefficiency) = 81, 907.2 bits per line

•Phase 2: Write 1 line, read 1 line = 1920 × 10 bits × 2 × 2 × 1.0665 = 81, 907.2 bits per line Read and write motion = 1920 × 8 bits × 2 × (one read and one write) = 30, 720 bits per line

•Image data = Phase 1 + phase 2 accesses = 163, 814.4 bits of image data per line pair × 540 pairs = 88, 459,776 bits per output frame

•Motion data = 30, 720 bits per line pair

30, 720 × 540 pairs = 16,588,800 bits per output frame

16,588,800 × 60 frames per second = 995,328,000 = 0.995 GBps of motion data written/read Total = 5.307 + 0.995 = 6.302 GBps

•Broadcast Deinterlacer processing 1080i60 input data

•Phase 1: Read 2 lines = 1920 × 10 bits × 2 (YCbCr) × 2 × 1.0665 (inefficiency) = 81, 907.2 bits per line

•Phase 2: Write 1 line, read 1 line = 1920 × 10 bits × 2 × 2 × 1.0665 = 81, 907.2 bits per line

Read and write motion, and video over film context bits = 1920 × 32 bits × 2 = 122, 880 bits per line

•Image data = Phase 1 + phase 2 accesses = 163, 814.4 bits of image data per line pair × 540 pairs = 88, 459, 776 bits per output frame

88, 459, 776 × 60 frames per second = 5, 307, 586, 560 = 5.307 GBps of image data read/written

•Motion/video-over-film data = 122, 880 bits per line pair 122, 880 × 540 pairs = 66, 355, 200 bits per output frame

66, 355, 200 × 60 frames per second = 3, 981, 312, 000 = 3.981 GBps of motion data written/read Total = 5.307 + 3.981 = 9.288 GBps

Behavior When Unexpected Fields are Received

So far, the behavior of the Deinterlacer has been described assuming an uninterrupted sequence of pairs of interlaced fields (F0, F1, F0, …) each having the same height. Some video streams might not follow this rule and the Deinterlacer adapts its behavior in such cases.

The dimensions and type of a field (progressive, interlaced F0, or interlaced F1) are identified using information contained in Avalon-ST Video control packets. When a field is received without control packets, its type is defined by the type of the previous field. A field following a progressive field is assumed to be a progressive field and a field following an interlaced F0 or F1 field is respectively assumed to be an interlaced F1 or F0 field. If the first field received after reset is not preceded by a control packet, it is assumed to be an interlaced field and the default initial field (F0 or F1) specified in the parameter editor is used.

When the weave or the motion-adaptive algorithms are used, a regular sequence of pairs of fields is expected. Subsequent F0 fields received after an initial F0 field or subsequent F1 fields received after an initial F1 field are immediately discarded.

Deinterlacing IP Cores	Altera Corporation

Send Feedback