Buffer¶

Maintain a sliding window buffer of the last N values by storing recent inputs in a FIFO (First-In-First-Out) queue, with newest elements added to the beginning and oldest elements automatically removed when the buffer exceeds the specified length, enabling temporal data collection, frame history tracking, batch processing preparation, and sliding window analysis workflows.

How This Block Works¶

This block maintains a rolling buffer that stores the most recent values passed to it, creating a sliding window of data over time. The block:

1. Receives input data of any type (images, detections, values, etc.) and configuration parameters (buffer length and padding option)
2. Maintains an internal buffer that persists across workflow executions:
3. Buffer is initialized as an empty list when the block is first created
4. Buffer state persists for the lifetime of the workflow execution
5. Each buffer block instance maintains its own separate buffer
6. Adds new data to the buffer:
7. Inserts the newest value at the beginning (index 0) of the buffer array
8. Most recent values appear first in the buffer
9. Older values are shifted to later positions in the array
10. Manages buffer size:
11. When buffer length exceeds the specified length parameter, removes the oldest elements
12. Keeps only the most recent length values
13. Automatically maintains the sliding window size
14. Applies optional padding:
15. If pad is True: Fills the buffer with None values until it reaches exactly length elements
16. Ensures consistent buffer size even when fewer than length values have been received
17. If pad is False: Buffer size grows from 0 to length as values are added, then stays at length
18. Returns the buffered array:
19. Outputs a list containing the buffered values in order (newest first)
20. List length equals length (if padding enabled) or current buffer size (if padding disabled)
21. Values are ordered from most recent (index 0) to oldest (last index)

The buffer implements a sliding window pattern where new data enters at the front and old data exits at the back when capacity is reached. This creates a temporal history of recent values, useful for operations that need to look back at previous frames, detections, or measurements. The buffer works with any data type, making it flexible for images, detections, numeric values, or other workflow outputs.

Common Use Cases¶

• Frame History Tracking: Maintain a history of recent video frames for temporal analysis (e.g., track frame sequences, maintain recent image history, collect frames for comparison), enabling temporal frame analysis workflows
• Detection History: Buffer recent detections for trend analysis or comparison (e.g., track detection changes over time, compare current vs previous detections, analyze detection patterns), enabling detection history workflows
• Batch Processing Preparation: Collect multiple values before processing them together (e.g., batch process recent images, aggregate multiple detections, prepare data for batch operations), enabling batch processing workflows
• Sliding Window Analysis: Perform analysis on a rolling window of data (e.g., analyze trends over recent frames, calculate moving averages, detect changes in sequences), enabling sliding window analysis workflows
• Visualization Sequences: Maintain recent data for animation or sequence visualization (e.g., create frame sequences, visualize temporal changes, display recent history), enabling temporal visualization workflows
• Temporal Comparison: Compare current values with recent historical values (e.g., compare current frame with previous frames, detect changes over time, analyze temporal patterns), enabling temporal comparison workflows

Connecting to Other Blocks¶

This block receives data of any type and produces a buffered output array:

• After any block that produces values to buffer (e.g., buffer images from image sources, buffer detections from detection models, buffer values from analytics blocks), enabling data buffering workflows
• Before blocks that process arrays to provide batched or historical data (e.g., process buffered images, analyze detection arrays, work with value sequences), enabling array processing workflows
• Before visualization blocks to display sequences or temporal data (e.g., visualize frame sequences, display detection history, show temporal patterns), enabling temporal visualization workflows
• Before analysis blocks that require historical data (e.g., analyze trends over time, compare current vs historical, process temporal sequences), enabling temporal analysis workflows
• Before aggregation blocks to provide multiple values for aggregation (e.g., aggregate buffered values, process multiple detections, combine recent data), enabling aggregation workflows
• In temporal processing pipelines where maintaining recent history is required (e.g., track changes over time, maintain frame sequences, collect data for temporal analysis), enabling temporal processing workflows

Requirements¶

This block works with any data type (images, detections, values, etc.). The buffer maintains state across workflow executions within the same workflow instance. The length parameter determines the maximum number of values to keep in the buffer. When pad is enabled, the buffer will always return exactly length elements (padded with None if needed). When pad is disabled, the buffer grows from 0 to length elements as values are added, then maintains length elements by removing oldest values. The buffer persists for the lifetime of the workflow execution and resets when the workflow is restarted.

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/buffer@v1to add the block as as step in your workflow.

Properties¶

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Runtime compatibility¶

soft — runtime hosted_serverless, dedicated_deployment; execution remote; input video

Block keeps per-video state in process memory (keyed by video_metadata.video_identifier). With remote step execution on stateless or multi-replica HTTP runtimes, successive requests may be served by different worker processes, so the state resets between calls and the output is meaningless for tracking / counting / aggregation. Use local step execution in an InferencePipeline for stable cross-frame results.

soft — input image

Block depends on temporal context from video or repeated-frame workflows. With a still image/photo, there is no meaningful history to track, compare, aggregate, or visualize, so the block provides little or no benefit.

Available Connections¶

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Buffer in version v1 has.

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/buffer@v1",
    "data": "$steps.visualization",
    "length": 5,
    "pad": true
}