Visible to Intel only — GUID: nln1640173706403
Ixiasoft
Visible to Intel only — GUID: nln1640173706403
Ixiasoft
26.3. Mixer IP Functional Description
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 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.