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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th September 2008, 18:34   #1001  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
--badapt 2 patch breaks API compatibility. To fix, s/b_bframe_adaptive/i_bframe_adaptive in mplayer code.
Dark Shikari is offline   Reply With Quote
Old 8th September 2008, 19:05   #1002  |  Link
stanjr
Linux Encoder
 
Join Date: Feb 2004
Posts: 78
DS, what do you mean by that (I'm a noob when it comes to altering code)? Do you mean to search and replace instances of code with something? In which files?
stanjr is offline   Reply With Quote
Old 8th September 2008, 19:29   #1003  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
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)
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 8th September 2008, 19:31   #1004  |  Link
stanjr
Linux Encoder
 
Join Date: Feb 2004
Posts: 78
Okay, that is easy enough. I do this in every single mplayer code file? To save time, would you know which ones specifically by chance?
stanjr is offline   Reply With Quote
Old 8th September 2008, 19:43   #1005  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,641
Quote:
Originally Posted by stanjr View Post
Okay, that is easy enough. I do this in every single mplayer code file? To save time, would you know which ones specifically by chance?
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.
nm is offline   Reply With Quote
Old 8th September 2008, 19:48   #1006  |  Link
stanjr
Linux Encoder
 
Join Date: Feb 2004
Posts: 78
Quote:
Originally Posted by nm View Post
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 ).
Duh!

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.
stanjr is offline   Reply With Quote
Old 8th September 2008, 20:45   #1007  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by Gabriel_Bouvigne View Post
The 32x32 fix seems really strange, especially the "pmb = -imb;" line. Did you intended to have a negative number of P MB ?
It is OK because pmb is only used for x264_log. Also I think imb in this situation would be always equal zero and so pmb would be also zero (also negative value in log would indicate that something is going strange). By the way without the patch the result of
Code:
int pmb = (h->sps->i_mb_width - 2) * (h->sps->i_mb_height - 2) - imb;
would be even less predictable. If h->sps->i_mb_width==2 or h->sps->i_mb_height==2 then the result would be again -imb. But if the h->sps->i_mb_width==1 and h->sps->i_mb_height>2 then the result would be 2-h->sps->i_mb_height-imb (and so pmb would be negative 100%)
Quote:
Originally Posted by Ranguvar View Post
Thanks very much, BugMaster - that may be what I'm looking for. I'll test ASAP.

Will all your updated patches be here always? http://komisar.gin.by/x.patch/BugMaster/
No. Only when komisar update them (it is his host, not my). Sometimes I give new versions to him directly (or post on the another forum), and sometimes post them here (as today) or in x264dev mailing list.

Last edited by MasterNobody; 8th September 2008 at 20:58.
MasterNobody is offline   Reply With Quote
Old 9th September 2008, 02:36   #1008  |  Link
Ranguvar
Registered User
 
Ranguvar's Avatar
 
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.
Ranguvar is offline   Reply With Quote
Old 9th September 2008, 03:45   #1009  |  Link
burfadel
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).
burfadel is offline   Reply With Quote
Old 9th September 2008, 03:48   #1010  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by burfadel View Post
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).
AQ mode 1 will eventually be removed completely once I modify VBV to take advantage of AQ. The patch is mostly ready but needs some bugfixes and tweaks.

--aq-mode 1 will then become VAQ, and other AQs will be insertable rather simply.
Dark Shikari is offline   Reply With Quote
Old 9th September 2008, 03:49   #1011  |  Link
Ranguvar
Registered User
 
Ranguvar's Avatar
 
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.
Ranguvar is offline   Reply With Quote
Old 9th September 2008, 04:02   #1012  |  Link
skystrife
Registered User
 
skystrife's Avatar
 
Join Date: Feb 2007
Posts: 176
Quote:
Originally Posted by techouse View Post
Ranguvar:
I guess you got GCC-4.3.2 from TDM's website and have overwritten all your old files with the new ones from TDM's zip/tar.gz packages. The problem is that the gcc-4.3.2-tdm-1-core.tar.gz package includes pthreadGC2.dll and pthreadGCE2.dll in its /bin folder, libpthreadGCE2.a, libpthreadGC2-static.a and libpthread.a in its /lib folder and pthread.h, sched.h and semaphore.h in its /include folder. You probably copied over those files to your MinGW /bin, your MinGW /include and your MinGW /lib folder folder.
I suggest you remove all these files, get the latest pthread cvs (cvs -d server:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads), compile (make clean GC-static) and install it (copy libpthreadGC2.a to your MinGW /lib folder and copy pthread.h, sched.h and semaphore.h to your MinGW /iclude folder). That way you will eliminate the need of x264.exe for an extra pthreadGC2.dll in C:\Windows\System32.
Trust me on this one, I had the same problem.

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

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

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.
skystrife is offline   Reply With Quote
Old 9th September 2008, 04:07   #1013  |  Link
burfadel
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)
burfadel is offline   Reply With Quote
Old 9th September 2008, 05:00   #1014  |  Link
Sagekilla
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.
Sagekilla is offline   Reply With Quote
Old 9th September 2008, 09:38   #1015  |  Link
komisar
Registered User
 
komisar's Avatar
 
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
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..

Last edited by komisar; 9th September 2008 at 10:21.
komisar is offline   Reply With Quote
Old 9th September 2008, 09:57   #1016  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
Quote:
Originally Posted by Sagekilla View Post
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.
Here it is (thread started by morph166955) : http://forum.doom9.org/showthread.php?t=124557

__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Old 9th September 2008, 12:35   #1017  |  Link
komisar
Registered User
 
komisar's Avatar
 
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/
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..
komisar is offline   Reply With Quote
Old 9th September 2008, 16:22   #1018  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
doing mtune with march is redundant: march calls mtune as well
Quote:
Originally Posted by gcc man pages
Moreover, specifying -march=cpu-type implies -mtune=cpu-type.
and all of those disable and use no's on the libraries are redundant as they are defaulted off in the configure as is as well.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 9th September 2008, 16:29   #1019  |  Link
komisar
Registered User
 
komisar's Avatar
 
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 ...
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..

Last edited by komisar; 9th September 2008 at 16:32.
komisar is offline   Reply With Quote
Old 10th September 2008, 14:28   #1020  |  Link
skystrife
Registered User
 
skystrife's Avatar
 
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.
skystrife is offline   Reply With Quote
Reply

Tags
h.264, x264, x264 builds, x264 patches, x264 unofficial builds

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.