Newest 'x264' Questions - Stack Overflow

Les articles publiés sur le site

• H.264 codec with FMO and data partitioning support ?

  25 avril 2018, par Siego

  For a project I need to use H.264 codec for a error prone environment. For this i want to use FMO and data partitioning. But i cant find a codec that support these features or the extend profile.

  So does anybody know a H.264 libary I can use that support this?

• delay in audio sync after converting ac3 to aac

  9 mars 2018, par samer metwally

  I have a MKV video consist of a video and an audio of duration 10 minutes, after using ffmpeg to extract ac3 to aac audio, its duration became 10:50, which lead to audio out of sync with the video after packaging the new extracted audio to mp4 container using mp4box. how to solve the problem of syncing or as i knew, the delay that happen with aac encoding ? commands:

  ffmpeg -i "d:/input.mkv" -vn -c:a aac "d:/audio.aac"
  
  MP4Box 
  -add "C:/1280x720.264" 
  -fps "23.976023976024"
  -add "d:/audio.aac:lang=ara" 
  

• x264 encoding timebase calculation

  4 mars 2018, par rosewater

  I have yuv frames that I am converting to h264 frames using libx264 successfully. I know the time difference between each frame. Then I use the following ffmpeg command to convert h264 video file to mp4:

  ffmpeg.exe -i frames.h264 -c:v copy -f mp4 frames.mp4

  This works. However I can't figure out how to set the variable frame rate properly. The movie plays too fast. I don't have fixed frame rate, otherwise I would set that and the resulting mp4 is the correct duration.

  I have the time difference between each frame in milliseconds. How can I set the timebase and pts so that when I convert the h264 file to mp4, it is the correct duration.

  bool X264Encoder::init(int width, int height, 
  AVRational &timebase,  // what should timebase be?
  int fps)
  {
     x264_param_t param;
      if( x264_param_default_preset( &param, "medium", NULL ) < 0 )
      { return false; }
  
      /* Configure non-default params */
      param.i_bitdepth = 8;
      param.i_csp = X264_CSP_I420;
      param.i_width  = width;
      param.i_height = height;
      param.b_vfr_input = 0;
      param.b_repeat_headers = 1;
      param.b_annexb = 1;
      if(0) // don't have fixed frame rate, can't use it
      {
          param.b_vfr_input = 0;
          param.i_fps_num = 4;
          param.i_fps_den = 1;
      }
      else
      {
          param.b_vfr_input = 1;
          param.i_timebase_num = timebase.den;
          param.i_timebase_den = timebase.num;
      }
  
      if( x264_param_apply_profile(&param, "high" ) < 0 )
      { return false; }
  
      m_pic_in = new x264_picture_t;
      x264_picture_init(m_pic_in);
      m_pic_in->img.i_csp = X264_CSP_I420;
      m_pic_in->img.i_plane = 3;
  
      m_encoder = x264_encoder_open(&param);
  
  }
  
  //This is called for each frame
  void X264Encoder::encode(uint8_t *plane[4], int64_t pts) // what should pts be?
  {
      m_pic_in->img.plane[0] = plane[0];  // Y frame
      m_pic_in->img.i_stride[0] = m_width;
      m_pic_in->img.plane[1] = plane[1];  // U frame
      m_pic_in->img.i_stride[1] = m_width;
      m_pic_in->img.plane[2] = plane[2];  // V frame
      m_pic_in->img.i_stride[2] = m_width;
  
      x264_picture_t pic_out;
      m_pic_in->i_pts = pts;
      int frame_size = x264_encoder_encode(m_encoder, &m_nals, &m_i_nals, m_pic_in, &pic_out);
  
      if(frame_size <= 0)
      {
          return;
      }
  
      writeH264Frame(m_nals->p_payload, frame_size); // basically same as fwrite
  }
  

• avcodec_encode_video2 crash on MinGW32 (but not on MinGW64)

  27 février 2018, par ksb496

  I have been testing for years a software that I am developing, compiled only for 64-bit systems through Qt-MinGW64, without experiencing any kind of issue regarding video encoding (which is one of the features of such application). Recently, I have been attempting to build the corresponding x86 version of my software by compiling it with Qt-MingGW32.

  However, after bulding the same ffmpeg and x264 library versions to create the 32-bit versions and successfully linking them to my project, the application keeps crashing after few frames are encoded, due to segmentation fault error. This is very strange because, as I indicated before, it works flawlessly when compiled for 64-bit systems.

  I have also lost a considerable amount hours trying to combine a big amount of different versions of both ffmpeg and x264 libraries, but with no luck either. Neither it works when disabling threads both for x264 and ffmpeg libraries, hence it does not seem to be a win32 threading issue. Therefore, I have concluded that the error is most likely in my code, which by some chance beyond my comprehension tells ffmpeg to allocate the right amount of memory in the x64 version, but not in the x86 version.

  It must be pointed out also that before the avcodec_encode_video2 call, I do the following calls, among others, in order to allocate the memory associated to the corresponding items (AVFrame, AVCodec, etc.), such as

  avcodec_open2( my_codec_context, my_codec, &opt );
  my_av_frame=av_frame_alloc();
  

  More precisely, the details involving the code structure that I am using can be found here.

  Therefore, the error appears to be more subtle than just issues regarding uninitialized memory.

  Many thanks in advance.

  UPDATE:

  I have discovered the focus of the problem. For some reason, FFmpeg/x264 libraries behave abnormally in Win32 GUI applications compiled with Qt-MinGW32, while they run correctly in Win32 console applications, also compiled with Qt-WinGW32. I have proven this claim performing two dummy tests, in which the exact same piece of code is run through a console application and on a GUI application, succeeding in the first case and failing in the latter one. The code for such tests can be found below, along with the x264 and FFmpeg libraries used in my projects, together with instructions to build them in msys2 with MinGW32:

  https://takeafile.com/?f=hisusinivi

  I have no idea whether it can be solved by simply tweaking the code or it is a serious bug involving an incompatibility issue. If it is the latter, should it be reported to the Qt/FFmpeg/x264 staff as a major bug?

• How can I retain 2x pixel density when encoding Retina screen capture with ffmpeg ?

  26 février 2018, par hfossli

  Whenever I use ffmpeg to encode a HiDPI/Retina screen recording, the video plays at 2x the size, so it looks fuzzy, because the pixel density is not retained.

  How can I retain the original pixel density of HiDPI screen recordings with ffmpeg?

  How to reproduce:

  1. Use QuickTime Player to create a Screen Recording on a Retina Mac.
  2. Play the video you recorded in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 2:1 on your Retina Display, so the video looks sharp. It’s playing in half the space of the actual recorded pixels.

  3. Use ffmpeg to encode the video using a command like this:

     ffmpeg -i haha.mov -c:v libx264 -crf 23 haha-lg.mov
     

  4. Play the new ffmpeg-compressed video in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 1:1, so the video looks fuzzy.

  To clarify, the video does not look blurry because it was compressed. Rather, it looks blurry because the video is being played twice as big as it should be, at a 1:1 pixel density, instead of the required 2:1 pixel density, presumably because some metadata is being discarded when encoding.

  For the record, VLC plays both videos too big (blurry). So being able to play HiDPI videos seems to be a feature of QuickTime Player.

  Here is the detailed information ffmpeg shows for the original screen recording:

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha.mov':
    Metadata:
      major_brand     : qt  
      minor_version   : 0
      compatible_brands: qt  
      creation_time   : 2018-02-26T16:46:00.000000Z
      com.apple.quicktime.make: Apple
      com.apple.quicktime.model: iMac18,3
      com.apple.quicktime.software: Mac OS X 10.13.3 (17D102)
      com.apple.quicktime.creationdate: 2018-02-26T10:45:50-0600
    Duration: 00:00:04.35, start: 0.000000, bitrate: 10947 kb/s
      Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1396x928 [SAR 1:1 DAR 349:232], 10701 kb/s, 60 fps, 60 tbr, 6k tbn, 12k tbc (default)
      Metadata:
        creation_time   : 2018-02-26T16:46:00.000000Z
        handler_name    : Core Media Data Handler
        encoder         : H.264
  

  And here is the information for the ffmpeg-compressed version:

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha-lg.mov':
    Metadata:
      major_brand     : qt  
      minor_version   : 512
      compatible_brands: qt  
      encoder         : Lavf57.83.100
    Duration: 00:00:04.35, start: 0.000000, bitrate: 1923 kb/s
      Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1396x928 [SAR 1:1 DAR 349:232], 1783 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
      Metadata:
        handler_name    : DataHandler
        encoder         : Lavc57.107.100 libx264