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.
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?