fix: adjust action validation and preserve recording timeline gaps

This commit is contained in:
somew1nd committed 2026-09-03 16:29:09 -07:00
1 parent 2fea9865ee
commit ab03e1d2bb
15 files changed
+235 -401

No files matched your search

+10 -1
View File
@@ -566,7 +566,16 @@ def _persist_stream(
influences booking or release (the ledger stays the source of truth).
"""
segments = capture.segments
if not attempt_id or not segments:
if not attempt_id:
return
thoughts = sum(1 for s in segments if s["role"] == "thought")
chars = sum(len(s["text"]) for s in segments)
# Log empty turns too, so missing transcripts can be checked in the session log.
logger.info(
f"Checker transcript for {attempt_id}: {len(segments)} segment(s)"
f" ({thoughts} thought, {len(segments) - thoughts} answer), {chars} chars"
)
if not segments:
return
try:
from artemis.graph.checkpoints import append_attempt_stream_record
+1 -1
View File
@@ -1,3 +1,3 @@
{
"main_template": "# ROLE\nYou are the Android Device Operator. Your priority is execution accuracy. You must operate the device step-by-step to achieve the goal, avoiding blind attempts or loops.\n\n# OPERATIONAL PRINCIPLES\n- **Action Scope & Interaction Precision**: Always select gestures whose scope of effect matches the boundaries of the target element. Avoid shortcuts or batch actions from popups or menus if they risk affecting non-target UI components on the screen.\n- **Vision-First Priority**: The screenshot is the primary source of truth for the real device state. Always visually inspect the screen state and layout on the screenshot before referencing the element list. Use the 'Visible UI Elements' list strictly as an auxiliary lookup table to retrieve target element indices and coordinates.\n[% if \"wait_for_delay\" in available_tools %]- **Loading & Transitions**: When entering page transitions (e.g., app launching, web page loading, or progress indicators), use `wait_for_delay` to let the screen settle before executing target actions. Some transition states are difficult to discern, such as a thin progress line at the top of the browser screen during webpage loads. Before questioning whether an error has occurred, you can first adopt a waiting strategy to see how the device state evolves. If the state remains ambiguous after waiting, certain UI components might be malfunctioning or failing to load; in this case, consider retrying the action or pivoting to an alternative path.\n[% endif %]- **Large List & Long Text Exploration Strategy (Zero-Miss, Zero-Duplication Single-Pass Principle)**: When traversing large lists, browsing long text bodies, or scanning continuous content feeds, strictly adhere to the single-pass exploration standard:\n 1. **Unidirectional Anchor-Based Traversal (Zero-Miss)**: Maintain a consistent, unidirectional scan (e.g., uniform downward scrolling). Before each scroll, identify the bottom-most visible item/text segment as your visual anchor and carry that anchor plus the scan direction in short-term memory or the traversal ledger. After the scroll, evaluate this handoff before doing anything unrelated: if the anchor remains visible with new content beyond it, record the new content and continue in the same direction without scrolling back to verify; if the anchor is missing, continuity is uncertain, so perform at most one minimal reverse recovery to re-establish overlap, then resume the original direction. While the traversal's declared exit condition remains unresolved, keep this traversal active and do not advance to another milestone or mark it complete.\n 2. **Boundary-Proven Completion**: A single scroll that reveals no new content is not sufficient evidence that the list is complete. For an exhaustive traversal, stop only when an explicit end-of-list indicator is visible, or when one additional successful swipe in the same direction and within the same list container leaves the same final anchor visible with no new items and no loading state. This boundary probe must remain unidirectional; never reverse direction merely to prove completion. If the task declares an earlier exit condition (for example, find one verified match or process N items), that explicit condition may end the traversal without reaching the list boundary.\n 3. **Memory & Plan-Driven Deduplication (Zero-Duplication)**: Systematically log extracted item names, identifiers, or processing states into notes or memory as you progress. After every screen transition, cross-reference visible items against your recorded ledger and strictly interact only with newly surfaced, unrecorded items to eliminate redundant actions on overlapping elements. Proactively maintain subtasks in `task_plan` (e.g., segmenting by batch, category, or alphabetical ranges like `a-d`), tracking exact paths and progress to prevent backtracking.\n 4. **Single-Pass Trust & Anti-Oscillation (No Over-Verification)**: Treat recorded notes as verified ground truth. Once a segment is traversed with confirmed anchor continuity and logged, consider it permanently resolved. Do NOT scroll back-and-forth or perform redundant re-scans for \"double-checking\", even if older execution history has been pruned. Resume from the last recorded anchor and direction. Only the single bounded recovery above, or a refreshed/mutated list, permits limited re-verification; otherwise continue the single pass over new content.\n- **Dynamic Monitoring & Reactive Loop Protocol (Monitor-Trigger-Action)**: When executing an active milestone matching `[Loop] <Goal> into note <TargetNote> (Exit: <ExitCondition>; Interval: <Interval>)` or `[Loop:continuous] <Goal> into note <TargetNote> (Interval: <Interval>)` (the milestone grammar itself is defined under Task Plan Grammar below), run this 5-step cyclic state machine:\n - **Step 1 (Baseline Sync)**: On the initial cycle, observe all visible entries/metrics in the primary monitoring view and save the full snaLine truncated
"main_template": "# ROLE\nYou are the Android Device Operator. Your priority is execution accuracy. You must operate the device step-by-step to achieve the goal, avoiding blind attempts or loops.\n\n# OPERATIONAL PRINCIPLES\n- **Action Scope & Interaction Precision**: Always select gestures whose scope of effect matches the boundaries of the target element. Avoid shortcuts or batch actions from popups or menus if they risk affecting non-target UI components on the screen.\n- **Vision-First Priority**: The screenshot is the primary source of truth for the real device state. Always visually inspect the screen state and layout on the screenshot before referencing the element list. Use the 'Visible UI Elements' list strictly as an auxiliary lookup table to retrieve target element indices and coordinates.\n[% if \"wait_for_delay\" in available_tools %]- **Loading & Transitions**: When entering page transitions (e.g., app launching, web page loading, or progress indicators), use `wait_for_delay` to let the screen settle before executing target actions. Some transition states are difficult to discern, such as a thin progress line at the top of the browser screen during webpage loads. Before questioning whether an error has occurred, you can first adopt a waiting strategy to see how the device state evolves. If the state remains ambiguous after waiting, certain UI components might be malfunctioning or failing to load; in this case, consider retrying the action or pivoting to an alternative path.\n[% endif %]- **Large List & Long Text Exploration Strategy (Zero-Miss, Zero-Duplication Single-Pass Principle)**: When traversing large lists, browsing long text bodies, or scanning continuous content feeds, strictly adhere to the single-pass exploration standard:\n 1. **Unidirectional Anchor-Based Traversal (Zero-Miss)**: Maintain a consistent, unidirectional scan (e.g., uniform downward scrolling). Before each scroll, identify the bottom-most visible item/text segment as your visual anchor and carry that anchor plus the scan direction in short-term memory or the traversal ledger. After the scroll, evaluate this handoff before doing anything unrelated: if the anchor remains visible with new content beyond it, record the new content and continue in the same direction without scrolling back to verify; if the anchor is missing, continuity is uncertain, so perform at most one minimal reverse recovery to re-establish overlap, then resume the original direction. While the traversal's declared exit condition remains unresolved, keep this traversal active and do not advance to another milestone or mark it complete.\n 2. **Boundary-Proven Completion**: A single scroll that reveals no new content is not sufficient evidence that the list is complete. For an exhaustive traversal, stop only when an explicit end-of-list indicator is visible, or when one additional successful swipe in the same direction and within the same list container leaves the same final anchor visible with no new items and no loading state. This boundary probe must remain unidirectional; never reverse direction merely to prove completion. If the task declares an earlier exit condition (for example, find one verified match or process N items), that explicit condition may end the traversal without reaching the list boundary.\n 3. **Memory & Plan-Driven Deduplication (Zero-Duplication)**: Systematically log extracted item names, identifiers, or processing states into notes or memory as you progress. After every screen transition, cross-reference visible items against your recorded ledger and strictly interact only with newly surfaced, unrecorded items to eliminate redundant actions on overlapping elements. Proactively maintain subtasks in `task_plan` (e.g., segmenting by batch, category, or alphabetical ranges like `a-d`), tracking exact paths and progress to prevent backtracking.\n 4. **Single-Pass Trust & Anti-Oscillation (No Over-Verification)**: Treat recorded notes as verified ground truth. Once a segment is traversed with confirmed anchor continuity and logged, consider it permanently resolved. Do NOT scroll back-and-forth or perform redundant re-scans for \"double-checking\", even if older execution history has been pruned. Resume from the last recorded anchor and direction. Only the single bounded recovery above, or a refreshed/mutated list, permits limited re-verification; otherwise continue the single pass over new content.\n- **Dynamic Monitoring & Reactive Loop Protocol (Monitor-Trigger-Action)**: When executing an active milestone matching `[Loop] <Goal> into note <TargetNote> (Exit: <ExitCondition>; Interval: <Interval>)` or `[Loop:continuous] <Goal> into note <TargetNote> (Interval: <Interval>)` (the milestone grammar itself is defined under Task Plan Grammar below), run this 5-step cyclic state machine:\n - **Step 1 (Baseline Sync)**: On the initial cycle, observe all visible entries/metrics in the primary monitoring view and save the full snaLine truncated
}
+2 -2
View File
@@ -741,8 +741,8 @@ class OperatorNode:
)
action_calls_to_translate = []
elif len(action_calls) > burst_cap:
# A multi-action turn is a fast-action burst: the Validator vets its first
# member, fires the rest unvetted; cap its length before it runs.
# A multi-action turn is a fast-action burst that the Validator
# fires without the safety net; cap its length before it runs.
validation_errors = True
for tc in action_calls:
tool_outputs.append(
+1 -1
View File
@@ -30,6 +30,6 @@ You will receive:
- **CHRONOLOGICAL STEP TRACE (CURRENT STEP)**: The step-by-step chronological history of the current execution turn, including:
- `[Operator Monologue] / [Operator Native Thought]`: The operator's planning, intentions, progress counting, reasoning, verified states, and explicit mentions of missing prerequisites.
- `[Operator Tool Call] / [Operator Final Action]`: The actual action(s) planned and executed.
- `[Planned Fast-Action Burst]`: A multi-action turn: the first member is vetted by the safety net, the rest fire back to back unvetted; each member's outcome is listed.
- `[Planned Fast-Action Burst]`: A multi-action turn executed back to back without the safety net, with each member's outcome.
- `[Pre-Execution Safety Net]`: Validation checks prior to action execution.
- `[Result]`: The Validator's execution outcome; an "Error:" line here is an execution incident the Operator must resolve.
+24 -82
View File
@@ -18,14 +18,12 @@ Two execution tiers, selected by how many turn-ending actions the Operator
emitted in the turn:
* **Vetted single action** (one action): the pre-execution Safety Net runs
first (XML-first; the pixel judge decides only when the XML verdict is
weak), then the action executes locally with a short retry loop.
* **Fast-action burst** (two or more actions): the first member is vetted by
the same Safety Net (the screen it was decided on is still the live screen)
and a refusal aborts the whole burst; the remaining members fire back to
back with no safety net, no retries and no screenshots in between. The burst
is the Operator's tool against turn latency (transient menus, toasts,
control bars); the Operator owns the risk. The first failure aborts the rest.
first (XML-first with pixel fallback), then the action executes locally with
a short retry loop.
* **Fast-action burst** (two or more actions): the actions fire back to back
with no safety net, no retries and no screenshots in between. The burst is
the Operator's tool against turn latency (transient menus, toasts, control
bars); the Operator owns the risk. The first failure aborts the rest.
Either way, a failure does not spawn a repair agent. The loop opens an
*execution incident* (:mod:`artemis.agents.validator.incidents`) that rides in
@@ -51,7 +49,6 @@ from artemis.agents.validator.incidents import (
KIND_SAFETY_NET,
open_incident,
)
from artemis.agents.validator.precondition_xml import XML_VERDICT_STRONG
from artemis.data_engine.trace import CURRENT_TRACE_ID
from artemis.graph.state import State
from artemis.utils.coordinates import normalize_action_dict
@@ -76,29 +73,10 @@ class _ActionOutcome:
post_screenshot_b64: str | None = None
#: ``safety_net_evidence`` keys the incident carries through verbatim (how the
#: verdict was reached), next to the normalized location/occupant facts.
_VERDICT_EVIDENCE_KEYS = ("xml_verdict", "xml_element_count", "xml_weak_reason", "pixel_judge")
def _note_pixel_judge(action_item: dict, note: str) -> None:
"""Records on the action item how the pixel judge figured in the verdict."""
action_item.setdefault("safety_net_evidence", {})["pixel_judge"] = note
async def _run_precondition_gate(
node, session, action_item: dict, state: State, pre_screenshot_b64: str, original_coords: list
) -> tuple[bool, ValidationErrorCategory, str]:
"""Runs the pre-execution Safety Net: XML-first, pixel judge for weak verdicts.
The pixel judge (a VLM call) is a fallback for when the hierarchy could not
see the target, never a second opinion when it could. A STRONG XML failure
(healthy, non-trivial tree; the target's identifiers were searched and not
found) is final and blocks the action without consulting the judge. A WEAK
one (XML bypassed/timed out, sparse tree, identifier-less target) hands the
decision to the judge. The path taken is recorded in ``safety_net_evidence``
and appended to the reason as one short clause.
"""
"""Runs the pre-execution Safety Net: XML-first with pixel fallback."""
is_explorer_candidate = action_item.get("target_class") == "ExplorerCandidate"
is_ocr_element = "[OCR]" in str(action_item.get("target_class") or "")
has_index_metadata = bool(
@@ -111,17 +89,14 @@ async def _run_precondition_gate(
and not is_ocr_element
)
async def _pixel_judge(note: str) -> tuple[bool, ValidationErrorCategory, str]:
passed, category, error = await node._validate_action_precondition_pixel(
async def _pixel_check() -> tuple[bool, ValidationErrorCategory, str]:
return await node._validate_action_precondition_pixel(
session, action_item, pre_screenshot_b64, original_coords, state=state
)
if not passed:
_note_pixel_judge(action_item, note)
return passed, category, error
if not has_index_metadata:
# Pure coordinate/non-index interactions: the pixel judge is the only gate.
return await _pixel_judge("consulted alone (target had no hierarchy metadata)")
# Pure coordinate/non-index interactions: pixel-based validation is the only gate.
return await _pixel_check()
# Index-based validation is fastest and safest when metadata is present
(
@@ -135,37 +110,21 @@ async def _run_precondition_gate(
if validation_category == ValidationErrorCategory.XML_BYPASSED:
logger.info(
"Pre-execution XML-based validation bypassed"
f" ({validation_error}). Falling back to"
" Pixel-based validation..."
f"Pre-execution XML-based validation bypassed ({validation_error})."
" Falling back to Pixel-based validation..."
)
return await _pixel_judge("consulted alone (XML bypassed)")
return await _pixel_check()
evidence = action_item.get("safety_net_evidence") or {}
if evidence.get("xml_verdict") == XML_VERDICT_STRONG:
clause = (
f"XML verdict final: {evidence.get('xml_element_count')} nodes searched for the"
" target's identifiers; pixel judge not consulted"
)
_note_pixel_judge(action_item, "not consulted (strong XML verdict)")
logger.info(f"Pre-execution XML-based validation failed: {validation_error}. {clause}.")
return False, validation_category, f"{validation_error} [{clause}]"
weak_reason = evidence.get("xml_weak_reason") or "no verdict strength recorded"
logger.info(
f"Pre-execution XML-based validation failed: {validation_error}. XML evidence is"
f" weak ({weak_reason}); asking the pixel judge..."
)
pixel_passed, pixel_category, _pixel_error = await _pixel_judge(
"consulted (weak XML verdict); did not confirm the target"
f"Pre-execution XML-based validation failed: {validation_error}."
" Attempting Pixel-based validation fallback..."
)
pixel_passed, pixel_category, _pixel_error = await _pixel_check()
if pixel_passed and pixel_category == ValidationErrorCategory.NONE:
logger.success("Pixel judge confirmed the target is present; overriding weak XML verdict.")
action_item.pop("safety_net_evidence", None)
logger.success("Pixel validation confirmed the target after XML validation failed.")
return True, ValidationErrorCategory.NONE, ""
clause = f"XML evidence weak ({weak_reason}); pixel judge did not confirm the target"
return validation_passed, validation_category, f"{validation_error} [{clause}]"
return validation_passed, validation_category, validation_error
async def _attempt_local_execution(
@@ -215,19 +174,14 @@ async def _process_action(
pre_screenshot_b64: str,
*,
burst: bool,
vetted: bool = True,
) -> _ActionOutcome:
"""Runs precondition checks (``vetted`` items only) and execution for one action item.
``vetted`` is True for a single action and for the first member of a burst;
later burst members fire unvetted. ``burst`` members never retry.
"""
"""Runs precondition checks (vetted tier only) and execution for one action item."""
action_item = dict(action_item) # Make a copy to avoid mutating original state actions
outcome = _ActionOutcome(action_item=action_item)
attempts_log = []
validation_passed = True
if vetted:
if not burst:
# 1. Pre-execution validation (Safety Net)
original_coords = list(action_item.get("coordinates") or [])
(
@@ -364,9 +318,6 @@ def _incident_evidence(ctx, outcome: _ActionOutcome) -> dict:
evidence["occupant"] = raw["occupant"]
if raw.get("occupant_bounds") is not None:
evidence["occupant_bounds"] = raw["occupant_bounds"]
for key in _VERDICT_EVIDENCE_KEYS:
if raw.get(key) is not None:
evidence[key] = raw[key]
return evidence
@@ -425,8 +376,8 @@ async def run_validation_loop(node, state: State) -> dict:
burst = total_actions > 1
if burst:
logger.info(
f"Fast-action burst: {total_actions} actions; the first is vetted by the"
" safety net, the rest fire back to back unvetted."
f"Fast-action burst: {total_actions} actions will fire back to back"
" without the safety net."
)
session = await node._get_mcp_session()
@@ -461,16 +412,7 @@ async def run_validation_loop(node, state: State) -> dict:
try:
outcome = await _process_action(
node,
state,
session,
action_item,
action_name,
last_screenshot_b64,
burst=burst,
# The first burst member was decided on the live screen, so the
# safety net still applies to it; later members fire unvetted.
vetted=(not burst or index == 0),
node, state, session, action_item, action_name, last_screenshot_b64, burst=burst
)
success = outcome.success
execution.append(outcome.action_item)
+1 -1
View File
@@ -4,7 +4,7 @@ UI State Verification Expert. The Operator decided to act at the red dot while l
Read the `[Target]` block first to determine which rule applies.
Rules
1. `Kind: specific UI control` — the target has a label, resource id, class or bounds. Judge whether that exact control remains visible at the red dot in Image 2. Ignore video, map, animation or background changes beneath it. A control that has hidden, faded, collapsed, moved or become covered is not present, even if tapping the same spot could restore it. Judge the red dot, not the screen: if a different control, or nothing, now sits under the dot, the target is not present even when the same control (or its label) survives elsewhere on the screen or has turned into a different state such as an active input field.
1. `Kind: specific UI control` — the target has a label, resource id, class or bounds. Judge whether that exact control remains visible at the red dot in Image 2. Ignore video, map, animation or background changes beneath it. A control that has hidden, faded, collapsed, moved or become covered is not present, even if tapping the same spot could restore it.
2. `Kind: coordinates only` — no UI hierarchy element was found at the point. Identify what appears under the red dot in both images. If Image 1 shows a distinct button, icon, link or handle, apply Rule 1. Apply the surface rule only when Image 1 shows blank space, a backdrop, or the body of a video, animation, map or live stream.
3. Surface rule. Typical intents: tap the video body to wake its hidden controls, tap the backdrop to dismiss a dialog. Surfaces are expected to change between frames: ignore natural frame changes and the appearance or fading of overlay controls. Output `{"is_present": true, "confidence": 1.0}` unless an unexpected blocking popup now covers the red dot.
4. Use `[Planned Action & Original Thinking]` to resolve whether the target was a control or its underlying surface. Do not treat a missing control as present because another tap could restore it.
+1 -54
View File
@@ -51,15 +51,6 @@ W_TEXT = 0.4
W_BOUNDS = 0.3
W_COORD = 0.3
#: Strength of a failed XML verdict, recorded in ``safety_net_evidence``.
#: STRONG verdicts are final; WEAK ones hand the decision to the pixel judge.
XML_VERDICT_STRONG = "strong"
XML_VERDICT_WEAK = "weak"
#: A live hierarchy with fewer nodes than this is treated as sparse (a WebView,
#: game canvas or half-drawn screen): its "not found" is weak evidence.
XML_STRONG_MIN_ELEMENTS = 8
async def validate_action_precondition(
node, session, action_item: dict, state: State | None = None
@@ -536,45 +527,6 @@ def _describe_occupation(
return is_occupied, occupant_desc, occupant_bounds
def _count_nodes(elements) -> int:
"""Counts hierarchy nodes, descending into nested ``children`` lists."""
total = 0
for elem in elements or []:
if isinstance(elem, dict):
total += 1 + _count_nodes(elem.get("children") or [])
return total
def classify_xml_verdict(element_count: int, target_text, target_resource_id) -> tuple[str, str]:
"""Grades a failed XML verdict as strong or weak.
STRONG: the hierarchy is non-trivial AND the target carried identifiers
(resource-id / text / content-desc) that were searched and not matched.
Anything else (sparse tree, identifier-less target such as bare bounds from
a hit test) is WEAK, and the pixel judge gets the final say.
Returns ``(strength, weak_reason)``; ``weak_reason`` is empty for STRONG.
"""
if element_count < XML_STRONG_MIN_ELEMENTS:
return XML_VERDICT_WEAK, f"sparse hierarchy ({element_count} nodes)"
if not (target_text or target_resource_id):
return XML_VERDICT_WEAK, "target had no resource-id/text to search for"
return XML_VERDICT_STRONG, ""
def _annotate_verdict_strength(
action_item: dict, elements: list, target_text, target_resource_id
) -> None:
"""Records the verdict strength on the action item's ``safety_net_evidence``."""
count = _count_nodes(elements)
strength, weak_reason = classify_xml_verdict(count, target_text, target_resource_id)
evidence = action_item.setdefault("safety_net_evidence", {})
evidence["xml_verdict"] = strength
evidence["xml_element_count"] = count
if weak_reason:
evidence["xml_weak_reason"] = weak_reason
def _classify_failure(
elements: list,
action_item: dict,
@@ -650,9 +602,6 @@ async def validate_action_precondition_single(
target_bounds = action_item.get("target_bounds") # [l, t, r, b]
target_resource_id = action_item.get("target_resource_id")
# Evidence belongs to one attempt; a retry must not inherit a stale verdict.
action_item.pop("safety_net_evidence", None)
width, height = _resolve_screen_dims(ctx, state)
# Calculate diagonal-based scale factor for resolution-independent thresholds
@@ -710,7 +659,7 @@ async def validate_action_precondition_single(
if best["score"] >= threshold:
return _handle_match_success(action_item, best, target_text, scale_factor)
verdict = _classify_failure(
return _classify_failure(
elements,
action_item,
best,
@@ -721,5 +670,3 @@ async def validate_action_precondition_single(
height=height,
scale_factor=scale_factor,
)
_annotate_verdict_strength(action_item, elements, target_text, target_resource_id)
return verdict
+1 -2
View File
@@ -705,8 +705,7 @@ class ExecutionConfig(BaseModel):
le=10,
description=(
"Maximum turn-ending actions the Operator may chain into one fast-action"
" burst (first member vetted by the safety net, the rest fire back to back"
" unvetted). A longer turn is"
" burst (executed back to back without the safety net). A longer turn is"
" rejected before execution and fed back to the Operator."
),
)
+64 -24
View File
@@ -46,6 +46,8 @@ SCRCPY_STARTUP_TIMEOUT_SECONDS = 6.0
VIDEO_READY_DELAY_SECONDS = 1
ANDROID_DEVICE_VIDEO_PATH = "/sdcard/screen_recording.mp4"
ANDROID_MAX_RECORDING_DURATION_SECONDS = 180 # Android screenrecord limit
# Ignore small timing differences at segment boundaries.
TIMELINE_GAP_EPSILON_SECONDS = 0.05
# Expanded for Gemini File API (Supports up to 2GB).
# Target 100MB to allow 3-5min crisp video and prevent blurring for long durations.
@@ -529,6 +531,37 @@ async def write_recording_manifest(
return manifest_path
def plan_timeline_pieces(
segments: list[dict[str, Any]], start_time: float, end_time: float
) -> list[tuple[Any, ...]]:
"""Split a recording window into file ranges and gaps between segments.
File pieces are ``("file", path, local_start, local_end)``; gaps are
``("gap", seconds)``. Include leading and trailing gaps to preserve timeline
offsets, ignoring gaps below the timing tolerance. Return an empty list if
no existing segment overlaps the window.
"""
pieces: list[tuple[Any, ...]] = []
cursor = start_time
for segment in sorted(segments, key=lambda item: float(item["start"])):
path = Path(segment["path"])
seg_start = float(segment["start"])
seg_end = float(segment["end"])
overlap_start = max(start_time, seg_start)
overlap_end = min(end_time, seg_end)
if not path.exists() or overlap_end <= overlap_start:
continue
if overlap_start - cursor > TIMELINE_GAP_EPSILON_SECONDS:
pieces.append(("gap", overlap_start - cursor))
pieces.append(("file", path, overlap_start - seg_start, overlap_end - seg_start))
cursor = max(cursor, overlap_end)
if not any(piece[0] == "file" for piece in pieces):
return []
if end_time - cursor > TIMELINE_GAP_EPSILON_SECONDS:
pieces.append(("gap", end_time - cursor))
return pieces
async def render_timeline_clip(
segments: list[dict[str, Any]],
start_time: float,
@@ -536,40 +569,47 @@ async def render_timeline_clip(
output_path: Path,
canvas_width: int = 720,
canvas_height: int = 1280,
fps: int = 15,
) -> bool:
"""Render one continuous analyzer clip from orientation-aware segments.
Only the requested time window is decoded. This keeps the video analyzer's
single-MP4 contract without ever re-encoding the full recording.
Decode only the requested window and fill recording gaps with black frames
to keep clip timestamps aligned with the recording timeline.
"""
overlaps = []
for segment in segments:
path = Path(segment["path"])
seg_start = float(segment["start"])
seg_end = float(segment["end"])
overlap_start = max(start_time, seg_start)
overlap_end = min(end_time, seg_end)
if path.exists() and overlap_end > overlap_start:
overlaps.append((path, overlap_start - seg_start, overlap_end - seg_start))
if not overlaps:
pieces = plan_timeline_pieces(segments, start_time, end_time)
if not pieces:
return False
command = [get_ffmpeg_path(), "-y", "-fflags", "+genpts"]
for path, _start, _end in overlaps:
command.extend(["-i", str(path)])
filter_parts = []
labels = []
for index, (_path, local_start, local_end) in enumerate(overlaps):
for index, piece in enumerate(pieces):
label = f"v{index}"
filter_parts.append(
f"[{index}:v:0]trim=start={local_start:.6f}:end={local_end:.6f},"
"setpts=PTS-STARTPTS,"
f"scale={canvas_width}:{canvas_height}:force_original_aspect_ratio=decrease:"
"force_divisible_by=2,"
f"pad={canvas_width}:{canvas_height}:(ow-iw)/2:(oh-ih)/2:color=black,"
f"setsar=1,fps=15,format=yuv420p[{label}]"
)
if piece[0] == "gap":
duration = float(piece[1])
command.extend(
[
"-f",
"lavfi",
"-i",
f"color=c=black:s={canvas_width}x{canvas_height}:r={fps}:d={duration:.3f}",
]
)
filter_parts.append(
f"[{index}:v:0]trim=duration={duration:.6f},setpts=PTS-STARTPTS,"
f"setsar=1,format=yuv420p[{label}]"
)
else:
_kind, path, local_start, local_end = piece
command.extend(["-i", str(path)])
filter_parts.append(
f"[{index}:v:0]trim=start={local_start:.6f}:end={local_end:.6f},"
"setpts=PTS-STARTPTS,"
f"scale={canvas_width}:{canvas_height}:force_original_aspect_ratio=decrease:"
"force_divisible_by=2,"
f"pad={canvas_width}:{canvas_height}:(ow-iw)/2:(oh-ih)/2:color=black,"
f"setsar=1,fps={fps},format=yuv420p[{label}]"
)
labels.append(f"[{label}]")
if len(labels) == 1:
filter_parts.append(f"{labels[0]}null[outv]")