Newest 'libx264' Questions - Stack Overflow

Les articles publiés sur le site

• Error on compilation of x264 on qnap

  3 octobre 2015, par user2060812

  We are facing issues on compiling x264 on qnap.
  We need to compile ffmpeg with x264 library, qnap packages have the built-in x264 0.66 library but ffmpeg-0.9.2 doesn't support too old version of x264 and produces the following error on compiling x264 from source.

  [/share/MD0_DATA/.qpkg/x264-snapshot-20130208-2245] # make
  gcc -Wshadow -O3 -ffast-math -m32  -Wall -I. -I. -march=i686 -mfpmath=sse -msse -std=gnu99  -I/opt/include    -I/opt/include   -fomit-frame-pointer -fno-tree-vectorize   -c -o x264.o x264.c
  x264.c: In function 'help':
  x264.c:401: error: 'X264_VERSION' undeclared (first use in this function)
  x264.c:401: error: (Each undeclared identifier is reported only once
  x264.c:401: error: for each function it appears in.)
  make: *** [x264.o] Error 1
  
  
  [/share/MD0_DATA/.qpkg/x264-snapshot-20130208-2245] # cat /proc/version
  Linux version 2.6.33.2 (root@NasX86-4) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Wed Dec 5 06:48:23 CST 2012
  

  Can someone assist me on that ?

• x264 encoding taking longer when encoding static frames (than

  14 septembre 2015, par Danilo

  ​Hi, I'm using x264 for live video streaming and I've noticed that the thread responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e.: camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

  This seems somewhat counter intuitive to me, as I would expect x264 to use more processing power when encoding complex scenes other then static ones.

  My encoder settings are the following:

  1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
  me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
  8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
  sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
  constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
  intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
  qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none
  

  I created a github gist based on the example.c encoder bundled in x264's source code and tested encoding times with it. (You can find it here: https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

  Average encoding time for the static scene is ~38% bigger than for a scene with movements. (You can find my test case and also the output from my test encoder on the link above).

  ​​ ​I've also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

  ​ ​Could anyone, please, shed some light on the reasons for this odd behavior? ​Also, what can be done in order to avoid this situation without a major decrease in quality?​

• In FFmpeg, encoding anything lower than slow preset takes video to level 5

  1er septembre 2015, par Leo Zerino

  Why whenever I use any preset lower or equal to slow, it makes my video High@L5 (profile high / level 5)? It doesn't make sense to me, I always tought that levels were associeted with frame size, frame rate and data rate only

  I've searched all over for a relation between presets and levels in x264 encoding through FFmpeg, but couldn't find any.

  My only concern is compatibility, since anything above 4 tends to be exotic to most players.

• Encoding H.264 CBR videos with FFmpeg

  27 août 2015, par Cornstalks

  I'm trying to encode a video with ffmpeg into H.264 (via the libx264 library) with a constant bit rate. I know, I know, VBR is often preferred, but for this specific job I'm required to use CBR (just as long as it's so many kilobytes per second; it doesn't have to be an exact kilobytes per frame, afaik). My sample video I'm using to test is from here: http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iTunes.mov.zip (it comes from http://support.apple.com/kb/HT1425)

  I can get a constant bit rate when encoding the video with MPEG-4 Video (using the commands ffmpeg -i sample_iTunes.mov -b 819968 -minrate 819968 -maxrate 819968 out.mov), and the bit rate is as expected. Reading the video's specs via the QuickTime Inspector, it's got a data rate of 844.94 kbit/s. Cool.

  However, when I change the codec to libx264, it seems to completely ignore my bitrate requests! The command I'm trying is "ffmpeg -i sample_iTunes.mov -vcodec libx264 -vpre medium -b 819968 -vb 819968 -minrate 819968 -maxrate 819968 -bufsize 400000 test.mov". But when I check the video's specs via the QuickTime Inspector, it's got a data rate of 254.74 kbit/s. WTF? That's not even close!

  I've tried changing so many parameters and adding tons of different things, and I've spent 2 days googling this, but I can't seem to get it to work. If I encode the video with the MainConcept H.264 encoder, I can get a constant bitrate, but I need this to work with ffmpeg.

  If someone can help me figure out how to do CBR H.264 encoding with FFmpeg, I will love you forever!

• x264 library speed - Altivec vs SSE4 -

  15 août 2015, par Asain Kujovic

  I have simple cheap dualcore intel-3ghz-debian and access to super-expensive powerPc7-Aix.

  And after few days of strugle, i compiled libx264 and tested it on both computers:

  1. GCC: library x264 on intel (with SSE2 capabilities) and
  2. GCC on 16 core powerPc (with altivec).

  ... and result is that cheap intel is x2 times faster ! (with altivec disabled, intel is 10x times faster)

  My question: is this normal? Does all other powerPC-users have same results? Can powerPc-altivec-optimisation of x264 library work at same speed with intel... or MMX/SSE optimisation is officially at least 2 times faster for this library?

  I am not interested in multi-thread options. Number of cores and threads are irrelevant. Just simple one-thread x264 encoding with default "medium preset" using rawvideo as source, sse vs altivec.

  Maybe native Aix XLC compiler provide better results? (i managed only gcc to work)

  ... mac-powerpc-users maybe know something about this.

  powrPc7-Aix:$ time (cat raw10sec.y4m |x264 --input-res 720x576 --fps 50 -o /dev/null -)
  x264: 64-bit XCOFF
  x264 [info]: using cpu capabilities: Altivec
  time: real 0m33.559s
  ---
  intelDebian:$ time (cat raw10sec.y4m |x264 --input-res 720x576 --fps 50 -o /dev/null -)
  x264: ELF 32-bit LSB executable
  x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
  time: real 0m16.503s