Skip to content

[NOT_READY] Ensure OTIO video triming is duration accurate (for re-encoding to avoid keyframe rounding issue). #1394

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
rdelillo wants to merge 1 commit into
base: develop
Choose a base branch
from
+0 −1
Draft

[NOT_READY] Ensure OTIO video triming is duration accurate (for re-encoding to avoid keyframe rounding issue). #1394

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion client/ayon_core/plugins/publish/extract_otio_trimming_video.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,6 @@ def _ffmpeg_trim_seqment(self, input_file_path, otio_range):
"-ss", str(sec_start),
"-t", str(sec_duration),
"-i", video_path,
"-c", "copy",
Copy link
Contributor Author

@rdelillo rdelillo Jul 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakubjezek001 @iLLiCiTiT @philippe-ynput @antirotor

I'm torn by this change. Using the -c copy stream option when trimming the video get us codec accurate sub-videos BUT with potential duration mismatch due to keyframes (see PR description).
While removing this as I do here, force a re-encoding, giving frame-accurate sub-videos but through different codecs than source (ffmpeg default is x264) which might not be what we want here.

I could go with a more sophisticated approach is and detect codec from source than attempt to re-encode in same codec but not all codec variations are natively supported by FFmpeg and we could still end-up with subtle variations (color, gamma, bitrate...) compare to copy.

Copy link
Member

@iLLiCiTiT iLLiCiTiT Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the codec copy is important.

I could go with a more sophisticated approach is and detect codec from source than attempt to re-encode in same codec but not all codec variations are natively supported by FFmpeg and we could still end-up with subtle variations (color, gamma, bitrate...) compare to copy.

There is get_ffmpeg_codec_args to do so.

Copy link
Contributor

@philippe-ynput philippe-ynput Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The accuracy of the cut is probably more important than the image quality, assuming the re-encoding will not totally destroy the image quality.

Copy link
Contributor Author

@rdelillo rdelillo Jul 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just gave it more testing this afternoon this is not good enough.
I have to set copy stream option to ensure frame accurate (but not duration accurate) stuff.
When I re-encode blindly from input I got misinterplated interlaced-frames.

The only correct way I have to to "trim" properly the video right now is to extract the video as image sequence than re-encode the portion required in order to leave no room for video codec subtilities. But this is obviously way slower.

Copy link
Member

@jakubjezek001 jakubjezek001 Sep 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why dont we just simply convert the trimmed cut of the video to intermediate PNG image sequence? It would secure that we are on frame accurate and also would preserve the most of the video.

Copy link
Contributor Author

@rdelillo rdelillo Sep 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely we simply wouldn't keep the video native encoding/codec metadata.
This could end up looking different on some player.

output_path
])

Expand Down
Loading