AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > General Anime > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2006-08-03, 10:49   Link #21
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 36
Send a message via AIM to Starks
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.
__________________
Starks is offline   Reply With Quote
Old 2006-08-03, 12:30   Link #22
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 50
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Quote:
Originally Posted by ffdshow
It's lucky that so far I only encode in mkv, so I won't receive any complain if I switch to vbr, hopefully.
Just yesterday, we made a vfr release in mp4. So far, I haven't seen anyone take a notice of it or cared or complained. So it works.

Quote:
Originally Posted by Starks
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?
That depends. I've heard of stories where episodes were made in pure hybrid mode throughout the episode that if you decimate carelessly, those 30fps sections within the main episode would get jerky too.

Quote:
Originally Posted by Starks
As an encoder, I don't see a need for VFR in non-AVC avi encodes unless the ED is really ****ing amazing.
As long as the container used can handle vfr, I don't see why we wouldn't use vfr in any other codecs, especially if we can show people how it can be done. Smooth video is smooth video, no matter how crappy the video quality itself is. I think it's a benefit.
Sylf is offline   Reply With Quote
Old 2006-08-03, 12:41   Link #23
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
Quote:
Originally Posted by Starks
As an encoder, I don't see a need for VFR in non-AVC avi encodes unless the ED is really ****ing amazing.
I'll assume we're talking raws here.

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.
__________________
Zero1 is offline   Reply With Quote
Old 2006-08-03, 12:46   Link #24
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
Quote:
Originally Posted by Starks
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?
I wouldn't assume that a source is hybrid simply to compensate for an OP/ED while the rest of the episode is 23.976fps. As Sylf pointed out, it's possible for 29.97fps content to be within the episode itself; those sections are fair-game for jerkiness when you decimate.
xat is offline   Reply With Quote
Old 2006-08-03, 13:03   Link #25
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 37
Quote:
Originally Posted by Starks
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?
Uh, well, the ending in itself has nothing to do with it... it all depends on the raw.

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.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2006-08-03, 16:38   Link #26
relentlessflame
 
*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)?
relentlessflame is offline   Reply With Quote
Old 2006-08-03, 17:13   Link #27
TheFluff
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...
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read

Last edited by TheFluff; 2006-08-04 at 08:03.
TheFluff is offline   Reply With Quote
Old 2006-08-03, 17:36   Link #28
relentlessflame
 
*Administrator
 
 
Join Date: Dec 2003
Age: 41
Quote:
Originally Posted by TheFluff
I'm afraid I don't quite understand your question about the implementation, though...
Nope, actually, I think you answered it perfectly. The first "use" of VFR is sorting the source material into sections by framerate (23.976, 29.97, etc.), and the second "use" can be done after the first using DeDup, but in either case, it all comes down to the exact same thing: a timecode file that controls how the mkv is played. And also, what you said about H.264 also matches what I heard/suspected. So, although it may not seem like it, you actually answered both of my questions. Thanks!
relentlessflame is offline   Reply With Quote
Old 2006-08-04, 07:34   Link #29
checkers
Part 8
*IT Support
 
 
Join Date: Jul 2006
Location: Western Australia
Age: 35
Send a message via MSN to checkers
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.
checkers is offline   Reply With Quote
Old 2006-08-04, 09:45   Link #30
DryFire
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).
DryFire is offline   Reply With Quote
Old 2006-08-04, 10:09   Link #31
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 50
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Quote:
Originally Posted by DryFire
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).
I really wonder how much of encoding time difference it really would make though. Sure, there's always an overhead of having to compare frames to frames before encoding to calculate the difference. But once the program determines they're identical, I can't imagine it taking long at all to produce 8 bytes.
Sylf is offline   Reply With Quote
Old 2006-08-04, 13:08   Link #32
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 41
Dedup was proven to be quite useless ages ago, even when we only had XviD/DivX. There are far better means of reaching lower compression.
Nicholi is offline   Reply With Quote
Old 2006-08-04, 17:49   Link #33
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
Quote:
Originally Posted by checkers
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.
While that is true, don't forget that there is also a container overhead per frame - but it's significantly smaller in Matroska, than in AVI. IMO, it still doesn't justify going through all the trouble to use DeDup, though.
ArchMageZeratuL is offline   Reply With Quote
Old 2006-08-04, 21:28   Link #34
Yuvi
Alternative User
 
 
Join Date: Mar 2006
Location: Near the ocean
Quote:
Originally Posted by ArchMageZeratuL
While that is true, don't forget that there is also a container overhead per frame - but it's significantly smaller in Matroska, than in AVI. IMO, it still doesn't justify going through all the trouble to use DeDup, though.
Yeah, from what I understand, overhead in Matroska for small difference frames is 11-12 bytes per frame (versus AVI's 24 bytes I think.) There's also an added overhead for the remaining frames, though, because for each frame sequence that's removed, the previous frame needs a duration set (though it would be set already if it's in a section with a different frame rate than the default), which is 3-4 bytes per sequence of frames dropped.

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:
Originally Posted by Sylf
I really wonder how much of encoding time difference it really would make though. Sure, there's always an overhead of having to compare frames to frames before encoding to calculate the difference. But once the program determines they're identical, I can't imagine it taking long at all to produce 8 bytes.
I can't speak to how x264 handles it, but a programmatic test to determine only whether two frames are identical takes no longer than the time to read both frames' data.
Yuvi is offline   Reply With Quote
Old 2006-08-05, 15:05   Link #35
M.D. Geist
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 ...
M.D. Geist is offline   Reply With Quote
Old 2006-08-05, 17:20   Link #36
jfs
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.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2006-08-05, 17:24   Link #37
Yazakura
Enigma of Nothing
 
 
Join Date: Jan 2006
Location: Seattle WA, USA
Does anyone use the Windows Movie maker to fansub, if that's possible at all?
Yazakura is offline   Reply With Quote
Old 2006-08-05, 18:20   Link #38
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
Quote:
Originally Posted by jfs
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.
The WMV-HD movies avaliable are actually 24fps (yes, 24.00). Then again, it's, you know, WMV.

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:
Originally Posted by Yazakura
Does anyone use the Windows Movie maker to fansub, if that's possible at all?
No. I seriously hope no one ever has, anyway.
Eeknay is offline   Reply With Quote
Old 2006-08-05, 19:41   Link #39
Yazakura
Enigma of Nothing
 
 
Join Date: Jan 2006
Location: Seattle WA, USA
Quote:
Originally Posted by Eeknay
The WMV-HD movies avaliable are actually 24fps (yes, 24.00). Then again, it's, you know, WMV.

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.



No. I seriously hope no one ever has, anyway.
What's the best software to use for it then?
Yazakura is offline   Reply With Quote
Old 2006-08-05, 19:50   Link #40
DryFire
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).
DryFire is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 06:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
We use Silk.