Repository navigation
[python] Speed up LeRobot single-video window decoding - #10721
Merged
JingsongLi merged 1 commit intoOct 21, 2026
Merged
Conversation
XiaoHongbo-Hope
force-pushed
the
python-lerobot-single-video-decode
branch
from
October 21, 2026 12:51
3c6b342 to
36985ab
Compare
XiaoHongbo-Hope
marked this pull request as ready for review
October 21, 2026 14:10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
A batch whose windows reference one video uses only one decoder, leaving the shared decode pool idle. Split those windows across independent cached decoders to improve LeRobot throughput for single-video datasets such as PushT.
read.video.decoders-per-payload(default: 4; 1 disables splitting). Multi-payload batches keep their existing scheduling. No public constructor changes.Built on master after #10703; the implementation is a single commit.
PushT prototype results (three paired runs, median samples/s):
Both OSSFS stores were remounted and kernel caches cleared before each run. Eight workers, batch 32, eight-frame windows, uint8, CPU, no transforms/model; 10 warmup and 500 timed batches. These are warmed throughput results, not cache-free OSS throughput. Lance:
lerobot-lancedbcommit40bcb659a52d, pylance 13.0.0. Paimon used an integration branch with #10701/#10703/#10704 and startup/allocation optimizations; these are prototype measurements, not benchmarks of this PR head.On OSSFS, four decoders raised CPU use from about 8.7 to 12.2 cores and PSS from 3.32 to 3.42 GiB. Fixed-workload time was unchanged versus baseline (14.05 → 14.08 s); two decoders were faster for that short task (13.33 s). Additional decoders can increase startup cost and repeated reads.
Follow-up OSSFS checks use this implementation on integrated base
5c23609a04(three paired runs, 10 warmup + 100 timed batches; other settings unchanged):ALOHA exercised splitting in all workers: +9.0% throughput over baseline, CPU 24.7 → 34.8 cores, PSS 9.72 → 9.91 GiB. Koch never exercised splitting because its batches contain multiple payloads; measured throughput was 4.2% lower and total time essentially unchanged (24.80 → 24.87 s), so no incremental benefit is claimed there. Both candidate throughput results exceeded Lance in all three paired runs. Candidate/Lance total times: ALOHA 28.77/36.79 s; Koch 24.87/28.49 s. Koch first batch remained slightly slower (13.82/13.55 s).
Tests
git diff --checkpassed.