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

[jpsdr]

Patched x86 and x64 don't work.
Unpatched x64 work, but of course i've to remove the --fade-compensate option.

[JEEB]

Will see if I can see what's the reason. Have you tried with scripts that don't relate to Lagarith?

Anyways, what I can see being the problem:

Lagarith is having fun
L-SMASH or something results in it failing
Cosmic radiation


Am building a new build with an updated L-SMASH to see if I can re-create what is happening to you at all.

As for the audio error, it's fine. Happens every time you don't use the audio feature >_>.

Edit: Chikuzen had tested it with UTVideo and it seems to be fine. I'm running a test encode on 32bit build + avs at the moment myself. Thus I'm inclined to blame Lagarith.

[jpsdr]

I'm only using avi in lagarith YV12. Work fine with patched 1688 rack04 version...

[JEEB]

I'm only using avi in lagarith YV12. Work fine with patched 1688 rack04 version...
From the results so far I can see that most probably some part of the new code is just affecting Lagarith, and nothing else.

Until you tell me it breaks something else, my care levels will be very low to do something about it. Lagarith has been and still is a broken pile of balls, and it even has good alternatives nowadays (did I mention UT Video already from YV12 all the way to RGBA, or, you know, something that can be decoded by ffmpeg if you only need YV12?). Of course this isn't the best thing you could've expected, but unfortunately Lagarith just is what it is. Re-encoding those YV12 sequences into something else should've been your goal for a long time now, to be honest.

Of course, if you actually find that it breaks something else that I can do something about, do tell me.

[livetolove92]

This is my settings

And this my avs

This my log

I use the latest x264 1713, ffms2, megui, avisynth for x64.
I can't create the .stats file. x264 crash immediately when i run the bat.

Somebody helps me

[Guest]

Somebody helps me You have specified your stats file as ".stats". Try giving it a real name before the extension:

--stats "movie.stats"

[livetolove92]

still not work. But I can use the same command with FFVideosource instead of ffmpegsource2.
If I del --b-adapt 2 new issue happens
x264 [error]: timebase mismatch with 1st pass (1001/24000 vs 1/25). The source's fps is 23.976

Anyway, tks for your help ^^

[Guest]

You still get the --stats error when specifying a proper filename? Or are you reporting a new error?

[livetolove92]

I still get the --stats error when specifying a proper filename. x264 crash immediately when I run the command. But if I replaced ffmpegsource2 by FFVideosource in avs it works correctly.

[jpsdr]

Lagarith has been and still is a broken pile of balls, and it even has good alternatives nowadays (did I mention UT Video already from YV12 all the way to RGBA, or, you know, something that can be decoded by ffmpeg if you only need YV12?).
Of course, if you actually find that it breaks something else that I can do something about, do tell me.

When i was looking for a lossless YV12 codec with keyframe only, i only found lagarith (or found maybe 1 or 2 others, but toooo slow), and, as it was working fine until now, i didn't see the point of changing.
Now, i didn't know UT Video, i've just take a look, and i'll give a try. Seems interesting, as you can also say if video is interlaced or not.

I'll tell you my results.

Edit : Works fine with UT Video. Thanks.

[livetolove92]

You still get the --stats error when specifying a proper filename? Or are you reporting a new error?

I have fix it. It sucks. I just add 2>log1.txt to pass 1.

[easyfab]

For OSX,
A) install Xcode - it's on the OSX install disc or through Apple Developer Connection.
B) Install MacPorts (by following Parts 1 & 2 from http://davidbaumgold.com/tutorials/wine-mac/ - although if you want to go on to install wine feel free to).
C) Use MacPorts to install subversion, git-core, yasm, nasm, texi2html, automake, autoconf, libtool, pkg-config (might already be installed through Xcode...I can never seem to remember this), and I think that's it.



svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffms2
git clone git://git.videolan.org/x264.git

cd ffmpeg
./configure --prefix=$HOME/ffms2_build --enable-gpl --enable-version3 --enable-postproc --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--extra-cflags="-march=pentium3"
make
make install

cd ../ffms2
./configure --prefix=$HOME/ffms2_build PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig
make
make install

cd ../x264
wget http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff
patch -p1 < mp4muxer.diff
PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --extra-cflags="-march=pentium3"
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-9bit \
--extra-cflags="-march=pentium3" --bit-depth=9
make
make install
make distclean

PKG_CONFIG_PATH=$HOME/ffms2_build/lib/pkgconfig ./configure --prefix=$HOME/x264-10bit \
--extra-cflags="-march=pentium3" --bit-depth=10
make
make install



All -march=pentium3 parts should be changed to the processor you actually have; refer to GCC's documentation for that list (http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html)...-march=native could also be used if you'd rather not take the time to target your cpu explicitly and let GCC autodetect it.

The MSYS/MinGW instructions are pretty much identical to those - the only place they differ are that ffmpeg requires two additional options: --enable-memalign-hack and -U__STRICT_ANSI__ needs to be added to the cflags, like --extra-cflags"-U__STRICT_ANSI__ -march=pentium3".

EDIT: I forgot...I have read reports that ffmpeg won't build under Snow Leopard unless --disable-asm and --arch=x86_64 are also given. I'm not entirely sure because I can't remember if I've ever built without those options, so be aware of that as well.

Thanks qyot27 , very useful.

FFmepg/lavf build is now Ok and LAME, FAAC too
but not FFMS2 r331 I got compile error mesage ( pthread problems ) ? I use Komisar pthreads 2.9.0.0 GC-static
build for info .

But it's ok I can build x264 audio with mp3 and faac .

Here is my build (based on the experimental silverfilain-x264 source ) if someone want to try.

Link removed as request

I think It's only working with mp4 muxer and sometimes audio is not sync but it give a good overview of futur x264 with audio encoder.

Let play with it if you want :)

[Chikuzen]

@easyfab
Please don't distribute the binary that links libfaac.
Distributing the binary that links libfaac undertakes the violation of the license since it contains a lot of codes of the reference encoder(GPL incompatible).
(I proposed that add "--enable-nonfree" in the configure, and it was approved. )

[tormento]

I am currently suffering of macroblock and fluctuations in dark areas. I read there was a patch, called AQ patch, created to alleviate this problem.

Is it implemented on current tree or is there a newer, better, one?

[nurbs]

There are currently 2 different AQ modes in x264 and the first one is activated by default. I haven't heard anything about a new patch. The last change to AQ was at the beginning of this year IIRC. If you use low bitrates the blocking is in some cases very hard to get rid of, especially when the picture is dark and contains fog or smoke.

[tormento]

There are currently 2 different AQ modes in x264 and the first one is activated by default.
Where can I find syntax/switches?

Thanks.

[nurbs]

x264 --fullhelp

Same as always.

[Chikuzen]

I am currently suffering of macroblock and fluctuations in dark areas. I read there was a patch, called AQ patch, created to alleviate this problem.

Is it implemented on current tree or is there a newer, better, one?

I think that it is Haali 's AQ Pathch that you look for.
Haali's AQ is older than VAQ, and the one to do working that lowers QP in dark and blue points.
(because HAQ doesn't decrease bits at all unlike VAQ, the filesize will be increased if you use.)
The patch is still maintained by VFR maniac (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/), and includes his "MixAQ build".

[rack04]

I have compiled x86 and x64 builds of x264 r1834 for the sole purpose of performing your own speed tests relating to threading.

x264_r1834_x86-x64_posix (http://www.mediafire.com/?scnu6p8jkx6a168)

x264_r1834_x86-x64_win32thread (http://www.mediafire.com/?dtxfrwwjdlcdw52)

My results:

CPU: Intel Core2 Duo T7250
OS: Windows XP Professional SP3

x264_r1834_x86-x64_posix
encoded 2595 frames, 32.84 fps, 429.02 kb/s

x264_r1834_x86-x64_win32thread
encoded 2595 frames, 33.86 fps, 429.02 kb/s

[soneca]

Hi, rack04
Here the difference was much smaller.
Using RipBot264...

CPU: Intel i7 980x
OS: Windows 7 Ultimate 64bit

x264_r1834_x86-x64_posix
encoded 47162 frames, 95.40 fps, 3033.76 kb/s

x264_r1834_x86-x64_win32thread
encoded 47162 frames, 95.66 fps, 3033.76 kb/s

[kemuri-_9]

it should be noted that for those that are doing comparisons of pthread-win32 threading against native windows threading that the windows threading takes different codepaths depending on the version of windows:
A) 2000/XP
B) Vista/7/(anything beyond this)

as such, comparing pthread-win32 against win32thread should take this into account.

[aegisofrime]

Any improvement no matter how small is welcomed :)

Thanks rack04 for the 64-bit builds. Neither x264.nl nor fushizen has them yet.

[LoRd_MuldeR]

it should be noted that for those that are doing comparisons of pthread-win32 threading against native windows threading that the windows threading takes different codepaths depending on the version of windows:
A) 2000/XP
B) Vista/7/(anything beyond this)

as such, comparing pthread-win32 against win32thread should take this into account.

May I ask: What was the main motivation to implement support for native Win32 threads? Speedup? Getting rid of pthreads?

[kemuri-_9]

May I ask: What was the main motivation to implement support for native Win32 threads? Speedup? Getting rid of pthreads?

pthread-win32 is LGPL, this causes a conflict with --disable-gpl x264 builds.
it was not done for performance reasons.

though since we were doing it, might as well use windows for all its worth when it's available (for vista+ platforms) so there might be a very small performance increase there.


the windows threading might be more important later when support for windows 7 x86_64's (and similar/later x86_64 platforms) way of handling systems with over 64 logical cores is added
(yes, microsoft totally made things a bit odd to extend support to 256 logical cores on the x86_64 systems starting with 7/server 2008 R2).

[Dark Shikari]

pthread-win32 is LGPL, this causes a conflict with --disable-gpl x264 builds.No it doesn't. Even a commercial x264 can link fine with LGPL libs.

It caused a conflict with a customer who didn't like LGPL libs ;)

[upyzl]

Excuse me, is it still worth patching ME-prepass(#5 (http://forum.doom9.org/showthread.php?p=1050161#post1050161)) now? (or can the patch be available now? Of course manually -- ignore patch's line numbers)

Because of large changes in x264, I want to patch it myself manually

[upyzl]

...and another question

Is ME prepass patch (rev 680, #1 (http://forum.doom9.org/showthread.php?t=130364)) the latest?

[Kurosaki Ichigo]

Hi there, I'm new. I don't know if I'm writing in the right place. I have a problem with Lagarith Lossless Codec. I tried the 1.3.2.0 version and the last 1.3.2.5, but when the process finished, the output file is too small

This is the source RAW

General
Unique ID : 235762869933910293037496416019526284763 (0xB15E46EFE5A7B520951159776D4175DB)
Complete name : J:\[IM9 & FTF] RAW Anime\Freezing\[Yousei-raws] Freezing 01 [BDrip 1920x1080 x264 FLAC].mkv
Format : Matroska
Format version : Version 2
File size : 2.26 GiB
Duration : 23mn 41s
Overall bit rate : 13.6 Mbps
Encoded date : UTC 2011-04-02 07:30:50
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') сборка от Mar 10 2011 02:50:32
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 41s
Nominal bit rate : 12.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.259
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=0.90:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=12860 / ratetol=1.0 / qcomp=0.65 / qpmin=9 / qpmax=32 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=27000 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.90
Language : Japanese

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 41s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese

And this, the output with Lagarith, in Full Processing Mode:

General
Complete name : J:\Freezing 01.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 37.5 GiB
Duration : 23mn 41s
Overall bit rate : 226 Mbps
Writing application : VirtualDubMod 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release

Video
ID : 0
Format : Lagarith
Codec ID : LAGS
Duration : 23mn 41s
Bit rate : 226 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.552
Stream size : 37.5 GiB (100%)


For what I know about Lagarith, this file size is too small. I don't know if I missed something when installed it. I have the last version of K-lite codec pack for 32 bit, on Windows 7 32 bit without SP1. Anyone Have an idea?

[Guest]

@Kurosaki Ichigo

Please read and follow forum rules, especially rule 6 regarding downloaded files, torrents, etc. Further violations will incur strikes.

@all

No help on this. Thank you.

[Kurosaki Ichigo]

I get it for rule number 6. I'll pay attention in future! ^^ Thanks anyway...

[Guest]

Thank you for your understanding.

[Kurosaki Ichigo]

Don't say it! It's a rule, it's just normal! ^^

[RipFan]

Thanks for all the information and effort.
I have only one question, I use Megui 2624 (latest version) downloaded x264 2638 Kmod and replaced it by the "x264_64.exe" that was placed inside megui folder "tools".
My question is: to use a fade_compensate CLI do I have to download the patch as well?
If the answer is yes, where do I have to place this Patch?

Best regards and many thanks once again

[sneaker_ger]

The patch file (.diff) is not needed, that's just what the kMod creator used to build x264.exe from.

[RipFan]

The patch file (.diff) is not needed, that's just what the kMod creator used to build x264.exe from.

Thanks a lot, just what I nedded to know:thanks:

[benwaggoner]

That said, it's been about 8 years since the first post was updated. It'd be nice to have a current version of this thread with up-to-date info.