x264 development

[Sagittaire]

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks:

You can create artificial interlaced source (resize 1080p24 to 1080i12). It's really artificial but it's just test.

[IgorC]

You are sure?
Are you sure?


MSU say 40% in really best case (for Y-SSIM).
So, now it is 40% instead of your 25%.

x264 had 60% of the Xvid´s size for the same quality.
Also MSU hasn´t used the best settings for x264 to keep it fast.

http://compression.ru/video/codec_comparison/h264_2010/appendixes.html#Appendix_5

[Dark Shikari]

You are sure?

MSU say 40% in really best case (for Y-SSIM).

"Average relative bitrate for the same quality" is 100% for Xvid, 52% for x264, in the 2011 MSU comparison.

[CruNcher]

Btw MSU does someone knows how well x264 was in the HDTV test (i guess first place seeing the football results), and will the upcoming include MBAFF evaluation as well, i really wonder if we might see Ateme coming back also ;) ?

[Mini-Me]

7000 kbps again, but this time a slightly longer video (3235 frames @ 25.0 fps = 2:09.4 min), taken with a rather low-quality HD Cam, anamorphic 1440x1080i.

Content: Zooming and panning around a woodworking machine, sometimes with flying wood shavings and moving grippers

I will upload the original later, because FFMS2 is unable to decode that correctly, the video jumps forth-and-back... tests were run using DGAVCDec. | 96.5 MB (http://www.holzon.de/PRIVAT/holzon_k2.m2ts)

r1913 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677229 (14.911db) | PSNR Mean Y:43.647 U:49.150 V:49.665 Avg:44.835 Global:44.680 kb/s:7031.11 | 13.04 fps
r1913 I: final ratefactor: 16.90 | SSIM Mean Y:0.9747748 (15.982db) | PSNR Mean Y:44.853 U:50.153 V:50.603 Avg:46.030 Global:45.902 kb/s:7013.13 | 8.84 fps
r1995 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677235 (14.911db) | PSNR Mean Y:43.648 U:49.151 V:49.663 Avg:44.836 Global:44.680 kb/s:7031.35 | 13.10 fps
r1995 I: final ratefactor: 17.14 | SSIM Mean Y:0.9723570 (15.584db) | PSNR Mean Y:44.387 U:49.944 V:50.474 Avg:45.599 Global:45.455 kb/s:7031.06 | 9.95 fps

x264 revisions 1913 (TechARP HD Bench 4.0) and 1995 (currently available in MeGUI); "P" = progressive, "I" = interlaced (--tff); FRF from 1st pass, SSIM + PSNR + fps from 2nd pass. All runs with "--tune psnr".

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks:

The first impressions I've seen with my 480i VHS captures are similar to this: The new build is a little bit faster, but the compression ratio (metrics vs. bitrate) is actually a little bit worse (encoding pure interlaced material as interlaced). This is really surprising to me in light of the 10-15% improvement claims. I know nothing about encoding or the H.264 standard, but what confuses me is that x264 was always said to encode interlaced video as an MBAFF stream, just without implementing the "adaptive" part. In that case, I'm not understanding why the overhead/extra metadata wasn't already present in the output of previous versions.

Is this about as good as it's going to get (i.e. the old builds are better for some sources), or will the interlaced/progressive selection heuristics be tweaked to make better decisions?

[LoRd_MuldeR]

Mini-Me, how exactly did you measure "metrics vs. bitrate"? And did you use the appropriate tunes (e.g. "--tune psnr" for PSNR comparison and "--tune ssim" for SSIM comparison)? Also remember that "metrics" cannot predict "visual quality" very accurately. The effect of Psy-optimizations is the best counterexample (and the reason why Psy-optimizations must be off for PSNR/SSIM measurement).

[Sagittaire]

Mini-Me, how exactly did you measure "metrics vs. bitrate"? And did you use the appropriate tunes (e.g. "--tune psnr" for PSNR comparison and "--tune ssim" for SSIM comparison)? Also remember that "metrics" cannot predict "visual quality" very accurately. The effect of Psy-optimizations is the best counterexample (and the reason why Psy-optimizations must be off for PSNR/SSIM measurement).

MBAFF don't introcuce another psy-optimizations. "MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison: a pure architectural optimisation for interlaced source. You can certainely discut the PSNR-SSIM accurancy to visual quality. But for MBAFF you can use PSNR-SSIM to measure exact improvement.

[kieranrk]

"MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison

No it isn't.

[LoRd_MuldeR]

MBAFF don't introcuce another psy-optimizations.

Well, I didn't want to imply that there are new MBAFF-specific psy-optimizations. However x264's exiting psy-optimizations, which are known to optimize against SSIM/PSNR, will still be enabled by default. Consequently any SSIM/PSNR measurement done without "--tune ssim" or "--tune psnr" (or the corresponding options set manually) will be tainted. MBAFF or not.

"MBAFF vs PAFF" comparison is in theory like "CAVLC vs CABAC" comparison: a pure architectural optimisation for interlaced source. You can certainely discut the PSNR-SSIM accurancy to visual quality. But for MBAFF you can use PSNR-SSIM to measure exact improvement.

You can accurately measure the improvement of PSNR or SSIM, at a given (average) bitrate. But this doesn't say anything about how well this improvement in SSIM or PSNR correlates to the actual improvement in perceived quality. So one shouldn't blindly rely too much on these numbers...

[Sagittaire]

You can accurately measure the improvement of PSNR or SSIM, at a given (average) bitrate. But this doesn't say anything about how well this improvement in SSIM or PSNR correlates to the actual improvement in perceived quality. So one shouldn't blindly rely too much on these numbers...

MBAFF don't improve visual quality. MBAFF improve interlacing efficiency (like CABAC improve coding entropy efficiency if you compare with CAVLC). dev claim 15% gain for efficiency. For make this calcul dev simply compare bitrate reduction for the same PSNR-SSIM. Here it's just mathematic and it's easy to make direct comparison with and without MBAFF like it's easy to make comparison between CABAC and CAVLC (even if it's little more complex in reality because you have possible and particular pre-optimisation for CABAC and CAVLC compression)

[Dark Shikari]

Sagittaire is correct.

[LigH]

Unfortunately you can't optimize for both PSNR and SSIM comparison at the same time:

--tune <string> Tune the settings for a particular type of source
or situation
...
- psnr (psy tuning):
--aq-mode 0 --no-psy
- ssim (psy tuning):
--aq-mode 2 --no-psy
In my tests I preferred "--tune psnr"; still I reported SSIM values, but they are not accurate ... I believe, though, that their relation should be in a meaningful dimension.

[rallymax]

I've built x264 and ffmpeg hundreds of times from the checkouts but I can't get it to build right now.
I checked that ffmpeg (r26402) was installed to ../sharedbuild/include|lib and it is.
I can also confirm that HAVE_LAVF is on and it is pulling in the necessary header.... but it doesn't.
I can't work out for the life of me what's wrong.


/p/x264
$ uname
MINGW32_NT-6.1

/p/x264
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

/p/x264
$ ./version.sh
#define X264_VERSION ""
#define X264_POINTVER "0.115.x" (it's .1995)

/p/x264
$ head config.log -n 15
x264 configure script
Command line options: "--enable-debug" "--enable-shared" "--enable-static" "--enable-win32thread" "--prefix=../sharedbuild" "--extra-cflags=-I../sharedbuild/include" "--extra-ldflags=-L../sharedbuild/bin"

checking whether gcc works... yes
checking whether gcc supports for( int i = 0; i < 9; i++ ); with -std=gnu99... yes
checking whether yasm supports vpaddw xmm0, xmm0, xmm0... yes
checking whether gcc supports __asm__("pabsw %xmm0, %xmm0");... yes
checking for return log2f(2); in math.h... yes
checking for sws_getContext(0,0,0,0,0,0,0,0,0,0); in libswscale/swscale.h... yes
checking whether LIBSWSCALE_VERSION_INT >= AV_VERSION_INT(0,9,0) is true... yes
checking for enum PixelFormat pixfmt = PIX_FMT_YUV422P16LE; in libavutil/pixfmt.h... yes
checking for -lpostproc... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -Wall -I. -I../sharedbuild/include -march=i686 -mfpmath=sse -msse -std=gnu99 -lpostproc -L../sharedbuild/bin -Wl,--large-address-aware -o conftest

/p/x264
$ make
gcc -o x264.exe x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o input/lavf.o libx264.a -L. -lavformat -lavcodec -lavcore -lswscale -lavutil -lm -lavifil32 -lswscale -lavutil -L../sharedbuild/bin -Wl,--large-address-aware
x264.o: In function `print_csp_names':
p:\x264/x264.c:337: undefined reference to `av_pix_fmt_descriptors'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

[LigH]

Another test with a 7 minute TV report (containing interviews, TFT closeups, some CG, and semi-dramatical pans and zooms).

This time also with r1342 from the x264 HD benchmark v3.0; well, yes, it surely had different defaults, so don't compare between revisions too much, only between progressive and interlaced modes.

fps 1 fps 2 FRF 1 SSIM Y PSNR

r1342p 47.93 16.01 18.72 0.9774624 Y:43.689 U:46.320 V:47.125 Avg:44.424 Global:43.969
r1342i 43.03 11.81 18.39 0.9774914 Y:43.718 U:46.144 V:46.891 Avg:44.413 Global:43.989

r1913p 52.64 16.04 18.73 0.9778888 Y:43.791 U:46.322 V:47.123 Avg:44.507 Global:44.057
r1913i 47.66 11.10 18.38 0.9779887 Y:43.830 U:46.137 V:46.877 Avg:44.501 Global:44.105

r1995p 50.05 15.70 18.73 0.9778829 Y:43.790 U:46.320 V:47.124 Avg:44.506 Global:44.057
r1995i 41.76 12.94 18.34 0.9793411 Y:44.143 U:46.446 V:47.234 Avg:44.813 Global:44.398

Uuuhm ... :eek: -- now that looks like an efficiency boost! :cool:

[Phil_L]

Hi

I'm having issues with 2 pass encoding where in a couple of complicated scenes the bottom row of pixels around 30-50 in height are glitching every few seconds causing a sort of vertical stretching. This is repeatable every time. First noticed in a 20 minute film, and cutting and testing just the troublesome segments shows the same problem. The original footage has no problem.

The glitching is absent with ABR (single pass) encoding and only shows up on 2 (or 3) pass encodes. This is version 1995 but also affects version 1924, I've not tried other versions. The problem is also absent on a 2 pass encode with keyint set to 24.

Details:
AVI input via AVSynth script 1280x720 at 50fps encoding for Blu-ray 720p/50 on Windows 7 64bit but using the 32bit compiled x264. I've tried the compiled versions from www.x264.nl and from www.xvidvideo.ru, with the same results.

First pass:

x264.exe --bitrate 25000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000
--vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709"
--colormatrix "bt709" --sar 1:1 --pass 1 -o test.264 "test.avs"

Second pass:

x264.exe --bitrate 25000 --preset veryslow --tune film
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o test.264 "test.avs"

If I look at the output from the first pass no problem, but the output from the second pass has the issue.

If I can provide any more info let me know.

EDIT, looks like this problem is related to "Use MB-Tree", if I turn this off with --no-mbtree then 2 pass encodes stop having the issue. What is MB-Tree, is it required?

More info: Enabling mb-tree again the frequency of glitches is reduced with --qcomp set to 0.7 (from default of 0.6) and gone with qcomp set to 0.8, hopefully this info will help.

Regards

Phil

[CruNcher]

Another test with a 7 minute TV report (containing interviews, TFT closeups, some CG, and semi-dramatical pans and zooms).

This time also with r1342 from the x264 HD benchmark v3.0; well, yes, it surely had different defaults, so don't compare between revisions too much, only between progressive and interlaced modes.

fps 1 fps 2 FRF 1 SSIM Y PSNR

r1342p 47.93 16.01 18.72 0.9774624 Y:43.689 U:46.320 V:47.125 Avg:44.424 Global:43.969
r1342i 43.03 11.81 18.39 0.9774914 Y:43.718 U:46.144 V:46.891 Avg:44.413 Global:43.989

r1913p 52.64 16.04 18.73 0.9778888 Y:43.791 U:46.322 V:47.123 Avg:44.507 Global:44.057
r1913i 47.66 11.10 18.38 0.9779887 Y:43.830 U:46.137 V:46.877 Avg:44.501 Global:44.105

r1995p 50.05 15.70 18.73 0.9778829 Y:43.790 U:46.320 V:47.124 Avg:44.506 Global:44.057
r1995i 41.76 12.94 18.34 0.9793411 Y:44.143 U:46.446 V:47.234 Avg:44.813 Global:44.398

Uuuhm ... :eek: -- now that looks like an efficiency boost! :cool:

yep especially if you look @ the fps cost compared to paff its relatively low for the huge improvement :)

[Didée]

@Phil_L: You should show the Avisynth script, too. If it is "complex", and/or DirectShowSource is used, that could be the cause of the problem.

[Phil_L]

Hi

@Phil_L: You should show the Avisynth script, too. If it is "complex", and/or DirectShowSource is used, that could be the cause of the problem.

The Avisynth is really straight forward as the AVI is already in YV12 space and at 1280x720 @ 50fps

AVISource("source.avi", audio=false).AssumeFPS(50,1)


I've also tried the full HD file that is 1080/50p using the settings recommend for Blu-ray 50i and getting AVISynth to create 50i from 50p. I get the same problem on the exactly same scene when enabled for two pass, again it goes away disabling mb-tree or with mb-tree enabled and raising --qcomp to 0.8 the problem is gone, ABR (one pass encoding) is also glitch free but I assume that is because mb-tree isn't used.

It seems a very complicated scene causes the issue with mb-tree enabled, not sure what effect raising qcomp has but it also seems to fix it.

Regards

Phil

[LoRd_MuldeR]

Why do you need Avisynth at all, if you do not apply any filters? Can't x264 read your source directly, using FFMS2?

(BTW: You generally shouldn't overwrite "qcomp" manually. If you have problem with MB-Tree RC, you should provide a sample clip on which MB-Tree behaves bad)

[Phil_L]

Hi

Why do you need Avisynth at all, if you do not apply any filters? Can't x264 read your source directly, using FFMS2?

(BTW: You generally shouldn't overwrite "qcomp" manually. If you have problem with MB-Tree RC, you should provide a sample clip on which MB-Tree behaves bad)

Because the video is using the Lagarith codec, I don't think I could get that opened directly.

I'll sort out a sample clip and post where it can be found.

Many thanks

Phil

[nm]

Because the video is using the Lagarith codec, I don't think I could get that opened directly.

Libav/FFmpeg has a lagarith decoder these days and it's also supported by latest FFMS2 versions. Changelog (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-changelog.html) note:

FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)

[Phil_L]

Hi

Libav/FFmpeg has a lagarith decoder these days and it's also supported by latest FFMS2 versions. Changelog (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-changelog.html) note:

Experimental :confused: I'll stick with AVISynth as sometimes I need to do other things with the source.

I'm arranging a sample of the problem clip to be uploaded, who shall I PM with the link?

Regards

Phil

[MasterNobody]

Phil_L
We can't help you if you don't provide us with short source sample on which this problem will be reproducible.

[Phil_L]

Hi

Phil_L
We can't help you if you don't provide us with short source sample on which this problem will be reproducible.

As stated above I have now uploaded a sample, just wondering who I should send the download links to.

Regards

Phil

[MasterNobody]

As stated above I have now uploaded a sample, just wondering who I should send the download links to.
No need to PM, you can post it here. Short samples are fair use so I don't see legal issues. But if you so concerned about it, than at least PM link to me. But may be somebody other are also interested in sample.

[Phil_L]

Hi

No need to PM, you can post it here. Short samples are fair use so I don't see legal issues. But if you so concerned about it, than at least PM link to me. But may be somebody other are also interested in sample.

I've put a very short clip (to keep file size small) up in the link below. It shows the glitch when encoded using the commands below in order to create 720/50p for Blu-ray:

--bitrate 25000 --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 50 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o test.264 input.file

The first pass is glitch free, the second pass has the glitch, I get the second pass using the same but with --pass 2. There were two scenes this glitch occurred flicking throughout every couple of seconds.

Turning off mb-tree and there is no glitch on the second pass.

The short video clip is here (only a few seconds long), it is lagarith compressed 1280x720 @ 50fps: http://www.megaupload.com/?d=25TW03J3

A picture of how the glitch manifests itself: http://www.megaupload.com/?d=1ZY88FZU

Hope that helps.

Regards

Phil

[Dark Shikari]

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

[LoRd_MuldeR]

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

His source is mod16, so there shouldn't be any padding/cropping :confused:

[Phil_L]

Hi

That's not a glitch, that looks like your decoder not properly cropping the pixels used for padding at the bottom.

I have absolutely no issues if a use ABR and/or view the output of the first pass. It is only when the second pass is performed with mb-tree enabled this glitch appears and then it's only on two scenes in a 20 minute video, where those 'stretched' pixels flicker in and out continually across those two scenes. Both scenes I suspect are challenging the x264 as they contain lots of detail.

I don't see how it can be the decoder given the first pass is fine, would the decoder even know or care how many passes there were?

Something is troubling the 2 pass encoding in some complicated scenes by the looks of things.

I hope the developers can identify and fix it, the encoding is super quality otherwise.

Regards

Phil

[Didée]

It's still possible that the usage of MB-tree causes a frame access pattern that brings up a bug in Lagarith. Not necessarily, but possibly.

To rule this out, you should convert the whole clip to an uncompressed YCbCr avi file, then do the same 2-pass scenario with this uncompressed avi as input.
- Artifact gone => Lagarith is to blame.
- Artifact still present => x264 is to blame.

That easy. ;)

[MasterNobody]

Phil_L
I reproduced and hopefully fixed problem (it was problem with VBV and MinCR limit) with your short sample. Try this build (http://www.mediafire.com/?ibmrxzfu368y4s4) with longer sample and check that problem was really fixed.

P.S. Patch (http://privatepaste.com/3017602c58)

[Phil_L]

Hi MasterNobody

Tried your patched version and can confirm that the problem is gone. I've rendered both full scenes that had the glitches and they are perfect now:thanks:

Many thanks for the quick investigation and turn around.

Regards

Phil

[Phil_L]

Hi

Some slight bad news, I've since watched through the entire video I re-encoded and found the same glitches appear but now in a different scene (this scene was not affected originally), just a couple of flickers of the same repeated pixels at the bottom of the frame. I've tried to isolate just this clip and re-encode it again, however the glitch didn't repeat.

So some progress, it is definitely an improvement but perhaps it needs tweaking a bit more?

I get trouble free encodes if I disable mbtree, use only 1 pass, or up qcomp to 0.8. Not sure what is so troubling about my footage, perhaps it just contains a lot of detail being first generation from an HD camera?

Regards

Phil

[Dark Shikari]

Hi

Some slight bad news, I've since watched through the entire video I re-encoded and found the same glitches appear but now in a different scene (this scene was not affected originally), just a couple of flickers of the same repeated pixels at the bottom of the frame. I've tried to isolate just this clip and re-encode it again, however the glitch didn't repeat.

So some progress, it is definitely an improvement but perhaps it needs tweaking a bit more?There is no such thing as "tweaking". There is either a bug (it is broken) or it is fixed (it works). Your source is not at blame for magically creating a bug in x264, unless it has psychic powers and the ability to cause developers to make mistakes.

[jpsdr]

If problem is not reproductible with short clip, i'm afraid the only solution at this stage is to provide the full file to x264 developers and the exact precise command line you used for them to analyse and solve this problem, wich is somehow not little.
One possible thing also, you can try to get some previous versions here (http://x264.fushizen.eu/) (maybe 2 or 3 last versions), and test them to see if the problem is also occuring with them. It also can help x264 developers if you find out for exemple, that v1995 produce problem but not v1947.

[Dark Shikari]

If problem is not reproductible with short clip, i'm afraid the only solution at this stage is to provide the full file to x264 developers and the exact precise command line you used for them to analyse and solve this problem, wich is somehow not little.
One possible thing also, you can try to get some previous versions here (http://x264.fushizen.eu/) (maybe 2 or 3 last versions), and test them to see if the problem is also occuring with them. It also can help x264 developers if you find out for exemple, that v1995 produce problem but not v1947.This bug dates back 500+ revisions, so that's highly unlikely to be useful.

[Sagittaire]

AQ for x264 seem not really flexible. Some user (and some compressionist) report visible artefact in dark area for example even at very high bitrate.

I will try to write patch for AQ with same parameters than Mainconcept for have really flexible AQ:
- Complexity, strength [-100;+100]
- Luma, strength [-100;+100]
- Contrast, strength [-100;+100]

I think that these parameters will be more clear than actual AQ parameters. I think that I know x264 very well but I never understand how work the actual AQ. There are already patch for AQ here to have reference patch to work ... ???

[shon3i]

AFAIK x264 AQ is only Complexity mask, and lowering AQ on higher bitrates (which is probably recommended) will reduce that blocking, but sound to me is like Psy Trellis blocking. Anyway there is some OreAQ/MixAQ patches around there that use several AQ methods.

[Phil_L]

Hi

There is no such thing as "tweaking". There is either a bug (it is broken) or it is fixed (it works). Your source is not at blame for magically creating a bug in x264, unless it has psychic powers and the ability to cause developers to make mistakes.

Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

Phil

[Dark Shikari]

Hi



Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

PhilThere's absolutely zero chance the problem will be fixed unless you can provide a sample that triggers it.

Changing qcomp doesn't "resolve" anything; it's just throwing things at the wall in the hopes of fixing something unrelated.

Please post a sample that produces a problem with the patched build posted above, along with settings and so forth.

[MasterNobody]

Phil_L
If you can't provide sample than at least run this build (http://www.mediafire.com/?7zb5wda3g8z2947) with stdout redirecting to file (>log.txt) on your sample. And post resulted file with used command line.

P.S. Patch with debug info (http://privatepaste.com/692433d71e)

[Phil_L]

Hi

There's absolutely zero chance the problem will be fixed unless you can provide a sample that triggers it.

Changing qcomp doesn't "resolve" anything; it's just throwing things at the wall in the hopes of fixing something unrelated.

Please post a sample that produces a problem with the patched build posted above, along with settings and so forth.

I did provide a sample originally, however this is essentially uncompressed video and the recent glitch I couldn't get to happen on just a tiny sample and the whole video weighs in at 100GB. I would if I could :)


If you can't provide sample than at least run this build with stdout redirecting to file (>log.txt) on your sample. And post resulted file with used command line.


I will do this, might be tomorrow now.

Regards

Phil

[Phil_L]

Hi

A log is attached. I only seemed to get a log with the 2 pass, not sure if this is correct or not.

I checked the scene that showed the glitch last time but it hasn't appeared this time around, at least not at the same location. This might be because I've gone for medium speed to get this run through in a more reasonable time. If the log isn't of use let me know and I'll run a "slow" pass.

Command used:

--level 4.1 --preset medium --tune film --pass 1 --bitrate 25000
--stats "test.stats" --keyint 50 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --sar 1:1
--bluray-compat --open-gop --slices 4 --colorprim "bt709"
--transfer "bt709" --colormatrix "bt709" --output "test.264" test.avs > "log.txt"

Hope that helps.

Regards

Phil

[MasterNobody]

I checked the scene that showed the glitch last time but it hasn't appeared this time around, at least not at the same location.
Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

[burfadel]

Hi

Thanks for the reply. MasterNobody put a patched version here (http://forum.doom9.org/showthread.php?p=1504282#post1504282) that resolved the issues in the two scenes I'd seen it on. Unfortunately it cropped up on another scene when doing a full encode of everything.

I had thought changing qcomp to 0.8 resolved it also, this was certainly true testing just the problem scene, but on re-encoding the full project the glitches were back, just elsewhere, always in highly detailed scenes.

If it helps, the glitches only occur in scenes with lots of fine detail.

I've reluctantly gone back to using the Mainconcept encoder bundled with the software. There is something about the end result that just seems better with x264, so I will try again in a few versions time.

Regards

Phil

Have you tried AQ-mode 2 (Auto-variance AQ)?

[Dark Shikari]

Have you tried AQ-mode 2 (Auto-variance AQ)?AQ is unrelated to the problem.

[burfadel]

My mistake, in my haste I used the wrong quote. I was meaning to use this one:

AQ for x264 seem not really flexible. Some user (and some compressionist) report visible artefact in dark area for example even at very high bitrate.

I will try to write patch for AQ with same parameters than Mainconcept for have really flexible AQ:
- Complexity, strength [-100;+100]
- Luma, strength [-100;+100]
- Contrast, strength [-100;+100]

I think that these parameters will be more clear than actual AQ parameters. I think that I know x264 very well but I never understand how work the actual AQ. There are already patch for AQ here to have reference patch to work ... ???

Your statement probably still applies though! and I do realise aq-mode 2 isn't perfect either :) ...

[Phil_L]

Hi

Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

Thank you again, I will test the patched version out later today and let you know. I'll also check out those frames for the problem.

Regards

Phil

[jpsdr]

I did provide a sample originally, however this is essentially uncompressed video and the recent glitch I couldn't get to happen on just a tiny sample and the whole video weighs in at 100GB. I would if I could :)
Phil

Have you try to use losless codec ?
The both i know (maybe there is also others), wich are free, have a good speed, have YV12 support and exist in both x86 and x64 version are Lagarith and UT Video.
Lagarith produce a little smaller files than UT Video, but is slower. Nevertheless, it's speed is problably not a issue compared to speed of x264.
I don't remember precisely the size difference between both, but it was around 10%. Speed was more (100fps for UT Video vs 40fps for Lagarith on my PC on 1080p YV12 video).

[Phil_L]

Hi

Approximate locations of glitches are in frame number (not fully correct because this is stream order) after "2: " so for your log glitches are probably visible around frames 25882, 25930, 25977, 26027, 26077.
Anyway I seems to find real bug which caused all this. So this build (http://www.mediafire.com/?4561sk9w9b879fo) probably must work without this glitches.

P.S. Patch (http://privatepaste.com/4a040788ba)

Not good news I'm afraid. I've run through again using your latest version and logging the output and very similar debug output has been written to the log file, and at the locations of the frames indicated (which are pretty much the same as the first log) the glitches are there. The log file is pinpointing the problem frames pretty much exactly.

I've attached the second log, please note I cancelled the encoding once it was apparent there were glitches being logged again so it may not be as long as the first one.

The most recent exe I downloaded has hashes of:
MD4: 2dd29ea685ce5ca92a1998727abd5ca7
MD5: e2f366b83cc266fb790ec87c7394cfa0
SHA-1: fc630981abec36452526d2359300e3d159c7ccfe

This is different to the first EXE that contained logging, so I think I did get the newest one.

Regards

Phil