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

Non integer framerates #6

Open
benroeder opened this issue Sep 5, 2016 · 3 comments
Open

Non integer framerates #6

benroeder opened this issue Sep 5, 2016 · 3 comments

Comments

@benroeder
Copy link

Do you have any plans to support generation of non integer framerates such as
NTSC (30/1.001) or the 23.976/23.98 Film'ish ones ?

@matt-hammond-001
Copy link
Contributor

Looking at the command line arguments, it looks like you can already specify a non integer tick rate for a timeline. (see lines 92 and 93 of src/testsetupcmdline.py).

Have you found any part of the project where it is not possible to specify the require frame rate?

@benroeder
Copy link
Author

Sorry I did not make my self clear, the generation of test material, is what I was after.
https://github.com/bbc/dvbcss-synctiming/blob/master/test_sequence_gen/src/generate.py#L175 see test_sequence_gen/src/generate.py line 175
which relies on https://github.com/bbc/dvbcss-synctiming/blob/master/test_sequence_gen/src/generate.py#L67 line 67

@matt-hammond-001
Copy link
Contributor

matt-hammond-001 commented Sep 6, 2016

Ah, I understand.
To avoid a massive rewrite in can probably be hacked in relatively easily by adding a "x1.001" command line option:

  • To select a suitable "pattern", then picking the numerically closest from that existing list is probably acceptable.
  • The image drawing code could then simply pretend, for the purposes of generating video frames, that it is running at the integer rate. Might need to suppress generating a "hh:mm:ss:ff" graphic to avoid being misleading (*).
  • The audio rendering code would need to pretend it is running at a slightly faster sampling rate (x1.001) when calculating where to begin and end each beep.
  • The timings and fps saved into the metadata file would need scaling by x1.001

I don't personally plan to make the changes, but contributions are very welcome.

* I won't even pretend to understand drop frame timecode :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants