View Single Post
Old 14th May 2018, 10:46   #6154  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,829
Quote:
2855 [Chapter Creator]time codes will only be changed when the input fps is changed if the input fps of the source is not known (regression of 2851)
Thanks for the hard work! It seems to be working the other way around though. Changing the input FPS changed the timecodes in the GUI with an IFO as the source and when previewing a script, but not for a txt chapter file.
Although... if chapter five is at 00:25:07, I'm not sure why it shouldn't stay at 00:25:07 whether the input is 12fps or 250fps.

Quote:
@hello_hello - changing the output fps does not change the time codes in the preview as this would be a major change. Please have a look if you can work with it. Nevertheless I will have a look to have it completely changed but this is nothing which I can do in a few days.
I'm not sure if it's this simple, but it's almost as though the Input FPS and the Output FPS need to be swapped.
If the "top" FPS was the output and the "bottom" FPS was the input...

Changing the "bottom" FPS could continue to have no effect on the timecodes in the GUI, no effect on the preview timecodes, and logically no effect on the timecodes saved to a chapters file. Changing the "bottom" FPS probably should do nothing but change the "top" FPS to match, and when they match, the "top" FPS should also do nothing (aside from determining the preview frame rate, I think).

On the other hand, changing the "top" FPS independently should continue to change the timecodes in the GUI, and being the "output" FPS it probably makes it's the assumed preview frame rate. Changing the "top" (output) FPS independently would also have to change the timecodes saved as chapters, but then everything should match. The timecodes in the GUI, the saved timecodes and the preview frame rate would all be stretched together. Chapters would always correspond to the same frames in the preview.

The current "top" and "bottom" FPS would have to swap positions in the GUI, and I guess the calculations would need to be reversed. It'd probably require a third FPS option to restore the original QP functionality, as the (stretched) timecodes need the chapter creator equivalent of ChangeFPS() applied to them. Have I mentioned my "QP FPS" idea?

I don't know if any of that has any basis in reality. It works well in my head.

Last edited by hello_hello; 14th May 2018 at 10:59.
hello_hello is offline   Reply With Quote