Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
8th September 2008, 19:29 | #1003 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
yes, the variable was called b_bframe_adaptive (b for bool type),
and is now called i_frame_adaptive (i for int type) in the new bframe decision patch. that's why DS has stated to do a simple search and replace (that's what s/x/y means - search for x and replace with y) |
8th September 2008, 19:43 | #1005 | Link |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
The error message already told you which one: libx264.c, which is actually in libavcodec, not MPlayer itself (but you'll find the file in libavcodec subdirectory of the MPlayer source tree ).
Last edited by nm; 8th September 2008 at 19:45. |
8th September 2008, 19:48 | #1006 | Link | |
Linux Encoder
Join Date: Feb 2004
Posts: 78
|
Quote:
Thanks for your help. I'll try it out when I get home! Edit: s/b_bframe_adaptive/i_bframe_adaptive in libx264.c in libavcodec folder of mplayer source allowed it to compile correctly. Last edited by stanjr; 9th September 2008 at 14:51. |
|
8th September 2008, 20:45 | #1007 | Link | ||
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
Code:
int pmb = (h->sps->i_mb_width - 2) * (h->sps->i_mb_height - 2) - imb; Quote:
Last edited by MasterNobody; 8th September 2008 at 20:58. |
||
9th September 2008, 02:36 | #1008 | Link |
Registered User
Join Date: Feb 2007
Location: ::1
Posts: 1,236
|
rang_x264_r965-2
Okay new build. Fixes the pthreads problem and updates gpac (Thanks, techouse!), as well as using a whole new set of patches. Now my builds seem like a copy of komisar's Sorry, komisar. Obviously credit for patches goes to you and BugMaster, and any others. I just build with whatever patches I deem useful, and after I did some VAQ2mod tests, and learned more about the others you use, that happens to be those (yeah, for all others viewing, I tried VAQ2mod and now prefer 4ver0 and 4ver1 (can't really decide between them). It's not a huge difference, and this patch is, like psy optimizations, very open to interpretation. Some may find its effects displeasing, but I do highly recommend giving it a shot).
EDIT: Went over patches with DS... gonna change things up again next time xD Home Direct download, Mirrors Code:
x264 r965 from Git (patched, fprofiled). Thanks to the x264 devs, including those who made the patches I use. Compiled by Ranguvar on September 8th, 2008, with GCC 4.3.2. This build has the pthreads issue fixed, and the gpac libs updated. DON'T think that because I used march=athlon it restricts the CPUs you can use. It seems to improve performance (VERY slightly) for all CPUs. Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA. The src folder contains the patched source code. The bin folder contains a binary executable, and a DLL for those apps that use it (May not work in AviDemux. Get those DLLs from LoRd_MuldeR). Git: git://git.videolan.org/x264.git Info, and source tarballs: http://www.videolan.org/developers/x264.html Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git Vanilla builds: http://x264.nl/ Discussion: http://forum.doom9.org/forumdisplay.php?f=77 http://forum.doom9.org/showthread.php?t=130364 Applied patches, in the order applied (included, unchanged, in the patches folder): patch -p1 -i ../x264diffs/rang_x264_version.diff patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff patch -p1 -i ../x264diffs/k.38.cosmetic.diff patch -p1 -i ../x264diffs/999.log_param.diff patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff patch -p1 -i ../x264diffs/x264_32x32samples_crash.r965.diff patch -p1 -i ../x264diffs/k.20.x264_fix_stats_file_work.r877.diff patch -p1 -i ../x264diffs/x264_multithreading_Nth_pass_ratecontrol.r965.diff patch -p1 -i ../x264diffs/x264_thread_pool.r965.diff patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff patch -p1 -i ../x264diffs/999.profiled.01.diff patch -p1 -i ../x264diffs/k.41.x264_log_file.01k.r928.diff patch -p1 -i ../x264diffs/k.47.002.VAQmod.diff patch -p1 -i ../x264diffs/k.52.PsyRD_0.6.r955.diff patch -p1 -i ../x264diffs/k.53.x264_new_bframe_decision_04.7.diff CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe" make fprofiled VIDS="../enctests/deadline_cif.y4m" Platform: X86 System: MINGW asm: yes avis input: yes mp4 output: yes pthread: yes gtk: no debug: no gprof: no PIC: no shared: yes visualize: no Last edited by Ranguvar; 9th September 2008 at 03:46. |
9th September 2008, 03:45 | #1009 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Thread pool results in a higher frame rate encoding and better cpu utilisation, as tested earlier (just confirming it works well with its latest revision). Knowing the number for the queue is the hard part, maybe for a default it could be double the number of available simultaneous threads or something? (or related to the number of threads set if not auto). VAQ2 is a hard one though, I can understand why it hasn't been added yet. I'm surprised part of it hasn't been added, and thats aq mode 3 (hybrid mode).
|
9th September 2008, 03:48 | #1010 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
--aq-mode 1 will then become VAQ, and other AQs will be insertable rather simply. |
|
9th September 2008, 03:49 | #1011 | Link |
Registered User
Join Date: Feb 2007
Location: ::1
Posts: 1,236
|
What CPU did you test with? According to DS, it should improve utilization with 8 cores and beyond, possibly with 4, and decrease utilization of less CPUs. But tests mean most. On my quad, with --threads auto, there's no difference.
|
9th September 2008, 04:02 | #1012 | Link | |
Registered User
Join Date: Feb 2007
Posts: 176
|
Quote:
This, as far as I can tell, does not build the new library (for GPAC). Look at it this way: if you extract the old library source to ~/gpac, and then cd to ~/gpac, checking out from cvs using that command will put the NEW GPAC source in ~/gpac/gpac. So, when you configure and make in ~/gpac, you're building the old libraries that you extracted, and not the ones you checked out. If you cd to ~/gpac/gpac, you'll find the new library there with its own configure. If you try to make the new library, it will fail. tl;dr: making GPAC in mingw still doesn't work, unless I misunderstand your method. EDIT: also, lol @ the massive amounts of patches circulating. More patches != better; a lot of this stuff hasn't been comitted for a reason. I'm fine with playing with the patches, but some of these (as explained by DS on #x264) make changes that don't make sense or changes that only apply to VfW. Last edited by skystrife; 9th September 2008 at 04:05. |
|
9th September 2008, 04:07 | #1013 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
There's a slight different on dual core, but then again its possibly related to filters being used etc! it wasn't a very thorough test. Its possibly related to the sharing of one core of the cpu for the avisynth filters and x264. I think avisynth filters should run at a higher priority than x264 so x264 doesn't take processing time away from the avisynth filters, which could potentially improve performance (this could be the case even with a multithreaded avisynth). That way there is an improved flow of data to x264, and in the case where there isn't an avisynth filter bottleneck x264 can still utilise that processing capability. Besides the basic 'realtime, abovenormal, normal, below normal, low, and idle priorities, isn't there a more thorough scale that can be utilised? such that even if the priority of x264 is set to low, the avisynth filters runs at a priority of between low and below normal and hence you end up with potentially faster processing...
(I'm guessing threal pool has an effect such as this, in a way) |
9th September 2008, 05:00 | #1014 | Link |
x264aholic
Join Date: Jul 2007
Location: New York
Posts: 1,752
|
I remember the thread pool patch from a very long time ago --- It was back when someone had access to dual quad cores (What a dream..) or something to that effect, and the thread pool patch increased encoding speed and CPU utilization a good deal.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame. |
9th September 2008, 09:38 | #1015 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
Ranguvar
Check you build for --log-file... (k.41.x264_log_file.01k.r928.diff) This patch should be applied as soon as possible. P.S. See encoder/encoder.c. File close earlier than shown recent data in "void x264_encoder_close ( x264_t *h )" New version of this patch without depending on applying order: k.54.x264_log_file.02k.r928.diff Last edited by komisar; 9th September 2008 at 10:21. |
9th September 2008, 09:57 | #1016 | Link | |
aka XaS
Join Date: Jun 2005
Location: France
Posts: 1,122
|
Quote:
__________________
Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS |
|
9th September 2008, 12:35 | #1017 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
skystrife, this is my working script for build GPAC from CVS (static lib, static mp4box) for specified platform:
Code:
#!/bin/sh g_cvs=~/gpac g_bld=~/gpac.bld # Update GPAC from CVS cd ${g_cvs} export CVSROOT=:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac #cvs login #....for initial grab source #cvs checkout gpac #....for update cvs update # Make building environment mkdir -p ${g_bld} rm -rf ${g_bld}/* cp -rf ${g_cvs}/* ${g_bld}/ cd ${g_bld}/gpac #o_arch=generic ; cf_ar="-mtune=generic" #o_arch=i686 ; cf_ar="-march=i686 -mtune=i686" o_arch=nocona ; cf_ar="-march=nocona -mtune=nocona" #o_arch=k8 ; cf_ar="-march=k8 -mtune=k8" #o_arch=k8-sse3 ; cf_ar="-march=k8-sse3 -mtune=k8-sse3" #o_arch=amdfam10 ; cf_ar="-march=amdfam10 -mtune=amdfam10" #o_arch=core2 ; cf_ar="-march=core2 -mtune=core2" o_cmn="-O4 -finline-functions -mno-cygwin -mwin32 -m32 -fno-strict-aliasing -Wno-pointer-sign" cf="${o_cmn} ${cf_ar}" mkdir -p "/arch/${o_arch}" o1="--prefix=/arch/${o_arch}" o2="--strip \ --disable-ipv6 \ --disable-wx \ --disable-oss-audio \ --disable-x11-shm \ --disable-x11-xv \ --disable-opengl \ --disable-ssl \ --use-js=no \ --use-ft=no \ --use-jpeg=no \ --use-png=no \ --use-faad=no \ --use-mad=no \ --use-xvid=no \ --use-ffmpeg=no \ --use-ogg=no \ --use-vorbis=no \ --use-theora=no \ --use-openjpeg=no \ --disable-shared \ --enable-static \ --extra-ldflags=-s" ./configure $o1 $o2 cp -f ./config.h include/gpac/internal/ cp config.mak config.mak2 sed -e "s/OPTFLAGS.*/& ${o_cmn} ${cf_ar}/; s/CPPFLAGS.*/& ${o_cmn} ${cf_ar}/" config.mak2 > config.mak #... Make LIB (static) make lib make install-lib #... Make mp4box.exe cd applications/mp4box mv -f Makefile Makefile.orig sed -e "s/^LINKFLAGS+=/#.LINKFLAGS+=/; s/#LINKFLAGS+=/LINKFLAGS+=/" Makefile.orig > Makefile make cd ../../ mkdir -p /arch/${o_arch}/bin cp -f bin/gcc/MP4Box.exe /arch/${o_arch}/bin/ |
9th September 2008, 16:22 | #1018 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
doing mtune with march is redundant: march calls mtune as well
Quote:
|
|
9th September 2008, 16:29 | #1019 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
This is only work example to compile GPAC. Modify this as you wish...
And I usually use full line/options, that there was no misunderstanding ... Last edited by komisar; 9th September 2008 at 16:32. |
10th September 2008, 14:28 | #1020 | Link |
Registered User
Join Date: Feb 2007
Posts: 176
|
new_bframe_decision patch breaks with the new revision.
And as I was going through the patch, there are still really stupid lines in it (for example, removing a line and replacing it with the same exact line). I'm going to wait and see if there's another "official" patch made for it before making my build. |
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
Thread Tools | Search this Thread |
Display Modes | |
|
|