Newest 'x264' Questions - Stack Overflow

Les articles publiés sur le site

• h.264 MVC 3D support in x264/ffmpeg

  13 mai 2016, par Codec Guy

  Many threads say that there is no open source support for h.264 3D on x264 and the technology is dead. However, I am working on x264 and would like to ask the experts here about their opinion:

  • Is h.264 MVC 3D support added to any opensource codecs like ffmpeg/x264?
  • If it's not currently supported in x264, could I add 3D support to x264?
  • Can I take x264 source code and make changes according to the JM of H.264?
  • Is there any open source 3D decoder available?

  NOTE: Please don't mark this question as duplicate, as all the answers I found were answered in 2010-2012 and hoping many things have been changed by now.

• How to use x264 source code after compiling it

  8 mai 2016, par Zia Khattak

  I need to use the x264 code to compress and stream video from a camera in real time as part of my university project (first using computer and then dsp kit) (and vary quantization value when required). I am totally new to this domain and have absolutely no background.

  So far I have compiled the code using the given method in http://www.ayobamiadewole.com/Blog/How-to-build-x264-or-libx264.dll-in-Windows and created the x264.exe and libx264.dll

  I need help with what to do next in order to use the code for my purpose.

  All help is appreciated.

• X264—Why does "—pass 1 —stats" make the file bigger ?

  4 mai 2016, par Codecodeup

  I am using --pass 1 --stats to generate the stats file for H.264 encoding with x264. The command is like this:

    -o 
   --preset veryslow --crf 27 
    --tune ssim  --scenecut 0 --pass 1 --stats 
  

  When I ran this command with and without --pass 1 --stats , the difference between the sizes of the final output files are very different. The one with --pass 1 --stats is much bigger. What is the reason? Thanks.

• x264 Decoding time increases with zerolatency

  13 avril 2016, par Ajay Ponna Venkatesh

  Reference - Why sliced thread affect so much on realtime encoding using ffmpeg x264?

  With Zerolatency / sliced-threads enabled, I am observing that the decoding time shoots up! I am encoding on my Windows 10 laptop and streaming to Samsung S4 phone where it is decoded and rendered. If usually, decoding takes 2-3 ms, it shoots up to around 25 ms if I use sliced-threads. It is a real time streaming application so I need low latency and that's why I enabled zerolatency. Can someone help please?

  I am using the hardware decoder on the phone.

• vframes option ignored in ffmpeg ?

  25 mars 2016, par cooper

  I have a directory that contains 2001 PNG files. I can convert all of the frames to an mp4 video using ffmpeg and the following command:

  ffmpeg -framerate 60 -start_number 0 \
  -i pic.comp2.%07d.png -c:v libx264 -r 30 \
  -pix_fmt yuv420p input1ia.mp4
  

  This works fine. However, I am creating a more complicated application that needs to read only the first 1020 files in the directory (specifically 0 thru 1019). Some googling around led me to the -vframes option. My problem is -- it seems to get ignored or at least interpreted differently than I expect.

  My modified command looks like:

  ffmpeg -framerate 60 -start_number 0 \
  -i pic.comp2.%07d.png -vframes 1020 -c:v libx264 
  -r 30 -pix_fmt yuv420p input1.mp4
  

  It seems like many other people doing the same thing as me do not encounter this issue. So I did some more digging. I tried changing vframes from 1020 to -vframes 20, and this seemed to work properly. So now I am thinking it might be some kind of mismatch between -framerate and -r?

  The full resultant video is 33 sec long... which makes sense mathematically.

   1 sec
   ---------   x  2001 frames = 33.35 seconds
   60 frames
  

  That's why I thought that specifying ~1/2 of the PNGs as the 'end point' would result in a video of the first ~16-17 seconds. But I always get the full length video from using the -vframes option.

  I assume my input to -vframes must be incorrect mathematically, since a small number of frames seems to work. However, I do not understand why.

  The most educated guess I can seem to make is that it is reading the PNGs as 60fps (-framerate), but the -r makes the output video 30fps or something? However, then I would assume that the full output video would not be 33 seconds long.