Newest 'libx264' Questions - Stack Overflow

Les articles publiés sur le site

• Recording with libx264 results in audio muting prior to recording being stopped depending on preset

  24 janvier 2020, par Pyon

  ffmpeg -thread_queue_size 512 -f dshow -i audio="AudioDevice" -thread_queue_size 512 -f gdigrab -rtbufsize 100000000 -hwaccel auto -framerate 60 -offset_x 332 -offset_y 720 -video_size 340x162 -probesize 10000000 -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"
  

  I'm using the above command to record desktop video/audio in a defined region. The video is being recorded using gdigrab while the audio is being recorded using dshow with a custom loopback driver.

  When the libx264 preset is set to anything below "ultrafast" like "veryslow", the audio will be muted around 80% into the recording (varies depending on video size and the preset selected, worsening for slower presets). By muted I mean: If I record a 10 second video, the video will be 10 seconds in length but the audio will only be audible for the first 8 seconds.

  I'm not really sure what could be causing this, but is there any way around it?

  Below are simplified versions which produces same results..

  Veryslow preset (audio issue):

  ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"
  

  Ultrafast preset (no audio issue):

  ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset ultrafast -crf 23 -pix_fmt yuv420p "output.mp4"
  

  I don't want to use ultrafast because it results in poor quality/compression ratio.

• How to deal ffplay being too slow playing iPhone's videos ?

  8 janvier 2020, par Mikhail T.

  Trying to play a 3840x2160 video recorded by an iPhone 7 (@30fps), I get frequent pauses -- in the video, music keeps playing.

  This happens both in firefox and when ffplay is invoked to play the file directly -- from command-line. The CPU is a dual E6700 @3.20GHz -- not super fast, but it should be able to play smoothly, shouldn't it? Video is Intel's "series 4" integrated chipset -- again, not a speed-daemon, but it should be adequate... Support for Intel's VA API is included.

  I build ffmpeg-4.1 from source using FreeBSD port. As you can see, the port has a maddening amount of options -- including several different ones for the 264-codec.

  Any suggestions for improving the decoding speed to the point, where it is watchable by a human? Thank you!

• libavcodec/libx264 isn't respecting keyint_min

  6 janvier 2020, par seanr8

  Using libavcodec 57.107.100, I have some code to encode frames into H.264 and I'm working on tweaking the settings to prep resulting videos to be streamed with DASH, which requires consistent keyframe timings. So I'm setting the GOP to 4x the framerate and setting the keyint_min to the same as the GOP so that I can guarantee that the keyframe interval lines up with the 4 second segment boundaries.

  I'm using the following code to build the AVCodec and AVCodecContext:

  AVCodec* codec = NULL;
  codec = avcodec_find_encoder_by_name("libx264");
  AVCodecContext* avcodec_context = avcodec_alloc_context3(codec);
  context->bit_rate = 200000;
  context->height = 640;
  context->width = 480;
  context->keyint_min = 100;
  context->gop_size = 100;
  context->qmax = 31;
  context->qmin = 2;
  context->pix_fmt = AV_PIX_FMT_YUV420P;
  context->time_base = (AVRational) {1, 25};
  

  Clearly, the keyint_min is 100 here, yet when I execute my program, the stderr output from libavcodec says this when the encoding starts:

  [libx264 @ 0x5577bde61f20] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 
  AVX2
  [libx264 @ 0x5577bde61f20] profile High, level 3.0
  [libx264 @ 0x5577bde61f20] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=100 keyint_min=51 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=200 ratetol=1.0 qcomp=0.60 qpmin=2 qpmax=31 qpstep=4 ip_ratio=1.40 aq=1:1.00
  

  For emphasis, in the third line of that blurb, the encoder says keyint=100 keyint_min=51. So obviously my GOP is being set correctly at 100, but the keyint_min is not being respected. Since the FFMPEG docs are pretty difficult to approach, I haven't been able to find an answer to this. Does anyone know what I'm missing?

• what is the lowest allowed framerate of VP9 codec

  5 janvier 2020, par d3im

  I was searching over Net to find what is the lowest allowed framerate of VP9 but didn't find anything. I'm asking because I successfully encoded video at 0.25 or 1 FPS to x264 or x265, but with VP9 it gives me an error on that framerates.

• Remove extra SPS and PPS from h264 stream

  3 janvier 2020, par izambl

  I have some screen recordings taken with Chrome MediaStream, but Mac Chrome 79 introduced a bug (https://bugs.chromium.org/p/chromium/issues/detail?id=1034633) that breaks some of the videos because of the way SPS and PPS are handled.

  I found out that if I reencode the video with ffmpeg -i video.mp4 -c:v libx264 video1.mp4 it works but it takes too long to process, so I was thinking on converting the stream to AVCC or maybe another way of removing any extra SPS and PPS data so chrome won't use SPS and PPS from IDR slice headers.

  I tried using FFmpeg Bitstream Filters but I couldn't get a working video.

  Is it possible to do without reencoding the full video?