x264 development

[Sergejack]

When MAX-IDR keyframe interval is exceeded, what happen ?
Is the current frame just forced IDR ?


I think the MIN-IDR keyframe interval is weird; IDR should be used as soon as no previous references are used, it could be know after the first pass.


I still don't figure the real purpose of the internal deblocking filter, is it really safe to relly on that ?

[akupenguin]

Originally posted by Sergejack
When MAX-IDR keyframe interval is exceeded, what happen ?
Is the current frame just forced IDR ? Yes, though it rarely gets quite that far: The scene-cut detection threshold increases as it nears max keyframe interval, so it usually finds some not quite so bad match somewhat before the hard max.

I think the MIN-IDR keyframe interval is weird; IDR should be used as soon as no previous references are used, it could be know after the first pass. So many ideas, so little time. Yes, a 2 pass IDR decision is on the todo list.

I still don't figure the real purpose of the internal deblocking filter, is it really safe to relly on that ? Internal deblocking ends up with better quality than postprocessing, because it can use the deblocked version of each frame to predict the next frame. An encode with deblocking will always look better than an encode without, though some people prefer to turn down the deblocking strength somewhat (e.g. -3).

[len0x]

Suggestion: make stats file to be choosable in vfw interface. This will come very handy later on.

[virus]

Originally posted by len0x
Suggestion: make stats file to be choosable in vfw interface. This will come very handy later on.
that's already planned and will be in place soon ;)
(together with the ability of updating it during the 2nd pass, which effectively allows multipass)

[Elias]

When will the ffdshow filter contain an mp4 splitter?

[len0x]

First, VFW registry settings for min and max keyframes are swapped :)

Second, if you set min_keyframes = max_keyframes = N then I would have expected that every N frames I have a keyframe. But this is not respected and key frames are appearing anywere below every N frames.

[Sagittaire]

Originally posted by akupenguin
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.

yes ... H264 ateme too don't use 100% for RC variability.

IMO for RC-optimal variability the best metric is the Overall PSNR ...

[virus]

Originally posted by len0x
First, VFW registry settings for min and max keyframes are swapped :)
Indeed :)
Thanks for reporting it.

Second, if you set min_keyframes = max_keyframes = N then I would have expected that every N frames I have a keyframe. But this is not respected and key frames are appearing anywere below every N frames.
The intra frames you're seeing are probably I-frames, not IDR-frames. The option only affects IDR-frames.
Also, remember that even if I-frames are not guaranteed to be seekable when using multiple ref. frames, they are likely to be seekable anyway if they happen on a scenechange (usually in that case the frames before the I, even if kept as references, aren't actually used because they have totally different content from the ones after the I).
That means that often you won't be able to "see" a difference between an I and an IDR frame just by watching or seeking to them ;)

[CruNcher]

@Sagittaire

From my tests it seems to High encavc prefers more High Motion then Low Motion were x264 does it much better and then it makes no difference if you boost it with full tools or not it will allways look more bad then x264 in the end. Exactly that's the case i expierience now with a nice Low Motion/High Motion mixed up scene quant is +2 to high in the 2pass mode for the Low Motion part ABR does better on it, but i think you can imagine how it looks on the High Motion :P, but really the funiest thing is i boosted that Scene to the max PSNR wise it's alot higher then the x264 clip but visualy it looks bad no mater if i try normal, good, best or extra it allways stays behind x264 (minimal settings) in visual quality for the low motion part and this part is very long (conversation scene) before high motion gets in, to me it looks like every bit is pumped into the High Motion (the motion is so fast you don't recognize it) i hope babayagas new RC will yield better results with such a case in the future.

[len0x]

Originally posted by virus
That means that often you won't be able to "see" a difference between an I and an IDR frame just by watching or seeking to them ;)

I don't watch them...
VDubMod produces a log file with frame sizes along with information about which frames are key-frames (I don't think its about I-frames, but real key-frames that are going to be written in the seek table at the end of AVI file).

[virus]

Originally posted by len0x
VDubMod produces a log file with frame sizes along with information about which frames are key-frames
I fear VDub(Mod) has no clue about the difference between an I-frame and an IDR-frame... the same applies to players. For example you can see very nasty blocking artifacts in MPC if you seek to an I-frame when previous frames are effectively used as references.

From a practical standpoint an I-frame in H.264 is basically just a P-frame all made up of intra blocks, and should be handled like such.

[len0x]

Originally posted by virus
I fear VDub(Mod) has no clue about the difference between an I-frame and an IDR-frame...

Hm... what about seeking then? I assume that if I set minimum IDR distance I should not be able have seekable frames in between even if scene changes, right? Or you're saying that even if frame is not marked as key-frame by the codec, but writing application (like VDubMod) treats every I-frame as key frame and therefore puts them into container as keyframes anyway?

[virus]

Originally posted by len0x
Or you're saying that even if frame is not marked as key-frame by the codec, but writing application (like VDubMod) treats every I-frame as key frame and therefore puts them into container as keyframes anyway?
^^^^ This is what I'm saying. The application which handles the stream (being the encoding app or a player) needs to be aware that I-frames may not be seekable, and avoid seeking to them (or avoid marking them as keyframes when storing).

Instead I've been able to seek to such frames with MPC (AVI created with VDub) so I guess Vdub simply marks everything as keyframe. I'm not sure if VDub can be "fooled" in some way, making it think that I-frames are P-frames and thus avoiding the problem.

EDIT: looks like the VfW frontend already does the right thing (marks only IDR-frames as keyframes)

[len0x]

that's pretty sad considering lack of development of VDubMod :(

Just curious - how can vfw application get which frames are real key-frames from the codec?

[bond]

wouldnt setting the min IDR interval to 1 lead to that every i-frame becomes an idr-frame?
wouldnt that solve all the problems, but practically not allow reference frames to refer to frames before a scenechange (assuming that every scenechange starts with an i-frame), which practically wont happy often anyways?

Originally posted by akupenguin
(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.)but this is practically not relevant if you use small reference numbers, like 5, right? because hardly a switch between 2 scenes will take something like 5 frames

[virus]

Originally posted by bond
but this is practically not relevant if you use small reference numbers, like 5, right? because hardly a switch between 2 scenes will take something like 5 frames
AFAIK H.264 allows the use of long-term references - I think that means that the 5 frames are not necessarily the 5 frames before the current one, but they can be drawn from before almost arbitrarily. Of course, the codec must support the feature. (aku please correct me if I'm wrong :))

@len0x:
the codec uses a flag to mark the outcoming frame as keyframe and passes that to VDub; x264vfw already does that for IDR-frames only, apparently - but then I don't understand why you get IDRs closer than keyint_min :confused:

[bond]

Originally posted by virus
AFAIK H.264 allows the use of long-term references - I think that means that the 5 frames are not necessarily the 5 frames before the current one, but they can be drawn from before almost arbitrarily. Of course, the codec must support the feature. (aku please correct me if I'm wrong :))well might be, but practically when i choose 5 reference frames in x264, thats enabling using the 5 frames before the actual ones as reference
and with that, i think, my statement is valid

[len0x]

Originally posted by virus
the codec uses a flag to mark the outcoming frame as keyframe and passes that to VDub; x264vfw already does that for IDR-frames only, apparently - but then I don't understand why you get IDRs closer than keyint_min :confused:

Well, it might be a bug since I get this only when min_keframe = max_keyframe. The behaviour is correct when min_keyframe < max_keyframe (i.e. don't get key_frames closer than min distance).

[len0x]

Where is the revision log published I wonder? (i.e. what was commited)

[Tommy Carrot]

Originally posted by len0x
Where is the revision log published I wonder? (i.e. what was commited)
The changes of the new revisions are posted in the mailing list (here is the archive (http://www.via.ecp.fr/via/ml/x264-devel/) of it, although it lags behind with a few revisions), and you can follow the changes in the SVN too.

[len0x]

Well, I know that list, but it lags behind with 12 revisions now! :)

Is there a web frontend for SVN like for CVS?

[Tommy Carrot]

Originally posted by len0x
Well, I know that list, but it lags behind with 12 revisions now! :) If you subscribe to the list, you'll get the info about the changes immediately.
Is there a web frontend for SVN like for CVS?
http://developers.videolan.org/cgi-bin/viewcvs.cgi/?root=x264

[bond]

Originally posted by len0x
Is there a web frontend for SVN like for CVS? http://developers.videolan.org/cgi-bin/viewcvs.cgi/trunk/?root=x264 :)

[len0x]

Great! 10x

[Sirber]

Gonna put that on my site :D Thanks!

[Sergejack]

Isn"t VFW an outdated technology wich should be avoided ?

BTW : Is Mencoder relaying on another technology ?

[Sirber]

mencoder is not VFW. And yes, VFW is old and smelly, but everything still works with it. I saw some dshow codec, but it's not the same and not well supported.

[len0x]

VFW will be used until DShow version of VDub will be out (if ever). No codec will be popular in masses without VFW interface for the time being (heck look here - h264 was being developed for how long already? - yet only with VFW interface it's starting to kick in).

[len0x]

VFW GUI resets encoding type to constant bitrate no matter what was selected previously (saving works ok as I see correct value in the registry after I close codec settings).

[len0x]

I was looking at the stats file from the first pass and saw this:


in:0 out:0 type:I q:23.000 itex:43433 ptex:0 mv:12597 misc:250 imb:640 pmb:0 smb:0;
...
in:144 out:144 type:i q:23.000 itex:258490 ptex:0 mv:25100 misc:66 imb:640 pmb:0 smb:0;


What's the difference between type "I" and "i" ? :)

[virus]

Originally posted by len0x
VFW GUI resets encoding type to constant bitrate no matter what was selected previously (saving works ok as I see correct value in the registry after I close codec settings).
ehm, I encoded quite a bit with rev. 105 (and other people did as well) and nothing similar ever happened... anyway I recommend to completely uninstall revisions < 105 before installing 105 (or 106, which fixes the 2 swapped entries in the registry) and then immediately hit Load Defaults and OK to save the default settings in the Registry.

Updating by overwriting can lead to strange behaviour in VDub, apparently even if you hit Load Defaults (can't reproduce here, but at least 1 person reported so). The first time you load x264 in VDub weird things may happen and give you errors. So, better uninstall first ;)

[RadicalEd]

I think long term references were only introduced with high profile :O

[akupenguin]

Long term references are part of Baseline, even. They're just hard to use effectively.

[len0x]

Originally posted by virus
ehm, I encoded quite a bit with rev. 105 (and other people did as well) and nothing similar ever happened... anyway I recommend to completely uninstall revisions < 105 before installing 105 (or 106, which fixes the 2 swapped entries in the registry) and then immediately hit Load Defaults and OK to save the default settings in the Registry.


This doesn't help. Apparently some ppl have also some issues here:
http://forum.doom9.org/showthread.php?s=&postid=600067#post600067

My problem is very wierd because what I do in GK is:
- load saved settings from a registry file (if exists)
- launch config window via ICConfigure()
- save registry to a file

So the first time I launch settings (without restoring config) everything is just fine, but second time codec resets itself to CBR mode (although registry settings are correct!). This did not happen with rev 103. It almost looks like x264 fails to read registry because of shared access (tries exclusive access may be and fails because a lock from previous writing is not released yet) or something like that.

P.S. where can I get rev 106? It doesn't seem to be up anywhere...

[708145]

rev 106 is on my mirror.

http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/

bis besser,
T0B1A5

[celtic_druid]

Should be up here: http://www.aziendeassociate.it/cd.asp?dir=/x264 some time soon and it is already up here: http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/

The changelog by the way: registry values for min/max keyint were mixed up .

[len0x]

I've tested this VFW GUI reset problem with revisions 103, 105 and 106 and only 103 is correct. Something got defintely messed up in 105 when stats file path was introduced.

[Sharktooth]

106 is up in the main mirror

[CruNcher]

len0x i also have a problem now that i hadn't before sometimes the config window cant be accessed anymore it does not show up very strange, it looks like algern0n messed something up ;)

[virus]

I cannot reproduce that, but I will check the code again ;)

[len0x]

If you need help I can test any binaries as I have 100% reproducibility here :)

[Tommy Carrot]

Quoted from another thread:Originally posted by Sirber
x264 fails on my HDTV test encode at 1280x720. AVS2AVI gives me a nasty exitCode :confused: I've experienced the same with virtualdub. It seems x264 doesn't like a few resolutions, i've got crashes at 1280x720 and 768x576 too.

[Sirber]

ok, thanks. About the quote, I will use this thread instead :o

[niamh]

I can confirm what len0x said, I have the same issues here, with rev 105 (will try rev 106 now)

[Sirber]

How can I compile the source with studio? Last time I tryed I wasn't aboe to open the project file... I know, bouh sirber bouh!!! :devil:

[Sharktooth]

sirber: no need to compile with studio. pre compiled binaries (from Celtic Druid) are available here: http://celticdruid.no-ip.com/xvid/
Now the files are hosted on one of my server and the download speed is very good.

[len0x]

that's not fun :)
Not being able to play with sources - how sad is that? :cool:

[Sharktooth]

ehrrmmm...

[Sirber]

The point is not to get the binaries, it's to play with the source :o Any tutorial? :D

[hellfred]

Originally posted by Sirber
The point is not to get the binaries, it's to play with the source :o Any tutorial? :D
Why mess with MS if you can take MinGW. Just install current MSYS and MinGS, compile nasm and you are ready to take off.
In MSYS shell change into x264/build/cygwin and run make to build the libs and standalone x264.exe. Then go to x264/vfw/build/cygwin and run yet again make, followed by make install to install the x264vfw dll.
Never had problems with this approach :)

Hellfred