Video and Vision Processing Suite Intel® FPGA IP User Guide

ID 683329
Date 12/12/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
1. About the Video and Vision Processing Suite 2. Getting Started with the Video and Vision Processing IPs 3. Video and Vision Processing IPs Functional Description 4. Video and Vision Processing IP Interfaces 5. Video and Vision Processing IP Registers 6. Video and Vision Processing IPs Software Programming Model 7. Protocol Converter Intel® FPGA IP 8. 3D LUT Intel® FPGA IP 9. AXI-Stream Broadcaster Intel® FPGA IP 10. Chroma Key Intel® FPGA IP 11. Chroma Resampler Intel® FPGA IP 12. Clipper Intel® FPGA IP 13. Clocked Video Input Intel® FPGA IP 14. Clocked Video to Full-Raster Converter Intel® FPGA IP 15. Clocked Video Output Intel® FPGA IP 16. Color Space Converter Intel® FPGA IP 17. Deinterlacer Intel® FPGA IP 18. FIR Filter Intel® FPGA IP 19. Frame Cleaner Intel® FPGA IP 20. Full-Raster to Clocked Video Converter Intel® FPGA IP 21. Full-Raster to Streaming Converter Intel® FPGA IP 22. Genlock Controller Intel® FPGA IP 23. Generic Crosspoint Intel® FPGA IP 24. Genlock Signal Router Intel® FPGA IP 25. Guard Bands Intel® FPGA IP 26. Interlacer Intel® FPGA IP 27. Mixer Intel® FPGA IP 28. Pixels in Parallel Converter Intel® FPGA IP 29. Scaler Intel® FPGA IP 30. Stream Cleaner Intel® FPGA IP 31. Switch Intel® FPGA IP 32. Tone Mapping Operator Intel® FPGA IP 33. Test Pattern Generator Intel® FPGA IP 34. Video Frame Buffer Intel® FPGA IP 35. Video Streaming FIFO Intel® FPGA IP 36. Video Timing Generator Intel® FPGA IP 37. Warp Intel® FPGA IP 38. Design Security 39. Document Revision History for Video and Vision Processing Suite User Guide

27.3. Mixer IP Functional Description

The mixer includes alpha blending for each overlay layer. Alpha blending allows you to vary the transparency of the overlay layer as it is mixed onto the existing image.

Alpha blending

The value to determine the level of transparency is the alpha value. The alpha value varies between 0 and 1. 0 represents full transparency (the overlay layer data does not appear at all). 1 represents fully opaque (the overlay layer completely obscures the existing image).

The IP recursively applies alpha blending, with the image from layer 1 (I 1) blended onto the image from layer 0 (I 0) to create the intermediate image (O 1). The IP then blends the image from layer 2 (I 2) onto 0 1 to create O 2, and so on for each of the layers in turn. For a mixer with N layers, O N-1 is the final output image. The equations show the alpha blending:
Equation 2. Alpha Blending

The IP applies the alpha blending process independently to each color plane in the image and only in the areas where the offset overlay image overlaps the intermediate image.

Alpha blending mode

You can parameterize each layer of the mixer to support different options for how the IP superimposes the foreground layer data onto the existing image. The Alpha blending mode parameter has four options:

  • No blending. The mixer does not include the logic required to perform the alpha blending process for the given layer. The IP overlays the layer image onto the existing image without transparency. It completely replaces the pixel value for the existing image with that of the layer image in the appropriate regions of the output image (as defined by the layer offsets and layer dimensions). You may still select to turn off the overlay at runtime via the register map. No blending does not require any DSP blocks.
  • Alpha from command. The IP includes the logic for alpha blending. The IP takes the alpha value from the register map and applies it as a constant (static alpha) value to every pixel in the layer image. You can still turn off the overlay at runtime via the register map or select to ignore the alpha value entirely and revert to no blending.
  • Alpha from data. The IP includes logic for alpha blending. The incoming video data includes an additional color plane that contains a per-pixel alpha value to determine the transparency. The alpha value is always in the highest index color plane, in the MSBs of each pixel. You can still turn off the overlay at runtime via the register map or select to ignore the alpha value entirely and revert to no blending.
  • Alpha from command or data. You have full flexibility to select at runtime between disabling the overlay, overlay with no blending, overlay with static alpha, or overlay with per pixel alpha.

Register map settings

You can adjust the settings for each overlay layer in the mixer at runtime by making edits to the mixer’s register map through the Avalon memory-mapped control agent interface. When you turn on Lite mode, the properties of the base layer are also set via the register map.

Each overlay layer has five runtime controllable settings when you turn off Lite mode:

  • Layer enable (turns the layer on and off)
  • Layer blend mode
  • Layer static alpha
  • Layer horizontal offset
  • Layer vertical offset

When you turn on Lite mode, two additional registers per overlay layer set the expected resolution for that layer. All these registers are double buffered and edits their values only take effect at the next frame boundary. When you turn off Lite mode, a write is required the COMMIT register for any of the edits to take effect at the next frame boundary.

Overlay layer enables

Each overlay layer n (1 <= n <= 7) has a register in the Avalon memory-mapped control agent register map to define if the IP turns on or off the layer (LAYER n _MODE). The three LSBs of the register value determine how the IP processes the layer.

  • Bit 0. The main enable bit for the given layer. If you set this bit to 0, the IP holds the layer at a field boundary with the tready signal set to 0. When you set this bit to 1, the IP accepts the input packets for the given layer, with one field’s worth of packets accepted for every field on the base layer. The IP propagates the control packets to the output, and either displays the field data as part of the output frame or not, depending on the value in bit 1 of the register.
  • Bit 1. This bit determines if the IP displays the layer or not. If you write 0 to this register, the IP mixes the layer’s field data into the output field (display mode) (according to the settings in the LAYER n _BLEND_MODE register). If you write 1 to this register, the IP does not include the layer’s field data (consume mode). In consume mode, the mixer accepts 1 field of layer data for each field of the base layer. The control packets in the layer stream are still propagated to the output. In display mode, the mixer accepts the layer field data at the input only at times when it must make up part of the output image – according to the vertical and horizontal offsets settings for this layer. In consume mode, the mixer accepts the layer field data as quickly as possible, with no reference to the offsets and no attempt to accept one line of layer field data for each line of base field data.
  • Bit 2. This bit determines how the mixer behaves for the first field after any change to the value in the LAYERn_MODE register. If you set this bit to 0 (and bit 0 is set to 1), the mixer waits for data to be available on layer n before starting the output field. If no data is available, the mixer pauses and waits (hard start condition). If you set this bit to 1, the mixer can progress with the output frame, even if a new frame is not ready at the layer n input. At each field boundary the mixer again checks to see if data becomes available. When data is available at layer n, normal mixing for that layer resumes, and the mixer waits for data on subsequent fields if it is not immediately available (soft-start condition).

Carefully consider the difference between the hard- and soft-start conditions when deciding which is more appropriate for your system.

  • If the layer input comes directly from a source that you cannot stall, such as a clocked video input from HDMI or DisplayPort for example, do no use soft start. In this case the IP forces the output to match the start-of-frame timing of the layer input, as anything else forces a stall on the input. Using soft start allows the output to run in sync with the start-of-frame timing of the base layer (or another overlay layer). If the start-of-frame timing of the overlay layer does not exactly align to that of the base layer, the overlay layer misses the output start of frame and holds off for some amount of time, up to a full frame period in the worst case. This behavior causes the input to overflow.
  • Unless multiple input layers are being externally controlled to force an alignment of their start-of-frame and frame rates, only one layer may come directly from a nonstable source. If the layers are not synchronized at the input, there is no way that each of them can have a hard start without at least one being stalled and overflowing. This typically means that, at most, only one layer should use the hard start condition.
  • Typically, a source that you can stall drives most layers – such as a frame buffer with drop or repeat of frames. You can stall a frame buffer without overflowing. A soft start condition is more appropriate, as it allows any existing output from the mixer to retain its current start-of-frame timing. The overlay layer from the frame buffer synchronizes to the existing timing. Because the output timing stays the same, no glitch in any display connected to it occurs.

The mixer does not commit to processing a field until the data for all layers is pending at each input. Until the IP reaches this condition, the mixer remains in a state where you can still edit the register map via the Avalon memory-mapped control agent interface. The changes take effect immediately because the mixer is between fields. If the system experiences a loss of video on any input, the system controller can turn off the given layer and avoid lock-up in the system.

Restricted offsets

You supply a horizontal offset for each overlay layer. This determines the pixel index within the line at which that layer begins to be mixed onto the background. If the number of pixels in parallel is 1, it is trivial to begin mixing at any pixel offset. If the number of pixels in parallel is greater than 1, any offset that is not an integer multiple of pixels in parallel gives additional challenges.

The mixer must include logic to shift pixels within and across data words by any number of pixels between 0 and the number of pixels in parallel minus 1. If the number of pixels in parallel is small, the ALM cost of this extra hardware is relatively small, but at 4 to 8 pixels in parallel the resource usage can be a significant proportion of the overall mixer ALM count.

If you limit the horizontal offset for any layer such that it is always an integer multiple of the pixels in parallel, you can turn on use restricted offsets for that layer. Then the mixer omits the extra pixel shifting logic for that layer and reduces the ALM cost. If you turn on use restricted offsets for any layer and you try to set a horizontal offset for that layer to a noninteger multiple of pixels in parallel, the internal logic moves the offset back to the nearest integer position.

Subsampling support

The mixer supports 4:4:4, 4:2:2 and 4:2:0 chroma sampled video data and can switch dynamically between chroma samplings at runtime. Full variants drive the current chroma sampling by the image information packet that accompanies each field. Lite variants let you set the chroma sampling via the register map. The following restrictions regarding chroma sampling apply:

  • All layers must be the same chroma sampling as the base layer (layer 0).
  • For 4:2:2 chroma sampling, the field width for all layers (including the base layer) must be an integer multiple of 2.
  • For 4:2:2 chroma sampling, the horizontal offset for each active overlay layer must be an integer multiple of 2.
  • For 4:2:0 chroma sampling, both the field height and field width for all layers (including the base layer) must be integer multiples of 2.
  • For 4:2:0 chroma sampling, both the horizontal and vertical offsets for each active layer must be integer multiples of 2.

Interlaced support

The mixer is mainly for progressive video but does have limited support for interlaced video for full variants. You should apply vertical offsets within each field and not within the progressive frame. Each layer should supply either an F0 or F1 field in sync with the base layer (layer 0). If any layer that you turn on for display provides an F1 field when the base layer provides F0, or vice versa, the IP asserts the broken-field flag in the output end of frame packet.

Overlay error conditions

Each overlay layer has an expected field width and height, derived either from the image information packets for full variants, or the register map for lite variants. Each layer also has a horizontal and vertical offset within the base layer which you specify through the register map. If the sum of the overlay field width and the horizontal offset for any layer exceed the field width of the base layer, the IP does not display layer (the IP forces the layer into consume mode). The IP asserts the broken-field flag in the output end of frame packet

Packet propagation

In the full variant of Intel FPGA streaming video, the input stream on each layer may contain image information, end of field, and auxiliary control packets with the video line packets. The mixer adheres to the following rules when handling these packets from each layer:

  • Image information and end of frame packets. The image information and end of frame packet from the base layer (layer 0) propagate to the output. The image information packet is always unaltered. The end of frame packet propagates with the broken-field flag potentially edited, but otherwise unaltered. If the IP asserts the broken-field flag in the base layer or any displayed overlay layer. Then the IP asserts the output broken field flag. The broken-field flag in the end of frame packet may also be asserted if the mixer experiences an error during processing, such as an interlaced field mismatch.
  • Auxiliary control packets. When any layer is active, either for display or consume, its auxiliary control packets propagate to the output with the video packets from the base layer. The IP takes the auxiliary control packets from each layer in sequence, both before and after the field line packets.
Figure 61. Control packet propagationThe figure assumes n layers and all n layers are active on the current field: