Fix PTS error

[moveman]

This is to fix #677

1. Change to use 196 x 27000000 Hz clock frequency as the unit of PTS instead of using nanosecond. With this unit, frame duration of video frame of common frame rate can be expressed in integer and calculation will be precise. Sample duration of common audio codec of common audio sample rate can also be expressed in integer.
2. Change the correctFps() function to support more frame rate. This function is needed to ensure the m_pcrIncPerFrame is integer and has no precious loss for common frame rate.

Sample output files before the change and after the change are put here, along with the PTS analysis excel: https://drive.google.com/drive/folders/1fCWmNde66EUb5VE8GEyh_ZneqBTStXGa?usp=sharing

There are many code used the term Nano which does not match the change. We need to come up with a new term.

[jcdr428]

@moveman I've kept the rounding to nearest as this should not affect your purpose. Please confirm whether this solves the issue.

[moveman]

Hi @jcdr428, the rounding has to be removed. Consider the original code: newPCR = (uint64_t)((m_endStreamDTS - m_minDts) / INT_FREQ_TO_TS_FREQ + 0.5 + m_fixed_pcr_offset); The type of INT_FREQ_TO_TS_FREQ is changed from double to int64_t, thus, (m_endStreamDTS - m_minDts) / INT_FREQ_TO_TS_FREQ will become an integer. The + 0.5 will become meaningless.

if newPCR = (uint64_t)((m_endStreamDTS - m_minDts) / INT_FREQ_TO_TS_FREQ + 0.5 + m_fixed_pcr_offset); can work well with the PTS error fix, I think changing it to newPCR = (m_endStreamDTS - m_minDts) / INT_FREQ_TO_TS_FREQ + m_fixed_pcr_offset; should not cause any problem.

[jcdr428]

@moveman you're right, the +0.5 rounding is useless.

Could you please push the 'nano' commit again, with the changes needed so that the four timing options (--start-time, --cut-start, --cut-end, --split-duration) are not broken ?

Edit: ok, I've pushed your commits again, should be fine this time for --cut-start and --cut-end. I'll look at the other options.

[moveman]

Many thanks @jcdr428.