x264 development

[Revgen]

I've just downloaded the Amazon 1280x720 clip from the Microsoft site.

I've encoded 40 sec's of the clip at 1600kbps in both SP and HP and I still find no huge differences between the two profiles.

The only way I can still see any differences is by looking at two frames of each clip in Vdub.


That being said, the quality is still much better compared to xvid and divx.

I'm sure it will improve as you guys go further.

[cheburashka]

@akupenguin
Can you comment the last changes in x264 ?
r255 | pengvado | 2005-06-08 19:16:20 +0200 (Wed, 08 Jun 2005) | 3 lines

revert 216, another try at max_dec_frame_buffering.
disable adaptive cabac_idc by default; 0 is always best anyway.
I can't find anything in rev.216 about this.

Thank you

[akupenguin]

http://trac.videolan.org/x264/changeset/216
http://trac.videolan.org/x264/changeset/255

[Selur]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)

Cu Selur

[Manao]

It almost always help. It only doesn't when your video is almost not textured ( which happens when you blur it, or when it's a simpson-like cartoon ). Small-res videos tend not to be that much textured, but 'normal' resolution ( over 512xXXX ) should be detailed enough for high profile to be worth it.

[Sagittaire]

8x8dct help always in all situation (metric always better): if you make H264 encoding 720*576 q28 for average quant quality difference between MP and HP could be high but if you make H264 encoding 720*576 q20 for average quant quality difference could be little. IMO HP help very well like all advanced function ... for hard situation.

[Tommy Carrot]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)
Cu Selur
The improved efficiency of high profile is a nice addition, but imo the biggest advantage of 8x8 DCT is that it helps reducing the blocking artifacts (or at least makes them less annoying) quite effectively, when i encode something with disabled inloop-filter. Until now h.264 only gave acceptable quality with activated deblocking, and that more or less blurs the video. With 8x8 DCT, we can relatively safely encode without deblocking, so we can get sharper videos as result.

[Tima]

Sorry, I don't know how to tell it corectly..

When encoding 'Tonari No Totoro' ('My Neighbour Totoro') at 1175 kbps I get a lot of blocks in many scenes. Especially on areas with solid colour.

For example, in first scene when the cat bus arrives, there are VERY much blocks on Totoro's back (it's solid grey)..

The problem doesn't disappear even afer denoising (the source is noisy only a little, though). I tried FFT3D with different sigma and default settings of GK (little, medium and heavy)

I used x264 CLI rev 255, 255a (also tried 250, no diffecence) with such comandline:

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs

This result of encoding the full cartoon has this pb too..

Also I use the latest FFDshow (2005-06-09)

(sorry 4 my bad English)

[hpn]

You could also use "reference frames" and "adaptive spatial transform size", so add this to both passes:
--ref 5 --8x8dct

Also 200 frames maybe too little to allow the encoder to do its best, so try encoding at least 2000 (or more)

[Sagittaire]

lol ... you want no blocking why use inloop = -5 ... :confused:

the best setting with h264 is inloop = [-2;0] interval and certainely not inloop = -5 ... :search:

[Tima]

--filter 0:0
The result is nearly the same.

[Sagittaire]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...

H264 is a very good codec but not make miracle ...

[hpn]

the best setting with h264 is inloop = [-2;0] interval Is it --filter -2:0 or you mean something else?

This term "best settings" is so speculative, cause it depends exclusively on the source you encode. I dream of a tool that authomatically returns the "best settings" for a given bitrate by doing multiple short encodes with different predefined profiles (sets of settings) and probably comparing the resulting SSIM or PSNR, so I don't have to scratch my head trying to figure out what settings to use every time I encode a new movie :D

[Sagittaire]

0:0 is in practice always the best setting for OPSNR (perhabs not for SSIM). Inloop is adaptative: 0 for quant 25 is not the same deblocking strenght than 0 for quant 20. For low quant (high quality) inloop is in practice desactived. IMO if you want no problem then you must use the default setting for inloop ... ;)

[Tima]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...


No, the result is SMALLER (447 KB vs 1.15 MB).

Could you have a look at it?

http://nwfiles.gorodok.net/test.mp4 - --bitrate 1175

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs



http://nwfiles.gorodok.net/test_qp25.mp4 - --qp 25

x264 --pass 1 --bframe 3 --qp 25 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test_qp25.mp4 Project_unresized.avs

[Manao]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.

[Tima]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.
The pb is that my source doesn't have much noise. :) After basic denoising i can't see any noise at all..

But.. I encoded uncropped source. Could black border be responsible for these blocks?

[akupenguin]

The blocks on totoro's back are caused by noise. It's less visible before compression, but a good temporal smoother is the way to fix it.
Black borders don't directly cause blocking, but they do seriously hurt compression in general, so you'll see lower quants without the borders.
Likewise, multiple reference frames don't directly affect blocking, but they also generally reduce bitrate and thus allow more bits to be spent where they're needed.

[hpn]

Yes, just remove the black borders and you may get quantizers less than that on the screenshot (19). There is really some blocking on totoro's back, but the clip quality is pretty good overall
http://img12.echo.cx/img12/4117/199dq.jpg

[Sagittaire]

try higher inloop ... :devil:

IMO for particular source like anime you can use higher deblocking, inloop [2;4] is better and produce the same visual result than RV10 ...

[Tommy Carrot]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

[Sergejack]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

nevertheless inloop keep being usefull :p

[akupenguin]

Accurate deblocking: yes You have postprocessing enabled for h264 ?!

[Tommy Carrot]

nevertheless inloop keep being usefull :p
The fact that 8x8 DCT helps with disabled deblocking doesn't mean that it is not beneficial with activated inloop-filter as well, it should be in all circumstances.

[Maximus_G]

Sorry, i don't see any mencoder/mplayer thread whish is fresh enough.

When i'm trying to start mencoder from mplayer2005.06.09.P3 - i get an error message saying (it's not in english, so this is just a translation):
"Application could not be started, because pthreadGC2.dll could not be found. A new application install may solve this problem."

And Mencoder from mplayer2005.06.04.P3 works just fine. Just I8x8 high profile is unusable, because of inadequate version of mencoder.

Seems like a bug?

[Manao]

Maximum_G : the error message is clear enough. Download the missing dll, and place it in your path. That link (http://forum.doom9.org/showthread.php?t=92726&page=5&pp=20) should help you to find the dll.

[Maximus_G]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.

[celtic_druid]

Odd. x264 is using native windows threads and I don't remember enabling pthreads in mencoder. I'll have a look later.

edit: Ok, configure was updated to support mingw pthreads . Previously I had to manually enable it. As such since I had pthreads, it was autodetected.

[Sharktooth]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.
It's already there...

[hpn]

You have postprocessing enabled for h264 ?!
Actually I couldn't find a way to disable "Accurate deblocking". It's always "On" (Yes) on the OSD, no matter if I disable or enable postprocessing, but maybe I look at a wrong place or it should always be ON anyway:

http://img176.echo.cx/img176/9746/19b5vl.jpg

[bond]

i assume this refers to loop deblocking. why do you want to disable it?
and if you dont want it you have to disable it when encoding

[LigH]

Somehow it seems hard to distinguish the general DCT based deblocking functions (which shall be deactivated if H.264 video gets decoded) from the H.264 internal deblocking functions (e.g. inloop filter). Just for that reason, the current ffdshow has the long combobox in the lower right part, which allows to disable the usual DCT deblocking when H.264 is decoded, I thought...

[hpn]

I don't want it disabled (I don't even know what exactly it really does), but because akupenguin asked me a few posts above, I thought he was wondering why it's ON, not OFF in this particular case.

[celtic_druid]

Updated the VfW again.
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Added Me method, range and chroma me.

[Tommy Carrot]

Thank you, finally vfw is up to date again. :cool:

I found a small bug though, it seems to me that 8x8 transform is not applied on keyframes, if you could fix this, everything would be perfect. :)

[bob0r]

@celtic_druid

Looks great, x264 rev 260 updated your previous update.
Can you add ,Configure to the .dll?

With celtic_druid VFW still has a great future.... and so does cligui ;)

[celtic_druid]

Well, I'll finish up some stuff and then do a new diff vs. rev 260.
Also the 8x8 bug is as far as I know fixed.

Looks live Configure has been uncommented in the CVS anway.

[bob0r]

..
Looks live Configure has been uncommented in the CVS anway.

That's what i meant :sly:

[Sharktooth]

i submitted all patches i was using to create my builds, including the driverproc.def one (configure).
i confirm the 8x8 thing is fixed in rev260.

[celtic_druid]

Well under debug you can now change the log level to get stats on stuff like 8x8. Default is error.

I also moved fourCC there and put scene change threshold in its place.

Link is still the same: http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Diff file: http://mirror05.x264.nl/celtic_druid/test/x264vfwpatch.diff
I also updated the GUI: http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff

[bond]

http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff
thx a lot!
btw it seems there is a problem starting an encode right from inside the gui, because it seems that your build seems to assume that x264.exe is in the path c:\ and not in the folder of x264gui

edit: it seems this only happens when you load defaults (if you dont do it the encoding process starts fine)

btw: can you disable the debug mode by default plz

[LigH]

I like the new detailed GUI in rev. 260A!

I'm not sure what exactly you would like to have tested. But at least I was able to successfully encode a video (see the "Terragen" thread).

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.

[bob0r]

"btw: can you disable the debug mode by default plz"
My thoughts exactly :sly:

And about the x264.exe dir, i think its best to select where x264.exe is when you first run the gui (and after reset load defaults).

Then people know where the x264.exe is, and people know what and where they are working. More knowledge is more test results :)

[hpn]

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.
Actually it's not a real issue, just a warning. The Dub encodes at "Idle" priority by default, so it's very common to get such "not cycled for 10 seconds" messages, if you're doing other stuff with your PC. I often get these when compressing with winrar at the same time for example :)

p.s. The extended vfw dialog is awsome. celtic_druid rocks!

[LigH]

@ hpn:

But the warning list gets longer and longer if I don't close it. It seems to wait for a not correctly terminated thread, in my opinion. But it may be hard to determine the real reason.

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".

[hpn]

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".
I haven't tried it, cause I've never had such issue with GKnot and multiple passes, but maybe changing the Vdub default priority could help:
Vdub ->Options->Preferences->Process Priority (Norma or High) -> click "SAVE" (not Accept)

(OT here, but anyway)

[SeeMoreDigital]

The new GUI in build X264VFW_rev260A_mmx.exe looks okay: -

http://img172.echo.cx/img172/7416/x264newgui8td.gif

PAR signalling appears to work fine too.... I will do some more tests tomorrow ;)


Many thanks guys

[bond]

i think that "direct mode" and "weighted biprediction" should be grouped together with "b-frames". i dont think they belong to "analysis"

also i wouldnt enable everything by default, eg p4x4 is disabled in mencoder by default, after all enabling everything also slows things down
also i would disable the high profile features by default, cause they will definitely lead to interoperability problems (eg with quicktime). only people who know what they are doing should enable this

[Doom9]

btw, zones are still missing ;)

[Revgen]

I just encoded a Garfield and Friends cartoon episode from my DVD with all default options.

It plays fine in the latest version of FFDShow.