PDA

View Full Version : x264 development


Pages : [1] 2 3 4 5 6 7 8

aketon
15th August 2004, 17:55
What is going on with x264? I haven't heard any news about it lately! Are we going to see any beta version with 2-pass code soon???

Tommy Carrot
15th August 2004, 18:52
Since Fenrir left the development, the project was moved to Videolan.org, and unfortunately very few has been changed since then. As far as i know there were bugfixes in the ME, and it got a basic cbr rate-control, but that's all.

BoNz1
15th August 2004, 20:59
Someone on the mailing list said that they were working on a 2pass rate control. I don't know when or if we will see it though. There was also a simple scene change detection which was also added.

bond
18th August 2004, 22:17
BoNz1, whos working on it?

virus
19th August 2004, 00:31
IIRC Nic, after providing a patch to add AVS input, talked about adding a 2-pass rate control a couple of months ago. Has this code never been completed/commited?

And why they don't simply borrow such code from XviD (including the keyframe insertion algorithm), given that both projects are GPL'ed?

Joe Fenton
19th August 2004, 22:16
That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.

aketon
19th August 2004, 22:39
Originally posted by Joe Fenton
That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.

But if you look carefully the wings of a Lear jet, you can have an idea about how to make wings for an F-15!!! Right? Especially the keyframe insertion algorithm from Xvid can be obtained in any codec, since the only thing it does is to show to the codec where to put a keyframe! It has nothing to do with the very internals of the codec! (at least, I believe so)!!!:D

Sorry for my bad english!!!

BYE!!!

virus
19th August 2004, 23:45
Originally posted by Joe Fenton
That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.
Basically, I agree with aketon on that. The keyframe insertion algorithm should be almost unrelated to the type of compression you're using. Maybe your statement holds better for the 2-pass RC, since H.264 allows more ways to compress MBs in a frame (and thus more ways to modify their size in the 2nd pass). But still XviD RC will be a very good starting point... you can tweak it for optimality later.
Even a sub-optimal algorithm is better than nothing ;)

snacky
1st September 2004, 22:17
x264 encoding is now supported in the latest CVS of mencoder. Build (and maybe install) the x264 library, and currently it'll require a patch posted here: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-September/028856.html

This patch will probably be included in CVS in a day or two.

Since the previous post to this thread, a lot has gone on in x264. It now supports ratecontrol and 2pass encoding. If you want to see something really impressive, try it on animation source material. You can get good-looking, non-blocky results with incredibly low bitrates.

bond
2nd September 2004, 17:55
cool stuff, may i ask who is currently working on x264? if more than one person, maybe it would be good to join forces and create one big project, which might become what xvid is now: the opensource codec, which kicks the commercial implementations asses :D

snacky
2nd September 2004, 20:35
Laurent Aimar (fenrir) is the most active committer, or perhaps even the only committer - I'm not completely sure.

My own impression is that x264 has attracted very few additional developers over its lifetime. This is unfortunate. I heard that last year, fenrir was talking about adding an h.264 encoder to ffmpeg. IMO this would have been the best possible outcome, because it would have helped attract a lot more attention from ffmpeg developers and perhaps mplayer developers. But obviously nothing ever came of this.

x264 is by far the most active and most useful open source encoder. Yet it is really not that active after all, and there are some important features that have yet to be implemented. There are only a handful of highly competent codec coders in the open source world, and it's a pity there aren't more of them interested in h.264.

BoNz1
3rd September 2004, 05:39
Originally posted by bond
cool stuff, may i ask who is currently working on x264? if more than one person, maybe it would be good to join forces and create one big project, which might become what xvid is now: the opensource codec, which kicks the commercial implementations asses :D

Currently, fenrir is the maintainer. But due to his employment at ateme he isn't actively working on his own code for x264. A guy by the name of Loren Merrit sent to the list the 2pass rate control and mru sent the 1 pass rate control. So there is some interest. The 2 pass rate control borrows a lot of code from ffmpeg.

Bogalvator
19th September 2004, 00:05
How can I build Mencoder with x264 encoding support?

./configure --with-x264libdir="c:/x264" --with-x264incdir="c:/x264"

is not working.

akupenguin
19th September 2004, 01:06
Originally posted by Bogalvator
How can I build Mencoder with x264 encoding support?
Try the more general --with-extra{inc,lib}dir instead of --with-x264{inc,lib}dir
Try not using Windows

snacky
19th September 2004, 08:59
"It's not working" is not usually a good way to get useful replies. What exactly isn't working, and why?

Latest CVS should do the sensible thing with --with-x264incdir, whereas a week or so ago it didn't actually use the include while compiling. But in general I agree with akupenguin's remark. ALL "--with-XXXXincdir" options misbehave in this way now, except for x264!

Also, in case anyone's curious, the main new feature in the next x264 revision will be subpel quality refinement options. This has a significant effect on bitrate (as well as speed!).

Bogalvator
19th September 2004, 12:08
Sorry, I should have been more exact. I was using the MPlayer CVS snapshot for 18/9/04, and while configuring it just said "Checking for x264 ... no", so that's what I meant.

I tried with "--with-extra***" as well but no joy. I shall see if I have any success with Linux.

Thanks for your help.

KpeX
19th September 2004, 16:56
@Bogalvator

Under linux, I simply compiled x264, then copied x264.h to /usr/local/include, and libx264.a to /usr/local/lib, and mplayer detected the library without any additional configuration arguments. Perhaps this will work under cygwin by copying these files to the appropriate directories.

snacky
19th September 2004, 20:25
I should also add that mencoder is ONLY keeping compatibility with current revisions of x264, without even an attempt to keep backwards compatibility. This is because, IMO, it'd be a waste of time to keep backwards compatibility with an encoder that's not mature and hasn't even had an official "release" version. At the time of my writing, that means you must have revision 46 or mplayer simply won't compile (assuming you're using CVS mplayer). When the next x264 revision comes out, CVS mencoder will be synched to it, instead.

easyfab
20th September 2004, 16:57
Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?

Jerry_Sm@rt
3rd October 2004, 13:17
Originally posted by easyfab
Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?
Where can I get x264 vfw version (based on core 8)?
I've been searching for some time,only get a 2004.05.19 build (core 7)

BoNz1
3rd October 2004, 19:44
Originally posted by easyfab
Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?

I think someone needs to update the vfw to support it. There is a build here though http://dc0der.is-a-geek.org/ but not with the 2-pass. But it is latest svn.

virus
5th October 2004, 12:18
Ok, I finally managed to test 2-pass RC on a single clip using ffdshow-20041003 (see the instructions in the ffdshow thread about using 2-pass in x264).

I run a first pass at QP:16 (output bitrate was over 3000 kbit/s) and asked for 1600 kbit/s in the 2nd pass (that should be ~65% of XviD 1st pass size).

I ended up with 1594 kbit/s, which is good since the clip was only 40 seconds... but there are still very bad blocking artifacts which look quite like Soulhounter's encodings with Ateme's codec early betas (remember the Shuttle sequence?).
Maybe the cause is the same (too much aggressive MB skipping)? I can post screenshots if needed, but the problem should be pretty obvious, it happened on a lot of frames.

Due to the artifacts the PSNR measurements were, of course, very, very bad.

:(

Tommy Carrot
5th October 2004, 12:50
You mean these white blocks (http://www.fw.hu/carrotland/whiteblocks.avi)? I gotta agree, it's pretty bad, but it's not a new bug, it occured in some older ffdshow builds too. Unfortunately it makes the x264 encoder completely useless.

snacky
5th October 2004, 13:03
Those blocks might have something to do with the insanely low quants you're using. Do you realize the quants are looping from 27 all the way down to zero, and then to 27 again?

It's obviously still a bug and it'd be nice to see it fixed, but in practice, quants less than 4 are pretty useless afaik.

snacky
5th October 2004, 13:15
I wasn't clear. The video you linked to has frames with quant 0. This is a legal quant in h.264, but surely you didn't intend for it to happen.

virus
5th October 2004, 13:18
Originally posted by Tommy Carrot
You mean these white blocks (http://www.fw.hu/carrotland/whiteblocks.avi)?
Similar... they're not always exactly so big and perfectly square... maybe it's because of the variable MB size. Or maybe a different bug. They happened often on water, too. Anyway you're right: with such frequent and bad artifacts x264 is basically unusable right now :(

EDIT: the buggy blocks in Tommy's video have a QP:27, according to ffdshow. What 0 are you talking about?

Tommy Carrot
5th October 2004, 13:24
Originally posted by snacky
I wasn't clear. The video you linked to has frames with quant 0. This is a legal quant in h.264, but surely you didn't intend for it to happen.
Your're right, but it has no connection with the problem, because "bad blocks" have quant 27, just like the rest of the frames. The low quantizers are in the upper left corner of the image, this is probably another bug. :D

netchris
5th October 2004, 13:28
I believe its the same bug, the artifacts are square because the inloop
option was disabled. Am I correct Tommy Carrot?

Also the two pass method is problematic as sometimes when I start the second pass I get an error. I dont know what could be the fault of this
maybe the first pass stats file written isnt always written correctly.

snacky
5th October 2004, 13:31
The frame level quants look like this:

frame=01 qp=26
frame=02 qp=25
frame=03 qp=24
[...]
frame=24 qp=03
frame=25 qp=02
frame=26 qp=01
frame=27 qp=0
frame=28 qp=27
frame=29 qp=26

Maybe this has nothing to do with the white blocks, but surely you wouldn't want those kinds of quants. On second look I guess the thing I'm pointing out is a bug in ffdshow's 2-pass.

Tommy Carrot
5th October 2004, 13:35
Originally posted by netchris
i believe its the same bug, the artifacts are square because the inloop
option was disabled. Am I correct Tommy Carrot?
The problem is still there (http://www.fw.hu/carrotland/whiteblocks_looped.avi) even with enabled inloop-filter. I guess the corrupted blocks are so different from the neightbours that the filter cannot correct them.

virus
5th October 2004, 13:39
I had the in-loop filter on, yes.

About the quantizers that start high and scale down to zero, frame after frame: I saw this happening during the second pass (made at "constant bitrate" ;)) but only in the ffdshow statistics graph.
There's no such behaviour in the actual encoded file. I-frames are encoded at QP:15-17 and P-frames range from QP:19 to 24 IIRC. Everything seems quite fine with the 2-pass RC. Maybe ffdshow can't display the right quantizer values due to the different way x264 works in 2-pass mode, compared to the other codecs supported.

netchris
5th October 2004, 13:39
quote
"the problem is still there even with enabled inloop-filter. I guess the corrupted blocks are so different from the neightbours that the filter cannot correct them."


I didnt say that the problem is caused by the lack of the inloop filter, just that the blocks are "perfectly square" because there was no inloop.

virus
5th October 2004, 14:13
Here are my screenshots:

Frame 1: look below and on the right of the text (but there are even more artifacts around...):
x264 (2 pass) (http://img2.exs.cx/img2/2572/x264-blocks.png)
source (http://img2.exs.cx/img2/8002/x264-source.png)

Frame 2: well, here it's so clear... looks like Tommy's clip
x264 (2 pass) (http://img2.exs.cx/img2/17/x264-blocks-2.png)
source (http://img2.exs.cx/img2/8383/x264-source-2.png)

netchris
5th October 2004, 14:26
Ok its the same bug I'm talking about.
In the subpel refinement option choose : "halfpel only" and these blocks are gone. It is a problem that appears when any other of the subpel options is chosen.

virus
5th October 2004, 16:23
Originally posted by netchris
In the subpel refinement option choose : "halfpel only" and these blocks are gone.
Confirmed. The blocks are gone and the quality was massively increased. Here are the results of my comparison against XviD. To be fair I tested XviD with both HPel and QPel, and guess what happened? HPel gives better results... :rolleyes:

Test setup:

clip: 506x304 @ 25 fps, DVD source, Lanczos resize, XviD 1st pass size: 2394 kbit/s

output bitrate: 1600 kbit/s

XviD 1.0.2: MPEG matrix, AQ, B-VOPs 2/1.50/1.00, no GMC, no Turbo, MSP 6, VHQ 4, Chroma ME, Trellis, 2nd pass overflow 10/10/7

x264/ffdshow-20041003: CABAC, in-loop filter, max ref. frames 3, subpel: HPel only, all analyzer flags on, 1st pass @ fixed QP:16

decoding: XviD -> deblocking only; x264 -> no postprocessing

PSNR results:

x264
min: 36.10 dB
avg: 42.79 dB
max: 51.12 dB

XviD (QPel)
min: 36.78 dB
avg: 42.91 dB
max: 49.46 dB

XviD (HPel)
min: 36.86 dB
avg: 43.03 dB
max: 49.31 dB

netchris
5th October 2004, 17:00
Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
My problem now is that when I start the second pass i get this error in
vdub :
"cannot start video compression, an unknown error occurred (may be corrupt data). (error code -100)"

Edit : I used a higher quantizer for the first pass (20) and the second pass is done ok. When I used a quantizer as low as 10 I got the error.

virus
5th October 2004, 17:20
Originally posted by netchris
Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
Already tested... I was faster this time :)

Disabling the in-loop filter makes the PSNR fall down (-0.29 dB). Instead, keeping it on but reducing the max ref. frames to 1 brings a 0.03 dB reduction in PSNR.
This is a high motion sequence so I doubt multiple reference frames can be really useful... still, according to some results I had with a very old version of x264 (at constant quantizer) on this clip, I expected a somewhat higher improvement using 3 ref. frames.

Ah, I've encoded several times but VDub never gave me any error, so I've got no clue on what's happening on your machine, sorry :confused:

akupenguin
5th October 2004, 17:43
Originally posted by virus
Confirmed. The blocks are gone and the quality was massively increased. Here are the results of my comparison against XviD. To be fair I tested XviD with both HPel and QPel, and guess what happened? HPel gives better results...
The difference is that in MPEG-4 ASP you can actually save 2 bits per motion vector by not storing qpel precision. In H.264, you can't disable qpel. x264's subq=halfpel option doesn't search with qpel precision, but it doesn't save anything other than time. If qpel doesn't increase the quality, it's just plain a bug.

Originally posted by netchris
Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
No, the strength of the inloop filter already depends on the quantizer used. Disabling it should never help, though you might want to decrease the deblock{alpha|beta} parameters for a slightly sharper but slightly blockier image.

virus
5th October 2004, 17:49
Originally posted by akupenguin
you might want to decrease the deblock{alpha|beta} parameters for a slightly sharper but slightly blockier image.
ffdshow doesn't offer this option in the GUI right now. But I'm glad to see that the in-loop filter has already been made adaptive. At what QP do you switch it off?

Also, what do you think about the "subpel refinement > 0" bugs? Who is to blame? Compiler optimizations? ffdshow? x264? :confused:

KpeX
5th October 2004, 18:05
Originally posted by virus
Also, what do you think about the "subpel refinement > 0" bugs? Who is to blame? Compiler optimizations? ffdshow? x264? :confused: I've been using subq=5 pretty consistently with mencoder without problems, so there's a pretty good chance it's a ffdshow / vfw problem.

netchris
5th October 2004, 18:20
There must be something wrong with the compiler, since my built doesn't have these problems.
I would like to hear too what akupenguin's thinks about it.
Subq=5 does indeed offer better quality when working correctly. To my eyes the edges are more well defined (and the color gradients are better?)
Virus : since I started using quant 20 the problem with the second pass is gone. Lucky me :cool:

bond
5th October 2004, 19:43
is there some "reference" x264 encoding tool (commandline or so) which the x264 devs work on, for being able to differentiate between real x264 bugs and bugs introduced by "x264 wrappers", like ffdshow?

easyfab
5th October 2004, 20:41
in the lastest svn sources you have a vfw directory and i think you can built a vfw codec to play with

ivan_alias
5th October 2004, 21:37
Does anyone know of a vfw build available ?

akupenguin
6th October 2004, 06:12
Originally posted by bond
is there some "reference" x264 encoding tool (commandline or so) which the x264 devs work on?
There is a vfw frontend in the x264 subversion repository. However, it hasn't been updated since june and I have no idea if the author is still around. Enough has changed since then that it probably won't even compile as is.

There is also a simple commandline encoder program in svn, which could be considered the reference frontend. It is up to date, but still may contain unnoticed bugs, because (I think) no one uses it for real encodes.

And then there's mencoder, which I base all comparisons on.

akupenguin
6th October 2004, 06:34
Originally posted by virus
I'm glad to see that the in-loop filter has already been made adaptive. At what QP do you switch it off?
By default, it's completely off at QP<=15. (And of course it ramps up smoothly, so there's almost no filtering at QP=16, all the way up to something close to a plain blur at QP=51.)
The deblocking strength options control a QP offset. So a block/frame with QP=25 and deblock{alpha,beta}=-5, gets processed with the filter strengths from QP=20.
("alpha" affects how much change the filter is allowed to cause to any one pixel, "beta" affects the detail threshold. The unimaginative names are copied straight from the H.264 spec.)

bond
6th October 2004, 20:29
Originally posted by akupenguin
There is also a simple commandline encoder program in svn, which could be considered the reference frontend. It is up to date, but still may contain unnoticed bugs, because (I think) no one uses it for real encodes.

And then there's mencoder, which I base all comparisons on.can anyone make a compile of this than plz? :)

or would you say that we should use mencoder for testing x264 itself?

Bogalvator
6th October 2004, 23:10
Making the little command line is pretty easy if you have MinGW, MSYS & binutils installed.

Run MSYS, then type

cd c:/x264/build/cygwin #or wherever you unzipped the directory

then type

make

and it should build x264.exe for you.

It only takes raw YUV files I think (though I briefly tested a HuffYUV file renamed *.yuv and it seemed to work).

akupenguin
7th October 2004, 03:35
Originally posted by Bogalvator
It only takes raw YUV files I think (though I briefly tested a HuffYUV file renamed *.yuv and it seemed to work).
Did you look at the output? It takes raw YUV. As in no headers or anything (hence why you have to specify resolution on the commandline). So there's absolutely no way for it to tell whether the input file is actually a YUV video. (Like most unix programs, it ignores the file extestion.) Anything you give it is a valid input, but it will look like random static if it's not in the right format.

And that is the main reason I recommend mencoder instead.

celtic_druid
7th October 2004, 05:08
@bond, I put up a build almost a month ago (2004.09.16). Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.

bond
7th October 2004, 19:45
cool stuff! thanks a lot :)

virus
9th October 2004, 14:57
So, after almost sinking into several assorted troubles, I've finally completed the PSNR test I started a while ago (look at the corresponding post on page 2 for further details about settings, source, bitrate, ...). I've added some x264 results as well as VP6.2 (sharpness 7, Best quality, "Best PSNR" postprocessing = deblocking only).

VP6.2: 43.76 dB
x264 (more iterations): 43.39 dB
x264 (Qpel on all): 43.35 dB
XviD (HPel): 43.03 dB
XviD (QPel): 42.91 dB
x264 (Hpel): 42.79 dB

finally we can see x264 among the masters :)

netchris
9th October 2004, 15:36
Well done virus!

finally we can see x264 among the masters

if you think how immature x264 is and still can achieve such results :D

I am curious if we will see an even higher psnr if you decrease the deblock beta to something like -5 or -4.
The image will be sharper (and vp6 has very high sharpness with the chosen options).

Manao
9th October 2004, 20:34
Default deblocking settings were computed to give the best psnr, so I doubt playing with these settings will increase psnr.XviD (HPel): 43.03 dB
XviD (QPel): 42.91 dBI'm curious, what was the clip you used ?

akupenguin
9th October 2004, 21:31
I don't know what he used, but I've seen XviD's qpel give up to 0.5 dB worse than hpel, on anime.

And yes, deblock vars = 0 is the optimal setting for PSNR. (maybe +/- 1 for some sources, but you're not going to gain much.) The options are just in case you prefer sharpness or smoothness over mathematical accuracy. (I personally think 0 looks best, too.)

virus
9th October 2004, 21:37
Originally posted by Manao
I'm curious, what was the clip you used ?
It's Ghost Ship DVD (PAL), chapter 3, 1000 frames.
Reasonably clean source. This is a very high motion clip featuring small, detailed sea waves, large near-uniform areas (sky+clouds), a wide range of difficult edges, some closeups on faces, a few underwater detailed frames and even some hardcoded text - all in 40 seconds. My reference clip for high-motion DVD content. The caps on page 2 of this thread can give you an idea.

As for the results with QPel/HPel, I don't know. Maybe with long MVs you have a better chance to have hpel vectors do the job well, without that extra 2 bits/MB. Instead, if you have a low-motion clip with many "static" MBs they may need some small MV like (0.25, 0.25) due to slight camera movements, and thus you may end up with more MBs (on average) which "need" QPel and overall, you can compensate better the MV overhead. But this is really just speculation... I failed to come up with a better explanation :)

IIRC gruel once said that re-encoding MPEG-2 material - which uses HPel only - can reduce QPel effeciency due to the way MPEG-2 handles subpel interpolation. So maybe on DVDs you simply have a better chance to find a clip where HPel works better than QPel.

akupenguin
10th October 2004, 01:25
Originally posted by virus
IIRC gruel once said that re-encoding MPEG-2 material - which uses HPel only - can reduce QPel effeciency due to the way MPEG-2 handles subpel interpolation. So maybe on DVDs you simply have a better chance to find a clip where HPel works better than QPel.
That too. When re-encoding from a lossy format, you gain PSNR (though not necessarily visual quality) by using a format/setting that reproduces the same artifacts as in the original. One such artifact is quantization of motion vectors.
This effect can be reduced by pp/crop/scale/denoising the video (which you should do anyway, unless you really need to know how well the codecs can accurately reproduce noise).

pogo stick
10th October 2004, 23:56
It's so good to see that x264 is growing up!
I tried it in ffdshow and it looks nice. :)
Akupenguin, what do you think about interlaced encoding support?
Can we expect it any time soon? Or this feature have low development priority?
Originally posted by celtic_druid
Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.
Should this build work for P4 under WinXP?
I am getting this error when I use '-ovc x264':

http://pogo-stick.nm.ru/menc.jpg

And other errors when I use another codecs.
It's the first time I am trying mencoder, so I may miss something important about it.
What can be wrong?

IgorC
11th October 2004, 02:09
where can i get this codec?

Sirber
11th October 2004, 02:11
It's part of FFDShow (VFW) and mplayer (win32/linux).

celtic_druid
11th October 2004, 02:31
Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though.

akupenguin
11th October 2004, 02:37
Originally posted by pogo stick
Akupenguin, what do you think about interlaced encoding support?
Can we expect it any time soon? Or this feature have low development priority?
Interlacing is ugly. And unlike B-frames, it's not just the implementation that's ugly, but also the results. So, no, I refuse to have anything to do with interlaced video.
If you have telecined content, ivtc it. If you have an interlaced capture device, set it to progressive. If you're capturing interlaced TV or the like, accept the fact that it's half the resolution it purports to be, and the best you can do is interpolate the missing pixels (a.k.a. deinterlace).

Sirber
11th October 2004, 02:51
Originally posted by celtic_druid
Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though. AMD:
3DNOW!, 3DNOW!+

P4:
SSE2, SSE3

If the builds has been harcoded optimized with those feature, it might crash :)

pogo stick
11th October 2004, 14:22
Originally posted by celtic_druid
Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though.
I see now. I am clueless about these things. Can you, please, compile it for P4, if that wouldn't be too bothering?
Or is there a place where I can look for P4 builds with x264 enabled?
Originally posted by akupenguin
Interlacing is ugly. And unlike B-frames, it's not just the implementation that's ugly, but also the results. So, no, I refuse to have anything to do with interlaced video.
But why it's ugly?
mpeg2 people don't deinterlace usually.
And interlaced XviD video look good with bob post-deinterlacing.
Is it much different in H.264?


off topic: Sirber, what happened to your avatar? It was much nicer before.

Sirber
11th October 2004, 14:30
Originally posted by pogo stick
off topic: Sirber, what happened to your avatar? It was much nicer before. Someone told me it was looking childish and desperate :eek:

virus
11th October 2004, 23:09
@akupenguin

I've tried compiling x264 myself using MinGW and had a little problem. I used Makefile.cygwin but it lacks a file in the SRCS definition. You need to add encoder/eval.c to the file list. Here's the patch if you want to commit it (hope I didn't mess with svn diff, I'm pretty n00b with this stuff :D):

Index: Makefile.cygwin
===================================================================
--- Makefile.cygwin (revision 51)
+++ Makefile.cygwin (working copy)
@@ -9,7 +9,7 @@
core/common.c core/mdate.c core/csp.c \
encoder/analyse.c encoder/me.c encoder/ratecontrol.c \
encoder/set.c encoder/macroblock.c encoder/cabac.c encoder/cavlc.c \
- encoder/encoder.c \
+ encoder/encoder.c encoder/eval.c \
core/i386/mc-c.c core/i386/dct-c.c core/i386/predict.c \
x264.c

mmmh... the tabs have been converted... better if you rerun manually on your sources ;)

Bogalvator
12th October 2004, 00:09
I used the makefile in the build/cygwin directory and it worked fine - is there any difference in the outputs?

virus
12th October 2004, 00:19
Ok, I managed to compile the broken VfW interface (with only a few changes to the code).

It's outdated (only 1-pass @ fixed quantizer), and I get a crash after a few seconds of encoding with VDub on my machine. Anyway I've uploaded here (link now removed) the zip with the .dll and the .inf file. To install it, unzip to a temporary directory, right click on the .inf file and choose "Install". Then, you should see x264 in the VDub's codec list. Please test it and see if it crashes and with what options enabled.

I hope to hack it to get it up-to-date and hopefully not crashing, though I'll probably need some help for that.


EDIT: found the problem. I'll have an update (not crashing) soon.

EDIT 2: you can d/l the new file now. Sorry, I didn't realized that SSE2 and MMXEXT were enabled by default. They have been turned off. Right now I cannot decode the clips, though.

EDIT 3: mmmhh, the default FOURCC ("x264") won't work. You need to change it to "H264" and ffdshow will decode just fine. Anyway... my P4 shouldn't have crashed with MMXEXT & SSE2 enabled, no? I believe P4s have MMXEXT, or no?

(promised, I won't edit this post anymore :D)

netchris
12th October 2004, 02:16
Many thanks virus!
Its nice to have an alternative (even if it is the same codec exactly :D )
to ffdshows implementation .
Unfortunately the quantizer scale is different in ffdshow compared to x264 vfw.

akupenguin
12th October 2004, 02:27
Originally posted by netchris
Unfortunately the quantizer scale is different in ffdshow compared to x264 vfw. Yup. ffdshow had MPEG-style quantizers hardcoded in too many places, so they just rescaled H.264 quant to 1..31 rather than changing the limits. Which is confusing, because H.264 quants are on a logarithmic scale, so rescaling still doesn't make them equivalent to MPEG quants.

RadicalEd
12th October 2004, 02:50
Can anyone confirm that the VC6 project files are b0rked or do I just suck at compiling?

P0l1m0rph1c
12th October 2004, 03:13
They are b0rked.

BoNz1
12th October 2004, 04:54
BTW was the port of the gcc inline assembler to a nasm file completed?

pogo stick
12th October 2004, 06:05
I was looking at mplayer's manual and there is bframes option:
bframes=<0-16> number of consecutive B-Frames between I- and P-Frames (default: 0)
I wonder, why it is not in ffdshow?

Originally posted by Sirber
Someone told me it was looking childish and desperate :eek:
No, it's not. It's kinda cheerful. But that b/w thing with little moustache was definitely desperate.
Now I will be able to recognize you even if I will loss my reading ability. :)

akupenguin
12th October 2004, 06:45
Originally posted by pogo stick
I was looking at mplayer's manual and there is bframes option. I wonder, why it is not in ffdshow?
Because our implementation of B-frames is incomplete enough that they don't yet improve compression efficiency.

virus
12th October 2004, 10:27
I checked a bit better the sources. Well, the VfW frontend is very similar to the XviD one so yes, I think I can do that. (I mean, reworking it completely to support all the new stuff)

@akupenguin: maybe one of you guys is already working on that? If not, maybe I should ask on x264-devel if they need a mantainer for the VfW code?

akupenguin
12th October 2004, 17:39
There is officially a maintainer for the VfW code, but I haven't heard from him in months. I'm sure you'd be welcome if you want to take over that role.

bond
12th October 2004, 20:11
i couldnt look at the latest vfw version, but plz make as much configuration options as possible available in it, so people can enjoy testing it out and finding good options :)

virus
12th October 2004, 23:06
thanks for your support :)

Today I toyed a bit with my resource editor trying to invent a design, or at least something similar :D
Here's a very rough and incomplete draft. No code has been written, this is just my opening bid on the issue. I tried to keep the most important stuff in the first page, and hide the less n00b-friendly whistles behind the "Advanced" button.

Main page:

http://img14.exs.cx/img14/513/x264-gui-1-main.png

The (now) empty Encoding type list will contain stuff like "Single pass - constant bitrate" or "Twopass - 1st pass" and the Quantizer and Bitrate fields will be enabled/disabled accordingly. The Configure button should open a little window for extra configurations, like entering the statsfile name and something similar. Since sliders are bad, buggy and often useless, I'll probably remove the one for max ref. frames, too. The tiny little arrows are much better ;)

As for the Advanced dialog, here's what I came up with:

http://img14.exs.cx/img14/268/x264-gui-1-adv1.png

http://img14.exs.cx/img14/1000/x264-gui-1-adv2.png

http://img64.exs.cx/img64/8935/x264-gui-1-adv3.png

Again: the now empty dropdown lists will be filled in dinamically. Obviously the Tab names are still temporary... though I have no idea what name they should have :)


So, feedback? There was a lot of discussion time ago about reworking the XviD GUI so I hope someone can give useful suggestions... also, did I miss some important options? Did I add useless stuff? Please let me know!

virus

snacky
12th October 2004, 23:36
I have some suggestions about interface.

I would try to separate ratecontrol- and quantization parameter-related options into a tab or tabs separate from all the other options. You'd be surprised how many users do not understand which options do what... Anyway, this means a tab with options to limit quantizers, enable 2pass, adjust qblur, etc.

Another tab should focus on options that let you trade off encoding time for higher quality. These are subpel refinement, number of reference frames, CABAC (which should be on by default), and maybe the option as to whether or not to enable the deblocking filter (it should also be on by default). Arguably, deblocking parameter adjustment should probably also be in this tab.

Finally, another tab or section should include frame type decision related parameters. This includes the keyframe interval, frequency of IDR frames, scenecut detection parameter, bframes. I would probably also put the I/P and P/B ratio options in this location, but perhaps it also makes sense to put them in the ratecontrol/quantization tab.

I suggest giving the first tab I described a title that indicates it's all ratecontrol stuff, and the second tab I described should clearly indicate that most or all of its options are quality-vs-speed tradeoffs. That way, users have a better idea of what things they should be trying.

I have a hard time imagining how you can sanely divide up very many options based on how advanced they are, but maybe there turns out to be some benefit to deemphasizing certain options that are unlikely to be changed. For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are. You can also specify your own ratecontrol equation but people almost never use this. MPlayer's man page has, for several months running now, omitted to even mention that this option exists for x264, and so far nobody has even asked about it :) It also seems pretty darn unlikely that users will want to turn off CABAC or the deblocking filter. The other stuff is arguable maybe, but I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.

snacky
12th October 2004, 23:46
Also, I'm having a hard time thinking of how there can be a legitimate reason for the user to use anything but H264 for the fourcc.

RadicalEd
12th October 2004, 23:55
Originally posted by snacky
Also, I'm having a hard time thinking of how there can be a legitimate reason for the user to use anything but H264 for the fourcc.

Perhaps because the official fourcc is "AVC1" :O

Tommy Carrot
12th October 2004, 23:58
Originally posted by snacky
It also seems pretty darn unlikely that users will want to turn off CABAC or the deblocking filter.
I definitely would. :D Disabled deblocking filter often gives better results at higher bitrates.
The other stuff is arguable maybe, but I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.
The analysis flags are supposed to be a tradeoff between speed and quality. Although there is no big speed penalty when all is enabled, i'm not sure if this is the right behaviour, this can be a bug imo.

Personally, i think the less tabs the better, so i agree with snacky's approach: one tab for the rate control and the frame-type decisions, and the other for the speed/quality related options.

snacky
13th October 2004, 00:01
Sorry for triple posting, but this is kind of a separate topic: reasonable defaults.

I often use mencoder as a frontend to x264. It's my opinion that its defaults are now almost entirely reasonable. Check here (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c?rev=1.7&content-type=text/x-cvsweb-markup) to find them. Even if you don't replicate them exactly, IMO they're a good starting point.

snacky
13th October 2004, 00:06
Originally posted by RadicalEd
Perhaps because the official fourcc is "AVC1" :O
Hmm, I didn't know that.

virus
13th October 2004, 00:24
Originally posted by snacky
Anyway, this means a tab with options to limit quantizers, enable 2pass, adjust qblur, etc.
I can understand the rest, but maybe 2pass is a bit out of place here?

Another tab should focus on options that let you trade off encoding time for higher quality. These are subpel refinement, number of reference frames, CABAC (which should be on by default), and maybe the option as to whether or not to enable the deblocking filter (it should also be on by default). Arguably, deblocking parameter adjustment should probably also be in this tab.
Here we basically agree. This is the main page (designed to be the only one that a n00b should ever open to do a decent encode ;)) except for the subpel refinement, where I think 4 can be a good enough default value. You lose a lot quality if you go towards 0, so maybe there won't be need to add it to the Main tab imho.

I also thought about adding the deblock params in the main page, but they seem to me a bit too much "technical" for the Main tab. Remember, we are targetting Win32 here, and the average user is not so expert as the average Linux user ;)

For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are.
Yeah, I don't even know if I'm going to add them... mostly because I have no idea how they work :D

I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.
I didn't know that. But IIRC Ateme's H.264 codec doesn't even implement the equivalent of PSUB8x8 because it's too slow and gives just a little improvement, so I even thought about disabling this flag by default... but maybe x264 uses fast heuristics for that?

BTW between "H264" and "AVC1" 4CCs our dear x264 chose... "X264" (and it cannot decode it yet!). Think all 3 should be added, with maybe AVC1 as default...

snacky
13th October 2004, 00:50
For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are.
Yeah, I don't even know if I'm going to add them... mostly because I have no idea how they work

Stolen from the mplayer manpage:

qblur=<0-99>
Temporal blur of the quantization parameter (default: 0.5).
Lower values allow the quantizer value to jump around more,
higher values force it to vary more smoothly.
qcomp affects a parameter of the (default) ratecontrol equation. Low values make the bitrate more constant; high values make the quantization parameter chosen more constant.

As for scenecut threshold: the encoder first tries to encode a frame as inter, but if a large number of I-blocks show up, it will just encode the frame as an I-frame. The scenecut threshold affects the percentage of I-blocks that will cause the encoder to make the frame an I-frame.

BTW between "H264" and "AVC1" 4CCs our dear x264 chose... "X264" (and it cannot decode it yet!).
No idea what you mean by this. The muxer is the app that places the fourcc in the header, not x264. Also x264 is not being used for decoding. If you're using ffdshow, it uses ffmpeg's h.264 decoder.

bond
13th October 2004, 01:04
small letter "avc1" is indeed the four letter name given to h.264 (or mpeg-4 avc) when stored in .mp4, as "mp4v" is used for mpeg-4 part2 streams
so i indeed think that "avc1" can be seen as the official fourcc given to h.264 in the mpeg-4 standard

anyways the mess is already here: dicas uses DAVC as fourcc, and vanguard uses VSSH, so these might also be offered in the dropdown list
still i think that avc1 indeed should be default in x264

[apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw:
why not add the possibility to output smooth .mp4 files to the commandline encoder (a lib able to do that is available at mpeg4ip);
why not enjoy interoperability with neros, sorensons and envivios implementations (and virtually any h.264 implementation fully based on mpeg-4);
why not being able to port it to other platforms, like linux, by not using windows centric vfw stuff;
why not avoid upcoming hassles with storing b-frames, aso aso...?]

virus
13th October 2004, 01:18
Originally posted by snacky
No idea what you mean by this. The muxer is the app that places the fourcc in the header, not x264. Also x264 is not being used for decoding. If you're using ffdshow, it uses ffmpeg's h.264 decoder.
The current x264 GUI allows to enter the 4CC directly. XviD does the same... and if you change from X264 (the default) to H264 something changes (try decoding with ffdshow ;)) so I guess this param is still useful... :)

@bond:
I think ffdshow recognizes AVC1 (haven't tested it, just H264) with capital letters, but does it recognize avc1 lowercase?


also, further explanation about the GUI tabs. My idea was:

hopeless n00b -> use only the main tab
advanced user -> use the main tab and often just the 1st advanced tab, which includes the speed/quality options not contained in the main tab.

following this idea, I'm thinking about moving the deblock params to the 1st tab and move the GOV ones to the 2nd, since you'll probably want to tune the deblocking more often than changing the max keyframe distance... you see, in most cases you'll only work with 2 tabs that way. Remember that XviD uses 1 Main tab + 3 Prof@Lev tabs + 3 Advanced Tabs + 1 RC Tab for 2nd pass... it's not so easy to fit every useful option in a little space ;)

bond
13th October 2004, 01:24
Originally posted by virus
I think ffdshow recognizes AVC1 (haven't tested it, just H264) with capital letters, but does it recognize avc1 lowercase?i told milan to support small letter "avc1" and i think it does support it as small letter as ffdshow can connect to the 3ivx splitter which outputs small letter avc1

virus
13th October 2004, 01:39
Originally posted by bond
apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw
it works, why not?

why not enjoy interoperability with neros, sorensons and envivios implementations (and virtually any h.264 implementation fully based on mpeg-4)
why not do as I always do with my XviD DVD rips: using AVI as a transitional container for video only, and then remuxing to MP4? We have VDub(Mod), no-one will ever add MP4 support to it so why not AVI (or maybe MKV)? You should push for an MP4 muxer that accepts H.264 streams instead... you'll get better chances to have it done ;)

why not being able to port it to other platforms, like linux, by not using windows centric vfw stuff
bond, it's the other way around ;)
right now x264 is "Unix-centric"... we need to port it to Windows using the most widely supported encoding interface under Win32, aka VfW :D

Sirber
13th October 2004, 02:02
Better use VFW than crappy cmdline app... (I'm not talking about producer :angry: )

akupenguin
13th October 2004, 05:15
Originally posted by Tommy Carrot
Disabled deblocking filter often gives better results at higher bitrates. At higher bitrates, deblocking is disabled anyway, just due to the QP adaptive strength. You might want to adjust the strength parameters, but I would never completely disable deblocking, other than when it disables itself.

The analysis flags are supposed to be a tradeoff between speed and quality. Although there is no big speed penalty when all is enabled, i'm not sure if this is the right behaviour, this can be a bug imo. psub16x16 and i4x4 should come at a significant speed/quality tradeoff. psub8x8 is only tried if 8x8 is the best psub16x16 mode, which is only around 5-10% of the blocks in my tests, so it doesn't cost much speed. (I guess this counts as a "fast heuristic")

And I like my mencoder, so I won't let my opinions get in the way of you all designing a gooey interface.

yaz
13th October 2004, 09:03
Originally posted by Sirber
Better use VFW than crappy cmdline app... khmm ... mencoder works pretty fine producing the best output as regards the h264 implementations i've been able to test ... if u meant that :-)

ffdshow accepts avc1, vssh, davc and h264 as 4cc and associate them with h264 content. there are some further 4cc signed as other mpeg4 (e.g. 3ivx) the 4cc mp4v is also there but it's associated with divx4(???)
however, this all is just playing with 'letters' as the decoder only selectable is libav whatever 4cc is considered. pls, note, all this 4cc business come into sight if u wrap your video into avi (as made by mencoder or vfw) and not into mpg or mp4.

the bests
y

ps. can anyone tell me what 4cc is accepted by the 'sigma' decoder (found and pointed by bond sw in this thread) ? i'd like to test that too. thx!

ivan_alias
13th October 2004, 13:01
mencoder works pretty fine producing the best output as regards the h264 implementations

Where can I get a build of mencoder with x264 support? Has anyone put a build up anywhere?

ta'

netchris
13th October 2004, 14:33
yaz wrote :
mencoder works pretty fine producing the best output as regards the h264 implementations i've been able to test ... if u meant that :-)

What do you meen? Best output picture-wise? All the x264 implementations should have the same quallity since ffdshow and mencoder are just shells for the x264 codec (and they are both updated with the latest code).
Not to mention the x264 native vfw version itself (that is applied to the primary codec without any changes).

pogo stick
13th October 2004, 14:38
Originally posted by bond
apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw: why not add the possibility to output smooth .mp4 files to the commandline encoder (a lib able to do that is available at mpeg4ip)...
Maybe it will be a good idea to make mencoder output mp4 files using mpeg4ip or GPAC stuff. I wonder, is it very hard to do? Or mencoder developers just don't care about mp4? And it seems like there are no tools yet that can work (in any way) with H.264 in mp4. Am I right? I heard that Ateme's muxer can mux H.264.mp4 and aac.mp4, but it's not available for everyone.
Originally posted by Sirber
Better use VFW than crappy cmdline app...
But I'm sure you know what is the good side of command line programs. Someone can write nice GUI for it. Like there are many for producer.

yaz
13th October 2004, 15:07
@ivan_alias
mencoder : i tried celtic's build. it's available on his site (as noted sw above)

@netchris
All the x264 implementations should have the same quallity just as u wrote; should be. but they are not. just have a look into the ffdshow development thread. ffvfw produces artifacts not seen with mencoder. ok, it's a problem of the implementation but that's what a user see (mencoder is ok, ffdshow produces crap) and nobody bothers about that the core is the same.
so, speaking as correct as i can, i've been able to produce the best-looking output with mencoder ... so far.

btw, what decoder do u use ? i'm with vss now (that was suggested for x264 time ago) but i'm ready to change if anyone suggests sg better.

the bests
y

Tommy Carrot
13th October 2004, 15:21
Originally posted by yaz
just have a look into the ffdshow development thread. ffvfw produces artifacts not seen with mencoder.
In my knowledge this has been solved, the problem was not with the implementation, but with the compiler settings (and probably with the inaccuracy of the intel compiler).
btw, what decoder do u use ? i'm with vss now (that was suggested for x264 time ago) but i'm ready to change if anyone suggests sg better.

I use ffdshow. It offers much more features, especially the OSD and the visualizations functions can be useful, and the playback requirement is quite low too.

KpeX
13th October 2004, 16:25
AFAIK there is h.264 > mp4 muxing being worked on in both mpeg4ip and gpac. I doubt MP4 support would be added to mencoder. As long as the output is playable in mplayer I don't think the devs are interested in other containers.

Although vfw is outdated a good vfw interface will be useful to x264 development. Where would xvid be without the thousands of vfw users that tested it along the way? x264 in mencoder is great, but the exposure and testing will increase exponentially with an up to date, easy to use vfw interface.

bond
13th October 2004, 18:56
i would prefer a commandline tool with nice gui, but well i am no dev.
still the most important thing is that x264 gets further developed, no matter what interface/tool is used :)

yaz
14th October 2004, 08:16
Originally posted by Tommy Carrot
...ffdshow ...In my knowledge this has been solved, the problem was not with the implementation, but with the compiler settings (and probably with the inaccuracy of the intel compiler).after some short tests with the latest ffdshow i must say nothing's solved. i got the same crappy output :-( (see my comments in the other thread)
y

Tommy Carrot
14th October 2004, 12:07
Originally posted by yaz
after some short tests with the latest ffdshow i must say nothing's solved. i got the same crappy output :-( (see my comments in the other thread)
y

By solved i meant celtic_druid's x264 dll build #8 (it was discussed a few days ago in the ffdshow thread), which is free from this bug.

yaz
15th October 2004, 09:02
Originally posted by Tommy Carrot
By solved i meant celtic_druid's x264 dll build #8 (it was discussed a few days ago in the ffdshow thread), which is free from this bug. thx, TC ! it really worx.Originally posted by Tommy Carrot
I use ffdshow. It offers much more features, especially the OSD and the visualizations functions can be useful, and the playback requirement is quite low too.i made some quick tests which say vss is still better for x264. i encoded the duell scene from the 'last flight of the osiris' with subq=0-5 and with ffdshow the quality improvement was fairly visible. however, i noticed a kinda stepwise degradation on slowly moving, fine texture objects (y'know, that long stripes hanging/flipping in the fore- and background) which i always observe when my xvid encodes are decoded with libav. when changed to vss all these craps were gone and even the halfpel encode seemd amazing !
then i repacked the stream into mp4 and gave a go to xvid (that's my default mp4v decoder) and that seemed to be ok as well.
so, my experience tells that ffdshow is far not the best for x264 at the moment.

the bests
y

snacky
15th October 2004, 11:15
Does anyone know if it's even possible with current ffdshow to get the REQUESTED quants when encoding with x264?

I don't have a dedicated windows box, but in all cases I've seen, you get the ridiculous "looping quants" problem I mentioned earlier. IMO this renders ffdshow mostly useless as an x264 frontend.

Tommy Carrot
15th October 2004, 13:01
Originally posted by snacky
Does anyone know if it's even possible with current ffdshow to get the REQUESTED quants when encoding with x264?

I don't have a dedicated windows box, but in all cases I've seen, you get the ridiculous "looping quants" problem I mentioned earlier. IMO this renders ffdshow mostly useless as an x264 frontend.
This is a strange bug indeed.
http://www.fw.hu/carrotland/blockquants.jpg
As you see in the picture, most macroblocks got the requested quant, but MBs of the upper left corner are somehow underquantized, and the QP is constantly changing, giving the "looping quants" problem you mentioned. But the largest part of the video has the right quantizer.

snacky
15th October 2004, 13:25
Don't look at the per block quants, look at the per frame quants. This WILL result in ludicrous filesizes if a scene change happens to occur at a point where ffdshow has managed to request a quant of zero. In any case, it's very frustrating - there is really no way to get reasonable quants, OR the bitrate you want, OR the constant quant you want,.... This completely rules out ffdshow for generating watchable x264-encoded clips, and imo it throws a big monkeywrench in the works even if all you want to do is to test some options, since the main determinant of quality/filesize/encoding time/decoding time is always going to be the number of absurdly underquantized macroblocks.

Tommy Carrot
15th October 2004, 13:30
Come on man, most macroblocks always get the requested quant, except a few in the upper left corner. Yes, this is a strange and somewhat bothering bug, but 6-7 macroblocks cannot have a big influence in the bitrate.

snacky
15th October 2004, 13:49
No, it's essentially coincidence that any blocks get the requested quant. Insert 27 black frames before the video and see what happens.

Tommy Carrot
15th October 2004, 14:06
True, but it only happens with _perfectly_ black frames, and in that case it doesn't matter how do you quantize it, the frame wont be bigger. When there is any content on it, then most blocks will be correct, except a few in the upper left corner.

snacky
15th October 2004, 20:35
You're not understanding.

Here's an example of what ffdshow is doing.

Any I-blocks in frame 1 have quant 27.
Any I-blocks in frame 2 have quant 26.
Any I-blocks in frame 3 have quant 25.
[...]
Any I-blocks in frame 27 have quant 0.

The only reason your clip didn't have horrendously absurd quants is because you were lucky enough to get mostly predicted/skip blocks at the moment when ffdshow was choosing unreasonable quants. The upper left corner just happened to be affected by motion or something at a point where ffdshow had rolled on down to quant=6. 6, btw, is so insanely low as to be completely pointless for most ordinary purposes. Anyway, if you keep trying, you will end up with videos loaded with tons of quant-0 blocks, and that's just completely ridiculous.

Tommy Carrot
15th October 2004, 21:19
I've never experienced that (except in total black frames, where it doesn't count anyway), and i made a lot of test encodings with different characteristics. The majority of the blocks _always_ get the selected quantizer, no exception there. The only problematic part is the upper left region.

Don't get me wrong, it does bother me as well, all i want to say is that it doesn't make ffdshow completely unusable.

BTW, i've only tested fixed quantizer mode. If you refer to 2-pass mode, then you're probably right, i don't know nothing about it.

edit: it's probably worth to mention that i use ffdshow 20041003 build with celtic_druid's x264 build #8.

unmei
16th October 2004, 14:27
With the 20041003 ffdshow i experience what snacky observed as well. It is true in actual scenes as far as i have seen only the upper left corner is affected, but in the opening (title etc) i see this counting down of quantisers. It is always the top part down to where the text starts.
See this capture (146KB png) (http://homepage.hispeed.ch/mieru/doom9/x264/snapshot20041016151026.png).
The encode is "constant quantiser 18", but 18*51/31 is ~29, so the other quantisers are always correct taking that the selectable scale of 31 in the GUI is mapped to h.264 scale of 51.

But Tommy Carrot is probably right that these underquantised black blocks do not generate much too big frames..

Mug Funky
17th October 2004, 14:24
actually, quantscale seems to map like this:

h264_quant = int(ffd_quant*52/32)

remember 0 is still a quant.

ffdshow will round down, so there's a few target quants that just can't be set.

unmei
17th October 2004, 17:08
Thanks for the clarification, mug funky. It's not a big difference, but still good to know :)

Yong
19th October 2004, 06:46
Can someone suggest me a good encoding parameter(x264 and ffdshow h264)?
Thanks!

unmei
19th October 2004, 13:06
Yong, this sounds like you want to do actual backup in x264 :scared:
I would not recommend backing up with x264 at this point, it is still too deep in development.
That aside, the initial parameters are quite good so you can just start from there and toggle one or the other feature on/off.

The most important setting is surely the mode, one pass quantiser and two pass are imo the ones to choose from. I always do one-pass quantiser, as even i do some full movie encodes in x264 i never meant to fit them to a exact size so far (as im not using them for backup and mostly delete them soon again).

The Quantiser is a very sensitive parameter, in my experience in the mid-range, a decrease of 2 often almost doubles bitrate. Some example quantisers for full DVD resolution (anime) i got around 800-1100 kbit at q=14 and around 350 kbit at q=18. As with all codecs this depends much on the content, but i think quantisers around 12-18 are a good starting point.

For very high bitrates you could try disabling the loop filter, it will result in a bit less smooth/more block endangered picture. Cabac should be left enabled unless you do not want to use it due to its patented state. I read somewhere CABAC were shown to be 10% more effective in most cases than the CAVLC that would be used if you uncheck the CABAC box.

In the motion estimation tab you could play with the subpel refinement mode. I think the ones on top are the faster, the ones at the bottom the slower/better quality. However others reported artifacts with the "more iterations" mode. I did not experience these, but in this mode for me VDM crashed after 2150 frames (simply vanished without notice) :eek:
I had good experiences both with (halfpel on all, qpel on winner) and (qpel on all). Both did not produce artifacts and completed a shorter full movie (~75000 frames) sucessfully.
Still in the same tab, i would not touch the analiser flags unless you are up to some serious testing. All, on sounds good to me - just let it work to make hopefully the best estimation.
Reference frames should also probably stay at 1. You can try low other numbers though, but it seems higher numbers were inefficient and can increase the bitrate (reduce quality in bitrate mode respectively).

Anyway, i just fired up the config tab and tried to say something to every relevant parameter. Its not some proven recommended settings list and open for discussion/invalidation for sure.

bond
19th October 2004, 20:03
Originally posted by Yong
x264 and ffdshow h264also note that the h.264 encoder in ffdshow actually is x264 :)

akupenguin
19th October 2004, 20:35
Originally posted by unmei
The Quantiser is a very sensitive parameter, in my experience in the mid-range, a decrease of 2 often almost doubles bitrate. Some example quantisers for full DVD resolution (anime) i got around 800-1100 kbit at q=14 and around 350 kbit at q=18.
It's supposed to double the bitrate every 6 QP. But ffdshow has that funky 32->52 scaling going on.

Cabac should be left enabled unless you do not want to use it due to its patented state.
Just about all of H.264 is patented. You certainly can't get away from that just by disabling some options.

Tommy Carrot
19th October 2004, 20:44
Originally posted by akupenguin
But ffdshow has that funky 32->52 scaling going on.

Milan has fixed the quantizer scaling today, the scale range will be 0-51 in the next build.

virus
20th October 2004, 01:51
I've investigated a bit the "b0rked output with gcc -O2 and subpel ref > 0" problem discussed in the ffdshow thread a few days ago; celtic_druid posted his build #8 for ff_x264.dll compiled with -O and we know it works.

Well, I successfully managed to compile ff_x264.dll myself with -O3 (and all the other gcc flags in the default Makefile) but disabling MMXEXT code and got a build which produces bit-identical results with celtic_druid's one. Of course, mine is ~40% slower due to the lack of ASM optimizations. I'm using MinGW (gcc 3.2.3).

Maybe something is wrong in the way gcc interacts with nasm code? does compiling with MMXEXT and -O3 work with mencoder?

Sagittaire
20th October 2004, 08:57
What is the best way for testing x264?
- x264 vfw?
- ffdshow with build #8 for ff_x264.dll?

And best setting for you?
- more iterations or qpel on all?
- IDR interval?

hellfred
20th October 2004, 09:28
I think that akupenguin mentioned using mencoder in the ffdshow development #2 thread ( in this section of doom9 forum), because it allows to set more options than the other solutions. Update work on the vfw interface was started, don't know if the latesed options are available already. For ffdshows x264 you should try to get hold of a celtic_druid's x264 dll build #8 and replace the one that was installed from sourceforge's ffdshow build, as there were some problems with gcc -O2 optimization flag in the sourceforge ffdshow build of this file. See x264 development thread for more info. BTW, celtic_druid never put up a link to build #8, get yourself the links to builds with lower numbers and edit it to get #8.

Hellfred

P.S.: I did not verify that all infos given are still up to date. But this should at least help you getting started.

EDIT: Celtic_Druid posted the dlls in the ffdshow development #2 thread.
The link can be found on its 7th page, or just click here (http://celticdruid.no-ip.com/test/ff_x2648.7z).

akupenguin
20th October 2004, 21:57
Originally posted by Sagittaire
What is the best way for testing x264?
Yes, I use mencoder. But I've never tried ffdshow (I'm on Linux), so I can't say what's better.

"more iterations" is always the best mode. The only reason it's optional is the speed tradeoff.

I think that IDR interval = 1 is the best, for now. A larger IDR interval gives the same seeking penalty that you get from a large keyframe interval, but without as much compression gain. That will change when we get around to implementing adaptive IDR, but for now there's no benefit in IDR interval > 1.

gldblade
20th October 2004, 22:28
I think the previously described quantizer looping problem is best shown with a screenshot taken directly from ffdshow:

http://web.mit.edu/ctan/www/codecs/quantLoops.PNG
http://web.mit.edu/ctan/www/codecs/quantLoops2.PNG

I do believe that the white lines represent frame quantizers, in which case there is clearly something unusual going on.

*EDIT*
Just to make sure that the white lines do in fact represent quantizers, I decided to put x264 into constant quantizer mode. A look at the graph reveals that the white lines do in fact represent quantizers. This implies something is pretty wrong with constant bitrate mode. Rate control perhaps?

snacky
20th October 2004, 22:39
Hey, I'd almost given up on this thread, then you came along.

Yes, current ffdshow always does this. There is no way to even get constant quants with it, because of this hideous bug that causes frame-level quants to loop in exactly the manner your graphs show.

gldblade
20th October 2004, 22:56
Hm, are you sure about not being able to get constant quants? Maybe ffdshow is reporting this to me wrong, but:

http://web.mit.edu/ctan/www/codecs/quantConst.PNG

This suggests ffdshow works at least partly.

*EDIT*
In addition, after actually watching the video with quantizers overlaid on top, I have come to the same conclusion that this bug doesn't render ffdshow completely useless. As others have said, while the bug is disturbing, it shouldn't have too much of an effect.

So basically I have contributed nothing new here, oops sorry guys :P

Yong
21st October 2004, 08:25
Thanks unmei and bond for the replies.;)
@unmei:
I'm not going to backup my video using the x264, it's still to buggy right now, am i right? I just can't decided which setting or encoder is right for me.

@bond:
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.:cool:

yaz
21st October 2004, 08:36
Originally posted by Yong
Thanks unmei and bond for the replies.;)
@unmei:
I'm not going to backup my video using the x264, it's still to buggy right now, am i right? no, you're wrong :-) i've never had such artifacts you mentioned either with mencoder or with celtic's ff_x264. i'm sure it's an ffdshow bug. maybe that compiler issue again, mentioned in the ffdshow thread(?)Originally posted by Yong
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.:cool: what do you mean by this ???
y

Yong
21st October 2004, 09:06
@yaz:
Compare with the ffdshow h264, [x264vfw core 11] only have 6 options to "tweaking" IIRC.
I still don't how two use two pass(may be need to use the libavcodec stats file.). May be not need two pass encodeing, one pass already can produce good result.:cool:

mencoder with h264 encoding? plz tell me where it's! I'm tired with the VDMod "Parsing MPEG video" slow process..

Thanks for yaz reply and correct me,:D
i'm a newbies:) Still need sometime to learn how to encode video when using ffdshow, Xvid and h264.

akupenguin
21st October 2004, 09:32
Originally posted by Yong
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.
That just means x264vfw hasn't been updated in a while. (Virus is working on it, but nothing released yet.)
ffdshow uses x264 core 51 or so.

yaz
21st October 2004, 09:55
Originally posted by Yong
... Compare with the ffdshow h264, [x264vfw core 11] only have 6 options to "tweaking" IIRC ... see akupenguin's comment
Originally posted by Yong
I still don't how two use two pass... find milan's comment in ffdshow#2 thread on page 3, cited by virus (crosspost's not allowed) it's quite easy.Originally posted by Yong
mencoder with h264 encoding? plz tell me where it's! find an up-todate compile of mencoder, x264 is included. it offers the most complete option-set but u must pal up with the cli.
i've been using celtic's compiles but ... y'know :-(((Originally posted by Yong
i'm a newbies:) Still need sometime to learn how to encode video when using ffdshow, Xvid and h264. no blame :-) i'm not a noob but still i learn new things all day. y'know, living is learning.

the bests
y

celtic_druid
21st October 2004, 12:15
mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22P4.7z)
mplayer/mencoder Athlon TBird Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22tbird.7z)

Builds updated. There was a problem with x264 encoding.

virus
21st October 2004, 12:45
Originally posted by akupenguin
(Virus is working on it, but nothing released yet.)
Right now, I'm not working on anything. I'm still waiting for an answer by the devs (9 days...). If they don't ever care to talk to ppl that offer help, I don't see why I should waste my time with them.
I support other (not videocoding-related) projects and they for sure deserve my help much more. Sorry.

virus

RadicalEd
21st October 2004, 15:39
Originally posted by celtic_druid
mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.20.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.20P4.7z)

Any chance for an unoptimized (or MMX-only) build for poor suckers with old-skool Athlons? :O

RadicalEd
21st October 2004, 21:53
mplayer2004.10.21tbird.7z

Awesome :D Thanks!

celtic_druid
22nd October 2004, 12:06
I have updated the compiles. Anyone having problems with x264 encoding should grab the new build.

aketon
22nd October 2004, 13:27
Can anyone please tell me what kind of files are .7z and how can I use them?:confused:
Thanks!

Tommy Carrot
22nd October 2004, 13:35
http://www.7-zip.org

aketon
22nd October 2004, 13:45
Very interesting!

Thanks!

ivan_alias
22nd October 2004, 16:55
Thanks to Celtic_druid for the builds :)

I must ask though, does anyone have a mirror of these builds? They take over 40 mins to download!!

I'm only getting 1.3KB/s :(

celtic_druid
22nd October 2004, 19:19
WinRAR also supports 7zip files, that is if you have the latest version.

If someone wants to mirror anything, then yes please do.

pogo stick
23rd October 2004, 13:59
Originally posted by celtic_druid
mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22P4.7z)
mplayer/mencoder Athlon TBird Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22tbird.7z)

Builds updated. There was a problem with x264 encoding.

Thank you for P4 compile, Celtic Druid! 2004.10.22 version seems to work. :)
Is there a way to open AVS files with mencoder? I tried to use "makeAVIS.exe" from ffdshow, but mencoder says: "Cannot find codec matching selected -vo and video format 0x53495641." And docs doesn't say anything about AviSynth.

ac-chan123
23rd October 2004, 16:38
MPlayer have no avs support. mplayer is a linux player, wich is also availe for win32, but the development ist mostly on linux. So there are not so much win32 spezific things in it.

akupenguin
23rd October 2004, 21:54
Originally posted by pogo stick
Is there a way to open AVS files with mencoder?
MEncoder itself doesn't support AVS. MakeAVIS doesn't work because MEncoder doesn't use VfW.
I wrote an AVS decoder program which I cross-compiled and run under Wine, but who knows, it might work under Windows too. AVS2YUV (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)

yaz
25th October 2004, 08:20
Originally posted by pogo stick
... Is there a way to open AVS files with mencoder? I tried to use "makeAVIS.exe" from ffdshow, but mencoder says: "Cannot find codec matching selected -vo and video format 0x53495641." And docs doesn't say anything about AviSynth.yep, no avisynth support by def., but u can make a workaround with makeavis. for using the fake avi generated by that u must add ffsdhow to the codecs.conf file. drop sg like this intovideocodec makeavis
info "FFdshow makeavis"
status untested
fourcc AVIS
driver vfw
dll "(path)/ffdshow.ax" ; path=location of ffdshow.ax from root up
out YV12 ; add further formats by comma separated


i've just tried and it worked fine.

the bests
y

pogo stick
25th October 2004, 23:00
Both methods don't work for me. :(
avs2yuv's outputted files look green in mplayer or after encoding with mencoder.
makeAVIS files are causing this error:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'C:\Program Files\ffdshow\ffdshow.ax'
Loaded DLL driver C:\Program Files\ffdshow\ffdshow.ax at 10000000
ICDecompressGetFormat failed: Error -2

Fake avis are also giving error in VirtualDubMod and can not be decoded.
Opening in DShow and using AviSource() with VDub works.
It's strange.

Sagittaire
25th October 2004, 23:47
x264 seem to have a very good potential too ...

http://jfl1974.free.fr/Video/x264vsVP6-1000.JPG

Average PSNR
H264 : 44.7337 dB
VP6 : 44.3975 dB
x264 : 44.2624 dB
RV10 : 44.0334 dB
WMV9 : 43.7891 dB
XviD : 43.6912 dB
DivX5 : 43.0575 dB

Overall PSNR
H264 : 44.1604 dB
VP6 : 43.9286 dB
x264 : 43.6708 dB
RV10 : 43.5277 dB
WMV9 : 43.3891 dB
XviD : 43.2531 dB
DivX5 : 42.4873 dB


but visualy high block flicking for high quant encoding ... :(

Sirber
25th October 2004, 23:59
x264 is still CBR right?

Sagittaire
26th October 2004, 00:08
2 pass with ffdshow and libavcodec/h264 stat:
- first pass mode quant
- second pass mode bitrate

I make first pass with same average quant (approximative evaluation with little sample) than second pass -> very better RC and very constant quality

ak
26th October 2004, 01:16
Originally posted by pogo stick
makeAVIS files are causing this error:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'C:\Program Files\ffdshow\ffdshow.ax'
Loaded DLL driver C:\Program Files\ffdshow\ffdshow.ax at 10000000
ICDecompressGetFormat failed: Error -2

Probably old ffvfw.dll can do the trick, put it in mplayer codecs dir and edit codecs.conf. And maybe create fake avi with makeavis.exe from ffvfw bundle, not sure if it matters though.

I was trying .ax once and it didn't work for me either, although old ffvfw used to work, IIRC.

yaz
26th October 2004, 08:57
Originally posted by pogo stick
... ICDecompressGetFormat failed: Error -2 ... Fake avis are also giving error in VirtualDubMod and can not be decoded.
Opening in DShow and using AviSource() with VDub works.
It's strange. imho

1) its a colorspace misery. try
- destall all ffvfw (a time ago this whole makeavis business was made by ffvfw but now it's merged into ffdshow) and install ffdshow041012 (or newer:-) make sure makeavis is ticked!
- check whether vidc.avis is set in the registry (needed not by mencoder but by any ds player)
- when making fake avis do not(!) force any color ouput format (let mencoder convert it if needed). serve audio only if u got it in the source (mencoder will check it but why to make it risky? :-)
- try playing the fake avi. if everything went right it should play fine in ds (& mencoder will accept it)
if not ... try the 'workaround of the workaround'.
- find and old ffvfw (say, 031113 made me the trick).
- install
- copy ffvfw.dll (from the system dir) and libmplayer.dll (from the install dir) besides(!) mencoder.exe.
- change the codecs.conf's 'dll' item to ffvfw.dll
- uninstall ffvfw (& put back ffdshow)
i made avisynthing for months (until makeavi support was switched back) this way & worked fine.

2) some filters, filter-chains or functions (avis) may cause serving misery. if nothing works from the aboves try building your script filter by filter.

the bests
y

yaz
26th October 2004, 09:54
Originally posted by Sagittaire
x264 seem to have a very good potential ... sure! what it produces is really amazing. on some scenes it beats xvid (which is the etalon for me:-) definitely.
Originally posted by Sagittaire
... but visualy high block flicking for high quant encoding ... for playback i suggest vss decoder, as ffdshow makes some artifacting on fine texture and also on wide flat surfaces. maybe, that's what u experienced.
btw, how did u make that psnr tests ? & what is h264 ?

the bests
y

pogo stick
27th October 2004, 00:12
Thanks for helping, ak, yaz! :)
It seems like colorspace thing. I was forcing YV12 in makeAVIS. Without forcing it worked. With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK. But there are few things that I don't understand:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'codecs\ffvfw.dll'
Loaded DLL driver codecs\ffvfw.dll at 10000000
VDec: vo config request - 704 x 544 (preferred csp: Packed YUY2)
[PP] Using codec's postprocessing, max q = 9.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [makeavis] vfm:vfw (FFdshow makeavis)

If my source (just cropped and trimmed MPEG2 file) is YV12 then why it shows YUY2? Why it doesn't find matching colorspace, use scale filter and use converter? And what is codec's postprocessing? Also warning about rc buffer is little bit confusing. I didn't change default ratecontrol setting and it's fixed quantizer first pass so as I understand it shouldn't matter. :confused:

akupenguin
27th October 2004, 07:00
I don't know why forcing YV12 didn't work, or why YUY2 is preferred.

It needs a "unscaled Planar YV12 -> Planar YV12 special converter" because x264 (or at least the mencoder wrapper for x264) supports I420 but not YV12. The only difference is the order of image planes in memory, so the "scaler" swaps a couple of pointers and all is good.

rc buffer is indeed irrelevant to constant qp mode. I just submitted a patch to remove that warning.

yaz
27th October 2004, 10:35
Originally posted by pogo stick
...With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK ...
yep ... joke from ffdshow. sorry, i forgot to mention it. no problem, anyway. just put a flipvertical() at the end of your script & use ffdshow041012. (it's clean, dry & safe :-)
Originally posted by pogo stick
... If my source (just cropped and trimmed MPEG2 file) is YV12 then why ... :confused: so am i. it's spoken exactly the same way whatever input/output combination i've tried. don't bother, it doesn't hurt. it seems as if this mantra would be needed for proper operation of mencoder :-)))

the bests
y

ps celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.

pogo stick
30th October 2004, 01:14
OK. Than colorspace changing is not a big problem. But is postprocessing seems strange. Is it how it should be?
Originally posted by yaz
celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.
Great! Is there something new?

pogo stick
30th October 2004, 18:42
Originally posted by akupenguin
MEncoder itself doesn't support AVS. MakeAVIS doesn't work because MEncoder doesn't use VfW.
I wrote an AVS decoder program which I cross-compiled and run under Wine, but who knows, it might work under Windows too. AVS2YUV (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video). But mencoder with avs2yuv doesn't work:

Reading from stdin...
success: format: 0 data: 0x0 - 0x0
total frames: 896
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 384x208, codec: 384x208
VIDEO: [YV12] 384x208 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:384x208 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 384 x 208 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==================================
Writing AVI header...
ODML: vprp aspect is 16384:8874.

Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:8874.

Video stream: -1.#IO kbit/s (-2147483648 bps) size: 0 bytes 0.000 secs 0 frames
x264 [info]: analyse=0(0ms) encode=0(0ms) write=0(0ms) filter=0(0ms)
Output error: wrote only 77546 of 79872 bytes

I just thought that maybe something else is missing in my system.
"Reading from stdin..." in mencoder and "The outfile may be "-", meaning stdout" in avs2yuv.
What is std?

I am sorry that about talking too much about mencoder in x264 thread. But it is very connected now. And I fell much more comfortable encoding in mencoder then in virtualdub.

ak
30th October 2004, 23:08
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.

Yeah and 'std' means standard, afaik.

akupenguin
31st October 2004, 01:41
Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline. That won't work. Or rather, it should display something, but not what you want: avs2yuv outputs yuv4mpeg (yv12 with headers), not raw yv12. Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Output error: wrote only 77546 of 79872 bytes Someone in the Avisynth under Linux (http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround was to use fifos, but those don't exist in Windows.

ak
31st October 2004, 10:20
Oh boy, and was mixing them all the time. Going to rtfm.

pogo stick
31st October 2004, 16:25
Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.
I don't know what is it, but I really like how it looks!
It's like train of distorted video moving from left to right!
Not really useful, but fun! :)

ak
31st October 2004, 18:25
Originally posted by akupenguin
Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Someone in the Avisynth under Linux ("http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround waas to use fifos, but those don't exist in Windows.
Yeah, something confuses mencoder in piped avs2yuv output, mpeg2enc as well for that matter. They give this on first frame:
<mencoder>: error reading frame bad header magic
<mpeg2enc>: Error reading frame header (0): codebad header magic!

Ffmpeg's yuv4mpegpipe works with both otoh, so does encoding using fifo.

movmasty
31st October 2004, 18:30
Originally posted by snacky
In any case, it's very frustrating - there is really no way to get reasonable quants, OR the bitrate you want, OR the constant quant you want,.... This completely rules out ffdshow for generating watchable x264-encoded clips, and imo it throws a big monkeywrench in the works even if all you want to do is to test some options, since the main determinant of quality/filesize/encoding time/decoding time is always going to be the number of absurdly underquantized macroblocks.
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...

hellfred
31st October 2004, 19:53
Originally posted by movmasty
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...
Just get yourself to use mencoder for encoding to x264. It is not that hard to compile it for yourself, and once set up, you can easily compile the very latest x264 and link to it.
Steps involved:
Dl and install mingw and msys packages from www.mingw.org.
(First msys and than mingw into /mingw of msys root directory)
Dl nasm source. Unpack it (e.g. in your MSYS home directory /home/<loginname>) and compile it in MSYS using
"/.configure && make && make install"
Dl and compile x264 source from www.videolan.org using a windows svn client from http://subversion.tigris.org/ and the command line given on the vlc html page.
"cd x264/build/cygwin && make"
Afterwards copy the libx264.a and x264.h to /mingw/lib and /mingw/inclode:
cp bin/libx264.a /mingw/lib ;cd ../..; cp x264.h /mingw/include
You may have to edit the x264.h file to include stdargs.h:
...
#define _X264_H 1
#include <stdarg.h> //<- Add this
#define X264_BUILD 0x000b
...

Now downlad mplayer cvs source from mplayerhq.hu.
Get yourself the daily CVS snapshot source from the download page
Unpack it in MSYS and change into it using
tar xfj MPlayer-current.tar.bz2
cd MPlayer-2004xxyy
where xxyy will be the month and date of the day you have downloaded MPlayer-current.tar.bz2.
./configure
At the end of the summary you can check that x264 is listed under Codecs in the section, which should happen automatically when you copied the x264.h and libx264.a file to the appropriate directoris.
Enabled optional drivers:
Codecs: libavcodec ... x264

Then just type
make && make install
and you are done.
From then on you can use the command lines in the mencoder + x264 thread as a start to experiment with the codec. If you just can't get over using VDubMod for filtering/editing the source, output to some lossless codec from VDubMod and use that as imput for mencoder.
Only drawback of MSYS that i found up to now is that man is missing, so you have to find youself an up to date html man page for learning the x264encopts on the net.

Hellfred

ak
31st October 2004, 22:36
Regarding pipes, I remembered there was something similar with another program,
so this one here should work: http://4nykey.nm.ru/tmp/

akupenguin
1st November 2004, 05:22
I managed to find a Windows box and reproduced the piping bug: It occurs whenever the frame contains a byte 0x1A. (Ascii name "substitute", treated as EOF by Windows.) However, the stream does not translate \n to \r\n, so it isn't just the normal textmode corruption.
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Still, fwiw, I have updated avs2yuv to use binmode stdout.

... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

Leak
1st November 2004, 11:21
Originally posted by akupenguin
... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

I have the nagging feeling that all this will suddenly start to work as soon as it's done in a Cygwin bash or zsh, as opposed to CMD.EXE...

np: Poto & Cabengo - Life In San Diego (Poto & Cabengo)

ak
1st November 2004, 13:34
Originally posted by akupenguin
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).

hellfred
1st November 2004, 20:43
Originally posted by ak
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).
Thank you a lot, ak
If I find some time, I will test it (Win98 Command.com && MSYS rxvt or cmd.exe from ReactOS project). I am looking forward to see if it works.

Hellfred

hellfred
1st November 2004, 21:23
No good on Win98
Both using MSYS rxvt console and cmd from ReactOS project, avs2yuv does not work. First is end of dir command in cmd.exe and second is the output of rxvt.
10-31-2004 7:34p <DIR> MPlayer-20041020
11-01-2004 8:44p 6,233 avs2yuv.exe
11-01-2004 8:51p 47 test.avs
34 Files 43,015,199 bytes
20 Dirs 3,249,659,904 bytes free

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs -
Unknown error! Error code: 0xc1

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs - | ..\..\mplayer_x264\bin\m
player.exe -
Unknown error! Error code: 0xc1
File not found -- Error executing CreateProcess()!!


D:\Stefan\msys\1.0\home\Stefan>

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
Unknown error! Error code: 0xc1
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or
directory
Reading config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/config
Reading D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf: Can't open
'D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf': No such file or d
irectory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264
/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
font: can't open file: D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/font/font
.desc
font: can't open file: /opt/mplayer_x264/share/mplayer/font/font.desc
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/inp
ut.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such f
ile or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls
avs2yuv.exe mplayer out.avi skript.sh test.avi
mencoder.exe mplayer.exe out.avi.bak sub_snow_q255.avi test.avs

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs - | ./mplayer -
sh: ./avs2yuv.exe: Permission denied
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or directory
Reading config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/config
Reading D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf: Can't open 'D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf': No such file or directory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
Font D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/font/font.desc loaded successfully! (206 chars)
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/input.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such file or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

Stefan@J5U7R1 /opt/mplayer_x264/bin
$

"Unknown error! Error code: 0xc1" and "sh: ./avs2yuv.exe: Permission denied"
Any idear what those mean? I will try your avs2yuv on some WinXP SP1 system soon, too.

Hellfred

akupenguin
1st November 2004, 21:48
Originally posted by hellfred
11-01-2004 8:44p 6,233 avs2yuv.exe I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

Unknown error! Error code: 0xc1 I have no better idea what that is than you do.

sh: ./avs2yuv.exe: Permission denied That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.

hellfred
2nd November 2004, 00:07
Originally posted by akupenguin
I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

I have no better idea what that is than you do.

That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.
I have downladed that binary from 4nykey's side linked by ak. I will redownload it to see if it.

When doubleclicking the avs2auv on Win98, the OS will tell me that this is no win32 binary, and WinXP will tell me something about 16 Bit instructions. Sorry, as my OS is german, so are the messages, that i assume you will not understand therefore. So i did not copy & past them in here.

Msys tells me, that it can be executed:
Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls -l avs2yuv.exe
-rwxr-xr-x 1 Stefan unknown 6233 Nov 1 20:44 avs2yuv.exe

I will dl the executeable once more from 4nykey's side.

Hellfred

EDIT: Now i get an error message as the dll file AVISYNTH_C.DLL can not be found. I have latest AviSynth 2.5.5 installed and ffdshow 20041012 with all options checked. Where to get that file?

EDIT2: Found it in google and just downloading it.

EDIT3: Now it works, just a error in kernel32.dll at the end of playback.
AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00ad2780 SS=0167 ESP=017afb64 EBP=00ac38c0
ECX=00bd6b20 DS=0167 ESI=6fd30df0 FS=557f
EDX=00ac38c0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00bc0490 6fb169b2 6fd30df0 00ad2780 00bc0490 6fb26e5d 00ad2780 557f0167 00000000 6fac2e38 00ac38c0 bff9ab2b bff7b30e 00000000 00bc0490 00000004

CruNcher
2nd November 2004, 00:44
akupenguin how far is b-frame decoding in libavcodec for H.264 by now ?
i get damaged output with the newest videolan vlc-0.8.0-win32-20041101
i used Weighted Prediction, B-frames and Cabac in this clip

http://cruncher.mufflastig.com/h264/libavcodec_h264_b-frame-problem.png

ak
2nd November 2004, 01:21
Originally posted by hellfred
I have downladed that binary from 4nykey's side linked by ak.
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.

akupenguin
2nd November 2004, 04:45
Originally posted by CruNcher
akupenguin how far is b-frame decoding in libavcodec for H.264 by now ? Weighted prediction is not supported at all. (That probably caused the discolored blocks, but can't be related to the streaks.) CABAC should pose no problems. The only known issue with B-frames is that they are displayed out of order. But I'm open to any video clips that break decoding, if you want to send it to me.

hellfred
2nd November 2004, 09:23
Originally posted by ak
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.
avs2yuv does not work well on WinXP SP1, too. It is even worse. My testing script was just an
AVISource("C:\FUll\path\to\file.avi")
with three different avis containing MPEG4 encodes.
I could always open it in VDubMod easily, and in my DShow Player BSPlayer. But only the smallest (in terms of both resolution and file size) could be streamed to mplayer, giving me a error message ahead of mplayer displaying the video. Video playback started after clicking away the error message.
Is that due to the fact that i did not eleminate the audio track?

Hellfred

akupenguin
2nd November 2004, 10:03
Originally posted by hellfred
Is that due to the fact that i did not eleminate the audio track?
avs2yuv completely ignores the audio track. that shouldn't be an issue.

hellfred
2nd November 2004, 15:25
Originally posted by pogo stick
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video)...
Can you point me to a location where i can find this codec, please? Finding anything on helixcommunity.org is impossible, and google did not help either. Up to now i have tryed xvid and ffdshow for decode, but both are unstable. I know that once one programm that i installed came with it (RealAnime?) but i can not find it no more.
Hellfred

EDIT:
Found it here (http://forum.doom9.org/showthread.php?s=&threadid=56972) in the forum.

hellfred
3rd November 2004, 09:50
Finally everything is next to working smooth with the latest build of avs2yuv on WinXP and Win98, as long as i only decode 500 frames (-frames 500). The first binary that I have downloaded from ak got truncated somewhere in the download process. Getting another one fixed that.
Then output was unstable on Win98 when decoding using XviD v1.1 alpha build, and failed using ffdshow configured for processing raw videos, but with helix vfw codec finally i get some frames. Although there is still a error message to click away, so that using avs2yuv in batchs/scripts is still impossible, as nobody is there to click away the error message e.g between two passes of a multipass encode or differnt encodes. :(
On WinXP I had to get rid of DivX v5.0.2, as the output was all green, and install Helix vfw codec. But again an error message makes it impossible to do unattained batch encodes. :(

On Win98 i get the error message mainly at the end of decoding:

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=52bf
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 52bf0167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

No matter if i tage the msys, cygwin or ReactOS cmd.exe console.

Just usingure, build in command.com i get it ahead of mplayer showing the video. Command.com is a little bit faster than the other three consoles.

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4437
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 44370167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

This behavour is confirmed by the output of avs2yuv just ahead of / just after the error message popps up:
D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
test.avs
total frames: 10759
Output error: wrote only 213734 of 230400 bytes
The data are being writen to a file named "AJCKACDC" (command.com) or "CMDF001.TMP" (ReactOS cmd.exe) residing in c:\Windows\temp.
Any idea hot to fix this? Is there any information that i can provide for you to understand this bug? Or is there no way to implement something like a "real" pipe in Win9x that handles the information from one process to the other "on the fly"?

Hellfred

EDIT: Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.
And there still remains the problem of an error message at the end of decoding:
[code]AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=017afb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4fb7
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 4fb70167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004[\code]

Leak
3rd November 2004, 13:47
Originally posted by hellfred
Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

Ah, but that's the way piping was/is implemented in DOS and Win9x/ME command interpreters - writing the output of one program to a temp file and feeding that to the next one in the pipe. You can't do anything about it, other than either upgrading to a newer windows or use a different shell, like Cygwin bash or zsh.

Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.

Of course - after all, both the encoder and decoder are now running at the same time, whereas before the decoder's output was dumped to a file which was read in again afterwards...

hellfred
3rd November 2004, 14:30
Sorry for highjacking the x264 development thread
I have start a new thread (http://forum.doom9.org/showthread.php?s=&threadid=84852) in the AviSynth usage section of this forum. I wellcome akapenguin, ak and all the others to discuss avs2yuv usage and to help getting it working under win32 there.

Hellfred

Tommy Carrot
3rd November 2004, 17:04
Apparently the underquantization bug in fixed quantizer mode has been fixed in ffdshow, it works flawlessly in Celtic_druid's latest build.

celtic_druid
3rd November 2004, 23:19
http://celticdruid.no-ip.com/test/ ff_x264.2004.10.30 ones are the same was in my recent ffdshow builds, but with -march/mtune=Athlon-xp/pentium4. I guess that (ff_x264.dll) is what solved the problem so it should also work with the latest sourceforge builds.

hellfred
4th November 2004, 11:35
Here is a small feature request.
Is it possible to add a switch that will disable the output of the video frames? When doing a multi pass encode, the logfile is all what is needed to run the next pass. Discarding the frames can help when one has only limited disc space. This is done by several other codecs / encoders, too, e.g. Xvid and ffdshow.

Hellfrd

akupenguin
4th November 2004, 21:56
That feature doesn't belong in x264: it's not codec specific, and doesn't save any encode time (at least not unless I optimize CABAC for the case where we only care how many bits it would output.) Ask ffdshow to extend their discard 1st pass option to all codecs.

hellfred
5th November 2004, 00:45
In ffdshow one just has to uncheck "Store frames to AVI", and nothing is written to a file, no matter which codec you have chosen for encoding.
Actually the basic idea was to keep mencoder from writing the first pass to harddisk. On Linux one can use -o /dev/null and on win32 -o NUL: as a workaround. I have learned the later one from Leak after i have asked this question here.
So please spend your time on improving this great codec of yours. And thank you for the great work up to now.

Hellfred

virus
7th November 2004, 21:34
Here's what I got in the last days when trying to update or checkout the sources for x264 using SVN. It worked until a week or two ago.

$ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

Same output for "svn status" or "svn update".
I've tried with some permutations of the above cmdline (x264-trunk and similar, following the hints on videolan.org) but I always get the same error. I've also tried a fresh checkout of the VLC sources from the same server and everything worked perfectly. What happened?

Sirber
7th November 2004, 21:57
yep, same here:

sirber@detrinux sirber $ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

hellfred
7th November 2004, 22:34
Don't mind it being broken, as there are only very few modivications to the source code that can be tracked through the development mailing list via this link (http://www.via.ecp.fr/via/ml/x264-devel/).
Siber, don't you have a Athlon64. Have a look at the last mail of oktober (http://www.via.ecp.fr/via/ml/x264-devel/200410/msg00033.html) .

Hellfred

Sirber
8th November 2004, 03:34
No

Brand old AMD XP 2000+ :o

Sagittaire
11th November 2004, 20:49
Preview: very good test for x264

http://jfl1974.free.fr/Test/Comparatif/PSNRAverage.gif

http://jfl1974.free.fr/Test/Comparatif/PSNROverall.gif

gotaserena
12th November 2004, 06:31
I just tested revision 59 on two different encodes. The first went fine (TV capture, noisy), but the DVD backup I was making with bitrate set to double what qp_constant=22 said seg faulted with this error:

x264 [error]: Error: 2pass curve failed to converge
x264_encoder_open failed.

If I reduce the bitrate it encodes fine.

Anybody found some similar behaviour?

akupenguin
12th November 2004, 08:17
Try r60. It won't fix the error, but it will provide more information on what happened.

gotaserena
12th November 2004, 09:41
I'm recompiling mplayer and will begin encoding soon.

I'm also having these problems with some frames:

http://img120.exs.cx/img120/5152/sample-problem.th.png (http://img120.exs.cx/my.php?loc=img120&image=sample-problem.png)

qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2
deblock:deblockalpha=2:frameref=5

akupenguin
12th November 2004, 09:48
To help with that I would need not just a snapshot, but a source clip and compressed clip that demonstrate the problem (preferable short clips. and the source need not be lossless, as long as it's what you actually gave to mencoder), along with the exact encoder command line.

gotaserena
12th November 2004, 19:41
Here's it aku (ankka?)

Source (http://s5.yousendit.com/d.aspx?id=2DD4C707B54AA8FE857CCF0B9A97EF82)

1-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o /dev/null -vf scale=384:288 -ovc x264 -x264encopts pass=1:qp_constant=22:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

2-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-avc.avi -vf scale=384:288 -ovc x264 -x264encopts pass=2:bitrate=1168:qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

Result (http://s5.yousendit.com/d.aspx?id=7AF861860CBE9528F8E0FA275357FEC2)

BTW, thanks for the revision. I saw that I foolishly had set qp_min too high to manage the bitrate I wanted. Still it's better to have a reminder than a core dump :D

akupenguin
12th November 2004, 21:42
I confirm the error, and notice that all the extraneous black rectangles are Skip macroblocks. Skip simply copies the block from the previous frame, and the motion vectors look reasonable. This leads me to believe that it's a bug in lavc's decoder rather than in x264.
But I'm happy to patch lavc too, so I'll see what I can do.

Sidenote: you'll get improved quality by using "-vf field=0,crop=684:284:12:2,hqdn3d=5,scale=368:288": As long as you're downscaling interlaced content, you keep more detail by dropping one field rather than blending them. And black borders are also bad.
(Your error happens to go away when I add the crop filter. Maybe lavc is erroneously replicating pixels from the edge of the frame?)

p.s.
Here's it aku (ankka?)aku:
悪 【あく】 (n) evil; wickedness;
悪戯 【いたずら(P); あくぎ】 (adj-na,n,vs) tease; prank; trick; practical joke; mischief
(no relation to either the magazine Aku Ankka nor Donald Duck.)

gotaserena
12th November 2004, 22:26
Hmm, sorry for not trying to decode the file in windows before complaining here. At least something was learnt. Thanks for all the help and sorry for the bad joke!

akupenguin
12th November 2004, 22:47
What codec would you use under windows? ffdshow uses lavc too, so it should have the same bugs. Unless you have a beta of Ateme?
Anyway, you did uncover a bug, and I will try to fix it.

gotaserena
13th November 2004, 14:53
Ok, I did some encodes in windows (using celtic_druid's builds, based on r59 I believe).

The problem does not show in pass=1, decoding with libavcodec.

The problem does show in pass=2, decoding with libavcodec.

I thought it would be a simple thing to decode the output using Moonlight's H.264 decoder, but alas no luck, no matter what container I used. Funnily mp4creator refused to put the stream into mp4.

To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

RadicalEd
13th November 2004, 16:35
Originally posted by gotaserena
To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

That's just ffdshow's vfw part.

gotaserena
13th November 2004, 18:50
So, is quartz.dll some sort of DShow wrapper for vfw codecs?

akupenguin
13th November 2004, 21:20
Originally posted by gotaserena
The problem does not show in pass=1, decoding with libavcodec.
The problem does show in pass=2, decoding with libavcodec. Are you sure that's not just a question of quantizer? Try a first pass with different qp_constants.

gotaserena
13th November 2004, 21:58
Yes that seems a problem of quantising...
@q=22 there's no problem
@q=25 it begins to show and gets worse as q raises.

This is surely consistent with your point that these are regions the codec chooses not to change from one frame to the other. As q increases, so does the region in the approximation taken.

I compiled the reference codec from the link you posted elsewhere but I must admit my knowledge on how to deal with raw yuv files is wanting. If I could play the stream I could tell for sure if this is the decoder's fault.

gotaserena
14th November 2004, 01:07
Ok, here's what I did to avoid (unsucessfully) using libavcodec -- in windows -- during this game.

- Open the MPEG2 source in VirtualDubMod, resized to 512x384 using the built-in Lanczos filter and saved in huffyuv. Now since in all probability vdm uses libavcodec to decode mpeg2 I was left with little choice than just open the resulting video to see whether the problem showed up. It did not. By the way ffplay ran the huffyuv file without any black boxes either.

- mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-q30.avi -ovc x264 -x264encopts pass=1:qp_constant=30:nofullinter:cabac:keyint=250:psnr:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-hfyu.avi
Here's another point where I depend on libavcodec, but since ffplay did not show any black boxes, I went on and trusted that this step did not screw things up.

- Resulting file shows boxes on frames 40, 111 and 173 when played using a libavcodec decoder.

- avi2raw60 segment-q30.avi segment-q30.264 (avi2raw60 from mpeg4ip (http://mpeg4ip.sourceforge.net/))

- Compiled the source from http://iphome.hhi.de/suehring/tml/download/ and decoded the file segment-q30.264 using ldecod.exe. The input parameters for the decoder where kept on default.

- Converted from YUV 4:2:0 to RGB24 using this (http://www.ee.surrey.ac.uk/Personal/S.Worrall/dloads/yuv2avi_p2.zip) utility. The program wraps the resulting stream in avi so I can open it using virtualdub.

- The final file shows boxes on frames 40, 111 and 173.

RadicalEd
14th November 2004, 01:13
IIRC VDM uses libmpeg2.

akupenguin
14th November 2004, 02:16
OK, I enabled the debug output of decoded frames, and x264 itself displays the blocks. New hypothesis: the skip decision algorithm is too lenient at high quants. (I already know it's too strict at low quants.)

edit: yep, that's it.
Conditions for the bug: If the current area of the picture is flat (no gradient or detail), and the motion vector predicted from the neighboring blocks points to a flat region of another color (in this case black), and the inter DC quantizer brings that difference down to 1 unit, then the block will be erroneously skipped.
Now, how to fix it without killing the whole pskip decision? I might need more psychovisuals than just the current hadamard + weighted coeffs.
Eventually I'll implement a rate/distortion optimal skip decision, but there must be some fast way, too.

pogo stick
23rd November 2004, 23:53
Maybe it's too early for this and there are some other more important stuff that can be improved and implemented, but I just thought about this feature. Will it be hard to do in encoder? Is it similar to MPEG-4 video - PAR in bitstream? And I wonder if FFDShow already capable of auto-resizing anamorphic H.264 video?

gotaserena
24th November 2004, 00:14
My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

akupenguin
24th November 2004, 02:07
Fixed.
x264 already supported PAR, but MEncoder didn't set that parameter.

giandrea
24th November 2004, 03:57
Originally posted by gotaserena
My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

Hi gotaserena! How do you mux h.264 video into MP4? Do you use the latest mpeg4creator from CVS? I tryed to compile it, but it failed under MacOS X, I will try again soon anyway.

pogo stick
24th November 2004, 06:18
Look here (http://forum.doom9.org/showthread.php?threadid=84456).

giandrea
24th November 2004, 16:24
Talking about quality, from a test that I've done recently, x264 at fixed quantizer=19 and 1Mbps scored an average psnr of 52.75, while xvid scored an average psnr of 52 at 2.3 Mbps for the same clip. Is it possible for x264 to be so much superior to xvid in the early developement stage it is in now? Or I made some mistake and x264 hasn't got that high psnr?
thanks,

giandrea

Mug Funky
24th November 2004, 16:29
either:

a) x264 is really kicking a$$
b) you scored some choice x264 settings
c) you broke xvid's settings :)

hehe... maybe it's all 3. but x264 is looking very promising, at any rate. i get the impression that right now it's not even close to what it could finish up as. that fills me with optimism, as it's already awesome.

snacky
24th November 2004, 17:02
Just guessing, but I'll vote for:

d) neither encoder achieved the requested bitrate, so the comparison turns out to be invalid ;)

There are certain sequences that may be encoded at low cost with h.264, but are "pathological" for mpeg4 asp. I've been known to perseverate on certain types of rapid flashing sequences, where you can get nearly arbitrary (e.g., 1/100th the bitrate) improvements with h.264 as compared to mpeg4 asp.

But in my experience, you're very lucky to see x264 get more than a 25-30% bitrate improvement over xvid or lavc, and the more typical case is only a marginal improvement.

Tommy Carrot
24th November 2004, 17:28
In my experience x264 has big advantage at low bitrates, where the image of xvid tends to fall apart, while x264 remains solid. But at higher bitrates, the advantage is not clear, or there are cases where x264 is even inferior to xvid. This can be attributed to inloop-filtering imo, which can smooth away the finer details even at higher bitrates, thus making the video looking "flat". Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile.

akupenguin
24th November 2004, 21:36
Originally posted by Tommy Carrot
Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile. Hopefully that will be addressed by H.264 high profile, which allows a transform more like ASP's DCT. No word on when I'll have time to implement it, though.

virus
3rd January 2005, 03:04
Hi,

seeing that the commandline encoder seems to have been updated recently, I decided to give it a shot. So I fed it with the simple cmdline:
x264 -o test.h264 foreman.yuv 352x288


and ended up with something like this in the output (I've replaced the ridiculously long overflowed numbers with the short "huge value" text...):

...
x264 [info]: analyse=76(2760ms) encode=0(10ms) write=380(0ms) filter=10(370ms)
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y: (huge value)
U: (huge value) V: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2372 PSNR Mean Y:-0.00
U: 0.00 V: 0.00 Avg: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice I Avg I4x4:319 I16x16:0
...

Houston we have a problem :)

Also, I'd like to know if there's a way to retain the "x264 [info]" output without the lengthy per-frame info labelled "x264 [debug]"; the option "--quiet" removes almost everything from the output. I don't see a "log level" option in the encoder (but I think there was one available in x264, or not?).

virus

akupenguin
3rd January 2005, 03:43
I reduced default verbosity to [info], and added a -v to put to back to [debug].

The messed up stats are probably a failure to recompile something after updating. I've never got annoyed enough at make to track down the problem, since jam works.

virus
3rd January 2005, 03:53
hey, that was quick :)

Thanks. As for the messed up stats, yeah, sometimes things gets screwed due to missing dependencies in the makefile, but not this time it seems: I've checked out a completely fresh copy of revision 81 and compiled it: the error is still present.

akupenguin
3rd January 2005, 04:48
Works For Me (tm).

virus
3rd January 2005, 06:05
No problem, I've already tracked the issue... this is the Week Of Programs That Break On My Machine Only. :D

It's the usual incompatibility introduced by Micro$oft in their msvcrt.dll implementation. Instead of using the ISO standard "%lld" prefix for 64-bit integers, they use their own "%I64"-based format. I use MinGW and it of course is forced to behave the same way to produce code that work on M$'s runtime libraries.

So, I changed line 1354 of /encoder/encoder.c to:
"slice %s:%-4d Avg QP:%5.2f Avg size:%-5I64u PSNR Mean Y:%5.2f U:%5.2f V:%5.2f Avg:%5.2f
Global:%5.2f MSE*Size:%5.3f\n",

Note the change in the "Avg size" field. Now the output looks OK, unless you're able to identify further problems that I currently don't see:
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y:41.08 U:44.10 V:46.82
Avg:42.08 Global:42.08 MSE*Size:0.844
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2680 PSNR Mean Y:37.78 U:41.72 V:44.64
Avg:38.93 Global:38.91 MSE*Size:0.345

I'm not sure what kind of defined symbol we need to test to fork between the 2 versions of the code, though. Any idea?

virus

akupenguin
3rd January 2005, 06:20
Interesting. I see several cases of %lld in MPlayer, and the official win32 builds use MinGW, and I haven't heard of this issue from there...

If this really is the problem, the easiest fix is to cast most of them back to int and use "%.0f" for the rest.

virus
3rd January 2005, 06:43
Well, it's quite possible that newer versions of Windows come with a more decent version of msvcrt.dll that supports the ISO format strings... but I have Win98SE here, and I guess nobody tests against it. You should just see the spectacular bluescreens that Videolan produces here when you try to play something ;)

Anyway, this is the note I have in /MinGW/include/inttypes.h:

/* 7.8.1 Macros for format specifiers
*
* MS runtime does not yet understand C9x standard "ll"
* length specifier. It appears to treat "ll" as "l".
* The non-standard I64 length specifier causes warning in GCC,
* but understood by MS runtime functions.
*/

It's MinGW 3.1.0, not exactly the very latest version but still a recent one.

virus

virus
3rd January 2005, 18:00
Yet another boring feature request :)

Can we have an alternative makefile added to the repository (named, say, "Makefile.nodebug" or "Makefile.release") without the -g option enabled in CFLAGS and with -s turned on? That gives much smaller filesizes for everything (up to 2.5x smaller)... it would be really handy imho.

virus

Yong
17th January 2005, 13:06
1. 4x4 B frame search will be possible in the future?
2. How many options will be available in the complete of x264 encoder?
3. It is possible adding adaptive quantization to x264 encoder?

(sorry for my crappy english and stupid questions):p
Thanks for the replies.:)
too bad, seems noone could answer my questions:devil:

IgorC
19th January 2005, 15:25
How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to bitstream?

bond
19th January 2005, 15:48
Originally posted by IgorC
How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to beatstream? http://forum.doom9.org/showthread.php?s=&threadid=86870

Sergejack
19th January 2005, 19:38
Is x264 limited when used in avi container ?

What are the best free and not free containers to use with x264 ?

bond
19th January 2005, 20:36
Originally posted by Sergejack
Is x264 limited when used in avi container ?depends
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames
b-frames is the only avc technology used till now in x264 causing problems with avi and vfw

apart from that .avi will limit the possible audio/subtitle formats

What are the best free and not free containers to use with x264 ?there is no best, it all depends on what you want to do
but i think x264 is atm already usable in .avi, .mkv, .ogm and .mp4, all of which are free (meaning licensefree and free tools are available for creation and playback)

len0x
19th January 2005, 21:04
Originally posted by bond
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames


This is worrying. Is there a detail explanation of why and when frames are lost?

bond
19th January 2005, 21:10
Originally posted by len0x
This is worrying. Is there a detail explanation of why and when frames are lost? its not really a problem (who cares about 2 of 200000 frames in a movie?)
its just the same old problem that vfw is simply not able to handle b-frames. there are workarounds for this for divx5 and xvid (but for not other codec) in virtualdub(mod) (but in no other vfw based encoding tool), its just that these workarounds are not that easily applyable for x264

also to show the importance of this problem: note that till the last update virtualdub 1.6 was buggy and didnt apply the b-frames fix when encoding with xvid and divx5 for some months, but noone realized it ;)

Sergejack
19th January 2005, 21:43
I'm soewhat totally confused.

If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?

bond
19th January 2005, 21:51
Originally posted by Sergejack
If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?the frames are lost "forever" if you use both together:
- sex264 in virtualdub(mod)
- b-frames

if you encode in mencoder with x264 the frames are not lost

len0x
19th January 2005, 22:01
Originally posted by bond
its not really a problem (who cares about 2 of 200000 frames in a movie?)


ah, you never said it was just two frames :)

bond
19th January 2005, 22:07
Originally posted by len0x
ah, you never said it was just two frames :) well i wrote "2 out of 200000" ;)

actually it depends on how many b-frames you use:
with 1 b-frame in a row you loose 1 frame, with 2 b-frames in a row you loose 2, aso...

len0x
19th January 2005, 23:17
Has anyone noticed this: when opening x264 encode (in AVI) in VDubMod via DirectShowSource and scrolling frame-by frame through it - every 5-10 frames you get out of order frame (i.e. a frame that was 2-3 frames back already) then it resumes normally (but frame that was supposed to be instead of dupe is lost though). However normal playback doesn't seem to have this issue.

p.s. ffdshow was used for decoding.

Bogalvator
20th January 2005, 02:33
What date is your ffdshow? Try again with the latest celtic_druid compile as it may have been an issue that has been fixed ;)

len0x
20th January 2005, 12:21
Indeed, I tried the build from 17th of Jan and its seems ok.

@bond

I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame).

bond
20th January 2005, 12:28
Originally posted by len0x
I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame)during playback you will not see it
also virtualdub will show the correct framenumber, thats because the missing frames are "zero length frames", frames that are marked like frames in .avi, but actually dont exist :D

if you extract the stream from .avi with mpeg4ips avi2raw you will see that it will report 1 zero length frame
also when you analyse the stream with mplayers analysing function you will see the same result

Sergejack
20th January 2005, 12:36
A question about the variability parameter :

Is it the variability of the bitrate ? In wich case set it to 100% should be a good thing assuming the RDO function is properly done.

Or is it variability of PSNR (or wathever metric measure the quality) ? In wich case, what should be tough of when setting this parameter ?

akupenguin
20th January 2005, 13:17
100% variability is equivalent to constant quantizer. 0% variability is CBR.
There are two factors stopping 100% from being the optimal setting: The human visual system (or at least mine) is less sensitive to errors in high-motion scenes. And the quality of one frame influences the quality of the following frames predicted from it. Neither of those can be determined by any normal RDO algorithm. I have found the PSNR-optimal setting to be around 70%, and the psy-optimal setting to be around 60%. But neither of those have been tested on enough full length movies to be really certain, so YMMV.

len0x
20th January 2005, 19:13
Question: how can IDR settings affect compressibility result when using snips of original source? Usually we have 14-frame snips so every 14 frames for XviD/DivX its guaranteed to be an I-frame (that was usually discarded from calcualtions along with last frame of the snip). Now I see that min IDR-keyframe interval is 25. Does this mean that you should no longer discard start/end frame of the snip or discard even more or change snip size to at least 25 to make sure I-frames are inserted only at the beginning of a snip?

Is this also dependent on max frames reference parameter?

akupenguin
20th January 2005, 20:31
What are "snips"?
What calculations are you discarding I-frames from, and why?

Note that min keyint does not prevent I-frames from occurring wherever they are appropriate, and increasing min keyint will never reduce compression, only seeking precision. (as long as there's plenty of space between min and max.)
Currently, min keyint only helps with multiple reference frames.

Manao
20th January 2005, 20:35
When computing the compressibility, GK uses an avisynth script, selecting 15 consecutive frames every 300 frames. Hence a tendency to put I frames every 15 frames, which makes them overnumerous, so their size must not be taken into account for the compressibility value.

akupenguin
20th January 2005, 20:40
For that purpose, you don't need to adjust snip size or calculations, and it doesn't matter what you set min keyint to. min keyint = 14 might be slightly faster.

len0x
20th January 2005, 22:01
Actaully everything matters. Let me explain: for compressibility test there are good frames (that contribute to more precise result) and bad frames (that contribute to less precise result). Basically the diffence is how close size of the frame during comp test to what would have been during actual encode. That's why I-frames in the beginning of snip are bad, because they are artificial (i.e. they would usually not be present in the actual encode).

Now, you were saying that min keyframe interval doesn't affect comp test. I was thinking that indeed keyframes are not inserted much more often than usual (if you have much lower snip size than min keyframe distance), however since every non I frame is a difference frame and snips are taken from different parts of the movie then there is bound to be a huge difference between last frame of one snip and first frame of next snip. Situation complicates even more if you have multiple reference frames (if I'm not mistaken ASP only can have one while AVC can have several, right?), because then not only first, but may be more starting frames will be dependent on frames from previous snip (situation that we try to avoid since it won't happen in the actual encode).

So in the end the most logical step would be to have snip_size=min_keyframe_diff. This will ensure that first frame of each snip will most probably be a keyframe, which you can ignore during calculations. I've done some tests and indeed it works! However the most presize result I get is when I don't discard any frames from the snip... (but this may be just a coincidence and source dependent).

P.S. this was all done without trying to use b-frames. It will get really crazy later on when they are taking into account :)

akupenguin
20th January 2005, 23:33
First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.
(The reason I don't just make all I-frames into keyframes is that in a full encode, the frames after a scenecut are not necessarily unrelated to the previous frames: if it cuts and then cuts back to the first scene, you save some bits by putting only non-key I-frames inbetween.)

It is true that you won't see the full benefit of multiple references on the first few frames of a snip, but even with lots of references it's probably not worthwhile to discard more than the first 2 P-frames.

Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).

With those points in mind, a snip size bigger than 15 is probably useful. But I can't suggest a new size without lots of tests. Personally, I just use 3-pass encoding, and then I know that the first pass is accurate, and get slightly better ratecontrol too. But I understand that some people are more interested in speed.

len0x
21st January 2005, 00:31
Originally posted by akupenguin
First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.


Thanks, good to know! Now I understand why it is imperative to make comp test with the snip size that equals min keyframe distance(and may be actual I-frames do not matter that much as all my tests so far were more precise when i didn't discard anything)

Originally posted by akupenguin
Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).


For XviD it was found to be better to discard first three and last three frames of a snip. I'll test that against x264 later on.

Originally posted by akupenguin
With those points in mind, a snip size bigger than 15 is probably useful.

Well, statistically the smaller the snip the better accuracy is, because snips cover the whole movie range more smoothly. But yes lots of tests are to be done... So far I found snip=14 without discarding any frames the most presize option when not using b-frames (and yes setting min keyframe interval 14 as well).