Skip to content

Conversation

@AustinMroz
Copy link
Contributor

@AustinMroz AustinMroz commented Jan 27, 2026

Introduces a new "Video Slice" node which allows for restricting a VIDEO input to a provided start_time and duration.
image

Because remuxing videos requires that start_time is aligned to a keyframe, the existing implementation simply sets reuse_streams to False to utilize the existing architecture. This could be improved in the future to instead stream the transcoding for reduced memory usage.
Similarly, the VideoFromComponents creates a new VideoFromFile with the trimming applied. Since the values for start_time and duration are unlikely to align to an exact frame time, this ensures a subsequent save operation can correctly trim the duration of the last frame and that multiple VideoSlice applied in a row will not accumulate rounding errors.

@AustinMroz AustinMroz marked this pull request as ready for review January 29, 2026 08:26
@Kosinkadink
Copy link
Member

Played around with it a bit, is it intended that the node be super picky about there being exactly the duration amount of video sliced? e.g. if a video is 6 seconds long and you try to start to clip a second at 5.5s, it will throw an error that it couldn't be sliced due to not enough footage to slice.

There is definitely use for the error guaranteeing a duration, but the imo the Video interface should also have a boolean input, guarantee_duration default True or something like that, that when set to False would output whatever length clip it could get base on the values.

Also might be nice to support a negative start_time that would start the clip from the end of the video - I can see it being super useful if you want to trim the start without knowing the exact video duration to begin with.

@AustinMroz
Copy link
Contributor Author

Negative start time is a good idea. I'll add support for it.

I'll update the tooltip for duration to make it clear that 0 disables and investigate your suggestion. Allowing the option for duration less than requested would give closer parity to the VHS equivalent, frame_load_cap.

Worst case, support for less strict duration can be added later without any forward compatibility risk.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants