Coordinate Video Reading and Rendering at 25 Frames per Second

Read the full interview experience this question came from →

Quick Overview

Design a 25fps video player with serialized unsafe APIs, bounded producer-consumer buffering, deadline pacing, and explicit timing feasibility limits.

Coordinate Video Reading and Rendering at 25 Frames per Second

Company: Nuro

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: hard

Interview Round: Technical Screen

You are given a `Frame` type and a `VideoPlayer` with two operations: `Read()` returns the next frame or an end-of-video indication, and `Render(frame)` displays a frame. Design `on_play_click()` to play the complete video from first frame to last at a target of exactly 25 frames per second. Neither `Read()` nor `Render()` is thread-safe. Explain how you serialize access safely, use producer/consumer coordination, and schedule rendering without losing or reordering frames. ### Constraints Preserve the 25-frame-per-second requirement, equivalent to 40 milliseconds between presentation starts. For a conservative baseline, assume that Read and Render share unsafe player state and must never overlap, even with each other. The API durations, UI-thread affinity, buffering limit, and behavior under missed deadlines are unspecified and must be clarified. Do not promise strict real-time playback under arbitrary delays. ### Clarifying Questions - What are the worst-case Read and Render durations, and can reads be prefetched before playback begins? - Must Render execute on the UI thread, and which clock and scheduler are available? - How much buffering is allowed, and what happens if a frame is not ready at its deadline? - What should repeated play clicks, cancellation, or end of video do? ```hint Avoid waiting while holding the player lock A bounded queue and the non-thread-safe player APIs protect different state. Holding the API lock while waiting for queue space can prevent the consumer from making progress. ``` ### What a Strong Answer Covers - A serialized API-access policy and a bounded, ordered producer/consumer buffer. - Condition-variable predicates, end-of-stream signaling, cancellation, and lifecycle cleanup. - Absolute 40-millisecond presentation scheduling and an honest feasibility analysis. ### Follow-up Questions - Can the requirement be met if Render alone sometimes takes longer than 40 milliseconds? - How would you distinguish a temporarily empty buffer from the end of the video?

Overview: Design a 25fps video player with serialized unsafe APIs, bounded producer-consumer buffering, deadline pacing, and explicit timing feasibility limits.

Read the full Nuro Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Nuro
Nuro logo
Nuro
Feb 15, 2026
hardSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

You are given a Frame type and a VideoPlayer with two operations: Read() returns the next frame or an end-of-video indication, and Render(frame) displays a frame. Design on_play_click() to play the complete video from first frame to last at a target of exactly 25 frames per second.

Neither Read() nor Render() is thread-safe. Explain how you serialize access safely, use producer/consumer coordination, and schedule rendering without losing or reordering frames.

Constraints

Preserve the 25-frame-per-second requirement, equivalent to 40 milliseconds between presentation starts. For a conservative baseline, assume that Read and Render share unsafe player state and must never overlap, even with each other. The API durations, UI-thread affinity, buffering limit, and behavior under missed deadlines are unspecified and must be clarified. Do not promise strict real-time playback under arbitrary delays.

Clarifying Questions Guidance

  • What are the worst-case Read and Render durations, and can reads be prefetched before playback begins?
  • Must Render execute on the UI thread, and which clock and scheduler are available?
  • How much buffering is allowed, and what happens if a frame is not ready at its deadline?
  • What should repeated play clicks, cancellation, or end of video do?

What a Strong Answer Covers Guidance

  • A serialized API-access policy and a bounded, ordered producer/consumer buffer.
  • Condition-variable predicates, end-of-stream signaling, cancellation, and lifecycle cleanup.
  • Absolute 40-millisecond presentation scheduling and an honest feasibility analysis.

Follow-up Questions Guidance

  • Can the requirement be met if Render alone sometimes takes longer than 40 milliseconds?
  • How would you distinguish a temporarily empty buffer from the end of the video?
Loading comments...