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

[Blue_MiSfit]

If you're going to TempGaussMC a 1080i source, for god's sake save it at crf 12 or some equally high bitrate mezzanine file. Don't let that HUGE amount of time to go to waste. Srsly.

Derek

[mp3dom]

Sorry to ask, is there a recent (1629) patched version based on the plain vanilla build + only the fade improvement patch?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23548 and libswscale SVN-r31351 (http://www.multiupload.com/4TQNG2JECT)
ffms2 SVN-r312 (http://www.multiupload.com/VDKSOX6M2Y)
x264 Builds:

x264_x64_r1643M (http://www.multiupload.com/FYPUE1NSNC)
x264_x86_r1643M (http://www.multiupload.com/7XE5S8YUR3)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast (http://pastebin.com/EVSqTqAi)
x264.open_gop.28 (http://pastebin.com/suAVft2F)
x264_fade_compensation (http://pastebin.com/WGEapT1e)
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

[mp3dom]

Thanks rack04!

[outlaw.78]

x264 0.98.1643M x86 & x64 (http://www.mediafire.com/?mmufji2y2nj)

gcc 4.5.1 20100523 prerelease
ffmpeg svn 23555
swscale svn 31357
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1643M x86,x64,amdfam10,fprofiled
patches used :
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

[RainyDog]

x264 0.98.1643M x86 & x64 (http://www.mediafire.com/?mmufji2y2nj)

gcc 4.5.1 20100523 prerelease
ffmpeg svn 23555
swscale svn 31357
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1643M x86,x64,amdfam10,fprofiled
patches used :
x264_thread_pool_v2.9 (http://pastebin.com/9MMaKDER)

Thanks Outlaw, been waiting for one of your new amdfam builds :)

[tormento]

komisar: waiting for your build... braaaaiiinnn...

[outlaw.78]

x264 0.98.1649M x86 & x64 (http://www.mediafire.com/?xkluikx3jiu)


gcc 4.5.1 20100614 prerelease
ffmpeg svn 23619
swscale svn 31428
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.98.1649M amdfam10,fprofiled,LTO
patches used :
x264_thread_pool_v2.9 (http://komisar.gin.by/old/1643/p/x264_thread_pool_v2.9.r1643.diff)

[rack04]

I'm trying to compile the latest x264 with x264_open_gop_40. Each time make fprofiled finishes with one of the encodes I get a crash with debug screen. If I click debug the next encode runs. I'm wondering if anyone else has experienced this.

BTW, I'm using cross-mingw.gcc450.generic.20100612 (http://komisar.gin.by/mingw/cross-mingw.gcc450.generic.20100612.7z) without LTO.

[bnshrdr]

I just used the same compiler as you posted and with x264 patched and it seems to be working ok (I'm only about 5 encodes through in fprofile). I'm targeting x86_64-mingw32.

Would it matter what clip you use to fprofile? If it means anything, I'm using 720p5994_stockholm_ter.yuv

[komisar]

rack04, gcc 450 and 451 broked... :( dont use it (i am remove link from my site)

EDIT: but wait... 450 is normal compile... (recheck again...)

[rack04]

rack04, gcc 450 and 451 broked... :( dont use it (i am remove link from my site)

EDIT: but wait... 450 is normal compile... (recheck again...)

make fprofile i686-pc-mingw32? cross-mingw.gcc444.generic.20100506 works fine.

[bnshrdr]

Ok, I can confirm your error when targeting i686-pc-mingw32, but the fprofile seems to be fine when targeting x86_64-pc-mingw32

[komisar]

rack04, no... for 32-bit gcc450 also broked...

As BugMaster investigate this problem: "found that gcc can produce code with missaligned SSE (MOVAPS) access when -fprofile-generate used"
Need rebuild toolchain with "-fno-tree-vectorize" (as DS say)

EDIT: or wait gcc451 release ;)

[bnshrdr]

DOWNLOAD: x264_r1649 (http://www.mediafire.com/download.php?finamqymnzw)

Builds Included:
x86 Generic
x86 Patched (patch listed below)
x86_64 Generic
x86_64 Patched (patch listed below)

Libraries:
gcc 4.4.4
zlib-1.2.3
bzip2-1.0.5
pthreads 2.9.0.0 GC-static
ffmpeg-svn: FFMPEG-r23763/SWSCALE-r31555
yasm-svn: YASM-r2334
ffmpegsource-svn: ffmpegsource-r312
gpac-cvs: gpac-0.4.6-DEV

Patches:
ffmpeg_patch (http://pastebin.com/WbVwYT0z)
applied with patch -p0 -i ffmpeg_patch.patch
x264_thread_pool_v2.9_updated (http://pastebin.com/gANSYv4i)
applied with patch -p0 -i x264_thread_pool_v2.9_updated.patch

[lexor]

@bnshrdr: is that x264_thread_pool patch something different from the thread pool incorporated into the official git repository? I know there was a thread pool patch before git had thread pool support, but now that git has it, why is there still a patch for it?

[sneaker_ger]

bnshrdr's build is revision 1649 which didn't have the commit. The newest version is 1659.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
x264 Builds:

x264_x64_r1659 (http://www.multiupload.com/H1IYWFR5WM)
x264_x86_r1659 (http://www.multiupload.com/4BYZMQV7UI)
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[lexor]

bnshrdr's build is revision 1649 which didn't have the commit. The newest version is 1659.

Is there a way to get revision # from git's web ui? I usually check http://git.videolan.org/?p=x264.git;a=shortlog, but it's hard to tell who's builds have which submissions in them, atm.

[Chikuzen]

Is there a way to get revision # from git's web ui?

I always look x264.nl's changelog.
http://mirror01.x264.nl/x264/changelog.txt

[LoRd_MuldeR]

Is there a way to get revision # from git's web ui?

I wrote this simple tool for that purpose:
http://mulder.googlecode.com/svn/trunk/libx264/git2rev.exe

Usage:
git log > changelog.txt
git2rev changelog.txt

[outlaw.78]

x264 0.100.1659 x86 & x64 (http://www.mediafire.com/?yi3dmkmqniw)

gcc 4.5.1 20100623 prerelease
ffmpeg svn 23787
swscale svn 31559
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.100.1659 amdfam10,fprofiled,LTO

[qyot27]

I wrote this simple tool for that purpose:
http://mulder.googlecode.com/svn/trunk/libx264/git2rev.exe

Usage:
git log > changelog.txt
git2rev changelog.txt
Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

[JEEB]

Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.

git rev-list HEAD | wc -l | sed -e 's/^ *//' > revision.txt

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

I would guess this is because of libswscale being in the same repo on the SVN side.

[LoRd_MuldeR]

Awesome, I've been needing a tool like this. How portable is it? It'd be nice to use it under Linux or OSX, too.?

It's written in Delphi, so no native Linux or Mac binary. But I guess the Win32 binary would work under Wine/Linux too.

Anyway, it's really nothing special! I hacked that together in three minutes. You could probably do the same with a few lines of Shell/Python/Perl script :p

[mgb]

Are there any sources of x264 built as a shared library for windows?

I need to write a video stream as x264, the vfw is too slow and IU haven't had any luck trying to build it.

[LoRd_MuldeR]

Are there any sources of x264 built as a shared library for windows?

I need to write a video stream as x264, the vfw is too slow and IU haven't had any luck trying to build it.

http://forum.doom9.org/showthread.php?p=1412089#post1412089 :p

[mgb]

http://forum.doom9.org/showthread.php?p=1412089#post1412089 :p
Excellent thanks, now I just have to go through the Avidemux source to work out how to use it!

I need to record 1080p @ 60fps so the alternative is a $1000 hardware H264 capture board or a very big raid system.

Thanks again
Martin

ps. Unless there is a way of using the x264 command line client to read raw YUV from a pipe?

[LoRd_MuldeR]

Excellent thanks, now I just have to go through the Avidemux source to work out how to use it!

No need for that. All you need is the interface defined in "x264.h".

Applications using x264 as a library don't need to know anything but the functions/types defined in that file ;)

But make sure you use a "x264.h" that matches the DLL version. Currently 97 for my DLL's.

Anyway, you can have a look here (mainly the "encoder.cpp" will be interesting) for an usage example:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/plugins/ADM_videoEncoder/ADM_vidEnc_x264/#_branches_avidemux_2.5_branch_gruntster_plugins_ADM_videoEncoder_ADM_vidEnc_x264_


ps. Unless there is a way of using the x264 command line client to read raw YUV from a pipe?

This works for sure ;)

your_app.exe | x264.exe --demuxer yuv [more options] - 720x576


I need to record 1080p @ 60fps so the alternative is a $1000 hardware H264 capture board or a very big raid system.

1080p @ 60 fps will be though! I guess you want to use "--preset superfast" or even "--preset ultrafast" for that purpose ;)

[mgb]

No need for that. All you need is the interface defined in "x264.h".
I understand that there are one or two options to set in H264 ;-)

1080p @ 60 fps will be though! I guess you want to use "--preset superfast" or even "--preset ultrafast" for that purpose ;)
That's what I was trying with the vfw build but I was only getting 6-7fps.
It may have been either a disk I/O bottleneck or a threading issue - it was only using 15% CPU on a 8 core machine

[LoRd_MuldeR]

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

Well, I simply grab the log from git via "git log > file.txt" and then I walk through all lines (in reverse direction) counting the lines that start with a "commit" keyword.

This is a very simple approach and it works fine for the x264 log. No idea what is going on with the FFmpeg log. Maybe they have branches and other fancy stuff that I don't handle at all...

[LoRd_MuldeR]

That's what I was trying with the vfw build but I was only getting 6-7fps.
It may have been either a disk I/O bottleneck or a threading issue - it was only using 15% CPU on a 8 core machine

I get something like ~10 fps for 1080p footage (source is a HuffYUV AVI from HDD) with "--preset ultrafast --crf 22" on my Core2 Q6600.

CPU usage is around 33% for this scenario...

EDIT: Actually for this scenario the "veryfast" preset doesn't seem to be noticeably slower on my system, but causes ~55% CPU usage.

[J_Darnley]

Testing on ffmpeg's changelog resulted in a ~200 revision disparity, though (SVN reports r23791, git2rev reports r23587). Is that on their end with the SVN/git syncing process, or do you think something else is going on?

ffmpeg's git doesn't track this "release" business they're doing.

[LoRd_MuldeR]

I get something like ~10 fps for 1080p footage (source is a HuffYUV AVI from HDD) with "--preset ultrafast --crf 22" on my Core2 Q6600.

CPU usage is around 33% for this scenario...

EDIT: Actually for this scenario the "veryfast" preset doesn't seem to be noticeably slower on my system, but causes ~55% CPU usage.

I need to correct myself: The source turned out to be FFV1, not HuffYUV :o

This time I used a real HuffYUV 1080p source and I got ~22 fps with "--preset ultrafast --crf 22" for 1080p :cool:

[qyot27]

It's written in Delphi, so no native Linux or Mac binary. But I guess the Win32 binary would work under Wine/Linux too.

Anyway, it's really nothing special! I hacked that together in three minutes. You could probably do the same with a few lines of Shell/Python/Perl script :p
Yeah, Wine is always an option, I simply prefer to use Wine as a last resort (I was wrangling with it yesterday night trying to get Sherpya's mencoder build to correctly interpret Kanji in ASS subtitles; I have RVM's native build from SMPlayer's PPA working fine for that, but getting Sherpya's build to work was for the benefit of another system where I don't have that luxury).

git rev-list HEAD | wc -l | sed -e 's/^ *//' > revision.txt
Thanks. I knew that there was probably a way to do it with git and some of the query tools *nix systems usually come with, but said tools' usage generally goes right over my head.

I would guess this is because of libswscale being in the same repo on the SVN side.
I suspected as much, although running the rev-list command above on just libswscale prints out a revision number in the 1000s. I guess it's not a case of simple addition.

Doesn't matter as much for ffmpeg, though - I would only need it for some of the forks that lack an SVN repo to pull from (specifically the Lagarith decoder and Ordered Chapters branches hosted on repo.or.cz (http://repo.or.cz/w/FFMpeg-mirror.git/forks)), and I don't mess with them all too often, or I just do a regular merge with the main project, so it wouldn't really matter, knowing what the main branch's revision number is at.


In any case, this means I can [easily] use the revision number for x264 when I pack up tarballs rather than needing to compile it first to find out what the number is, or my usual solution of just using the date I cloned it instead.

ffmpeg's git doesn't track this "release" business they're doing.
'Release'? Do you mean the 0.5.2 or 0.6 packages? I ignore those completely.

[J_Darnley]

'Release'? Do you mean the 0.5.2 or 0.6 packages? I ignore those completely.

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.

[qyot27]

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.
I fully admit I might be misunderstanding this, but it seems like it is in there, though:
http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=ebc0bc8eba20291fe45b0916020a4e2062c13464

Committed 5 days ago, although the SVN commit was logged to yesterday.

[Maccara]

Yes, they are branches in the svn tree. A commit to one of these will have a revision number which is not known by git. Try subversion rev 23747, you won't find it in the git log.

Why don't they track the branches in the mirror? It's trivial. (or do they? didn't check, as I did my own mirror long ago when I had trouble with the "official" mirror)

Shows just fine in mine:

$ git show 5aa73351e66
commit 5aa73351e66c88a0b5c1d0baa9cf9e801bacd5bf
Author: siretart <siretart@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Date: Thu Jun 24 05:46:58 2010 +0000

10l: aacsbr: Fix f_master[2] calculation when k2diff == -1.



backport r23660 by alexc


git-svn-id: svn://svn.ffmpeg.org/ffmpeg/branches/0.6@23747 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index 0de81a5..0de89c2 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -402,7 +402,7 @@ static int sbr_make_f_master(AACContext *ac, SpectralBandReplication *sbr,
k2diff = sbr->k[2] - sbr->k[0] - sbr->n_master * dk;
if (k2diff < 0) {
sbr->f_master[1]--;
- sbr->f_master[2]-= (k2diff < 1);
+ sbr->f_master[2]-= (k2diff < -1);
} else if (k2diff) {
sbr->f_master[sbr->n_master]++;
}

[J_Darnley]

The branches are not tracked on git.ffmpeg.org. If they were everyone should be able to find this commit twice over

[Maccara]

The branches are not tracked on git.ffmpeg.org.

Apparently so. I just wonder, why not...

[B.F.]

Any rev. 1659 with fade compensation patch?

[MatLz]

Any rev. 1659 with fade compensation patch?

There is one here (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/1600-1699/)
Other good things in bonus like fgo, mixaq...

[rack04]

Is it true that mingw has to be patched to compile the latest ffmpeg? From what I've read stdio.h and string.h must be patched.

[bnshrdr]

Is it true that mingw has to be patched to compile the latest ffmpeg? From what I've read stdio.h and string.h must be patched.
What version of mingw are you using?

Currently I'm using komisar's 4.4.4 build (4.5.0 had some i686 problems) and I'm not having any problems building ffmpeg, despite the small patch needed in libswscale/swscale_template.c

What kinds of errors/warnings are you running into?

[Underground78]

There is one here (http://vfrmaniac.fushizen.eu/x264/x264_DANGEROUS/1600-1699/)
Other good things in bonus like fgo, mixaq...

Can any of the patches used in this build become part of main tree one day ?

[rack04]

What version of mingw are you using?

Currently I'm using komisar's 4.4.4 build (4.5.0 had some i686 problems) and I'm not having any problems building ffmpeg, despite the small patch needed in libswscale/swscale_template.c

What kinds of errors/warnings are you running into?

I am using komisar's 4.4.4 build and I get the following error:

libavfilter/parseutils.c: In function 'color_table_compare'"
libavfilter/parseutils.c:217: error: implicit declaration of function 'strcasecmp'
make: *** [libavfilter/parseutils.o] Error 1

[komisar]

rack04

workaround-1: from general.texi in ffmpeg:FFmpeg cannot be compiled because of broken system headers, add
@code{--extra-cflags=-U__STRICT_ANSI__} to the configure options as aworkaround.

workaround-2: use "--disable-filters" in configure options for ffmpeg

information about this bug: http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/2815

[bnshrdr]

Thanks komisar. I kept seeing that #ifndef __STRICT_ANSI__ in the header files and knew there had to be a way to feed it to gcc.

[kemuri-_9]

__STRICT_ANSI__ is defined automatically by -std=c99
which is what ffmpeg uses for some reason unbeknownst to me.
it should realistically use -std=gnu99 instead

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r23925 and libswscale SVN-r31591 (http://www.multiupload.com/RHKW6F9CM1)
ffms2 SVN-r314 (http://www.multiupload.com/OXSZWS0CXD)
x264 Builds:

x264_x64_r1659M (http://www.multiupload.com/MEXR8EO7J4)
x264_x86_r1659M (http://www.multiupload.com/E1J731O9LH)
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
Patches:
x264_sws_typecast (http://pastebin.com/nzYGvT9S)
x264_demuxer_threads (http://pastebin.com/qWkMKqbg)
x264_fade_compensation (http://pastebin.com/BBwB72Az)
x264_open_gop_bluray (http://pastebin.com/TvhtWhTu)

[lexor]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

[kemuri-_9]

I'm curious, why does sws_typecast patch still exists as just a patch? It's been included in builds for so long. It seems so simple, why not just commit it? Do developers see it as just another annoyance of GCC not for x264 to dignify with a fix?

A) the patch is purely cosmetic to avoid a warning when compiling x264 with lavf and/or ffms support
B) the issue is also fixed with the filtering patch.

Similar question for demuxer_threads... though I don't recall when if first appeared, so maybe it's still unproven or not universally better/faster?

I vaguely remember something along the lines of pengvado saying not all of the threading done in ffmpeg's decoders is stable.

[Blue_MiSfit]

Yes, from what I recall threads in ffmpeg is somewhat unstable with some codecs.

[bin_ch]

B) the issue is also fixed with the filtering patch.


Speaking of the filtering patch, any news on it?
Thanks.

[kemuri-_9]

Speaking of the filtering patch, any news on it?
Thanks.

Dark_Shikari is cracking the whip on me to get it committed before the first phase of the audio filtering/encoding patch.
the latter will try and get committed at GSOC midterms, which i heard is the 12th of july.

[D3C0D3R]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 :devil: revision change ))

[kemuri-_9]

can someone tell how new 9,10 bit depths patch affect compression, or better post x264 compiled with --bit-depth 10
as i understand it sets on compile stage and on x264.nl lies 8-bit version
166 page and 1666 revision change ))

configuring with bit-depth 9 or 10 will cause x264 to output video with that bit depth, which will require the use of the High10 profile (outside of lossless)
naturally this will cause the generated videos to take slightly more space....

at the moment there isn't much of a practical use for it as
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
B) x264 still only accepts input that has a bit-depth of 8.
C) no free/popular decoder outside of JM seems to even decode High10 correctly - only some 'pro' ones do it seems

all of these issues will eventually need be fixed to have it be more practical for use,
the first 2 are already planned/in works for x264 but the 3rd is something outside of x264's hands.
and then it'll be primarily only useful for videos where the input is >8 bit depth

[D3C0D3R]

naturally this will cause the generated videos to take slightly more space....
hm, but quality is rises? extra precision never hurts.
A) there's practically no asm for high bit depth mode (so it runs REALLY slow)
i didnt scared sLOW speed, perhaps like many people on this forum i use placebo options ))
B) x264 still only accepts input that has a bit-depth of 8.
i understand that and interesting how 10 bit precision can help to improve 8-bit quality e.g. dealing with banding effect

[julius666]

naturally this will cause the generated videos to take slightly more space....

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

[lexor]

If I remember correctly, DS said that 10 bit would give ~10-15% quality gain against 8 bit, at the same bitrate (I don't know the exact reason, maybe because less dithering is needed).

He didn't qualify this statement though. Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

[MasterNobody]

If judge by SSIM/PSNR than higher bit depth give higher quality on the same bitrate for 8-bit sources also.

[julius666]

Is it ~10% increase with 8bit source and 10bit output or do you need high bit source too? If the latter, then we are screwed, because all the common sources we get are 8bit.

I'm pretty sure that the former. His statement doesn't make sense otherwise.

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

[LoRd_MuldeR]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

I doubt DXVA does handle the "High 10" profile of H.264...

[JEEB]

A question: 10 bit colourspace isn't compatible with DXVA, am I right?

Basically agreeing with LoRd_MuldeR here.

I would say that you'd be pressed to find decoders for 10bit H.264 at the moment, software and hardware-wise. DXVA and CoreAVC should be out for sure, as well as other GPU-based solutions ('out' as in 'out of the question').

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

[lexor]

"Some professional decoders" seem to be capable of decoding the given material, as far as I've heard. But given that we still can't input 10bit into x264 itself, I'm not exactly pressed to see what those are at the moment.

Well, if it's true that we get a noticeable quality improvement even with 8bit source, I think we should all be interested in those rare decoders that can play it. In particular I am hoping higher bit depth will help with the banding (to smooth out gradients).

On a related note, what's the purpose of 9bit? Is it just to offer another performance grade for those who want better quality but can't wait for 10bit encoding? Seems an odd (literally) number, I mean I've seen 8, 10, and 12 bit video sources, but I've never heard of anything working in 9bits.

Speaking of which, why isn't there a 12 bit mode, since some pro-apps do output it (in their RAWish/uncompressed intermediate formats of choice, not h264)? Seems like it would be a perfect fit for x264 lossless to slide in there.

[mp3dom]

10bit could be useful for professional use (mainly if you capture in h264 rather than uncompressed yuv, but probably the decoding cycle of h264 will be larger without an hardware decoder). If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit). If you can hide/mask/fix color banding with avisynth then you can save it in lossless h264.
Actually it's not so useful to have a 10bit output if the source needs to be 8bit, anyway this could be a lot useful in future when x264 could support 10bit as input, or it could be VERY useful if it could dither a 10bit source to an 8bit output (IMHO the most useful option)

[Blue_MiSfit]

Yes, very!!

I would love to see 10 bit input support, possibly with an option to dither down to 8 bit as well.

Derek

[masterkivat]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

[rack04]

Since JEEB system hanged out (http://x264.fushizen.eu/?p=206), can someone build the new evil build :devil: with fade_compensation .diff?
Thanks in advance :thanks:

Explain evil build.

[Midzuki]

Explain evil build.

r1666 :devil:

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24064 and libswscale SVN-r31639 (http://www.multiupload.com/FYKG5OL4OM)
ffms2 SVN-r317 (http://www.multiupload.com/LZMNP9BUB3)
x264 Builds:

x264_x64_r1666M (http://www.multiupload.com/CGB3AA0T60)
x264_x86_r1666M (http://www.multiupload.com/A5B34AL9QM)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

as i know divx d3c0d3r support High10 so can someone build 10bit :devil: build ?

2 komisar - your crazy devil x264vfw build sets mb-tree=0 when use Command line option is off.

[julius666]

If you've a 8bit source, converting to 10bit is totally useless unless you need to do color correction or other similar things. Higher bit depth will preserve smooth gradients IF the source have smooth gradients. If you have already color banding, converting to 10bit will keep all the color banding (also avisynth is 8bit only so all its filters works in 8bit)

If the 8 bit source has banding, than the 10 bit output will obviously have it too. But if your source is dithered, than x264 will chop down the dither (especially at lower bitrates) and create banding. With more precision the banding could be less visible in this case.

[komisar]

D3C0D3R, yes... mb_tree=0 because [warning]: lookaheadless mb-tree requires intra refresh (http://sourceforge.net/projects/x264vfw/forums/forum/770225/topic/3759827)
if you known what you do -- add needed options to "Extra options:"-box...

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24069 and libswscale SVN-r31642 (http://www.multiupload.com/CHBOA7QFO8)
ffms2 SVN-r317 (http://www.multiupload.com/T24S6H1PPG)
x264 Builds:

x264_x64_r1666M_8bit (http://www.multiupload.com/LAXU555UTY)
x264_x86_r1666M_8bit (http://www.multiupload.com/VU3TNW6ZNA)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
x264_x64_r1666M_9bit (http://www.multiupload.com/7JYVOJ3E92)
x264_x86_r1666M_9bit (http://www.multiupload.com/08H0VT58B1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 9
x264_x64_r1666M_10bit (http://www.multiupload.com/HX4MVQA8C0)
x264_x86_r1666M_10bit (http://www.multiupload.com/660A5UNRH1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 10
Patches:
x264_sws_typecast (http://pastebin.com/6TjQAKV3)
x264_fade_compensation (http://pastebin.com/2L1PCDLx)

[D3C0D3R]

2 rack04 thank you for 9,10 bit builds and off course BIG Respect to Oskar, who developed this patch.

2 komisar - i always place in extra textbox something like "--rc-lookahead 120" and had in 1659 mb-tree=1, but in 1666 i didnt see any warnings and mb-tree=0 :(
AFAIK this is no other way to turn on MB-Tree only to off it ))

[komisar]

D3C0D3R
http://forum.doom9.org/showthread.php?p=1414971#post1414971

[D3C0D3R]

2 komisar thanx 4 help - works

high 10: first impressions & quick tests 8,9,10 bits
http://forum.doom9.org/showthread.php?p=1415028#post1415028

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24248 and libswscale SVN-r31736 (http://www.mediafire.com/?kmwjmngj5yymgth)
ffms2 SVN-r318 (http://www.mediafire.com/?xlkzytwj1zjfznh)
x264 Builds:

x264_x64_r1675M (http://www.mediafire.com/?nzazgxz2jmmhwnm)
x264_x86_r1675M (http://www.mediafire.com/?yzjyztdmzmjmd2n)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/Sp5bLbhJ)

[Audionut]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

[rack04]

Hi rack04,

Your 64bit build crashes when using --vf

32bit build is working fine.

What is your command line?

EDIT: This works for me. Windows 7 64bit Ultimate.

"C:\Program Files\x264\x264.exe" --preset veryslow --tune film --crf 18 --force-cfr --vf resize:1280,528,1:1 --aud --output "E:\Work\110902669-output.264" "E:\Work\110902669.mov"

BTW: Here is a new build.

x264_x64_r1677 (http://mfi.re/?itwkgmonrnnwz2m)

[Soichiro]

I have discovered that the current build of avs4x264 and vfw4x264 broke with the filtering patch (r1672). As such, I have created a fixed version for anyone using either of these for piping to 64-bit x264.

Updated vfw4x264+avs4x264 w/ source (http://www.megaupload.com/?d=NDPO6W7G)

[Audionut]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Any error message?

[Soichiro]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

[Audionut]

Yup, what ^^^^ he said.

rack04, are you on x264 irc to make debugging faster.

[rack04]

rack04, I can confirm that this crashes on your build (at the very beginning of the encode), although it runs fine on my personal build.

Windows (7 Ultimate x64) just pops up with a dialog message saying "x264_64.exe has crashed, what do you wanna do about it?"

I don't know what to say. It works with the .mov that I have handy.

[Audionut]

Tried on mkv and avs source. Same problem.

[komisar]

problem in libswscale... win64 is bad friend for ffmpeg&co :(

[JEEB]

problem in libswscale... win64 is bad friend for ffmpeg&co :(
At least Dark_Shikari has shown interest in giving a try to fix it as soon as a real backtrace is gotten with other ffmpeg devs. Although yes, as win64 is not officially supported, a bug report would most probably otherwise be brushed off as "lol win64".

[Selur]

anyone building current 9/10bit builds for win32bit? (rack04?)

[rack04]

Currently I'm not on a 64bit machine. Once I get get off work I will attempt to provide a useful gdb backtrace. For those who may want to help please refer to the following links for debug builds.

x264_x64_r1677_debug (http://www.mediafire.com/?ysi24vmd5c83n1y)

[rack04]

A simple sucker like this is enough,

--vf resize:640,272 -o f:\output.264 f:\input.avi

Crashes with the new build also.
On win7 64 ultimate

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

[Audionut]

Try this (http://www.mediafire.com/?j27p724jlj3puu4) build.

That works. Thanks.

Can you patch that with fade-compensate.

[RedDwarf1]

Why do recent builds, since mb-tree was introduced it might of been, produce files with an incorrect number of reference frames?

General
Complete name : L:\VIDEO_TS\test2.mkv
Format : Matroska
File size : 5.68 MiB
Duration : 40s 40ms
Overall bit rate : 1 190 Kbps
Writing application : x264 r1649 c54c47d
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@3.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 40s 40ms
Bit rate : 1 167 Kbps
Nominal bit rate : 1 149 Kbps
Width : 704 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.115
Stream size : 5.57 MiB (98%)
Writing library : x264 core 98 r1649 c54c47d
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1149 / ratetol=4.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=8 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.20

And before you start claiming that MediaInfo is incorrectly reporting the number of reference frames, AVInaptic also shows an incorrect number of reference frames, there being one less than was used to encode.

So why are both these programs showing lower numbers of reference frames than the number set when encoding?

[Trahald]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

[rack04]

That works. Thanks.

Can you patch that with fade-compensate.

I'll post something later today.

[Audionut]

Sweet, thankyou sir.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24287 and libswscale SVN-r31748 (http://www.mediafire.com/?yt5i6uoalxeg4p4)
ffms2 SVN-r318 (http://www.mediafire.com/?4f5p6s6fbllfy3k)
x264 Builds:

x264_x64_r1677M (http://www.mediafire.com/?6qwhe8e513cqzjo)
x264_x86_r1677M (http://www.mediafire.com/?0vnny5ubtop37fg)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/5Xnfraqd)

[RedDwarf1]

It's due to bpyramid. 'Normal' manages the flow of the dpb and makes sure there is one space for nonreference frames (when needed). Normal mode designates dpbslots and ref numbers as the same since it's smarter then strict and if possible uses the last dpb space for reference frames. Bpyramid strict 'always' leaves one spot open for one nonreference frame so ref is set to one less dpbsize. Normal is more efficient so unless you are doing bluray, use normal mode.

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.

[Dark Shikari]

Thank you for the explanation. A test has just confirmed it when using Normal, the reported ref frames is as was set in the encoding options.

The reason why I used strict was because I wanted improved quality while trying to retain hardware compatibility for hardware media player playback. I have been researching different media players using chipsets such as those made by Realtek and Sigma Designs because I wanted to purchase one. I don't want to get one and find it won't playback my already/recently encoded files.Strict does not improve hardware compatibility, it just improves compatibility with the Blu-ray spec.

[burfadel]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...

[Dark Shikari]

It seems pretty common that for animation, or sources where there are lines that separate too flat surfaces, for people to raise the deblocking to 1:1

I know the deblocking filter is already automated somewhat and that adjusts the bias, my question relates to the deblocking in certain scenarios like that above. Is it possible for x264 to increase the strength and threshold of deblocking up to say 1:1 (or part thereof), when transitions between different flat surfaces is detected, such as in animation? This would be more beneficial for lower res animation, say 512x384 or 640x352. At higher resolutions the bias to be automatic scaled, such that at 720x576 it would be more like (for example) 0.6:0.6.

For high resolution images, have this scaled back to the point where there is a high resolution image the deblocking is at the default. I think this would be very beneficial if possible. The deblocking bias should only be applied to the relatively flat surfaces/shaded surfaces and the transitions between such surfaces, and not to higher detailed parts of the picture. Of course, the deblocking can still be changed for peoples preference.

Probably a stupid idea, but I'm guessing I'm not the only one that has thought of it...Deblocking can only be set per-slice. Trying to add enough slices to cover objects efficiently would hurt compression quite a bit.

[burfadel]

Ah ok! that explains it :)! I knew there would have to be a simple reason why its not done automatically!

How about using something like me-prepass to determine whether the consecutive frames are animation or film, and adjust deblocking based on that?

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6-DEV
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24352 and libswscale SVN-r31758 (http://www.mediafire.com/?4d7gcu8gt74ppyi)
ffms2 SVN-r320 (http://www.mediafire.com/?d1wark634cg0yod)
x264 Builds:

x264_x64_r1680M (http://www.mediafire.com/?qb609r42rc2q52i)
x264_x86_r1680M (http://www.mediafire.com/?dgk2400dxtxw8l8)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (LINK)

[ckmox]

anyone help please im getting this error

ffms [error]: could not create index
lavf [error]: could not open input file
raw [error]: raw input requires a resolution.
x264 [error]: could not open input file `o.mkv' via any method!


my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

im on Windows XP SP3 32-bit

[nm]

my commandline
x264 --preset slow --tune animation --crf 27 --vf resize:704,400 -o "i.mkv" "o.mkv"

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

[ckmox]

Looks like you have i.mkv and o.mkv reversed in that command line, if i=input and o=output.

haha ye thats it silly me thanks a lot

[Snowknight26]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

[Midzuki]

And hopefully it doesn't really say
x264 [error]: could not open input file `o.mkv' via any method!
Who uses grave accents in place of apostrophes?

Looks like a "bad habit" that was born in the "7-bit age". :)

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24429 and libswscale SVN-r31767 (http://www.mediafire.com/?rdj7obkdvmtdo3i)
ffms2 SVN-r320 (http://www.mediafire.com/?99072bq150nnmk1)
x264 Builds:

x264_x64_r1683M (http://www.mediafire.com/?ah46kc955lckb3w)
x264_x86_r1683M (http://www.mediafire.com/?er1hcnlyabg8tlk)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/4tB1dw26)

[JEEB]

x264 r1683 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1683/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1683/x264.md5)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1683 32bit
download (http://x264.fushizen.eu/files/1683/x264_1683_32.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1683 64bit
download (http://x264.fushizen.eu/files/1683_64/x264_1683_64.7z)

built on Jul 22 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


After sorting out the problems with my encoding environment, here's something newer. After talking about FGO (http://x264dev.multimedia.cx/?p=25) with VFR Maniac, I decided to take it in. Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

[Soichiro]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

[JEEB]

I don't get it. I thought the whole point of Psy-RD and Psy-Trellis was to optimize for film grain in a way that wouldn't also destroy videos that lack grain. I also thought that was why builds with FGO were discontinued 1-2 years ago and why FGO never made it into the git. Correct me if I'm wrong though.

They are quite different tools and concepts, I would say (and thus do not cover each other off). Not to mention that FGO by itself, as you say, is nothing new. The main reason I took it into my own builds was because VFR Maniac commented to me that "it was/is a way of retaining some grain/noise while still not breaking the image with relatively low bitrates, unlike psy-rd and psy-trellis." I must say, I was interested.

And because I saw that it was extra something that might be useful, and, even if used, doesn't really break anything as long as you don't overdo it (high FGO and Psy-RD/-Trellis together seem like something you wouldn't want to use), I decided upon adding the properly updated patch to my builds. VFR Maniac and BakaPop have kept this patch up-to-date and 64bit-compatible (and their own builds of course contain this patch).

[elguaxo]

Sounds interesting, thanks JEEB!

Currently using --psy-rd 0.8:0.4 --fgo 2 and got pretty good results.

Just to know where to start my tests. I'll try it at a medium/low bitrate. Is that suggestion above for film or animation.

:thanks:

[JEEB]

Is that suggestion above for film or animation.
I mostly encode animation recently, which leads to most of my settings being closer to animation than live action. I guess I could've mentioned this in the post itself.

Anyways, since --fgo 5 is "weak", --fgo 2 is even weaker. This was mainly a precaution because I was trying it on an encode that I would rather like to come up nice the first time. Although I did up it from the recommendation of 1 that came from VFR Maniac ;) .

[elguaxo]

Ok! Thanks for the quick replay. :)

[rack04]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

[MasterNobody]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.
Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

[rack04]

Probably this is libavcore dependence. Try with this patch: http://pastebin.org/428030

That fixes it. Thanks.

[rack04]

Toolchain:
GCC 4.4.4
GPAC 0.4.6
Pthreads 2.9.0.0
Yasm 1.0.1
LAVF/FFMS Builds:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

[Soichiro]

Has something changed in how x264 ./configure detects ffms and lavf. I'm trying to compile the latest x264 and it says no for both ffms and lavf.

In msys/mingw32? Mine does this sometimes too, and I don't understand why. If I just rerun the configure script again, though, it usually detects everything properly. It's weird...

[pistacho]

@ rack04

Thank you very much by the build with filters. I've tested and works perfect :)

The command line is:
x264.exe --bitrate 5000 --preset medium --tune
film --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --fps "2
4000/1001" --force-cfr --keyint 24 --b-pyramid strict --open-gop bluray --bframe
s 3 --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709
" --sar 1:1 --vf "pad:,,,,1920,1080" --pass 2 -o "T:\TEMP\El_negociador.264" "E:
\TEST\El Negociador-006.mkv"
ffms [info]: 1920x800p 1:1 @ 24000/1001 fps (cfr)
pad [info]: expanding frame to 1920x1080, picture starting at (0,140)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 4.1
[20.6%] 633/3078 frames, 8.10 fps, 5119.04 kb/s, eta 0:05:01

Input: a 2.40:1 AR MKV (1920x800)
Ouput: 16:9 AR (1920x1080) AVCHD/Blu-Ray compilancy

I think this function is very useful to encode for Blu-ray when the source is not 16:9. (requires add borders).

I will add it to my application when I have more tested. I hope that soon could be included in x264 official releases.

:thanks:
________
amber trichomes (http://trichomes.org)
________
Triumph Sprint ST (http://www.cyclechaos.com/wiki/Triumph_Sprint_ST)

[JEEB]

Anyone else having trouble when building 64bit builds with pkg-config with lavf/ffms?

config.log paste (http://privatepaste.com/2f1472a7e9)

ffmpeg and ffmpegsource seem to build fine with the correct prefixes and all (like earlier) together with 32bit x264, but 64bit x264 seems to fail like this.

used command lines (have used them for quite some time now on my buildscript):
ffmpeg
./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-postproc --enable-filters --disable-network --disable-encoders --extra-cflags='-U__STRICT_ANSI__' --enable-runtime-cpudetect --enable-pthreads

ffmpegsource
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --host=x86_64-pc-mingw32 --prefix=/mingw/x86_64-pc-mingw32

x264
PKG_CONFIG_PATH=/mingw/x86_64-pc-mingw32/lib/pkgconfig/ ./configure --cross-prefix=x86_64-pc-mingw32- --host=x86_64-pc-mingw32

[kemuri-_9]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

[JEEB]

does adding --extra-ldflags=-lavcore to x264's ./configure fix the issue?

Aand yes, it did. I wonder why pkg-config doesn't handle that, though. I wonder if it's my damn system or something else :|

x264 r1688 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1688/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1688/x264.md5)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1688 32bit
download (http://x264.fushizen.eu/files/1688/x264_1688_32.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1688 64bit
download (http://x264.fushizen.eu/files/1688_64/x264_1688_64.7z)

built on Jul 31 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)

[qyot27]

x264_r1688-allbits.7z

Flags:
--extra-cflags="-march=pentium3"

Contains:
x264 r1688 (8-, 9-, and 10-bit)
FFmpeg git ~ of SVN-r24652 + Lagarith decoder (http://repo.or.cz/w/FFMpeg-mirror/lagarith.git)
FFMS2 r320 (FFmpeg git ~ of SVN-r24643 + Lagarith)
LAVF "2010-01-30 17:52" + Lagarith + Ordered Chapters (http://repo.or.cz/w/FFMpeg-mirror/ordered_chapters.git)
git checkout `git rev-list -n 1 --before="2010-01-30 17:52" master`
Notes:
No patching outside of the branch mergings. I forgot to use L-SMASH this time, so it's still using GPAC.

Cross-compiled on Ubuntu 10.04 using mingw-x (supposedly, gcc 4.4.5 prerelease; I somehow doubt this but lack any way of proving it).

All of the above are 32-bit. I don't have access to 64-bit Windows at all.

The disparity between the FFmpeg used for FFMS2 and the fully-built one is due to how ancient my computer is (i.e. it takes upwards of a half hour to compile FFmpeg at any stage; see also the -march used...I'm on a Coppermine-based Celeron), and an initial lack of Internet connection.

As the stats say, the LAVF these builds use is six months out-of-date. Newer versions of FFmpeg break the Ordered Chapters branch in a way I haven't a clue how to fix using Meld.

The Lagarith support is, well, a little spotty. Only YV12 files, and seems to have problems with fades.

[laserfan]

...
patched with:

mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)...
I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

[JEEB]

I can't seem to find any information on the usage of the fade compensation patch. Can anyone direct me to a site/thread where ppl talk about settings, sources, results etc?

Or maybe the folks who use it include a specific setting for every one of their encodings without tweaking (if yes, what setting would that be)? :confused:

There was some talk about it on doom10 and on IRC. Most people I see use it with settings around the 0.6-0.8 range, which is normally rather effective. Of course, if x264 doesn't find the fade a fade, nothing can really be done about that.

[moosekaka]

Toolchain:

ffmpeg SVN-r24577 and libswscale SVN-r31859 (http://www.mediafire.com/?i06g5a4ko628655)
ffms2 SVN-r320 (http://www.mediafire.com/?ayqcvcqkfmj3dcu)
x264 Builds:

x264_x64_r1688M (http://www.mediafire.com/?boo762he0q0hozm)

x264_x86_r1688M (http://www.mediafire.com/?tn626hv2vgd4gll)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)


hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

[detmek]

x264_x86_r1688M_Filtering (http://www.mediafire.com/?wuxrditjff33ac1)
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
gpac: yes
pthread: yes
filters: resize crop select_every hqdn3d yadif pad
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
x264_fade_compensation (http://pastebin.com/cSww2Afe)
x264_libavcore (http://pastebin.com/FpUsDC1y)
x264_filtering (http://pastebin.com/Pzu85cwi)

Hi. I tried using this build but I get this warrning:

ffms [info]: 720x304p 1:1 @ 24/1 fps (vfr)
pad [info]: expanding frame to 720x480, picture starting at (0,88)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile Baseline, level 3.0
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
x264 [warning]: 3015 suppressed nonmonotonic pts warnings

x264 [info]: frame I:13 Avg QP:17.54 size: 19819
x264 [info]: frame P:3006 Avg QP:19.32 size: 5262
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 8.4% 0.0% 0.0% P16..4: 28.3% 0.0% 0.0% 0.0% 0.0% skip:63.3%
x264 [info]: coded y,uvDC,uvAC intra: 23.0% 35.5% 11.9% inter: 15.2% 14.1% 2.4%
x264 [info]: i16 v,h,dc,p: 45% 28% 14% 13%
x264 [info]: i8c dc,h,v,p: 52% 25% 14% 8%
x264 [info]: kb/s:1022.40

encoded 3019 frames, 72.20 fps, 1022.44 kb/s


Command line is --vf pad:0,88,0,88/ --preset ultrafast -o testpad.mp4 D3.avi

D3.avi is:
General
Complete name : C:\ft\D3.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 151 MiB
Duration : 2mn 5s
Overall bit rate : 10.1 Mbps
Writing library : VirtualDub build 32817/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : H264
Duration : 2mn 5s
Bit rate : 10.1 Mbps
Width : 720 pixels
Height : 304 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 1.921
Stream size : 151 MiB (100%)
Writing library : x264 core 102 r1666bm d058f37
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=4 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

I found some posts but those are about resize filter problem, but my OS is WinXP Pro SP3 32-bit and I don't use Avisynth, as x264 log shows. Same problem with --preset medium. I did not have problems with resize filter, only with padding.

Tested again. No warrnings if I add --force-cfr to command line. VFR is the problem, I think.

[rack04]

hi, is the pad filtering patch available on 64bit x264 build? or is it somehow difficult to implement on 64 bit? thanks

No it is not available.

[JEEB]

And another update to my build script (http://x264.fushizen.eu/files/buildx264.sh), L-SMASH straight from the git repo :3

Yes, it looks ugly and very much like a hack, but works and seems to be the official way to install git L-SMASH at the moment. If anyone has a better version, please do share <3.

x264 r1698 64bit unpatched:
download (http://x264.fushizen.eu/files/revision1698/x264.exe) ; hash (http://x264.fushizen.eu/files/revision1698/x264.md5)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit

________________________________________________________________________________

x264 r1698 32bit
download (http://x264.fushizen.eu/files/1698/x264_1698_32.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86.generic.Komisar)
fprofiled, 8bit


x264 r1698 64bit
download (http://x264.fushizen.eu/files/1698/x264_1698_64.7z)

built on Aug 16 2010, gcc: 4.4.4 (x86_64.generic.Komisar)
fprofiled, 8bit


patched with:

0001-Fix-compilation-to-support-L-SMASH.patch (http://up-cat.net/L-SMASH/0001-Fix-compilation-to-support-L-SMASH.patch)
Adding the whole L-SMASH git repo (http://repo.or.cz/w/L-SMASH.git) (revision 2d99fcd) into /output and then rewriting the x264 mp4.c with the one for L-SMASH.
x264_fade_compensation_1629.patch (http://x264.fushizen.eu/patches/x264_fade_compensation_1629.patch)
x264_film_grain_optimization_1680.patch (http://x264.fushizen.eu/patches/x264_film_grain_optimization_1680.patch)


Flabbergasted and not really getting what I did? Read the build script, it should be more understandable ^^;. Seems to be working, though.

[julius666]

JEEB: Could you upload the files (the compiled binaries at least) to a file-sharing site like mediafire? For some reason I can't reach your webpage from Hungary just through a proxy. :(

[mariush]

I've put them here on the mplayer's mirror i host:

http://mplayer.savedonthe.net/x264/x264_r1698_64bit_unpatched.exe
http://mplayer.savedonthe.net/x264/x264_1698_32.7z
http://mplayer.savedonthe.net/x264/x264_1698_64.7z

... in the order they appear in the post

[julius666]

Thank you, that works :)

[rack04]

Toolchain:
GCC Version 4.5.1 Experimental Release SVN rev. 162774, 2010.07.31
Pthreads 2.9.0.0 Static
Yasm 1.1.0 r2361
LAVF/FFMS Build:

ffmpeg SVN-r24819 and libswscale SVN-r31971 (http://www.mediafire.com/?36b9y9ic4o9m8se)
ffms2 SVN-r325 (http://www.mediafire.com/?x0268x5cxw6sf4o)
x264 Build:

x264_x86_r1698M (http://www.mediafire.com/?idgw2sziatdh1it)
Platform: X86
System: MINGW
asm: yes
avs: yes
lavf: yes
ffms: yes
audio: yes (raw)
gpac: yes
pthread: yes
filters: resize crop select_every
debug: no
gprof: no
PIC: no
shared: no
visualize: no
bit depth: 8
Patches:
mp4muxer.diff (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff)

[qyot27]

x264_r1698-allbits.7z

x264=r1698 [8-, 9-, and 10-bit]
FFMS2=r325
FFmpeg=r24829

Patches:
http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff

Flags:
-march=pentium3

Cross-compiled on Ubuntu 10.04, GCC 4.4.5 prerelease (again, something I doubt but can't verify)
AAC encoding requires Quicktime to be installed. The version shipped with iTunes is sufficient, although I assume you need Quicktime 7.3 or higher; if you can use iTunes to access the Store, chances are it's a right version of Quicktime.

[RainyDog]

x264 0.100.1659 x86 & x64 (http://www.mediafire.com/?yi3dmkmqniw)

gcc 4.5.1 20100623 prerelease
ffmpeg svn 23787
swscale svn 31559
ffms2 svn 312
pthreads 2.9.0.0 static
x264 0.100.1659 amdfam10,fprofiled,LTO

Outlaw, will you be doing anymore of your amdfam builds? Cheers.

[qyot27]

With all the talk about licensing going on elsewhere in this section, I've made the decision to drop the builds I've made. Instead, I'll post the steps I took for the audio encoding one in the meanwhile (since the LAGS+OC build was a pain in the neck to get working right, and I'd have to constantly recheck the steps involved):

1. Sign up for a free account on Apple Developer Connection (sadly, there's no way around this part) and download the Quicktime 7.3 SDK for Windows (http://developer.apple.com/quicktime/download/).

2. Install the SDK normally.

3. Copy the contents of C:\Program Files\Quicktime SDK to a directory on msys' root called /qtsdk. Alternately, you could just install to said location right away, but you need to remember to rename the directory so there aren't any spaces in the path name.

4. When configuring x264, use --qtsdk=/qtsdk. It should recognize it and under Audio should respond with yes (raw, qtaac, qtaac_he).

4a. Cross-compiling on Linux is possible, but requires the .lib files in /qtsdk/Libraries to be renamed/copied/symlinked to have upper-case (.LIB, not .lib) extensions - case sensitivity causes configure to fail otherwise. Windows doesn't have this problem.

[bob0r]

You should not be scared by the money makers.
If it wasn't for "us" xvid and x264 would never grown so popular. We did all the hard work, and now companies make money of it.
If you are afraid of hosting stuff, you can always host it on x264.nl.

[qyot27]

Well, at least in my own case, those two builds were mainly for esoteric features/purposes, and my ability to churn them out with regularity was already a problem because of how old my comp is. The tide of progress on all the parts inside them would have made it a moot point in relatively short order anyhow. It already somewhat did to the r1688 build with Lagarith and Ordered Chapters. The Quicktime stuff is a regular part of the L-SMASH patch now, it's just a matter of whether one chooses to supplement said patch with AAC encoding or not by downloading the SDK from Apple.

It would be far more convenient for me to document what I did to get there, because this flare-up still points out that source code is apparently different from binaries; I'm comfortable with being told what to do with source code, or to rely on existing pipelines to get a hold of things, I've just re-evaluated whether I myself want to or have the time/ability to be part of said pipelines. Binaries may be more convenient for an average user without knowledge of compiling software, but the methodology to get different results is more valuable to those that feel confident with compiling it themselves - not to mention most of them would get through the process faster than I could simply due to better underlying hardware. Waiting 1h45m-2h or so just for a complete cycle of ffmpeg->ffms2->x264->ffmpeg is getting to be too much for me anyhow. That should seriously take me a half hour (or less!), not 3-4x that. Discounting, of course, any extra time racked up due to stuff causing builds to fail mid-way through and start the process over again trying to troubleshoot it.

[jpsdr]

@rack04 : Do you intend to make a 32/64 bit with fade_compensation patch of the last version ?

[easyfab]

Can someone make a build for LAVF/ffmpeg SVN but with all audio codec enable ( aac,lame,vorbis ... ) because I want to try to build "x264 audio" and I don't know how to build ffmpeg correctly under mingw/msys. ( A guide for ffmpeg under mingw/msys can also be good)

[lucassp]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)

[qyot27]

I'm also looking for a recent Mac build of x264 with ffms/lavf. Or at least a build tutorial. Thanks :)
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.

[jpsdr]

@jeeb : I've tested your x64 patched 1703 version, with the following command line :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET CHAPTERS=%6%5
SET STAT_FILE=%6%1.stats
SET TUNING=%4
SET LOG_FILE_1=%6%1_log_1.txt
SET LOG_FILE_2=%6%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %CHAPTERS% --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%


My avisynth script is only AVISource("File.avi"), where avi is Lagarith YV12 without audio.
2 problems :
- It displays avs errors about audio... First time i'm having this kind of message, specialy when output is raw h264...
- It never finish the 1st pass... Process is some kind of locked, i've one thread (ie one CPU) at 100%, log of 1st pass seems completed, but still used/locked by the process, and there is no log of 2nd pass, which mean 2nd pass is not starting.
Reproductible at 100%, even with a small file of few frames.

[livetolove92]

This is my settings
x264.exe --profile high --level 4.1 --pass 1 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output NUL "F:\Worker\x.avs"

x264.exe --profile high --level 4.1 --pass 2 --preset veryslow --bitrate 1900 --stats ".stats" --min-keyint 24 --thread-input --threads 6 --deblock -3:-3 --deadzone-inter 21 --deadzone-intra 11 --qcomp 0.6 --bframes 4 --direct auto --b-bias 0 --scenecut 40 --keyint 250 --ref 6 --rc-lookahead 00 --aq-mode 1 --aq-strength 0.7 --merange 24 --me umh --subme 7 --no-dct-decimate --mixed-refs --partitions all --trellis 2 --psy-rd 0.8:0.1 --ipratio 1.4 --pbratio 1.3 --no-fast-pskip --output "x.mkv" "F:\Worker\x.avs" 2>log.txt
And this my avs
LoadCPlugin("F:\Encode software\megui-core_0_3_4_15_x64\tools\ffms\ffms2.dll")
ffmpegsource2("H:\US\X.mkv")
Spline36Resize(960,406) # Spline36 (Neutral)

This my log
avs [info]: 960x406p 0:0 @ 24000/1001 fps (cfr)
x264 [warning]: lookaheadless mb-tree requires intra refresh or infinite keyint
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

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

[jpsdr]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

[kemuri-_9]

@jeeb
I've tested your x64 1713 patched build, still the same issue i've described in post #3397 (http://forum.doom9.org/showthread.php?p=1431557#post1431557)

have you even tried the unpatched x64 build to see if it also exhibits the issues?
iirc JEEB is using the still-being-developed audio support patch which would explain the audio warning...

[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

[neuron2]

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 ^^

[neuron2]

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?

[neuron2]

@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...

[neuron2]

Thank you for your understanding.

[Kurosaki Ichigo]

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