2006-08-03, 10:49 | Link #21 |
I see what you did there!
Scanlator
|
With regards to the 120fps hybrid avi...
If I were to decimate it by a factor of 5 and encode it to Xvid (or something else), the only thing that would be adversely affected would be the ED, which becomes jerky, right? As an encoder, I don't see a need for VFR in non-AVC avi encodes unless the ED is really ****ing amazing.
__________________
|
2006-08-03, 12:30 | Link #22 | |||
翻訳家わなびぃ
Fansubber
|
Quote:
Quote:
Quote:
|
|||
2006-08-03, 12:41 | Link #23 | |
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
I really fail to see the point in 120fps AVI. Bear in mind that DVB streams are 29.97 CFR, so it's barely different from dealing with DVDs. Now it could be that the raw capper has somehow obtained a 29.97fps raw, and has gone through and decimated the sections correctly, resulting in a hybrid framerate. I think it's pretty much given that there will be an MKV timecode generated somewhere along the line, what with the tools that exist. If this is the case, what is the point in creating an AVI with null frames rather than a true hybrid framerate MKV? You are using a less efficient format to kick off with, and then you go adding null frames (which still add to the filesize a little). It's crackers. "Proper" VFR is good whether you have an ED worth saving or not. Just remember that a big chunk of anime is low framerates, and there are plenty of identical frames. Instead of using VFR to make hybrid 29.97/23.976 sections, you can use VFR to decimate identical frames. In the high framerate areas, the full motion will be preserved, or places where you have a static image over 20 frames or so, instead of coding an I frame for instance and the following 19 being P and B frames, it will allow you to code a single I frame and hold it for 20 frames in total (20 frames is sane limit imposed by DeDup, however you can modify the source and compile it for yourself, like Coderjoe and I had done). Even if you are only saving a few hundred bytes per frame, it adds up when you get into the high thousands, and it all counts.
__________________
|
|
2006-08-03, 12:46 | Link #24 | |
Senior Member
Fansubber
Join Date: Dec 2005
|
Quote:
|
|
2006-08-03, 13:03 | Link #25 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
Note that what framerate(s) the original DVB dump has doesn't matter in the slightest - what matters is what the raw looks like. Some raws have only a section (commonly the ED or the OP for a number of reasons) as a different framerate than the rest. Others have different framerate sections interspersed all through the episode (especially WMV in WMV ones). If you want to avoid making your encode jerkier than the raw is, you will have to account for the different framerates. If you don't, and encode as CFR, some sections WILL be jerky - which ones depends on the raw. EDIT: xat already said most of it, but with fewer words.
__________________
|
|
2006-08-03, 16:38 | Link #26 |
Administrator
Join Date: Dec 2003
Age: 41
|
One question I have about VFR (well, a few on the same aspect of it), and hopefully it makes sense...
It seems to me that there are two possible uses for it. One would be the common scenario where you want to "toggle" between 23.976 and 29.97 fps at the appropriate points in a video to compensate for 3:2 pulldown (this could be easily accomplished using the "v1" timecode format posted). But the other that Zero1 mentioned here (and I've seen it mentioned before too), would be to eliminate duplicate frames and have a "floaty" (constantly changing) framerate. From an implementation perspective, is the only difference between these two uses the sort of analysis done to generate the timecode file? Also, given those two uses, would it make sense to do VFR work in two phases (First "use 1" to take care of major pulldown issues (like OP/ED, etc.), leave it that way while the rest of the team does timing/typesetting, then "use 2" to eliminate duplicate frames for the final encode)? |
2006-08-03, 17:13 | Link #27 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Yes, it does make sense, kind of, and it can be done (DeDup has a "timecodes in" parameter). This "floating" framerate thing is exactly what WMV in WMV does, BTW. However, if you're going to use h.264, you'll be almost as well off just using the ordinary Dup filter, because h.264 is so efficient that identical frames compress to almost zero (IIRC it's 10 bytes per frame).
I'm afraid I don't quite understand your question about the implementation, though...
__________________
Last edited by TheFluff; 2006-08-04 at 08:03. |
2006-08-03, 17:36 | Link #28 | |
Administrator
Join Date: Dec 2003
Age: 41
|
Quote:
|
|
2006-08-04, 07:34 | Link #29 |
Part 8
IT Support
|
as a point of interest - h264 takes only 8 bytes for encoding a frame that is identical to the previous frame (ffdshow reports it as 9, but that's another story). So in the interests of sanity you are generally better jsut using dup(), which makes almost identical frames identical, rather than dedup(), which actually cuts out almost identical frames for a vfr output.
|
2006-08-04, 09:45 | Link #30 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
While it will probably save less then a mb, fewer frames also means it could encode faster depending on when and how you decimate it (I guess if you make a pass just for stats it could take longer).
|
2006-08-04, 10:09 | Link #31 | |
翻訳家わなびぃ
Fansubber
|
Quote:
|
|
2006-08-04, 17:49 | Link #33 | |
Aegisub dev
IT Support
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
|
Quote:
|
|
2006-08-04, 21:28 | Link #34 | ||
Alternative User
Join Date: Mar 2006
Location: Near the ocean
|
Quote:
That's less than 20 bytes saved per frame in Matroska, and even if 2/3 of the frames of a 29.97 fps 24 minute episode were duplicates and dropped, that's only a half a megabyte saved as opposed to leaving the identical frames in. Really not worth it. Quote:
|
||
2006-08-05, 15:05 | Link #35 |
Senior Member
Join Date: May 2006
|
btw. why wont vfr just die out already ?
i thought new hd techologie uses progessive frames at 30 or 60fps ... So why are there still these =)"(&% mixes of framerates resulting in stupid hybrid formats like 120fps raws ?! I still dont get it with these hybrid formats ... |
2006-08-05, 17:20 | Link #36 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
Actually, why don't the HD formats rather use plain 24.000 fps (aka. FILM) instead? That makes way more sense than 23.976, 29.970 or 25.000. And progressive. Interlacing sucks.
Obviously, the animators don't want to animate for 30 fps, they prefer 24 fps, because they need less frames that way (even if they only animate every second or third.) But CG people and people compositing the stuff want 30 fps, because it's not really more work and looks better. So the result becomes a mish-mash of different framerates, and the 24 (actually 23.976) fps stuff has to be telecined. Now imagine if HD was 24.000 fps progressive. None of the problems. All compatibility. It's not like any modern TV sets (or computer monitors) are limited by the AC frequency anyway, so why keep the 25/30 fps differences? Uh, sorry for slightly off-topic rant.
__________________
|
2006-08-05, 18:20 | Link #38 | ||
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
Quote:
Also sports/live video stuff doesn't look good at 23.978. You really need 29.97/59.94 for fluid motion. Same deal with PAL land (the football on BBC HD, for example, would have been unwatchable at 25fps (yes, I tried re-encoding without bobbing, and it looked like ass, 50 was way better). I do wish the world would move on, though... VFR can be a pain. Quote:
|
||
2006-08-05, 19:41 | Link #39 | |
Enigma of Nothing
Join Date: Jan 2006
Location: Seattle WA, USA
|
Quote:
|
|
2006-08-05, 19:50 | Link #40 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
It seems vfr would fit anime the best. Why should animators duplicate frames when they can just set the time they display?
This would allow for sections that are 1 fps to sections that are 30+ (i.e a pan or something). |
|
|