The default framerate for NTSC sources is not accurate enough

[tmhlegolas]

I understand the program is undergoing a major change but wanted this on the radar if it isn't.

In the h.264 encoder the default setting for framerate is something like passthrough, being set to "%f_frame_rate%" However in the case of NTSC framerates this rounded number 29.97 and 23.98 is insufficient to create an accurate framerate.

Generally when NTSC frame rates are used within ffmpeg the correct fractional rates of 30000/1001 and 24000/1001 are used.

When you put in those framerates in the framerate field of the encoder the encode fails with this error "Encoding failed - No moov atom found. File might be corrupt!". I have had luck setting a user variable to 30000/1001 or 24000/1001 and inputting that user variable into the framerate field, this may be a syntax issue.

I am also wondering why it looks like i'm the first to encounter this. Perhaps I have done something else wrong that my files don't pass through correctly?

I have a test workflow that is boiled down to the simplest nodes I can manage, along with a test video file if it will help. I can send it to whoever would like.
Thanks!
-Alan

[admin]

Hi ALan,

FFAStrans does not round number but it also does not currently support the numerator/denominator method in the input field. However, I can see it would be nice to be able to use it and I will take a look at it for the next version. On the other hand, will a number like 29.97002997 (rounded 30000/1001) not be accurate? And if so, how do you notice the lack off accuracy?

Anyway, thanks for notifying

-steinar

[tmhlegolas]

The lack of accuracy came back to me from my 23.976 files with some players drifting audio and video out of sync over an hour long program.

The expanded 29.97 number you used did pass and is what I had in place for 29.97 before swapping to my new fractional variable method.

I am not sure what issues could arise with various player and ingest system compatibility with that long form number. Or if it is entirely accurate. I know that IMF which just be exact in time always uses the fractional rate to avoid any issues.

As I said though if I put the fractional rate into a variable it works without issue. I just have to have a node to catch the rounded framerate and set that variable.