Skip to content
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.

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

EDL drifting out of sync #26

Open
pietrop opened this issue Dec 13, 2016 · 5 comments
Open

EDL drifting out of sync #26

pietrop opened this issue Dec 13, 2016 · 5 comments

Comments

@pietrop
Copy link
Collaborator

pietrop commented Dec 13, 2016

As raised by one of the users when exporting an EDL file (paraphrasing)

for videos longer than 15 minutes it starts drifting out a sync of 30 to 20 seconds. In recognising the in and out points of the video in the EDL. Losing Accuracy.

To reproduce this issue
Get a video file NTSC, 30fps

  1. Add video to autoEdit
  2. Get a transcription
  3. Scroll towards the end of the transcription and select one of the last lines
  4. export EDL and reconnect in premiere (or other editing software of choice)
  5. When reconnecting sequence chose NTSC, 30fps in the sequence.
  6. See if the video segment correspond to the text selection in the app.

If bug occur, expecting it to drift of and not be same selection.

Further test. with same EDL file.

  1. import in premiere, but this time when chosing sequence settings chose PAL 25fps
  2. See if the video segment correspond to the text selection in the app.

From previous tests expecting the text selection in the app to match video segments in the EDL sequence using when choosing PAL and 25fps

Considerations

The timecode module used in the EDL composer has a default setting on 25fps.

Possible fix

Allow to pass in fps to timecode as a variable and give the user the option to export the EDL as a NTSC sequence?

Need to look more into how timecodes and PAL/NTSC work.

@pietrop
Copy link
Collaborator Author

pietrop commented Dec 13, 2016

Note, NTSC is actually 29.97fps not 30.

@pietrop
Copy link
Collaborator Author

pietrop commented Dec 13, 2016

I tried this, with the node-timecodes module in terminal

> var timecodes = require('node-timecodes');
undefined
> timecodes.fromSeconds(1427.4);
'00:23:47:10'
> timecodes.fromSeconds(1427.4, {frameRate: 29.97});
'00:23:47:NaN'

There might be an issue with the fromSeconds function.
Raised as an issue here

@pietrop
Copy link
Collaborator Author

pietrop commented Dec 13, 2016

See issue 25 for example.

@pietrop
Copy link
Collaborator Author

pietrop commented Apr 27, 2017

  • Node-timecodes module issue has been resolved in it's repo but just updating to latest version
  • reconnecting that file using PAL gives accurate EDL. reconnecting using NTSC does not.

Hypothesis is that it drifts because of PAL vs NTSC frame rate differece. in autoEdit, it's default to PAL.

Possible test/solution is

  • to read fps in metadata read
  • pass that when converting timecode to seconds in EDL.
  • test if it works

@pietrop
Copy link
Collaborator Author

pietrop commented Apr 27, 2017

Figured it out, if I add an optional frame rate to the EDL module, make selection, export EDL, and then connect as NTSC the sequence in premiere works with no drift.

timecodes.fromSeconds(this.tapeIn, {frameRate: 29.97}) 

so next step to fix this are

  • either read fps from metadata.
  • or if this this gives odd results such as 1001/48000, another solution is to ask in new transcription form, to specificy if it's NTSC or PAL.
  • then figure out a way to add that info to the EDL json when making papercuts in transcription and paperedit view so that it can reach the EDL module.

Then test it out again.

@pietrop pietrop added this to To do in Bugs Nov 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Bugs
  
To do
Development

No branches or pull requests

2 participants