IPSR-VIDEO Altera, IPSR-VIDEO Datasheet - Page 125

• Manufacturer Part Number: IPSR-VIDEO
• Description: RENEWAL Of IPS-VIDEO
• Manufacturer: Altera
• Series: IP Suitesr

Specifications of IPSR-VIDEO

• Software Application: IP CORE, SUITES
• Supported Families: Arria GX, Cyclone II, HardCopy II, Stratix II
• Features: Common Avalon Streaming (Avalon-St) Interface And Avalon-St Video Protocol
• Core Architecture: FPGA
• Core Sub-architecture: Arria, Cyclone, Stratix
• Rohs Compliant: NA
• Lead Free Status / RoHS Status: na

Chapter 5: Functional Descriptions
Deinterlacer
January 2011 Altera Corporation
Behavior When Unexpected Fields are Received
Handling of Avalon-ST Video Control Packets
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.
page 7–9
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.
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.
When the bob algorithm is used and synchronization is done on a specific field (input
frame rate = output frame rate), the field that is constantly unused is always
discarded. The other field is used to build a progressive frame, unless it is dropped by
the triple-buffering algorithm.
When the bob algorithm is used and synchronization is done on both fields (input
field rate = output frame rate), the behavior is dependent on whether buffering is
used. If double or triple-buffering is used, the bob algorithm behaves like the weave
and motion-adaptive algorithms and a strict sequence of F0 and F1 fields is expected.
If two or more fields of the same type are received successively, the extra fields are
dropped. When buffering is not used, the bob algorithm always builds an output
frame for each interlaced input field received regardless of its type.
If passthrough mode for progressive frames has not been selected, the Deinterlacer
immediately discards progressive fields in all its parameterizations.
When buffering is used, the Deinterlacer MegaCore function stores non-image data
packets in memory as described in
Memory” on page
describes the control register map.
4–21.
“Buffering of Non-Image Data Packets in
Video and Image Processing Suite User Guide
Table 7–8 on
5–45