http://blog.gmane.org/gmane.comp.video.x264.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.video.x264.devel/9615 <pre>I am trying to compile on Mac OS X with the latest XCode, for use it with FFmpeg... I just did: ./configure make I am getting... yasm: could not open file `common/x86/const-a.o' make: *** [common/x86/const-a.o] Error 1 Any hints? _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Wagner Patriota 2013-06-19T15:22:57 http://comments.gmane.org/gmane.comp.video.x264.devel/9614 <pre> &gt;&gt; What I was thinking was that on -p 2 and -p 3 videos frame structure is &gt;&gt; already known. So for example dividing encoding between CPU and GPU could be &gt;&gt; done taking frames from one I frame to next. CPU encodes one IPB set while &gt;&gt; GPU encodes another IPB set. &gt; &gt;You can't do that in an inter-frame video format; each frame depends &gt;on the encoded versions of previous frames. If you want to do that, &gt;you need to thread on a per-GOP level, which is basically equivalent &gt;to splitting up the video and sending it to two entirely different &gt;encoding apps -- which you can already do. When it comes to h.264 (x264) GOP is what I was thinking of. Since my own video codec coding experience is over decade old and at that time and with the codec I was playing with IPB set was independent structure which could be encoded independently without problems since there wasn't outside references to B-frames. I know this from the fact because I implemented multi-threading to that codec while it was single thread encoder at the beginning. Goal of that implementation was to utilize all CPU power on dual CPU systems. It's kind of sad that there isn't dual CPU MoBo's in consumer space anymore. Most people can't buy Xeon etc dual CPU systems but dual CPU Haswell could be nice for some consumers. Well personally I haven't looked into how to split video stream and direct it to two encoding application where one uses CPU and other uses GPU and after that combines output from those two application into one video stream. Frankly speaking that's not my cup of tea. When there is at least 3 or 4 different application doing just video stream encoding and adding multiplexing and synching to that, whole system gets way too complex for my taste. When system gets more complex risk of something going wrong gets higher. &gt;&gt; and if or when this isn't valid idea / process &gt;&gt; other ideas and maybe even some implementation can be looked from (in this &gt;&gt; case nVidia code, AMD might have something similar but since I haven't used &gt;&gt; ATI after early 2000 I don't know what they have to offer). &gt;&gt; &gt;&gt; https://developer.nvidia.com/nvidia-video-codec-sdk &gt;&gt; NVCUVENC - CUDA-Based Video Encoding &gt;&gt; NVCUVENC is a hybrid CPU/GPU accelerated library with related code samples &gt;&gt; that creates video streams compliant with AVC/H.264. &gt; &gt;nVidia's CUDA encoder is at best mediocre, in terms of speed, &gt;compression and features. They added a hardware encoder because the &gt;CUDA encoder wasn't able to provide good enough results to be useful. &gt; &gt;It is not something we could possibly call "x264-grade" with a straight face. If you say so. That nVidia CUDA encoder was just an example. As I said earlier there are reasons which limit time I can use for things like this. From where we get to "asking personal starship" and me asking generic things like "adding OpenCL/GPU support to -p 2 and -p 3". Personally I don't have time to start to implement this kind of functionality and I don't even have enough time to make some decent research which could have pointed out that NVCUVENC performance isn't that great and it doesn't meet x264 requirements. So best I could do was to ask if x264 developers have ideas, time, interest, something to expand OpenCL/GPU usage in x264 and improve encoding speed. Should we stop here since I don't have code etc to contribute and my spare time is barely enough for sending few e-mails. Thank you from answers and your time, sorry about inconvenience. &gt;Jason _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Nihil 2013-06-19T08:01:25 http://comments.gmane.org/gmane.comp.video.x264.devel/9605 <pre>--- version.sh | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/version.sh b/version.sh index 5466ef2..47d51b0 100755 --- a/version.sh +++ b/version.sh &lt; at &gt;&lt; at &gt; -1,5 +1,8 &lt; at &gt;&lt; at &gt; #!/bin/bash [ -n "$1" ] &amp;&amp; cd $1 + +git_version() { +trap 'rm -f config.git-hash' EXIT git rev-list HEAD | sort &gt; config.git-hash LOCALVER=`wc -l config.git-hash | awk '{print $1}'` if [ $LOCALVER \&gt; 1 ] ; then &lt; at &gt;&lt; at &gt; -15,10 +18,10 &lt; at &gt;&lt; at &gt; if [ $LOCALVER \&gt; 1 ] ; then fi VER="$VER $(git rev-list HEAD -n 1 | cut -c 1-7)" echo "#define X264_VERSION \" r$VER\"" -else - echo "#define X264_VERSION \"\"" - VER="x" fi -rm -f config.git-hash +} + +VER="x" +[ -d .git ] &amp;&amp; git_version || echo "#define X264_VERSION \"\"" API=`grep '#define X264_BUILD' &lt; x264.h | sed -e 's/.* \([1-9][0-9]*\).*/\1/'` echo "#define X264_POINTVER \"0.$API.$VER\"" </pre> Sean McGovern 2013-06-17T07:42:08 http://comments.gmane.org/gmane.comp.video.x264.devel/9603 <pre> &gt;&gt;&gt;&gt; So which leaves adding OpenCL support on -p 2 and -p 3. &gt;&gt;&gt; &gt;&gt;&gt;Multi-pass encoding performs the lookahead on the first pass; the &gt;&gt;&gt;lookahead doesn't run on the second pass, so there would be nothing &gt;&gt;&gt;for OpenCL to do. &gt;&gt; &gt;&gt; Well this is my bad, I wasn't expressing myself clearly. What my improvement &gt;&gt; proposal kept in it and what I was thinking but not explaining obviously is &gt;&gt; following. &gt;&gt; &gt;&gt; To expand OpenCL and GPU usage for all possible work areas not just &gt;&gt; lookahead. After all OpenCL &amp; GPU's are used for Bitcoin mining, password &gt;&gt; cracking, in heavy industry for making strength assessment, in &gt;&gt; supercomputers etc. So in sense like SMP work would be divided between CPU &gt;&gt; and GPU where some of the frames are processed in CPU and others in GPU. &gt; &gt;I'm confused; where is your proposal? Do you have a document &gt;explaining how you intend to deal specifically with the &gt;synchronization and parallelism problems inherent in GPU video &gt;compression and interaction with an existing CPU encoder, as well as &gt;restructuring or replacing all the various algorithms for which &gt;efficient GPU implementation are impossible? &gt; &gt;It is very easy to say that you want something extraordinary to happen &gt;(e.g. "I want a billion dollars and a personal starship"), but on its &gt;own not very useful without some kind of plan ("how I intend to earn a &gt;billion dollars and build a personal starship"). You are absolutely correct here it's easy for me to say or ask personal starship and that's exactly what I did. As 35 years old father who works full time I may have hour or two in week for side projects. Even though I work in software development and network industry sadly doesn't mean that I have a lot of time to code outside of work. So most I can do is ask that personal starship. Now without comprehensive internal knowledge of x264 source code etc. What I was thinking was that on -p 2 and -p 3 videos frame structure is already known. So for example dividing encoding between CPU and GPU could be done taking frames from one I frame to next. CPU encodes one IPB set while GPU encodes another IPB set. And if or when this isn't valid idea / process other ideas and maybe even some implementation can be looked from (in this case nVidia code, AMD might have something similar but since I haven't used ATI after early 2000 I don't know what they have to offer). https://developer.nvidia.com/nvidia-video-codec-sdk NVCUVENC - CUDA-Based Video Encoding NVCUVENC is a hybrid CPU/GPU accelerated library with related code samples that creates video streams compliant with AVC/H.264. Sure it's CUDA code but porting it to OpenCL should be possible on most parts. If it isn't well there is always more work requiring option which is GPU architecture specific implementation. So here I'm asking personal starship. &gt;Jason _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Nihil 2013-06-14T07:24:55 http://comments.gmane.org/gmane.comp.video.x264.devel/9601 <pre>According to http://www.itu.int/rec/T-REC-H.264-201304-I/ _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Harfe Leier 2013-06-15T13:58:49 http://comments.gmane.org/gmane.comp.video.x264.devel/9599 <pre> &gt;&gt; So which leaves adding OpenCL support on -p 2 and -p 3. &gt; &gt;Multi-pass encoding performs the lookahead on the first pass; the &gt;lookahead doesn't run on the second pass, so there would be nothing &gt;for OpenCL to do. Well this is my bad, I wasn't expressing myself clearly. What my improvement proposal kept in it and what I was thinking but not explaining obviously is following. To expand OpenCL and GPU usage for all possible work areas not just lookahead. After all OpenCL &amp; GPU's are used for Bitcoin mining, password cracking, in heavy industry for making strength assessment, in supercomputers etc. So in sense like SMP work would be divided between CPU and GPU where some of the frames are processed in CPU and others in GPU. How many actually do something else which needs GPU while encoding videos? For example me, video encoding is only thing I do at that moment, even --threads 8 I usually use tells something which is that CPU is 99% utilized but GPU utilization is 0%. I know that there is limitations what GPU's can do and bandwidth between main memory and GPU memory slows things down etc etc. But I have wishful thinking that there is some operations which can be speed up with using GPU's other than just lookahead. Anyway thank you about reading my rant and giving reasonable answers. &gt;Jason _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Nihil 2013-06-12T07:23:16 http://comments.gmane.org/gmane.comp.video.x264.devel/9596 <pre>HI， when I cross-compile libx264, there are some error. I have to changed the MakeFile to proceed: 1. add a space after each $(LD) and $(AR) 2. add "-r" after each $(AR) 3. delete $&lt; at &gt; after each $(LD) when make, I cannot use LD=/dir/powerpc-linux-ld, but only LD=/dir/powerpc-linux-gcc. Or other wise it cannot pass. here is the message, will someone help me? ＃./configure --enable-static --host=ppc-linux --disable-asm --prefix=/usr/local/powerpc-none-linux-gnuspe platform: PPC system: LINUX cli: yes libx264: internal shared: no static: yes asm: no interlaced: yes avs: avxsynth lavf: no ffms: no gpac: no gpl: yes thread: posix opencl: yes filters: crop select_every debug: no gprof: no strip: no PIC: no visualize: no bit depth: 8 chroma format: all ＃make CC=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc RANLIB=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ranlib LD=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ld AR=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ar STRIP=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-strip … … … /usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ld: warning: cannot find entry symbol _start; defaulting to 10001524 x264.o: In function `print_status': x264.c:(.text+0x184): undefined reference to `__floatdidf' x264.c:(.text+0x1ac): undefined reference to `__floatdidf' x264.c:(.text+0x238): undefined reference to `__divdi3' x264.c:(.text+0x3ac): undefined reference to `__floatdidf' x264.c:(.text+0x3f0): undefined reference to `__floatdidf' x264.o: In function `encode': x264.c:(.text+0x744): undefined reference to `__divdi3' x264.c:(.text+0x750): undefined reference to `__divdi3' x264.c:(.text+0x970): undefined reference to `__fixdfdi' x264.c:(.text+0xa40): undefined reference to `__floatdidf' x264.c:(.text+0xd70): undefined reference to `__floatdidf' x264.c:(.text+0xdbc): undefined reference to `__fixdfdi' x264.c:(.text+0xf18): undefined reference to `__floatdidf' x264.c:(.text+0xfec): undefined reference to `__floatdidf' x264.c:(.text+0x1030): undefined reference to `__floatdidf' x264.c:(.text+0x126c): undefined reference to `__floatdidf' x264.o: In function `main': x264.c:(.text+0x3fd8): undefined reference to `__floatundidf' x264.c:(.text+0x3ff8): undefined reference to `__floatundidf' input/input.o: In function `x264_cli_pic_plane_size': input.c:(.text+0x120): undefined reference to `__floatundisf' input.c:(.text+0x128): undefined reference to `__fixunssfdi' input.c:(.text+0x17c): undefined reference to `__floatundisf' input.c:(.text+0x184): undefined reference to `__fixunssfdi' input/input.o: In function `x264_cli_pic_alloc': input.c:(.text+0x2e0): undefined reference to `__floatundisf' input.c:(.text+0x370): undefined reference to `__fixunssfdi' input.c:(.text+0x62c): undefined reference to `__fixunssfdi' input/input.o: In function `x264_cli_pic_size': input.c:(.text+0x6cc): undefined reference to `__floatundisf' input.c:(.text+0x704): undefined reference to `__fixunssfdi' input.c:(.text+0x7a8): undefined reference to `__fixunssfdi' input/timecode.o: In function `try_mkv_timebase_den': timecode.c:(.text+0x254): undefined reference to `__fixunsdfdi' timecode.c:(.text+0x2fc): undefined reference to `__umoddi3' input/timecode.o: In function `correct_fps': timecode.c:(.text+0x444): undefined reference to `__floatundidf' timecode.c:(.text+0x4a4): undefined reference to `__fixunsdfdi' timecode.c:(.text+0x53c): undefined reference to `__floatundidf' timecode.c:(.text+0x5ac): undefined reference to `__umoddi3' timecode.c:(.text+0x5d4): undefined reference to `__udivdi3' input/timecode.o: In function `open_file': timecode.c:(.text+0xe60): undefined reference to `__floatundidf' timecode.c:(.text+0xee0): undefined reference to `__fixunsdfdi' timecode.c:(.text+0xf38): undefined reference to `__umoddi3' timecode.c:(.text+0xf64): undefined reference to `__udivdi3' timecode.c:(.text+0xf9c): undefined reference to `__floatundidf' timecode.c:(.text+0x12b0): undefined reference to `__umoddi3' timecode.c:(.text+0x12f4): undefined reference to `__udivdi3' timecode.c:(.text+0x1318): undefined reference to `__udivdi3' timecode.c:(.text+0x138c): undefined reference to `__floatundidf' timecode.c:(.text+0x13a8): undefined reference to `__floatundidf' timecode.c:(.text+0x1400): undefined reference to `__fixdfdi' input/timecode.o: In function `read_frame': timecode.c:(.text+0x1b30): undefined reference to `__floatundidf' timecode.c:(.text+0x1b48): undefined reference to `__floatundidf' timecode.c:(.text+0x1b88): undefined reference to `__fixdfdi' timecode.c:(.text+0x1bb0): undefined reference to `__floatundidf' timecode.c:(.text+0x1bc8): undefined reference to `__floatundidf' timecode.c:(.text+0x1c24): undefined reference to `__fixdfdi' input/raw.o: In function `open_file': raw.c:(.text+0x21c): undefined reference to `__udivdi3' raw.c:(.text+0x450): undefined reference to `__udivdi3' input/y4m.o: In function `open_file': y4m.c:(.text+0x6a4): undefined reference to `__udivdi3' y4m.c:(.text+0x884): undefined reference to `__udivdi3' output/matroska.o: In function `set_param': matroska.c:(.text+0xa4): undefined reference to `__divdi3' matroska.c:(.text+0xf8): undefined reference to `__divdi3' matroska.c:(.text+0x11c): undefined reference to `__divdi3' output/matroska.o: In function `close_file': matroska.c:(.text+0x184): undefined reference to `__divdi3' matroska.c:(.text+0x188): undefined reference to `__floatdidf' matroska.c:(.text+0x1c0): undefined reference to `__fixdfdi' output/matroska.o: In function `write_frame': matroska.c:(.text+0x294): undefined reference to `__floatdidf' matroska.c:(.text+0x2f4): undefined reference to `__fixdfdi' output/matroska_ebml.o: In function `mk_flush_frame': matroska_ebml.c:(.text+0x1308): undefined reference to `__divdi3' matroska_ebml.c:(.text+0x1490): undefined reference to `__divdi3' output/matroska_ebml.o: In function `mk_close': matroska_ebml.c:(.text+0x1dec): undefined reference to `__floatdidf' matroska_ebml.c:(.text+0x1e04): undefined reference to `__floatdidf' output/flv.o: In function `write_frame': flv.c:(.text+0xa4): undefined reference to `__floatdidf' flv.c:(.text+0xd8): undefined reference to `__fixdfdi' flv.c:(.text+0xf4): undefined reference to `__floatdidf' flv.c:(.text+0x124): undefined reference to `__fixdfdi' flv.c:(.text+0x340): undefined reference to `__divdi3' flv.c:(.text+0x35c): undefined reference to `__floatdidf' flv.c:(.text+0x390): undefined reference to `__fixdfdi' flv.c:(.text+0x3e4): undefined reference to `__floatdidf' flv.c:(.text+0x41c): undefined reference to `__fixdfdi' flv.c:(.text+0x450): undefined reference to `__floatdidf' flv.c:(.text+0x484): undefined reference to `__fixdfdi' flv.c:(.text+0x510): undefined reference to `__floatdidf' flv.c:(.text+0x54c): undefined reference to `__fixdfdi' output/flv.o: In function `close_file': flv.c:(.text+0xd50): undefined reference to `__floatdidf' flv.c:(.text+0xe48): undefined reference to `__floatundidf' flv.c:(.text+0xee4): undefined reference to `__floatundidf' flv.c:(.text+0xfbc): undefined reference to `__floatdidf' filters/video/select_every.o: In function `init': select_every.c:(.text+0x4b0): undefined reference to `__udivdi3' libx264.a(common.o): In function `x264_reduce_fraction64': common.c:(.text+0x10c): undefined reference to `__umoddi3' common.c:(.text+0x130): undefined reference to `__umoddi3' common.c:(.text+0x164): undefined reference to `__udivdi3' common.c:(.text+0x180): undefined reference to `__udivdi3' libx264.a(set.o): In function `x264_validate_levels': set.c:(.text+0x288): undefined reference to `__divdi3' libx264.a(encoder.o): In function `x264_encoder_open_133': encoder.c:(.text+0x3f84): undefined reference to `__udivdi3' libx264.a(encoder.o): In function `x264_encoder_frame_end': encoder.c:(.text+0x651c): undefined reference to `__floatdidf' encoder.c:(.text+0x6594): undefined reference to `__floatdidf' encoder.c:(.text+0x6600): undefined reference to `__floatdidf' encoder.c:(.text+0x6668): undefined reference to `__floatdidf' libx264.a(encoder.o): In function `x264_encoder_close': encoder.c:(.text+0x6a94): undefined reference to `__floatdidf' libx264.a(encoder.o):encoder.c:(.text+0x6b18): more undefined references to `__floatdidf' follow libx264.a(set.o): In function `x264_cqm_init': set.c:(.text+0x1120): undefined reference to `__udivdi3' set.c:(.text+0x1164): undefined reference to `__udivdi3' set.c:(.text+0x11a8): undefined reference to `__udivdi3' set.c:(.text+0x11ec): undefined reference to `__udivdi3' set.c:(.text+0x1230): undefined reference to `__udivdi3' libx264.a(set.o):set.c:(.text+0x1274): more undefined references to `__udivdi3' follow libx264.a(analyse.o): In function `x264_weights_analyse': analyse.c:(.text+0x102d0): undefined reference to `__floatundisf' analyse.c:(.text+0x102e0): undefined reference to `__floatundisf' analyse.c:(.text+0x10358): undefined reference to `__floatundisf' analyse.c:(.text+0x10368): undefined reference to `__floatundisf' analyse.c:(.text+0x103d8): undefined reference to `__floatundisf' libx264.a(analyse.o):analyse.c:(.text+0x103e8): more undefined references to `__floatundisf' follow libx264.a(analyse.o): In function `x264_slicetype_frame_cost': analyse.c:(.text+0x11014): undefined reference to `__udivdi3' analyse.c:(.text+0x11460): undefined reference to `__udivdi3' libx264.a(analyse.o): In function `x264_slicetype_analyse': analyse.c:(.text+0x18290): undefined reference to `__floatdidf' analyse.c:(.text+0x182d4): undefined reference to `__floatdidf' analyse.c:(.text+0x183e0): undefined reference to `__floatdidf' analyse.c:(.text+0x18424): undefined reference to `__floatdidf' libx264.a(analyse.o): In function `x264_slicetype_decide': analyse.c:(.text+0x19498): undefined reference to `__floatdidf' libx264.a(analyse.o):analyse.c:(.text+0x19b00): more undefined references to `__floatdidf' follow libx264.a(analyse.o): In function `x264_mb_analyse_transform_rd': analyse.c:(.text+0x22fb0): undefined reference to `__divdi3' libx264.a(ratecontrol.o): In function `x264_hrd_fullness': ratecontrol.c:(.text+0x720): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x760): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x794): undefined reference to `__floatundisf' ratecontrol.c:(.text+0x7a4): undefined reference to `__floatdisf' ratecontrol.c:(.text+0x7d0): undefined reference to `__floatundisf' ratecontrol.c:(.text+0x858): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x890): undefined reference to `__udivdi3' libx264.a(ratecontrol.o): In function `x264_adaptive_quant_frame': ratecontrol.c:(.text+0x165c): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x16d8): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x1740): undefined reference to `__udivdi3' libx264.a(ratecontrol.o): In function `get_qscale': ratecontrol.c:(.text+0x3634): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x3788): undefined reference to `__floatdidf' libx264.a(ratecontrol.o): In function `x264_ratecontrol_init_reconfigurable': ratecontrol.c:(.text+0x3c54): undefined reference to `__fixdfdi' libx264.a(ratecontrol.o): In function `init_pass2': ratecontrol.c:(.text+0x430c): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x4368): undefined reference to `__fixunsdfdi' ratecontrol.c:(.text+0x4624): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x4748): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x4b9c): undefined reference to `__floatundidf' ratecontrol.c:(.text+0x5330): undefined reference to `__fixunsdfdi' ratecontrol.c:(.text+0x57ac): undefined reference to `__floatundidf' ratecontrol.c:(.text+0x58d4): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x5ccc): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x6170): undefined reference to `__floatdidf' ratecontrol.c:(.text+0x62e0): undefined reference to `__fixunsdfdi' ratecontrol.c:(.text+0x649c): undefined reference to `__fixdfdi' ratecontrol.c:(.text+0x64cc): undefined reference to `__fixdfdi' ratecontrol.c:(.text+0x68b4): undefined reference to `__floatdidf' libx264.a(ratecontrol.o): In function `x264_ratecontrol_new': ratecontrol.c:(.text+0x6ec8): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x6ee8): undefined reference to `__udivdi3' ratecontrol.c:(.text+0x6eec): undefined reference to `__floatundidf' libx264.a(ratecontrol.o): In function `x264_ratecontrol_end': ratecontrol.c:(.text+0xa0b0): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xa1ac): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xa6d8): undefined reference to `__udivdi3' ratecontrol.c:(.text+0xa730): undefined reference to `__floatdidf' libx264.a(ratecontrol.o): In function `rate_estimate_qscale': ratecontrol.c:(.text+0xa9c8): undefined reference to `__fixdfdi' ratecontrol.c:(.text+0xaa08): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xaaec): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xaf38): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xafa0): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xb1c8): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xb214): undefined reference to `__fixdfdi' ratecontrol.c:(.text+0xb23c): undefined reference to `__floatundidf' ratecontrol.c:(.text+0xb270): undefined reference to `__floatundidf' ratecontrol.c:(.text+0xb360): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xb3b0): undefined reference to `__fixdfdi' libx264.a(ratecontrol.o): In function `x264_ratecontrol_start': ratecontrol.c:(.text+0xc050): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xc09c): undefined reference to `__divdi3' ratecontrol.c:(.text+0xc0a0): undefined reference to `__floatdidf' ratecontrol.c:(.text+0xc388): undefined reference to `__floatdidf' libx264.a(macroblock.o): In function `x264_noise_reduction_update': macroblock.c:(.text+0x1538): undefined reference to `__udivdi3' make: *** [x264] error 1 _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> 董 瑞涛 2013-06-12T14:27:49 http://comments.gmane.org/gmane.comp.video.x264.devel/9592 <pre>Thank you from answering and doing that pretty fast. &gt;&gt; x264 [error]: malloc of size 10031104 failed &gt;&gt; x264 [error]: x264_encoder_encode failed &gt; &gt;Your system ran out of allocateable memory when using very &gt;memory-intensive x264 settings; this is not a bug in x264. If you need &gt;to use settings that require more than 4GB of address space, I suggest &gt;you upgrade to 64-bit x264. I somewhat disagree here. Here's information I got with ProcessHacker. No -p option Peak Working Set 1,23GB Peak Virtual Size 1,94GB Peak Private Bytes 1,76GB x264 [error]: malloc of size 10031104 failed x264 [error]: x264_encoder_encode failed -p 1 Peak Working Set 1,14GB Peak Virtual Size 1,78GB Peak Private Bytes 1,59GB And the video file was same as in my original post. 1920*1200 15fps fraps avi which has 255 frames and size is around 467MB. So only thing that gets close to 2GB barrier while there isn't -p option used is virtual size. But even if 2GB barrier is culprit I was kind of expecting that x264 project has defined IMAGE_FILE_LARGE_ADDRESS_AWARE flag to be set in 32bit Windows makefile in which case x264 could hoard 3GB of memory in 32bit Windows systems. Going forward from malloc fail, is OpenCL supported in -p 2 and -p 3? If not then that improvement comment was valid. (of course it could be somewhat possible that memory handling caused OpenCL message not to be shown with -p 2 and -p 3) Now out of topic. I actually do have 64bit Windows 7 Pro but sadly it doesn't support my old trusted NIC (3Com 3C905B). So I have been waiting to make some bigger HW upgrades but . . . And installing 64bit Linux well there's other reasons against that. &gt;&gt; Add commandline option for storing ffms file index. I deal with large static &gt;&gt; files (not using AviSynth or some such) and when doing "Nth pass" a lot of &gt;&gt; time is wasted. It would be nice if file index could be saved in same manner &gt;&gt; as x264_lookahead.clbin x264_2pass.log x264_2pass.log.mbtree files so file &gt;&gt; indexing needs to be done only once. Thank you about this. From some reason my brain didn't connect this parameter to ffms and storing the index. Oh well everyone needs brain barf from time to time. &gt;This is what --index does. &gt; &gt;Jason _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Nihil 2013-06-11T16:18:06 http://comments.gmane.org/gmane.comp.video.x264.devel/9591 <pre>Hi, Does x264 encoder support loss resilience features?: - Flexible macroblock ordering (FMO) - Arbitrary slice ordering (ASO) - Redundant slices (RS) Thank you. Regards, Leo Born _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Leo Born 2013-06-11T15:09:02 http://comments.gmane.org/gmane.comp.video.x264.devel/9590 <pre> http://www.doctorhealth.tw/components/com_mailto/facebook.php?kawocdtdq795unasb.html mightyzdx 赵德祥 ********** No academic ever expects to be taken seriously by more than three other people, because really, we write for three other people in our field. -- Howard Gardner _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> 赵德祥 2013-06-11T19:04:41 http://comments.gmane.org/gmane.comp.video.x264.devel/9588 <pre>I'm sorry that I can't provide dumps or debug traces of what happens. I'm also sorry about the fact that I haven't tested out every possible commandline variation. I downloaded precompiled 32bit Windows executable from x264.nl. x264 executable: 8bit-depth 32bit Windows Test system: 32bit Windows XP, nVidia GFX 670 driver 320.18 WHQL Test video: 1920*1200 Fraps v3.5.9.15586 AVI Problems: Using parameters -p 1 -p 2 -p 3 Fast "indexing input file" NO -p options Slow "indexing input file" ------------------------------------------------------------- -p 1 | OpenCL acceleration enabled - Works -p 2 | OpenCL not enabled -p 3 | OpenCL not enabled NO -p options | OpenCL acceleration enabled - But fails ------------------------------------------------------------- x264_2334.exe -I 150 -b 100 --b-adapt 2 -B 4000 -m 10 -t 2 --direct auto --me esa --merange 24 --partitions all --ref 16 --rc-lookahead 60 --threads 8 --opencl --qpmin 5 --log-level debug -o test.flv test_enc.avi ffms [info]: 1920x1200p 0:1 &lt; at &gt; 15/1 fps (vfr) x264 [debug]: using mv_range_thread = 72 x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64 x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 670 x264 [info]: profile High, level 5.1 x264 [debug]: frame= 0 QP=12.42 NAL=3 Slice:I Poc:0 I:9000 P:0 SKIP:0 size=1023133 bytes flv [info]: initial delay 133 ms x264 [debug]: frame= 1 QP=15.73 NAL=2 Slice:P Poc:10 I:10 P:1756 SKIP:7234 size=111586 bytes x264 [debug]: frame= 2 QP=22.61 NAL=2 Slice:B Poc:6 I:6 P:1200 SKIP:7615 size=19476 bytes x264 [debug]: frame= 3 QP=22.41 NAL=0 Slice:B Poc:2 I:1 P:1036 SKIP:7779 size=12854 bytes x264 [debug]: frame= 4 QP=22.92 NAL=0 Slice:B Poc:4 I:0 P:1209 SKIP:7549 size=10635 bytes x264 [debug]: frame= 5 QP=22.96 NAL=0 Slice:B Poc:8 I:0 P:617 SKIP:8092 size=7375 bytes x264 [debug]: frame= 6 QP=15.31 NAL=2 Slice:P Poc:16 I:7 P:1687 SKIP:7306 size=85615 bytes x264 [debug]: frame= 7 QP=22.42 NAL=2 Slice:B Poc:14 I:0 P:980 SKIP:7798 size=8859 bytes x264 [debug]: frame= 8 QP=22.75 NAL=0 Slice:B Poc:12 I:3 P:1003 SKIP:7808 size=8233 bytes x264 [debug]: frame= 9 QP=25.37 NAL=2 Slice:P Poc:28 I:7 P:731 SKIP:8262 size=19342 bytes x264 [debug]: frame= 10 QP=22.77 NAL=2 Slice:B Poc:22 I:6 P:762 SKIP:8061 size=17575 bytes x264 [error]: malloc of size 10031104 failed x264 [error]: x264_encoder_encode failed x264 [info]: frame I:1 Avg QP:12.42 size:1023133 x264 [info]: frame P:3 Avg QP:18.80 size: 72181 x264 [info]: frame B:7 Avg QP:22.69 size: 12144 x264 [info]: consecutive B-frames: 6.7% 0.0% 20.0% 0.0% 33.3% 40.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% x264 [info]: mb I I16..4: 1.0% 36.5% 62.5% x264 [info]: mb P I16..4: 0.0% 0.0% 0.1% P16..4: 7.0% 1.0% 2.9% 2.3% 2.1% skip:84.5% x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 8.2% 1.4% 1.5% direct: 2.1% skip:86.8% L0:17.7% L1:47.5% BI:34.9% x264 [info]: final ratefactor: 26.73 x264 [info]: 8x8 transform intra:36.3% inter:5.8% x264 [info]: direct mvs spatial:28.6% temporal:71.4% x264 [info]: coded y,uvDC,uvAC intra: 99.9% 99.4% 98.7% inter: 6.2% 3.8% 3.3% x264 [info]: i16 v,h,dc,p: 26% 33% 23% 18% x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 17% 13% 10% 6% 5% 5% 14% 18% x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 13% 8% 10% 10% 9% 10% 12% 15% x264 [info]: i8c dc,h,v,p: 61% 16% 10% 12% x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x264 [info]: ref P L0: 83.1% 6.0% 5.4% 4.2% 0.7% 0.6% x264 [info]: ref B L0: 94.3% 0.9% 4.5% 0.2% 0.2% x264 [info]: ref B L1: 91.7% 8.3% x264 [info]: kb/s:14451.09 aborted at input frame 101, output frame 11 encoded 11 frames, 0.90 fps, 15905.30 kb/s ------------------------------------------------------------- x264_2334.exe -I 150 -b 100 --b-adapt 2 -B 4000 -m 10 -t 2 --direct auto --me esa --merange 24 --partitions all --ref 16 --rc-lookahead 60 --threads 8 --opencl -p 1 --qpmin 5 --log-level debug -o test.flv test_enc.avi ffms [info]: 1920x1200p 0:1 &lt; at &gt; 15/1 fps (vfr) x264 [debug]: using mv_range_thread = 72 x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64 x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 670 x264 [info]: profile Main, level 5.0 x264 [debug]: frame= 0 QP=11.98 NAL=3 Slice:I Poc:0 I:9000 P:0 SKIP:0 size=995889 bytes flv [info]: initial delay 133 ms x264 [debug]: frame= 1 QP=13.11 NAL=2 Slice:P Poc:10 I:19 P:2040 SKIP:6941 size=116963 bytes x264 [debug]: frame= 2 QP=21.84 NAL=2 Slice:B Poc:6 I:3 P:1082 SKIP:7915 size=21275 bytes x264 [debug]: frame= 253 QP=38.22 NAL=0 Slice:B Poc:202 I:0 P:19 SKIP:8981 size=169 bytes x264 [debug]: frame= 254 QP=37.94 NAL=0 Slice:B Poc:206 I:0 P:16 SKIP:8984 size=136 bytes x264 [info]: frame I:2 Avg QP:21.36 size:575161 x264 [info]: frame P:122 Avg QP:33.86 size: 39450 x264 [info]: frame B:131 Avg QP:36.15 size: 16157 x264 [info]: consecutive B-frames: 27.1% 11.8% 23.5% 18.8% 5.9% 9.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% x264 [info]: mb I I16..4: 21.8% 0.0% 78.2% x264 [info]: mb P I16..4: 24.8% 0.0% 0.0% P16..4: 40.2% 0.0% 0.0% 0.0% 0.0% skip:35.0% x264 [info]: mb B I16..4: 7.7% 0.0% 0.0% B16..8: 21.6% 0.0% 0.0% direct: 5.5% skip:65.3% L0:42.3% L1:49.4% BI: 8.3% x264 [info]: final ratefactor: 30.27 x264 [info]: direct mvs spatial:96.2% temporal:3.8% x264 [info]: coded y,uvDC,uvAC intra: 46.0% 44.2% 17.7% inter: 10.3% 9.2% 0.8% x264 [info]: i16 v,h,dc,p: 24% 26% 35% 15% x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 18% 12% 9% 8% 8% 8% 10% 12% x264 [info]: i8c dc,h,v,p: 67% 17% 12% 3% x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x264 [info]: kb/s:3802.26 encoded 255 frames, 13.16 fps, 3802.61 kb/s ------------------------------------------------------------- Bug fix(es): Malloc fail. Support --opencl with all encode options -p 1, -p 2, -p 3 and no -p (-p 2 and -p 3 not using OpenCL could be a bug or improvement proposal don't know which one) and with all profiles (profile Main, level 5.0 | profile High, level 5.1 | etc). ------------------------------------------------------------- Another improvement: Add commandline option for storing ffms file index. I deal with large static files (not using AviSynth or some such) and when doing "Nth pass" a lot of time is wasted. It would be nice if file index could be saved in same manner as x264_lookahead.clbin x264_2pass.log x264_2pass.log.mbtree files so file indexing needs to be done only once. _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Nihil 2013-06-11T08:53:56 http://comments.gmane.org/gmane.comp.video.x264.devel/9587 <pre> http://bocaciegaadultcommunity.com/wvopw/lamw.mpvrbjqxkux _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Peter Tap 2013-06-07T20:54:25 http://comments.gmane.org/gmane.comp.video.x264.devel/9582 <pre>Hi,   I see x264 doesn't support closed captioning. I think about it to add this feature in the lib. Is there a general interest, so that it would also feed into future versions.   Axel_______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Axel Voss 2013-06-04T13:19:31 http://comments.gmane.org/gmane.comp.video.x264.devel/9578 <pre>Good day x264-dev, I was reviewing H264 transform bypass functionality (lossless) implementation in x264 and base on my understanding of the H264 specifications, x264 doesn't implement I_PRED_8x8_V or I_PRED_8x8_H modes correctly. For all intra 8x8 predictions, the spec mentions the filtered samples should be used but x264 is using the source samples when doing I_PRED_8x8_V or I_PRED_8x8_H modes in lossless (see detail explication below). Here is the snippet of code from x264 macroblock.c handling 8x8 for lossless: void x264_predict_lossless_8x8( x264_t *h, pixel *p_dst, int p, int idx, int i_mode, pixel edge[36] ) ...     if( i_mode == I_PRED_8x8_V )         h-&gt;mc.copy[PIXEL_8x8]( p_dst, FDEC_STRIDE, p_src-stride, stride, 8 );     else if( i_mode == I_PRED_8x8_H )         h-&gt;mc.copy[PIXEL_8x8]( p_dst, FDEC_STRIDE, p_src-1, stride, 8 );     else         h-&gt;predict_8x8[i_mode]( p_dst, edge ); ... For I_PRED_8x8_V and I_PRED_8x8_H modes, the source samples stored in 'p_src' are used instead of the filtered samples stored in 'edge' which is not conform with the spec. x264 lossless streams are compatible with libavcodec because both are doing the same implementation in this case (ie: using source samples instead of filtered samples). I've also confirmed that CoreAvc has the same implementation as libavcodec. On the other side, JM 18.5 implementation (encoder and decoder) does match my understanding of the H264 spec, and when I disabled 8x8 transform during encoding (using --no-8x8dct), x264 streams become compatible with JM decoder (lossless). I've also tested the reverse (encoding with JM with 8x8 transform disabled and decoding with libavcodec) and it's also working. JM and x264/libavcodec are therefore currently compatible for lossless only when intra 8x8 transform is disabled (tested in 420/422/444 and 8/10 bits). The command line I used to show the problem was:   x264 --crf 0 --input-csp i420 --input-res 352x288 crowdrun_cif.yuv -o crowdrun_cif.264 but the issue can be reproduce with any YUV of 1 frame (MB intra 8x8 being very common). The difference can be seen by decoding with JM 18.5 and comparing with the source YUV. Could someone confirmed that this is real issue of x264 (and livavcodec) not being compliant with the H264 spec in transform bypass 8x8.   Regards   Alain     ## Information about transform 8x8 in Rec ITU-T H.264 (01/2012) From the spec, the 8x8 prediction is always generated with filtered version of the neighbouring samples. This prediction is sum with the residual process to get the reconstructed picture. For all 8x8 luma blocks of the luma component of a macroblock with luma8x8BlkIdx= 0..3  # Intra prediction     - Get the 25 neighbouring samples p[x,y]                          section 8.3.2.2   - Apply filtering on p[x,y] and return in p'[x,y]                 section 8.3.2.2.1   - Generate the prediction from p'[x,y] and return Pred8x8L[x,y]   section 8.3.2.2.2 to 8.3.2.2.10   - Output PredL=Pred8x8L from the intra prediction.                section 8.3.2 (8-71)    # Transform coefficient     - PrelL as input into the transform coefficient decoding          section 8.5   - if(TransformBypassModeFlag==1)                                  section 8.5.3 item 3.       - Apply the intra residual transform-bypass decoding process         and return rij                                              section 8.5.14   - Sum the residual to the prediction and return uij=PrelL+rij     section 8.5.3 item 5. (8-303)   - Do the picture reconstruction prior to the deblocking     process with uij                                                section 8.5.13 _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Alain Champenois 2013-06-03T20:04:31 http://comments.gmane.org/gmane.comp.video.x264.devel/9576 <pre>Any plans to incorporated HEVC codec into VLC? If so, any idea when it might be ready for testing? Neil _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Neil Smith 2013-05-29T14:43:50 http://comments.gmane.org/gmane.comp.video.x264.devel/9575 <pre>Hi; I'm reseaching about H.264 video encryption. Can you help me; What can i do h.264 video encrption/decryption C or C++ or whatever. Or may i have open source sample ? Regards... _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Uğur Cihan KOÇ 2013-05-28T13:01:09 http://comments.gmane.org/gmane.comp.video.x264.devel/9572 <pre>Hi guys, I'm writing application converting videos to specific H.264 Profile and level. As I know every level has max frame size (macro blocks) and max decoding speed. So I need to guarantee frame_size * fps of my input video shouldn't exceed the max decoding speed. What I want to know is, how if I supply a video that has a higher bitrate than the specified level. Will X264 encoder resize video frames (make them smaller) or limit fps? I guess X264 will not do this kind of process and I need to do it myself before encode starts. just want to get some confirm here. Thanks! _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> YIRAN LI 2013-05-27T05:42:46 http://comments.gmane.org/gmane.comp.video.x264.devel/9563 <pre>Hi Guys, I'm writing a application to convert videos into iPhone/iPad supported format. So I know the profile and highest level I can convert to. I know there's an API x264_param_apply_profile to set profile, but I couldn't find where can I set level in x264_param_t. Another question is, if I couldn't set level programmatically, could I achieve the same result by supplying max resolution, max frame size, and other params? Great thanks! _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> YIRAN LI 2013-05-24T00:49:48 http://comments.gmane.org/gmane.comp.video.x264.devel/9561 <pre>Hi, I am working on a software which transcodes clips and commercial to different resolution and serve the correct content to various media devices. We've been using x264 via ffmpeg for encoding h264. Recently we updated x264 from snapshot-20120705 to snapshot-20130303. This caused our stitching of commercial and video content to fail. The stitching fails because the pic_init_qp_minus26 in the picture_parameter_set differs between the clips. The results vary from foggy and saturate results to complete crash (depending on the decoder). Re-encoding is not an option since content needs to be stitched on the fly. I made a remuxer that changed the PPS/SPS Id before stitching, but only a hand full of the players tested supported multiple SPS/PPS in a video (ffplay and android go, iphone and vlc no). I was wondering if maybe it would be a good idea to allow to manually set the pic_init_qp_minus26 via a parameter? What is the gain from setting the pic_init_qp_minus26 value closer to the average qp? fewer bits in the delta_qs value? By the way, we use mp4 as container and use MP4Box (part of gpac) to stitch videos. Anders Rein _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Anders Rein 2013-05-22T09:02:00 http://comments.gmane.org/gmane.comp.video.x264.devel/9560 <pre>Hello, I don't have a vbv aware stream analyzer tool, but the following seems to be working in my test environment when I simulate lowered download speeds. Please let me know if my assumptions are incorrect and if I'm asking for trouble :) Objective: - need to provide videos such that a user with X-kbps can view (using RTMP/RTSP/HLS or other streaming protocols) - achieving a "constrained VBR" effect by using crf, vbv-maxrate, vbv-bufsize Test: - I want to target users that have 800kbps or higher download bandwidth - will use 64kbps audio - use crf 20 - vbv-maxrate=730 - vbv-bufsize=2190 - client is using a Flash player with 5 second client buffer Assumptions: - during any given second, the peak video bitrate will not exceed 2190kbps - for any 3 second stretch, the average video bit rate will not exceed 730kbps - my client (Flash player) buffer of 5 seconds will be sufficient to handle 1390kbps additional bandwidth requirement that could occur during any 3 second period (2190 - 800kbps) Since I don't have a vbv streaming analyzer to check, can any devs confirm or deny these assumptions? If this will not work as I expect, where is my misunderstanding? How would you achieve a "constrained" vbr encode (where peaks must be less than X for Y period?) Thank you, I greatly appreciate your time! _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Ran RanUser 2013-05-22T00:50:27 http://comments.gmane.org/gmane.comp.video.x264.devel/9559 <pre>x264 | branch: master | Henrik Gramner &lt;henrik&lt; at &gt;gramner.com&gt; | Fri May 3 23:06:10 2013 +0200| [b4be6e56629cf8fdcf53adc6b879969d8f6760b3] | committer: Jason Garrett-Glaser x86: Don't use explicitly aligned versions of SAD on AVX CPUs On modern CPUs movdqu isn't slower than movdqa when used on aligned data and using the same code in both cases saves cache. This was already done for the high bit-depth AVX2 implementation but the aligned version still exists as dead code so remove that. --- common/pixel.c | 2 ++ common/x86/pixel.h | 1 - common/x86/sad16-a.asm | 3 --- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/common/pixel.c b/common/pixel.c index 145fac7..2b323cb 100644 --- a/common/pixel.c +++ b/common/pixel.c &lt; at &gt;&lt; at &gt; -966,6 +966,7 &lt; at &gt;&lt; at &gt; void x264_pixel_init( int cpu, x264_pixel_function_t *pixf ) } if( cpu&amp;X264_CPU_AVX ) { + INIT5_NAME( sad_aligned, sad, _ssse3 ); /* AVX-capable CPUs doesn't benefit from an aligned version */ INIT_ADS( _avx ); INIT6( satd, _avx ); pixf-&gt;satd[PIXEL_4x16] = x264_pixel_satd_4x16_avx; &lt; at &gt;&lt; at &gt; -1234,6 +1235,7 &lt; at &gt;&lt; at &gt; void x264_pixel_init( int cpu, x264_pixel_function_t *pixf ) if( cpu&amp;X264_CPU_AVX ) { + INIT2_NAME( sad_aligned, sad, _sse2 ); /* AVX-capable CPUs doesn't benefit from an aligned version */ INIT8( satd, _avx ); INIT7( satd_x3, _avx ); INIT7( satd_x4, _avx ); diff --git a/common/x86/pixel.h b/common/x86/pixel.h index bddf528..555c4ec 100644 --- a/common/x86/pixel.h +++ b/common/x86/pixel.h &lt; at &gt;&lt; at &gt; -53,7 +53,6 &lt; at &gt;&lt; at &gt; DECL_X1( sad, sse2_aligned ) DECL_X1( sad, ssse3 ) DECL_X1( sad, ssse3_aligned ) DECL_X1( sad, avx2 ) -DECL_X1( sad, avx2_aligned ) DECL_X4( sad, mmx2 ) DECL_X4( sad, sse2 ) DECL_X4( sad, sse3 ) diff --git a/common/x86/sad16-a.asm b/common/x86/sad16-a.asm index 8c48723..7606da3 100644 --- a/common/x86/sad16-a.asm +++ b/common/x86/sad16-a.asm &lt; at &gt;&lt; at &gt; -205,9 +205,6 &lt; at &gt;&lt; at &gt; SAD 8, 8 INIT_YMM avx2 SAD 16, 16 SAD 16, 8 -INIT_YMM avx2, aligned -SAD 16, 16 -SAD 16, 8 ;============================================================================= ; SAD x3/x4 _______________________________________________ x264-devel mailing list x264-devel&lt; at &gt;videolan.org http://mailman.videolan.org/listinfo/x264-devel </pre> Henrik Gramner 2013-05-20T21:06:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.x264.devel