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

[rdelillo]

Changelog Description

resolve: ynput/ayon-hiero#77

When trimming video from OTIO timeline, we use ffmpeg with -c copy settings.
This means copy the streams (audio + video) without re-encoding, which is very performant but only allows to cut at video keyframes.
The issue with this approach is that the resulting trimmed video duration is not safely guaranteed:

• https://superuser.com/questions/924223/ffmpeg-no-cutting-accurately
• https://video.stackexchange.com/questions/16750/using-ffmpeg-to-cut-videos-with-more-precision-than-key-frames-allow

Additional info

Paragraphs of text giving context of additional technical information or code examples.

Testing notes:

1. Create a timeline in Hiero or Resolve
2. Create a clip based on video media which requires trimming with no handles
3. Publish the resulting plate with review
4. Ensure the plate + review videos duration match the source clip in the timeline

[ynbot]

Task linked: AY-8039 Plate duration mismatch when extracting from Hiero

[rdelillo]

@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.

[iLLiCiTiT]

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.

[philippe-ynput]

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

[rdelillo]

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.

[jakubjezek001]

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.

[rdelillo]

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