Current Patches, Where to get them, How they affect speed/output

[gav1577]

Originally Posted by skystrife

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

Ok thanks BTW previous versions work fine with the source sample

[gav1577]

Originally Posted by skystrife

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

EDIT: With your source something definitely borked. I don't know what.

If thats the case how come previous builds work fine ? source is cut from original blu ray. Do you have the same problem with older builds?

[kemuri-_9]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

[skystrife]

Originally Posted by kemuri-_9

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

Well even then, if the avs is playing fine when I preview it in MPC it shouldn't be doing anything like this when I encode it, right?

(Also, in case my EDIT2 was missed, both Ranguvar and my builds are affected, so beware for bugs in both.)

[gav1577]

Originally Posted by kemuri-_9

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

same outcome from FFmpeg r14675 when muxed to mkv havent tried DGAVCIndex yet


Thanks for confirming skystrife

[skystrife]

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

[gav1577]

Originally Posted by skystrife

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

Same here i tried everything i could think of before i posted

[kemuri-_9]

well i tried working at it and in different players, the frames were definitely miscolored, so maybe one of the new updates had a regression where the chroma gets corrupted.

tried on something else and got similar massive corruption.

when reverting back to my r956 build, there were no problems.

[gigah72]

Originally Posted by gav1577

Im having serious visual problems with this build can some one confirm /reproduce ?

--pass 1 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --direct auto --subme 1 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

--pass 2 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "C:\Documents and Settings\me\Desktop\123.mp4" "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

megui profile HD AVCHD Source sample logs avs provided below Thanks
http://www.mediafire.com/?sharekey=3...db6fb9a8902bda

screen shot of output

now with 964 i get the same nice green with my mpeg2source sample and crf settings??
957 works fine.

EDIT:
coreavc in mpc decodes the broken scene, powerdvd in mpc just skipps over the broken scene...
maybe this does say something to someone?

EDIT2:
964 broken: http://www.mediafire.com/?i9h3tshdlcs
957 ok: http://www.mediafire.com/?1llhbmrsjdy

[kemuri-_9]

i went through git revisions one by one starting from r958 to find which one caused the problem...

revision 963 caused the problem, meaning from r962 to r963, the problematic code occurs.

[Dark Shikari]

Originally Posted by kemuri-_9

i went through git revisions one by one starting from r958 to find which one caused the problem...

revision 953 caused the problem, meaning from r952 to r953, the problematic code occurs.

Huh? That doesn't even make sense... r953? Are you sure you don't mean r963?

Anyways, this seems odd because I ran all of these patches through a huge slew of regression tests, and posted the patches in #x264 IRC, where another few people ran them through all of their own regression tests and confirmed that they worked flawlessly...

[kemuri-_9]

yeah, typo on my part.... (i blame the fact that it is 2am)
cherry picking from 962 to 964 also has no problems.

[Dark Shikari]

Indeed, there was a subtle test case in which it failed (a very rare one which almost never crops up... almost) and thus slipped past our regression tests.

Thanks for the report, fixed in r965.

[Soichiro]

I can confirm that there's an issue in r963. Horrible blocking shows up in the encode, which I've run 3 times now. It's not there in the source, I'm 100% certain, and it's not an avs filter.

Actually, I guess I'm late since it's fixed now.

[Ranguvar]

Home

Direct download, Mirrors

x264 r965 from Git (patched, fprofiled).
Compiled by Ranguvar on September 6th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use. 
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use them 
(NOT for AviDemux - get those from LoRd_MuldeR).

Git:                                git://git.videolan.org/x264.git
Info, and source tarballs:          http://www.videolan.org/developers/x264.html
Changelog:                          http://git.videolan.org/gitweb.cgi?p=x264.git          
Vanilla builds:                     http://x264.nl/
Discussion:                         http://forum.doom9.org/forumdisplay.php?f=77
                                    http://forum.doom9.org/showthread.php?t=130364


Applied patches (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -i ../x264diffs/x264_psy_rdo_0.6_r956.diff
patch -p1 -i ../x264diffs/x264_new_bframe_decision_04.7.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
                    make fprofiled VIDS="../enctests/deadline_cif.y4m"

Platform:   X86
System:     MINGW
asm:        yes
avis input: yes
mp4 output: yes
pthread:    yes
gtk:        no
debug:      no
gprof:      no
PIC:        no
shared:     yes
visualize:  no

[Comatose]

Originally Posted by Soichiro

I can confirm that there's an issue in r963. Horrible blocking shows up in the encode, which I've run 3 times now. It's not there in the source, I'm 100% certain, and it's not an avs filter.

Actually, I guess I'm late since it's fixed now.

Yeah, umm, I've had two encodes go bad now =\ (r964)
Completely different source too, one anime and the other a 3D game D:

I shouldn't have downloaded a new compile D:

[Snowknight26]

Ranguvar, would be nice if you included pthreadGC2.dll in your build.

[Ranguvar]

I do. It's merged into the EXE. You don't need a separate one. If you just want it for something else, Google and download.

[techouse]

Ranguvar:
I guess you got GCC-4.3.2 from TDM's website and have overwritten all your old files with the new ones from TDM's zip/tar.gz packages. The problem is that the gcc-4.3.2-tdm-1-core.tar.gz package includes pthreadGC2.dll and pthreadGCE2.dll in its /bin folder, libpthreadGCE2.a, libpthreadGC2-static.a and libpthread.a in its /lib folder and pthread.h, sched.h and semaphore.h in its /include folder. You probably copied over those files to your MinGW /bin, your MinGW /include and your MinGW /lib folder folder.
I suggest you remove all these files, get the latest pthread cvs (cvs -d server:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads), compile (make clean GC-static) and install it (copy libpthreadGC2.a to your MinGW /lib folder and copy pthread.h, sched.h and semaphore.h to your MinGW /iclude folder). That way you will eliminate the need of x264.exe for an extra pthreadGC2.dll in C:\Windows\System32.
Trust me on this one, I had the same problem.

I also suggest you people update your GPAC libraries. Many have reported errors building it from CVS, however I have found a nasty trick that actually works:
1. download the old stable tarball from here http://downloads.sourceforge.net/gpa...4.4-rc2.tar.gz
2. once it is downloaded, extract it to your MSYS /home/username folder and cd into it (i.e. cd /home/username/gpac)
3. while inside the gpac folder get the latest GPAC CVS using the command cvs -z3 -dserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
4. run ./configure && make lib
5. copy /home/username/gpac/include/gpac to your MinGW /include folder

P.S.: If this doesn't work for you try it in your /home folder (i.e. /home/gpac).

[chriszxl]

Originally Posted by gigah72

now with 964 i get the same nice green with my mpeg2source sample and crf settings??
957 works fine.

EDIT:
coreavc in mpc decodes the broken scene, powerdvd in mpc just skipps over the broken scene...
maybe this does say something to someone?

EDIT2:
964 broken: http://www.mediafire.com/?i9h3tshdlcs
957 ok: http://www.mediafire.com/?1llhbmrsjdy

ya...me too...serious bug...