mirkosp wrote:Anyways, if you're interested in the why someone would do 120fps... as you might know, some sources are hybrid, meaning that they could be both telecined and full field interlaced. This means that some scenes would be animated at 29.97 and other scenes at 23.976. Now, a solution could be just IVTC'ing it all, and dropping some of the frames of the 29.97, which might make the motion a bit jerky. Similar issue if you just full field deinterlace, except that the scenes that'd have an odd motion would be the 23.976 ones. To fix this issue with a constant frame rate, the solution is to bring everything to 120fps, so that both parts will have smooth animation. This is the "perfect" choice if you need to make an avi encode. However the perfect solution would be to use YATTA or animeivtc so that one could output timecodes in order to make a VFR encode (requires an mkv container, though).
To be a tad more specific, the additional frames are null frames, which contain no data, and are essentially 'ignored' on playback. This is required because AVI doesn't support VFR, and this is a way of hacking it in. 120fps is chosen simply because of the assumption that the least common denominator of 24 and 30 (which is 120) is the best solution. However in reality, it would be just as optimal to leave the 29.97fps parts alone and add null frames to the 23.976 sections, bringing everything up to 29.97fps instead, considering the null frames get ignored anyway. It'd also result in smaller container overhead.
avi_tc is used to remove the null frames and create a timecodes file, which is why it's important to do so
prior to loading the video in a script - because AviSynth (or VirtualDub, for that matter, if you just loaded the AVI) will interpret those null frames as real frames.
All of this is essentially blamed on Japanese RAW cappers who don't want to use proper methods of storing video - you can even find 120fps H.264
MP4s, which just makes so little sense it's not even funny.