Skip to content

VideoSubject can silently drop frames with changed dimensions #413

Description

@sylvesterkaczmarek

Reproduction

VideoSubject validates RGB channels and dtype, but does not check that frame dimensions remain equal to the size used to open its writer. OpenCV can drop an incorrectly sized frame while the recorder proceeds and emits a completed video path.

Using the lossless AVI/PNG codec, sending FIRST, MID and LAST frames of shapes (8, 16, 3), (10, 16, 3) and (8, 16, 3) emits a path successfully, but reading the saved video yields only two frames. The middle frame is lost. A mismatched terminal frame likewise allows an incomplete recording to be reported as completed.

Expected behavior

Reject a within-episode size change before calling the writer or emitting a path. Keep the active recording usable so the caller can supply a correctly sized frame or dispose it. A subsequent episode may choose a different size. Existing validation, encoding and pixel values should remain unchanged.

Reproduced with actual OpenCV writing and playback on main at 1b4239b, using synthetic RGB arrays. This is separate from evaluation recorder cleanup (#403) and optional-writer type narrowing (#399).

Reference: OpenCV's VideoWriter.write requires the size specified when opening the writer: https://docs.opencv.org/3.4.16/dd/d9e/classcv_1_1VideoWriter.html.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions