Page MenuHome

VSE: Use timecodes by default
ClosedPublic

Authored by Richard Antalik (ISS) on Jan 23 2022, 6:38 PM.

Details

Summary

Movies with variable frame rate can cause mismatch of displayed frame
when proxies are used. Since proxies are not used for rendering, this
means, that output may be different than expected. This problem can be
avoided when timecodes are used.

Set used timecode to Record Run. Timecodes are built with proxies at
the same time, therefore if proxies are built and used this will
resolve possible mismatch of output.

Record run is chosen, because it will show frames based on time they
were encoded by encoder and should match behavior as if movie was
played back at normal speed. This change is done only for new strips
in order to not overwrite user defined settings.

Other minor changes:

  • When proxies are enabled, size 25% is no longer set by default. It was mostly annoying anyway.
  • Silence warning when timecode file is not present. This was introduced in 4adbe31e2fc98f982aed3d97505513750ec348d4. Previously use of timecodes was hard-coded in sequencer and this error would spam console if timecodes would be enabled by default and proxies would be never built.

ref: T95093

Diff Detail

Repository
rB Blender

Event Timeline

Richard Antalik (ISS) requested review of this revision.Jan 23 2022, 6:38 PM
Richard Antalik (ISS) created this revision.

Is my understanding correct that it is still required to manually build timecodes for such kind of videos to work reliably?

Is my understanding correct that it is still required to manually build timecodes for such kind of videos to work reliably?

Not quite. This patch makes it, so when you build proxy, you will be automatically using timecodes. If you don't build them then you will be using original media anyway. Problem reported was that when proxy is used, preview image looks different to when proxies are not used.

There is another aspect of this problem with VFR media, when seeking itself is unreliable. I was looking into adding automatic timecode building, but as I have said in T95093, this causes thread to use 100% of CPU and make UI barely responsive for a while (apx 1/5 of strip duration). If you edit many strips like this, it would happen randomly when seeking error is detected, so it would be quite disruptive. I am hoping to resolve this in D13583 instead, which would make timecodes not needed at all. But any approach around VFR media, even checking whether it is really VFR is a guesswork. I think that approach in D13583 is least disruptive to workflow and perhaps most reliable.

Thanks for explanation.
From the code aspect this seems fine. Indeed lots of other things can be improved, but is not really scope of this patch.

This revision is now accepted and ready to land.Jan 25 2022, 11:48 AM
This revision was automatically updated to reflect the committed changes.