Limit CPU video decoder codec support#6352
Conversation
|
NVIDIA/DALI_extra#135 & NVIDIA/DALI_deps#162 are related to this change. |
|
CI MESSAGE: [51666287]: BUILD STARTED |
|
| Filename | Overview |
|---|---|
| dali/operators/video/frames_decoder_cpu.cc | Core bug fixes: EOS signalling in ReadRegularFrame and ReadFlushFrame, codec allow-list narrowed to VP8/VP9/MJPEG, NumFrames() pre-population guard added. Minor comment typo. |
| dali/operators/video/frames_decoder_base.cc | SeekFrame now resets the decoder when next_frame_idx_ exceeds NumFrames() with a valid index, preventing reuse of a stale position. |
| dali/operators/video/video_test.cc | CompareFrame changed to count per-thread bad subpixels; tolerates up to 16 isolated deviations. CFR/VFR reference paths updated to VP9 variants. |
| dali/test/python/decoder/test_video.py | Converts unsupported-codec CPU handling from SkipTest to expected-failure assertions; adds device_id=None for CPU pipelines; filters h264 files from fixture lists. |
| dali/test/python/input/test_video.py | Adds module-level filter for h264 test_1.mp4/test_2.mp4; switches audio-stream test to sintel_trailer_vp9.mp4. |
| qa/TL0_videoreader_test/test.sh | CI setup script correctly copies only the vp9/ subdirectory to /tmp and switches sintel reference to sintel_trailer_vp9.mp4. |
| DALI_DEPS_VERSION | Set to literal 'ToDo' placeholder; acknowledged as intentional by the author pending dependent PRs. |
Reviews (19): Last reviewed commit: "Limit CPU video decoder codec support" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -1 +1 @@ | |||
| b270f29e9d7655512e7e8eaf055cca4d19b55f55 | |||
| ToDo | |||
There was a problem hiding this comment.
ToDo placeholder.
Both DALI_DEPS_VERSION and DALI_EXTRA_VERSION now contain the string ToDo instead of a commit SHA. Any CI job that reads these files to fetch the matching dali_deps / dali_extra artefacts will either fail outright or pick up an incorrect/stale revision, breaking reproducibility for the entire build. These files should be updated to the real commit SHAs before this PR merges (or the dependent PRs should land first).
JanuszL
force-pushed
the
remove_cpu_codecs
branch
2 times, most recently
from
13fd2c1 to
8375cb2
Compare
|
@greptile review |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
8375cb2 to
9389ee9
Compare
|
@greptile review |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
9389ee9 to
d364075
Compare
|
@greptile review |
| ++next_frame_idx_; | ||
| if (next_frame_idx_ >= NumFrames()) { | ||
| next_frame_idx_ = -1; | ||
| LOG_LINE << "Next frame index out of bounds (regular), setting to -1" << std::endl; | ||
| } | ||
| return true; |
There was a problem hiding this comment.
NumFrames() unconditionally on every decoded frame, which can invoke ParseNumFrames() when no index is built and nb_frames is zero in the container. ParseNumFrames() reads all remaining demuxer packets to completion, so the very first frame's increment will exhaust the packet stream and cause all subsequent av_read_frame calls to return EOF — silently dropping every frame after the first. The existing guard in ReadFlushFrame has the same limitation (documented with a TODO) but that function runs only after the demuxer is already exhausted. The fix is to guard the check with HasIndex(), mirroring the SeekFrame condition added in this same PR.
| ++next_frame_idx_; | |
| if (next_frame_idx_ >= NumFrames()) { | |
| next_frame_idx_ = -1; | |
| LOG_LINE << "Next frame index out of bounds (regular), setting to -1" << std::endl; | |
| } | |
| return true; | |
| ++next_frame_idx_; | |
| // TODO(awolant): Figure out how to handle this during index building | |
| // Or when NumFrames is unavailable | |
| if (HasIndex() && next_frame_idx_ >= NumFrames()) { | |
| next_frame_idx_ = -1; | |
| LOG_LINE << "Next frame index out of bounds (regular), setting to -1" << std::endl; | |
| } | |
| return true; |
| batch_size = 3 | ||
| pipe = test_pipeline(batch_size=batch_size, num_threads=3, device_id=0) |
There was a problem hiding this comment.
test_multichannel_fill_value hard-codes device_id=0 even though the test body uses fn.experimental.decoders.video which is a CPU/mixed operator; on a device-less CI machine this will fail at pipeline construction. Other tests in this PR were correctly updated to derive device_id from device, so this one was apparently missed.
| batch_size = 3 | |
| pipe = test_pipeline(batch_size=batch_size, num_threads=3, device_id=0) | |
| batch_size = 3 | |
| device_id = None if device == "cpu" else 0 | |
| pipe = test_pipeline(batch_size=batch_size, num_threads=3, device_id=device_id) |
|
CI MESSAGE: [51735694]: BUILD STARTED |
|
CI MESSAGE: [51735694]: BUILD FAILED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
2 times, most recently
from
a8f64cc to
fba22e3
Compare
|
CI MESSAGE: [51770028]: BUILD STARTED |
| # test overflow of frame_buffer_ | ||
| filenames.append(f"{get_dali_extra_path()}/db/video/cfr_test.mp4") | ||
| filenames = filter(lambda filename: "mpeg4" not in filename, filenames) | ||
| filenames = filter(lambda filename: "hevc" not in filename, filenames) | ||
| filenames = filter(lambda filename: "av1" not in filename, filenames) | ||
| if device == "cpu": | ||
| # some formats are not yet supported in the CPU operator itself | ||
| filenames = filter(lambda filename: "mpeg4" not in filename, filenames) | ||
| filenames = filter( | ||
| lambda filename: "test_1.mp4" not in filename and "test_2.mp4" not in filename, | ||
| filenames, | ||
| ) | ||
| filenames = cycle(filenames) |
There was a problem hiding this comment.
cfr_test.mp4 is H264 and is not filtered for CPU.
The DALI_extra README.rst shows cfr_test.mp4 is generated with -c:v libx264, so it's H264. This file is appended to filenames before the CPU-conditional filters run. The CPU block filters mpeg4, test_1.mp4, and test_2.mp4, but cfr_test.mp4 slips through. When the CPU decoder encounters it, SelectVideoStream issues a DALI_WARN and returns false, causing a RuntimeError that fails the test.
The fix is to guard the filenames.append call (or add "cfr_test" not in filename to the CPU filter) so that the H264-specific overflow fixture is only used when the device can decode H264.
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
fba22e3 to
c87a527
Compare
|
CI MESSAGE: [51774937]: BUILD STARTED |
| if device == "gpu": | ||
| filenames.append(f"{get_dali_extra_path()}/db/video/cfr_test.mp4") |
There was a problem hiding this comment.
cfr_test.mp4 is never appended for the "mixed" device.
test_multi_gpu_video is decorated with @params("cpu", "mixed"), so device is never "gpu". The frame-buffer overflow fixture (cfr_test.mp4) is silently skipped for the "mixed" case, which was the very path the file was added to stress. The condition should be device == "mixed" (or device != "cpu").
| if device == "gpu": | |
| filenames.append(f"{get_dali_extra_path()}/db/video/cfr_test.mp4") | |
| if device == "mixed": | |
| filenames.append(f"{get_dali_extra_path()}/db/video/cfr_test.mp4") |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
c87a527 to
4e1a23c
Compare
|
CI MESSAGE: [51777473]: BUILD STARTED |
|
CI MESSAGE: [51777473]: BUILD FAILED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
4e1a23c to
fd7b970
Compare
|
CI MESSAGE: [51925234]: BUILD FAILED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
fd7b970 to
dfa6ff4
Compare
|
CI MESSAGE: [51925957]: BUILD STARTED |
| find video_resolution/vp9 -type f -name '*vp9*' -print0 | while IFS= read -r -d '' file; do | ||
| mkdir -p "${DEST_ROOT}/$(dirname "$file")" | ||
| cp "$file" "${DEST_ROOT}/$file" | ||
| done |
There was a problem hiding this comment.
-name '*vp9*' filter will silently skip all multi-resolution VP9 files.
Based on the current DALI_extra naming convention, the video-resolution files are named by resolution (3840_2160.mp4, 1920_1080.mp4, 334_240.mp4) with no codec suffix. The new VP9 variants placed under video_resolution/vp9/ are almost certainly named the same way. Because none of those filenames contain vp9, the find -name '*vp9*' predicate matches nothing, the while loop body never executes, and /tmp/video_resolution/vp9/ is created but left empty. Every MultipleVideoResolution test that reads from that directory will then fail with "no video files found". Drop the -name predicate — the video_resolution/vp9 path already scopes the search to VP9 content.
| find video_resolution/vp9 -type f -name '*vp9*' -print0 | while IFS= read -r -d '' file; do | |
| mkdir -p "${DEST_ROOT}/$(dirname "$file")" | |
| cp "$file" "${DEST_ROOT}/$file" | |
| done | |
| find video_resolution/vp9 -type f -print0 | while IFS= read -r -d '' file; do |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
dfa6ff4 to
416da1d
Compare
|
CI MESSAGE: [51931118]: BUILD STARTED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
416da1d to
8812da4
Compare
|
CI MESSAGE: [51994441]: BUILD STARTED |
|
CI MESSAGE: [51994441]: BUILD FAILED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
8812da4 to
218a982
Compare
|
CI MESSAGE: [52057797]: BUILD STARTED |
|
CI MESSAGE: [52057797]: BUILD FAILED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
2 times, most recently
from
d53209a to
ce13c1e
Compare
|
CI MESSAGE: [52186630]: BUILD STARTED |
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
ce13c1e to
22563c3
Compare
|
CI MESSAGE: [52188114]: BUILD STARTED |
| } | ||
|
|
||
| unsupported_cpu_codec_error = r"is not supported by the CPU variant of this operator\." | ||
| unsupported_cpu_codecs = {"h264", "hevc", "mpeg4"} |
There was a problem hiding this comment.
[Maintainability] This Python-side set duplicates the implicit allow-list in frames_decoder_cpu.cc:218-227 (everything not in {VP8, VP9, MJPEG}). When the C++ array changes, this set has to track it manually with nothing to enforce the link. Consider either:
- A short comment here pointing to the C++ definition (
# Must match the inverse of frames_decoder_cpu.cc SelectVideoStream's codec table), or - Defining the supported codecs once and deriving
unsupported_cpu_codecs(the latter is harder across C++/Python).
Lowest-cost option is the cross-reference comment.
There was a problem hiding this comment.
That is the point. It list the codecs which are not supported as in C++ definition. I don't think we can track this easily besides adding a comment that this comes from the CPU decoder implementation.
| # some formats are not yet supported in the CPU operator itself | ||
| filenames = filter(lambda filename: "mpeg4" not in filename, filenames) | ||
| filenames = filter( | ||
| lambda filename: "test_1.mp4" not in filename and "test_2.mp4" not in filename, |
There was a problem hiding this comment.
[Robustness] The substring filter "test_1.mp4" not in filename and "test_2.mp4" not in filename is fragile — any future file containing test_1.mp4 anywhere in its path (e.g. prefix_test_1.mp4, or a directory named test_1.mp4_backup) would be unintentionally dropped. Prefer an exact basename check:
excluded = {"test_1.mp4", "test_2.mp4"}
filenames = filter(lambda f: os.path.basename(f) not in excluded, filenames)Same applies to the equivalent block at lines 356-358.
|
|
||
| ret = avcodec_send_packet(codec_ctx_, nullptr); | ||
| DALI_ENFORCE(ret >= 0, | ||
| DALI_ENFORCE(ret >= 0 || ret == AVERROR_EOF, |
There was a problem hiding this comment.
[Nit/Wording] Now that AVERROR_EOF is accepted as a non-error, the message "Failed to send packet to decoder" is misleading for ret == AVERROR_EOF — except, of course, that branch no longer triggers the ENFORCE. Still, if the ENFORCE does fire, the message reads better as "avcodec_send_packet (flush) failed: ..." so it's clear which call site it is.
More importantly: dropping into flush_state_ = true on AVERROR_EOF is the right thing, but worth a 1-line comment here explaining why EOF is acceptable (the decoder has already drained — no more packets to send) so this doesn't look like accidental error-swallowing.
| // Tolerate a tiny number of isolated subpixel deviations exceeding eps. The CPU VP9 | ||
| // decode path occasionally produces a single byte that differs by ~32 (suspected SIMD | ||
| // glitch in libavcodec/sws_scale that Valgrind cannot instrument). A genuine regression | ||
| // produces orders of magnitude more bad subpixels, so this budget still catches real |
There was a problem hiding this comment.
[Question/Design] Tolerating 16 deviating subpixels per frame to mask a suspected libavcodec/sws_scale SIMD glitch is pragmatic, but it does mean a regression that introduces ≤16 wrong subpixels per frame will be silently absorbed. Given the suspected upstream cause, is there any plan to file an upstream bug and/or pin a known-good FFmpeg version, or to scope this tolerance only to the VP9 paths it actually affects (e.g. an extra arg to CompareFrame rather than a global cap)?
Not blocking — the rationale in the comment is clear and the 16/2.7M ratio is tiny — just want to make sure we don't lose the thread on the underlying glitch.
There was a problem hiding this comment.
Good point. The threshold is set empirically based on the failures in tests observed. I don't know if there is a good FFmpeg we can pin. I still believe that 16 off pixels is still something we can tolerate, if something is seriously off the number if bigger.
|
CI MESSAGE: [52188114]: BUILD FAILED |
|
|
||
| CopyToOutput(data); | ||
| ++next_frame_idx_; | ||
| if (next_frame_idx_ >= NumFrames()) { |
There was a problem hiding this comment.
[Bug — concrete failure mode for greptile's NumFrames P1] Tracing this end-to-end on a container with no nb_frames (typical for VP9 in WebM, possible elsewhere):
- ReadRegularFrame decodes frame 0;
++next_frame_idx_→ 1. NumFrames()seesnum_frames_ < 0andnb_frames == 0→ callsParseNumFrames().ParseNumFramesreads packets from the current demux position to EOF (off-by-one: it counts only the remaining frames, not the one already consumed), then callsReset().Reset()(frames_decoder_base.cc:472) reopens the file and setsnext_frame_idx_ = 0.NumFrames()returns the (off-by-one)N.0 >= N→ false → don't set-1→ return true with frame-0 data.- Next ReadRegularFrame re-reads frame 0 (decoder was silently rewound).
User-visible: frame_0 is delivered twice, total frame count is wrong, and VideoInput's NextFrameIdx() != -1 loop (input/video_input.h:323) overruns or wraps unpredictably. Even when num_frames_ is correctly populated from container metadata, this code path is one cache-miss away from being hit.
Mirror the HasIndex() && guard from SeekFrame (frames_decoder_base.cc:512) here and on line 195 in ReadFlushFrame, or compute NumFrames() exactly once up front.
There was a problem hiding this comment.
Added early initialization of NumFrames. We cannot call HasIndex as sometimes we don't have index, still we want to know the number of frames available.
| } | ||
|
|
||
| if (next_frame_idx_ < 0) { | ||
| if (next_frame_idx_ < 0 || (HasIndex() && next_frame_idx_ >= NumFrames())) { |
There was a problem hiding this comment.
[Consistency] This is the right shape for the check — guarded by HasIndex(). But the new EOS check added in the same PR (frames_decoder_cpu.cc:161) is not guarded the same way, and neither is the pre-existing one at frames_decoder_cpu.cc:195. Asymmetric guards in the same change are suspicious — either this guard is unnecessary here (in which case those callsites are correct), or it's necessary in all three (in which case the cpu.cc callsites need fixing). The data-corruption trace in the comment on frames_decoder_cpu.cc:161 argues for the latter.
There was a problem hiding this comment.
frames_decoder_cpu.cc:161 should not have negative next_frame_idx_ as in we progressing forward only. dali/operators/video/frames_decoder_base.cc has next_frame_idx_ externally controlled so it could be negative as well here.
Same for frames_decoder_cpu.cc:195
|
|
||
|
|
||
| @params("cpu", "gpu") | ||
| @params("gpu") |
There was a problem hiding this comment.
[Coverage] Dropping CPU from @params here is a real regression in test surface, not just a fixture-availability artifact. The test uses /db/video/full_dynamic_range/video.mp4 (H.264), which the new CPU codec policy rejects — so the only fix is a VP9 version of that fixture in DALI_extra. Worth filing a follow-up so this CPU path doesn't quietly stay uncovered, or extending the PR #135 set with video_vp9.mp4 here.
There was a problem hiding this comment.
The code path that detect full range videos applies only to h264/h265, and for VP9 we would need to implement if separately. I will add this to our ToDo list.
| @params(*device_values) | ||
| # The only available test video with an audio stream (sintel) is h264, which is not supported by | ||
| # the CPU variant of the operator. Run this test only on the mixed (GPU) backend. | ||
| @params("mixed") |
There was a problem hiding this comment.
[Coverage / Question] Same shape as the test_full_range_video_in_memory coverage loss — CPU dropped because the only audio-stream fixture is H.264. However: NVIDIA/DALI_extra#135 adds sintel_trailer_vp9.mp4. Does that file retain the audio stream from the original sintel? If yes, this test can stay parameterized over both devices by switching the input to the VP9 variant. If no, worth re-encoding to preserve audio so we don't lose this CPU-side audio-stream regression check permanently.
| } | ||
|
|
||
| unsupported_cpu_codec_error = r"is not supported by the CPU variant of this operator\." | ||
| unsupported_cpu_codecs = {"h264", "hevc", "mpeg4"} |
There was a problem hiding this comment.
[Drift risk — separate from the maintainability comment on the original review] This set claims to enumerate "unsupported on CPU" codecs but is missing AV1, which is also unsupported on the CPU path (no decoder in libavcodec build + commented out in frames_decoder_cpu.cc:223). It works today only because both test_decoder_operator_codec_support and test_reader_operator_codec_support early-skip AV1 with raise SkipTest("...Ampere+ GPUs..."). If/when AV1 becomes generally available and that skip is removed, the codec-rejection branch will be silently bypassed and the test will attempt a real decode on CPU. Add "av1" here defensively, or guard the skip with if codec == "av1" and not has_ampere(): raise SkipTest(...).
JanuszL
force-pushed
the
remove_cpu_codecs
branch
2 times, most recently
from
c200f32 to
63ae75a
Compare
|
CI MESSAGE: [52225500]: BUILD STARTED |
| @params(*device_values) | ||
| def test_video_input_audio_stream(device): | ||
| """ |
There was a problem hiding this comment.
The block comment says "Run this test only on the mixed (GPU) backend", but the decorator @params(*device_values) expands to @params("cpu", "mixed"), so the CPU case still runs. The file was switched from sintel_trailer-720p.mp4 (h264 + audio) to sintel_trailer_vp9.mp4: if the VP9 re-encode preserved the audio track, CPU can handle it and the comment is simply stale. If the audio track was dropped during re-encoding, neither device is actually testing the "video decoding when audio stream is present" scenario described in the docstring — the test would pass vacuously. Please confirm whether sintel_trailer_vp9.mp4 retains an audio stream, and update the comment (or restrict the decorator to @params("mixed")) accordingly.
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
63ae75a to
8428bfe
Compare
|
CI MESSAGE: [52226023]: BUILD STARTED |
Restrict the CPU frames decoder to codecs supported by the currently
compiled libavcodec configuration. H264 and HEVC are no longer
advertised for the CPU variant while VP8, VP9, and MJPEG remain
enabled.
Make `ReadRegularFrame` mark end-of-stream by setting `next_frame_idx_`
to -1 when the index reaches `NumFrames()`, mirroring the existing
guard in `ReadFlushFrame`. Without this, codecs with no decoder latency
(VP9 on the new test inputs) deliver the final frame via the regular
path, leaving `next_frame_idx_` at `NumFrames()` and causing
`VideoInput` depletion to be reported one batch late.
Reset the decoder when an indexed next frame falls outside the valid
range, avoiding reuse of an invalid decoder position.
Update video decoder tests to expect CPU failures for unsupported
codecs instead of skipping only MPEG4. Use VP9 CFR/VFR test inputs
and device-less CPU pipelines where appropriate. Point the CFR/VFR
reference frame folders at `frames_{1,2}_vp9/` so CPU decode of the
new VP9 fixtures matches at the existing eps=10 tolerance. Drop the
CPU HEVC frames-decoder tests (`ConstantFrameRateHevc`,
`VariableFrameRateHevc`, `VariableFrameRateHevcNoIndex`) — HEVC is no
longer in the CPU codec allow-list.
Tolerate up to 16 isolated subpixel deviations exceeding eps in
`TestVideo::CompareFrame` (out of ~2.7M subpixels per frame). The CPU
VP9 decode path occasionally produces a single byte that differs by
~32 — a SIMD glitch inside libavcodec/sws_scale that Valgrind cannot
instrument. The budget is orders of magnitude below what any genuine
regression would produce, so test sensitivity is preserved.
In `dali/test/python/input/test_video.py`, filter out h264 from the
round-robin fixture (the unsuffixed `test_{1,2}.mp4` in `cfr/`/`vfr/`
are h264) and restrict `test_video_input_audio_stream` to the mixed
backend — the only DALI_extra video with an audio stream is h264.
Signed-off-by: Janusz Lisiecki <jlisiecki@nvidia.com>
JanuszL
force-pushed
the
remove_cpu_codecs
branch
from
8428bfe to
5c1c613
Compare
|
CI MESSAGE: [52231011]: BUILD STARTED |
|
CI MESSAGE: [52231011]: BUILD PASSED |
4 participants
Limit CPU video decoder codec support
Restrict the CPU frames decoder to codecs supported by the currently
compiled libavcodec configuration. H264 and HEVC are no longer
advertised for the CPU variant while VP8, VP9, and MJPEG remain
enabled.
Make
ReadRegularFramemark end-of-stream by settingnext_frame_idx_to -1 when the index reaches
NumFrames(), mirroring the existingguard in
ReadFlushFrame. Without this, codecs with no decoder latency(VP9 on the new test inputs) deliver the final frame via the regular
path, leaving
next_frame_idx_atNumFrames()and causingVideoInputdepletion to be reported one batch late.Reset the decoder when an indexed next frame falls outside the valid
range, avoiding reuse of an invalid decoder position.
Update video decoder tests to expect CPU failures for unsupported
codecs instead of skipping only MPEG4. Use VP9 CFR/VFR test inputs
and device-less CPU pipelines where appropriate. Point the CFR/VFR
reference frame folders at `frames_{1,2}_vp9/` so CPU decode of the
new VP9 fixtures matches at the existing eps=10 tolerance. Drop the
CPU HEVC frames-decoder tests (`ConstantFrameRateHevc`,
`VariableFrameRateHevc`, `VariableFrameRateHevcNoIndex`) — HEVC is
no longer in the CPU codec allow-list.
Tolerate up to 16 isolated subpixel deviations exceeding eps in
TestVideo::CompareFrame(out of ~2.7M subpixels per frame). The CPUVP9 decode path occasionally produces a single byte that differs by
~32 — a SIMD glitch inside libavcodec/sws_scale that Valgrind cannot
instrument. The budget is orders of magnitude below what any genuine
regression would produce, so test sensitivity is preserved.
In
dali/test/python/input/test_video.py, filter out h264 from theround-robin fixture (the unsuffixed
test_{1,2}.mp4incfr//vfr/are h264) and restrict
test_video_input_audio_streamto the mixedbackend — the only DALI_extra video with an audio stream is h264.
Category:
Bug fix (non-breaking change which fixes an issue)
Description:
Restricts the CPU video frames decoder to the codecs supported by the
currently compiled libavcodec configuration. H264 and HEVC are no longer
advertised for the CPU variant, while VP8, VP9, and MJPEG remain enabled.
ReadRegularFramenow mirrorsReadFlushFrameand signals end-of-streamby setting
next_frame_idx_to -1 onceNumFrames()is reached, socodecs with no decoder latency report depletion immediately instead of
one batch late.
Resets the decoder when an indexed next frame falls outside the valid
range, avoiding reuse of an invalid decoder position.
The video decoder tests now expect CPU failures for unsupported codecs
instead of skipping only MPEG4. The affected CFR/VFR test inputs are
switched to VP9 variants, and CPU pipelines use
device_id=Nonewhereappropriate. The CFR/VFR reference frame folders are repointed at the
new VP9-derived
frames_{1,2}_vp9/so CPU decode matches at theexisting eps=10 tolerance. CPU HEVC frames-decoder tests are removed.
TestVideo::CompareFramenow tolerates up to 16 isolated subpixeldeviations exceeding eps per frame (out of ~2.7M). The CPU VP9 decode
path occasionally produces a single byte that differs by ~32 — a SIMD
glitch inside libavcodec/sws_scale that Valgrind cannot instrument.
The budget is orders of magnitude below any genuine regression, so
test sensitivity is preserved.
dali/test/python/input/test_video.pyfilters out h264 from theround-robin fixture and restricts
test_video_input_audio_streamtothe mixed backend — the only DALI_extra video with an audio stream is
h264, which CPU can no longer decode.
Additional information:
Affected modules and functionalities:
ReadRegularFrameend-of-stream signalling.
range).
relaxed
CompareFrametolerance.dali/test/python/input/test_video.py: h264 fixture filter andaudio-stream test backend restriction.
Key points relevant for the review:
DALI_DEPS_VERSIONandDALI_EXTRA_VERSIONare temporaryToDoplaceholders until the corresponding
dali_depsanddali_extrarepository changes merge.
instead of being skipped for a subset of codecs.
ReadRegularFrameEOS guard is required forVideoInputdepletion to fire on the right batch with VP9 inputs (h264 hid the
off-by-one through its decoder latency, which routed the tail
through
ReadFlushFrame).CompareFrameis a flake mitigation,not a tolerance loosening: a real codec/colorspace bug would touch
thousands of subpixels.
Tests:
Not run locally.
Checklist
Documentation
DALI team only
Requirements
REQ IDs: N/A
JIRA TASK: N/A