AnimeSuki Forums

ender · 2006-10-06, 02:07

Quote:

Originally Posted by Zero1

Code:

------------------------------------------------------------------------
r581 | pengvado | 2006-10-05 10:15:55 +0200 (Thu, 05 Oct 2006) | 2 lines

no more vfw

Discuss

Who stole the rest of this post? Otherwise, finally!

Harukalover · 2006-10-06, 08:15

I have a feeling that most people who were doing vfw encodes weren't often updating their x264 anyway... -_-

But again its good that its finally removed. Hopefully will phase itself out now and make it that new H264 encoders don't go the vfw path anymore.

Nicholi · 2006-10-19, 23:35

I'm sure someone will make a mirror with the last vfw revision as a bastion of hope for the idiot encoders out there. Perhaps Power2Lamers will do it? As he is the obvious expert in why H.264 so totally is meant to be in AVI.

DryFire · 2006-10-19, 23:41

In an attempt to derail a flame war:

Has anyone had a chance to play with deadzone?

Zero1 · 2006-10-20, 13:23

A larger deadzone causes more coefficients to be rounded to zero, which in turn requires less bits to code at a said quality (or quantizer). It's sort of catch 22 (a better description does not come to mind), larger deadzone zeros more coeffs which reduces filesize (at a said quantizer it would look lower quality than the default deadzone with the same quantizer), but on the otherhand, when encoding to a set filesize, this loss and reduction in bitrate for a said quantizer means you can use lower quantizers for the same bitrate. It's like trellis in the sense that you lose something to gain something, which in turn lowers the total loss.

Obviously lowering the deadzone requires more bitrate. It's basically DCT decimation at the coeff level (remember that is a switch to disable DCT decimation), but IMO DCT decimation is not a bad thing, so long as it is not excessive (as with anything really).

Default values are optimal for RDO, no need to mess with it really, but it might provide an interesting option for low bitrate encodes where detail is not essential, as long as it doesn't block to hell.

It's sort of about finding the lesser of two evils. Detailed + high quants at a set filesize, or not so detailed and lower quants at a set filesize.

Quarkboy · 2006-10-21, 04:47

This might be a bit off-topic, but I've been experimenting with x264 encoding what I think might be the evilest source ever of anything....

Basically, I want to encode the replay of my triumphant beating of the extra stage in Pefect Cherry Blossom (see another person's video on youtube: http://www.youtube.com/watch?v=ZPO5giJmdK8 )

The full run is 16 minutes long,and I've captured the video at the full 60 fps (the game runs at that framerate and it looks crappy in comparison at 30 fps), using FRAPS to a 30 gig avi.

I crop out just the playing field so it's 384x448, and then try to encode the sucker.

To give you a concept of how insanely uncompressable this is, with x264 insane settings, and constant quality 18, the average bitrate ends up around 9000 Kbps...

If I set the bitrate to a more reasonable 1700 or so and do it two pass, I get average quants of _34_!!! It looks pretty decent, actually, but should I just give up on getting it compressed well?
Are there some kind of special settings which might help on a source like this?

Quarkboy asks in frustration....

P.S. this would probably make for a great encoder stress test. Also, xvid at 1700 Kbps is a blocky mess, probably 5-6 times worse than the h.264.

Starks · 2006-10-21, 05:24

Quote:

Originally Posted by Quarkboy

This might be a bit off-topic, but I've been experimenting with x264 encoding what I think might be the evilest source ever of anything....

Basically, I want to encode the replay of my triumphant beating of the extra stage in Pefect Cherry Blossom (see another person's video on youtube: http://www.youtube.com/watch?v=ZPO5giJmdK8 )

The full run is 16 minutes long,and I've captured the video at the full 60 fps (the game runs at that framerate and it looks crappy in comparison at 30 fps), using FRAPS to a 30 gig avi.

I crop out just the playing field so it's 384x448, and then try to encode the sucker.

To give you a concept of how insanely uncompressable this is, with x264 insane settings, and constant quality 18, the average bitrate ends up around 9000 Kbps...

If I set the bitrate to a more reasonable 1700 or so and do it two pass, I get average quants of _34_!!! It looks pretty decent, actually, but should I just give up on getting it compressed well?
Are there some kind of special settings which might help on a source like this?

Quarkboy asks in frustration....

P.S. this would probably make for a great encoder stress test. Also, xvid at 1700 Kbps is a blocky mess, probably 5-6 times worse than the h.264.

That's quite a challenge...

(BTW, that video proves that human beings are capable of transcending time, space, and can enter into SEED mode.

Quarkboy · 2006-10-21, 05:28

Quote:

Originally Posted by Starks

That's quite a challenge...

(BTW, that video proves that human beings are capable of transcending time, space, and can enter into SEED mode.

It's not THAT difficult... took me about a week of practice to beat it....

Unfortunately, that's only the prequal to the hadest stage, "phantasm", which I haven't been able to touch...

checkers · 2006-10-21, 06:00

upload an unprocessed sample

That means 60 fields not 60fps! :P

Starks · 2006-10-21, 06:27

what's the diff between pics per sec, fields per sec, and frames per sec?

Quarkboy · 2006-10-21, 06:36

Quote:

Originally Posted by Starks

what's the diff between pics per sec, fields per sec, and frames per sec?

Well, in this case, I don't know what checkers is talking about... It's captured from a computer screen, so there's no interlacing, it's true 60 frames per second.

normally 60 fields persecond is the same as 30 frames per second, since 1 frame = 2 fields.

And I have no idea what a pic per sec is.

checkers · 2006-10-21, 06:42

err sorry, I was thinking it was a ps2 or some video console game - 60fps is fine then

edit: 60 pics/sec == 60 frames/sec == 60p
60 fields/sec == 60i

Quarkboy · 2006-10-21, 07:01

Quote:

Originally Posted by checkers

upload an unprocessed sample

That means 60 fields not 60fps! :P

Ask, and ye shall receive. Here's a lossless h264 encode of 12 seconds of the demo: (yes I know that it's not ACTUALLY lossless... but the huffy was 320 MB)

go to #Arienai on irc.chatspike.net, and type:

/msg Seekun xdcc send #124

It's 84 MB (for 12 seconds

).

Zero1 · 2006-10-21, 07:18

Without being able to test this first hand, you can only really guess at it. Obviously you want to max all settings if you haven't already done, set a decent amount of max consecutive bframes and set a high b-bias.

The image won't be as "accurate" as the original since it's interpolating (the difference between P frames and B frames), but that sort of loss may be acceptable overall if it lowers the quants; again it's this situation of sacrifice one thing to gain on another which ought to help the video out in general.

Even though 16 minutes is a decent length, you might even be as desperate enough to do a 3 pass (even though I normally would just say that 2 pass is sufficient on sources this long).

Set a decent GOP size too, this will help cut down on the number if I frames used; but I guess this source is mainly P frames, eh? Maybe also set a chroma QP offset, but you have to be careful here, if you go over a certain amount, you tend to lose more than you gain (diminishing returns again). Remember that both chroma planes together are only as large (resolution wise) as half a luma plane, so you really have to sacrifice the choma to make a worthwhile improvement on the luma.

You may use deadzone(!) or a custom matrix. I'm assuming the graphics are jagged as opposed to nice smooth compressible edges. A smoothing matrix may help (or an avisynth filter for that matter).

If you are screamingly desperate, perhaps you could even reduce the horizontal resolution and use anamorphic. I noticed the resolution is odd to begin with, so I don't know if you are already using anamorphic to stretch it to the correct aspect ratio, or if that's how it's supposed to be.

How about posting the x264 output and/or your settings here? Might give us something to go on.

lamer_de · 2006-10-21, 07:25

Usually the advice for encoding video game footage is to add some motion blur or use strong antialiasing to help compression (but I somehow doubt a 2D game makes use of FSAA settings). There are some older threads on doom9, but they're well, old :P (from 2005 and prior).

CU,
lamer_de

Power2All · 2006-10-22, 11:47

Quote:

Originally Posted by Nicholi

I'm sure someone will make a mirror with the last vfw revision as a bastion of hope for the idiot encoders out there. Perhaps Power2Lamers will do it? As he is the obvious expert in why H.264 so totally is meant to be in AVI.

You fail life.

Medalist · 2006-10-22, 12:07

Power2Ass you fail...h.264 in avi is a total hack. (b-frames) is a hack in avi. You Power2Ass need to stop sucking avi's dick & learn to encode

[Avi isn't the only format out there..there's more suitable containers for the different codec(s)]

Power2All · 2006-10-22, 12:33

Quote:

Originally Posted by Uchikatsu

Power2Ass you fail...h.264 in avi is a total hack. (b-frames) is a hack in avi. You Power2Ass need to stop sucking avi's dick & learn to encode

[Avi isn't the only format out there..there's more suitable containers for the different codec(s)]

You should learn to stop flaming.
If you never saw my encodes, then you fail even more.
Yah I agree VfW is old and whatever not.
I use it for a purpose you guys don't seem to understand.

About the different codecs out there crap, sorry but AVI is a suitable container and well used (and it's features is good enough what I need).
If your talking about the MKV/OGM/MP4 crap, sorry to dissappoint you, but I don't need MKV/MP4 if AVI suits me enough.
Do you seen me ever releasing a softsub ?
There is your answer.

Harukalover · 2006-10-22, 12:42

Quote: