A nice blogger thankfully left a comment to a post, QTKit, QTStringTime() and SMPTE, mentioning a newly changed timescale when video is recorded by QTKit Capture.
So, I wanted to know why it was changed and asked in quicktime mailing list of Apple Inc.
I got a message from Brad Ford at Apple. So, I would like to share this information with visitors! :)
This is true. But it’s not a recent change. QTKit Capture recordings have always written files with more accurate timescales than the legacy Sequence Grabber code. The reason is accuracy. Reporting 29.97 NTSC video frames as having a duration of 100 / 2997 will introduce drift over time. Using a timescale of 30000 with frame times of 1001 is accurate and will not introduce a/v sync drift. The use of 2997 as the timescale is historical, and has a lot to do with Final Cut Pro compatibility.
Your code should never rely on movies having a fixed timescale. Assuming that timescale == 2997 means NTSC is a broken assumption. NTSC could just as well be written with a timescale of 90000 (HDV cameras run a 90 kHz clock, so it would not be unreasonable to write them to a quicktime movie unaltered).
Or.. you can search it on the quicktime mailing