View Full Version : Why not 29.97 fps?
bluemist
2003-12-02, 05:26
I want to ask some encoders, why do you convert most anime into 23.976fps?
In some fansubs (ex. Da Capo), there are some subbers (R-B, Soldats) who keep the frame rate to 29.97 fps, because the anime features 'smooth scrolling' of backgrounds etc. But in the AonE & HQA version, they convert it into 23.976fps, resulting in some jerky scrolling.
So why not always 29.97? Is it hard to encode? Or are you considering the quality, filesize, etc...?
Enragin_Angel
2003-12-02, 05:43
I'm not sure what the source was originally...but MOST anime are ORIGINALLY 23.976fps. But when it's aired on TV it gets telecined to 29.97fps. Encoders simply return it to what it was originally. However, inverse telecine is pretty difficult and its almost near impossible to do it perfectly...but they can get pretty close.
As is said above, most stuff is normally 23.976fps. So it is returning it to normal framerate. Also, 23.976 has fewer frames (about 8000 fewer) than 29.97. Removing frames allows for a higher bitrate per frame and lower file size, but you can get jerkyness or obvious interlacing issues. There are some shows that are 29.97 and some are hybrid (both 24 and 30fps sections). If the show is 23.976 and the raw is 29.97, it really goes to the preference (i.e., whether they feel like decimating it or not) of the encoder. Also, sometimes the raw capturers decimate it before hand. So its not always the encoders decision.
SirCanealot
2003-12-02, 11:29
Actually, most raws come deinterlaced. A lot of raws come with the old DivX 'jerk' with them. I've been told there's way to deinterlace with no jerk, but this can be hard. I think it's impossible to do once the anime has already been deinterlaced by the original Japanese rippers. And of all the raws I've seen so far working in fansubbing, they have been pretty bad.
Also, it is true that allmost all anime is 23.9fps. 100fps.com explains interlacing well. Most of the anime I see that hassen't be ITVC'd down to 23fps exibits a lot of ghosting. Allthough the DivX Jerk is annoying, I really prefer it over ghosting.
dbzgundam
2003-12-02, 12:59
It depends on how well you IVTC... Typically, if the CPU is being interuptted during encodes I notice the IVTC doesn't go as well... Motion Search is used to determine how the frames are taken out... You can tell it's good when scrolls are nice and smooth.
And Yes, removing the extra frames cuts filesizes 20% (but filesize will most likely be the same since it's adding more bits now.)
The ONLY way to perfectly deinterlace something is to separate each field into it's own frame and double up the framerate to 60fps... But this would double the filesize... You COULD reconvert that 60fps footage into 30fps, but it becomes a cumbersome task to do so.
Be glad we're not dealing with PAL framerates... They may have the upperhand resolution wise, but the framerate conversion is just a speed up... Lazy PAL users.
Some points about what dbzgundam said...
Typically, if the CPU is being interuptted during encodes I notice the IVTC doesn't go as well...
That's not really true, but it's a general rule, when you encode, avoid to run other processus during it, since they could interfere...
And oftently it's not the ivtc that does not go well, but any step hat could be bugging... (typically divx 3.11 crap encoder)
And Yes, removing the extra frames cuts filesizes 20% (but filesize will most likely be the same since it's adding more bits now.)
That would be true if you had a non compressed video...
Since the codec compresses the image, since it can contain keyframe & deltaframe,
since in a 29.76 fps anime there might be a 23.976 lead with duplicates,
it will result most likely that the duplicates will end in a 'near zero sized delta frame,
Meaning on a perfect clean image,
for a 25min clip you'll have 1-5mb of 'near zero sized delta frame'
(while those 1-5mb are 20% of the total frames in number)
But since we get anime raws of a various and very low quality sometimes,
theses frames can have heavy noises and can be not compressing well at all...
on 60fps
...But this would double the filesize...
Again, it's only true when you don't compress...
So about ivtc?
ivtc is usually done for performance issue:
not all machines are able to play a 29.76 fps clip while more are able to play the clip
if it was ivtced...
Since most animes are made as 24fps, we can find a way to ivtc,
this being sometimes easier, deferred to automatic process without problems
and sometimes very painfull, needing an ivtc by the hand...
A bad quality raw can benefit of ivtc, since we remove bad duplicates that would take some space....
To speak about dc, there is some jerkiness in eps 1 due to a bad setting of mine,
i noticed it after the release while working on the pv,
but for the other episodes depending of the eps the raw quality were very various...
from some clean 60fps raw in the beginning to some 30 fps raw in the middle with
very high or low quality (in term of image), and the ivtc process was a bit different
so some jerkiness might have showed here and there,
but since it's a free fansub, nothing that would stop someone from watching anime...
That would be true if you had a non compressed video...
Since the codec compresses the image, since it can contain keyframe & deltaframe,
since in a 29.76 fps anime there might be a 23.976 lead with duplicates,
it will result most likely that the duplicates will end in a 'near zero sized delta frame,
Um... most telecining create duplicate fields, not frames, so you'll have 5 different 29.97 frames, although they are various combinations of 4 23.976 frames, with no two of the 29.97 frames different.
Since most animes are made as 24fps, we can find a way to ivtc,
this being sometimes easier, deferred to automatic process without problems
and sometimes very painfull, needing an ivtc by the hand...
Unfortunately, GONZO did something really creepy with FMP, and the same can be said about other stuff too. In FMP, the footage is 23.976, but all the post processing was done in 29.97, so all those special effects are 29.97.
dbzgundam
2004-01-24, 17:50
Video lowering to 20% via IVTC is simply in reference to if it's CBR or something....The decrease is of course much more measureable with uncompressed video though.
I also do not see the logic in encoding in 23.976 when 23.976 is NOT a real frame rate to begin with! 23.976 is simply 24fps slowed down to 23.976, then more frames are inserted (visit 100fps.com to see EXACTLY how it's done) to match 29.97. So in reality 23.976 is only an existant and correct framerate because computers are able to convert to that exact measure. So technically, 24 would be more correct.
::sigh:: That's just me being the always persistent encoder. :P
Anyway, I didn't say it was a FACT that CPU usage affected IVTC performance... Infact this only seems to partially apply to TMPGEnc anyway. VirtualDub seems to have no trouble. Another note is that the framerate does not always have to be doubled in all instances. Infact....it never does; use the proper deinterlacer and framerate conversion (to 60fps...or in actuality, 59.94fps) should not be necessary. One such interlacer is "Tomsmocomp" which should retain the framerate and leaves no "bobbing" or "ghosting" trails in the video. Another suitable deinterlacer is MarkFD's "aDeInt."
You may notice that some older series (80s, early 90s) may not like the fps conversion since the pans aren't always smooth to begin with, nowdays of course, pans all computer driven and are basically incredibly smooth, making framerate conversion nearly flawless.
PocariSweat
2004-01-24, 20:13
In FMP, the footage is 23.976, but all the post processing was done in 29.97, so all those special effects are 29.97.
Actually this isn't too uncommon. What happens is especially with pure CGI scenes, the video's generated at the full NTSC 29.97 framerate. This sort of mixed content makes it hell to deinterlace properly, and it also tends to make the CGI look oddly *too* smooth and distracting when mixed with the normal scenes.
You can also notice this in a regular TV show that's been recorded direct to video. It'll have a weird quality that's hard to place but seems fakeish somehow. Now days you only see it in very low budget stuff. You'd think the higher framerate would look better, but somehow were just too used to seeing the 23.976/24 fps that movies use.
I remember seeing an old BW Twilight Zone episode that was recorded this way (one of the rare hour long ones they don't show very often) - the show looked remarkably sharp and clear - it did look almost too "real" where everything had an almost sound stage or live play feel to it. Very strange, it had to be one of the really early uses of direct video recording I'd guess.
Lastly, another big reason people IVTC stuff is because, unlike a TV, on a computer monitor you can really see the interlacing unless you filter it out in post-processing (like selecting bob over weave). I notice it all the time watching NTSC DVD content and it's pretty ugly.
There are ways to do a proper IVTC if you have time and patience to do it. And after you've done this several times and get used to it, it's like piece of cake. Knowledge is power, but sadly enough most raws you find these days have poor quality and some with poor IVTC as well which makes it harder to use than before where the magical raw supplier who released 350mb raws.
^danshi^
2004-01-27, 19:43
Be glad we're not dealing with PAL framerates... They may have the upperhand resolution wise, but the framerate conversion is just a speed up... Lazy PAL users.It used to be that way (original source framerate 24 fps --> speedup to PAL 25 fps) untill some years ago, but now they are mostly using a different method maintaining the original episode lenght but resulting in even more ghosting and interlacing artefacts than in the NTSC version (NTSC framerate --> some wtf ever conversion to PAL framerate that can't be inversed by VirtualDub) So most PAL anime DVDs (and especially the rips) look rather fuzzy compared to the originals :(
Hope I didn't confuse you too much, I don't understand it exactly myself either :heh: I'm not 100% sure if what I just explained is right.
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.