Recherche avancée

Sur d’autres sites (3052)

• The neutering of Google Code-In 2011

  23 octobre 2011, par Dark Shikari — development, GCI, google, x264

  Posting this from the Google Summer of Code Mentor Summit, at a session about Google Code-In !

  Google Code-In is the most innovative open-source program I’ve ever seen. It provided a way for students who had never done open source — or never even done programming — to get involved in open source work. It made it easy for people who weren’t sure of their ability, who didn’t know whether they could do open source, to get involved and realize that yes, they too could do amazing work — whether code useful to millions of people, documentation to make the code useful, translations to make it accessible, and more. Hundreds of students had a great experience, learned new things, and many stayed around in open source projects afterwards because they enjoyed it so much !

  x264 benefitted greatly from Google Code-In. Most of the high bit depth assembly code was written through GCI — literally man-weeks of work by an professional developer, done by high-schoolers who had never written assembly before ! Furthermore, we got loads of bugs fixed in ffmpeg/libav, a regression test tool, and more. And best of all, we gained a new developer : Daniel Kang, who is now a student at MIT, an x264 and libav developer, and has gotten paid work applying the skills he learned in Google Code-In !

  Some students in GCI complained about the system being “unfair”. Task difficulties were inconsistent and there were many ways to game the system to get lots of points. Some people complained about Daniel — he was completing a staggering number of tasks, so they must be too easy. Yet many of the other students considered these tasks too hard. I mean, I’m asking high school students to write hundreds of lines of complicated assembly code in one of the world’s most complicated instruction sets, and optimize it to meet extremely strict code-review standards ! Of course, there may have been valid complaints about other projects : I did hear from many students talking about gaming the system and finding the easiest, most “profitable” tasks. Though, with the payout capped at $500, the only prize for gaming the system is a high rank on the points list.

  According to people at the session, in an effort to make GCI more “fair”, Google has decided to change the system. There are two big changes they’re making.

  Firstly, Google is requiring projects to submit tasks on only two dates : the start, and the halfway point. But in Google Code-In, we certainly had no idea at the start what types of tasks would be the most popular — or new ideas that came up over time. Often students would come up with ideas for tasks, which we could then add ! A waterfall-style plan-everything-in-advance model does not work for real-world coding. The halfway point addition may solve this somewhat, but this is still going to dramatically reduce the number of ideas that can be proposed as tasks.

  Secondly, Google is requiring projects to submit at least 5 tasks of each category just to apply. Quality assurance, translation, documentation, coding, outreach, training, user interface, and research. For large projects like Gnome, this is easy : they can certainly come up with 5 for each on such a large, general project. But often for a small, focused project, some of these are completely irrelevant. This rules out a huge number of smaller projects that just don’t have relevant work in all these categories. x264 may be saved here : as we work under the Videolan umbrella, we’ll likely be able to fudge enough tasks from Videolan to cover the gaps. But for hundreds of other organizations, they are going to be out of luck. It would make more sense to require, say, 5 out of 8 of the categories, to allow some flexibility, while still encouraging interesting non-coding tasks.

  For example, what’s “user interface” for a software library with a stable API, say, a libc ? Can you make 5 tasks out of it that are actually useful ?

  If x264 applied on its own, could you come up with 5 real, meaningful tasks in each category for it ? It might be possible, but it’d require a lot of stretching.

  How many smaller or more-focused projects do you think are going to give up and not apply because of this ?

  Is GCI supposed to be something for everyone, or just or Gnome, KDE, and other megaprojects ?

• libavcodec/libx264 do not produce B-frames

  6 novembre 2013, par Rob Schmidt

  I am writing an application in C++ that uses libavcodec with libx264 to encode video. However, the encoded data ended up being much larger than I expected. I analyzed the results and discovered that my encoding never produced B-frames, only I- and P-frames.

  I created a standalone utility based on the ffmpeg source code and examples to test my encoder setup. It reads in an H.264 file, re-encodes the decoded frames, and outputs the result to a file using the ITU H.264 Annex B format. I also used ffmpeg to perform the same operation so I could compare against a known good implementation. My utility never outputs B-frames whereas ffmpeg does.

  I have since tried to figure out what ffmpeg does that my code doesn't. I first tried manually specifying encoder settings related to B-frames. This had no effect.

  I then tried running both ffmpeg and my utility under gdb and comparing the contents of the AVStream, AVCodecContext, and X264Context prior to opening the encoder and manually setting any fields that appeared different. Even with identical settings, I still only produce I- and P-frames.

  Finally, I thought that perhaps the problem was with my timestamp handling. I reworked my test utility to mimic the pipeline used by ffmpeg and to output timestamp debugging output like ffmpeg does. Even with my timestamps identical to ffmpeg's I still get no B-frames.

  At this point I don't know what else to try. When I run ffmpeg, I run it with the command line below. Note that aside from the "superfast" preset, I pretty much use the default values.

  ffmpeg -v debug -i ~/annexb.264 -codec:v libx264 -preset superfast -g 30 -f h264 ./out.264

  The code that configures the encoder is listed below. It specifies the "superfast" preset too.

  static AVStream *add_video_stream(AVFormatContext *output_ctx, AVCodec **output_codec, enum AVCodecID codec_id)
  
  {
  
      *output_codec = avcodec_find_encoder(codec_id);
  
      if (*output_codec == NULL) {
  
          printf("Could not find encoder for '%s' (%d)\n", avcodec_get_name(codec_id), codec_id);
  
          return NULL;
  
      }
  
  
  
      AVStream *output_stream = avformat_new_stream(output_ctx, *output_codec);
  
      if (output_stream == NULL) {
  
          printf("Could not create video stream.\n");
  
          return NULL;
  
      }
  
      output_stream->id = output_ctx->nb_streams - 1;
  
      AVCodecContext *codec_ctx = output_stream->codec;
  
  
  
      avcodec_get_context_defaults3(codec_ctx, *output_codec);
  
  
  
      codec_ctx->width = 1280;
  
      codec_ctx->height = 720;
  
  
  
      codec_ctx->time_base.den = 15000;
  
      codec_ctx->time_base.num = 1001;
  
  
  
  /*    codec_ctx->gop_size = 30;*/
  
      codec_ctx->pix_fmt = AV_PIX_FMT_YUVJ420P;
  
  
  
      // try to force B-frame output
  
  /*    codec_ctx->max_b_frames = 3;*/
  
  /*    codec_ctx->b_frame_strategy = 2;*/
  
  
  
      output_stream->sample_aspect_ratio.num = 1;
  
      output_stream->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->sample_aspect_ratio.num = 1;
  
      codec_ctx->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
  
  
  
      codec_ctx->bits_per_raw_sample = 8;
  
  
  
      if ((output_ctx->oformat->flags & AVFMT_GLOBALHEADER) != 0) {
  
          codec_ctx->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
      }
  
  
  
      return output_stream;
  
  }
  
  
  
  
  
  int main(int argc, char **argv)
  
  {
  
      // ... open input file 
  
  
  
      avformat_alloc_output_context2(&output_ctx, NULL, "h264", output_path);
  
      if (output_ctx == NULL) {
  
          fprintf(stderr, "Unable to allocate output context.\n");
  
          return 1;
  
      } 
  
  
  
      AVCodec *output_codec = NULL;
  
      output_stream = add_video_stream(output_ctx, &output_codec, output_ctx->oformat->video_codec);
  
      if (output_stream == NULL) {
  
          fprintf(stderr, "Error adding video stream to output context.\n");
  
          return 1;
  
      }
  
      encode_ctx = output_stream->codec;
  
  
  
      // seems to have no effect
  
  #if 0
  
      if (decode_ctx->extradata_size != 0) {
  
          size_t extradata_size = decode_ctx->extradata_size;
  
          printf("extradata_size: %zu\n", extradata_size);
  
          encode_ctx->extradata = av_mallocz(extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
  
          memcpy(encode_ctx->extradata, decode_ctx->extradata, extradata_size);
  
          encode_ctx->extradata_size = extradata_size;
  
      }
  
  #endif // 0
  
  
  
      AVDictionary *opts = NULL;
  
      av_dict_set(&opts, "preset", "superfast", 0);
  
      // av_dict_set(&opts, "threads", "auto", 0); // seems to have no effect
  
  
  
      ret = avcodec_open2(encode_ctx, output_codec, &opts);
  
      if (ret < 0) {
  
          fprintf(stderr, "Unable to open output video cocec: %s\n", av_err2str(ret));
  
          return 1;
  
      }
  
  
  
      // ... decoding/encoding loop, clean up, etc.
  
  
  
      return 0;
  
  }

  My test utility produces the following debug output in which you can see there are no B-frames produced :

  [libx264 @ 0x1b8c9c0] using mv_range_thread = 56
  
  [libx264 @ 0x1b8c9c0] using SAR=1/1
  
  [libx264 @ 0x1b8c9c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x1b8c9c0] profile High, level 3.1
  
  Output #0, h264, to './out.264':
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122837 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   1 QP=18.03 NAL=2 Slice:P Poc:2   I:411  P:1825 SKIP:1364 size=25863 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   2 QP=17.03 NAL=2 Slice:P Poc:4   I:369  P:2159 SKIP:1072 size=37880 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   3 QP=16.90 NAL=2 Slice:P Poc:6   I:498  P:2330 SKIP:772  size=50509 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   4 QP=16.68 NAL=2 Slice:P Poc:8   I:504  P:2233 SKIP:863  size=50791 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   5 QP=16.52 NAL=2 Slice:P Poc:10  I:513  P:2286 SKIP:801  size=51820 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   6 QP=16.49 NAL=2 Slice:P Poc:12  I:461  P:2293 SKIP:846  size=51311 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   7 QP=16.65 NAL=2 Slice:P Poc:14  I:476  P:2287 SKIP:837  size=51196 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   8 QP=16.66 NAL=2 Slice:P Poc:16  I:508  P:2240 SKIP:852  size=51577 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   9 QP=16.55 NAL=2 Slice:P Poc:18  I:477  P:2278 SKIP:845  size=51531 bytes
  
  [libx264 @ 0x1b8c9c0] frame=  10 QP=16.67 NAL=2 Slice:P Poc:20  I:517  P:2233 SKIP:850  size=51946 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame I:7     Avg QP:13.71  size:152207
  
  [libx264 @ 0x1b8c9c0] frame P:190   Avg QP:16.66  size: 50949
  
  [libx264 @ 0x1b8c9c0] mb I  I16..4: 27.1% 30.8% 42.1%
  
  [libx264 @ 0x1b8c9c0] mb P  I16..4:  6.8%  6.0%  0.8%  P16..4: 61.8%  0.0%  0.0%  0.0%  0.0%    skip:24.7%
  
  [libx264 @ 0x1b8c9c0] 8x8 transform intra:41.2% inter:86.9%
  
  [libx264 @ 0x1b8c9c0] coded y,uvDC,uvAC intra: 92.2% 28.3% 5.4% inter: 50.3% 1.9% 0.0%
  
  [libx264 @ 0x1b8c9c0] i16 v,h,dc,p:  7%  7% 77%  8%
  
  [libx264 @ 0x1b8c9c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 15% 49%  6%  4%  3%  5%  3%  8%
  
  [libx264 @ 0x1b8c9c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 25% 24%  6%  7%  4%  6%  3%  6%
  
  [libx264 @ 0x1b8c9c0] i8c dc,h,v,p: 72% 14% 10%  4%
  
  [libx264 @ 0x1b8c9c0] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x1b8c9c0] kb/s:6539.11
  
  </snip></snip>

  ffmpeg, on the other hand, produces the following output that is almost identical but includes B-frames :

  [libx264 @ 0x20b9c40] using mv_range_thread = 56
  
  [libx264 @ 0x20b9c40] using SAR=1/1
  
  [libx264 @ 0x20b9c40] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x20b9c40] profile High, level 3.1
  
  [h264 @ 0x20b8160] detected 4 logical cores
  
  Output #0, h264, to './out.264':
  
    Metadata:
  
      encoder         : Lavf54.63.104
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> libx264)
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122835 bytes
  
  [libx264 @ 0x20b9c40] frame=   1 QP=18.75 NAL=2 Slice:P Poc:8   I:984  P:2045 SKIP:571  size=54208 bytes
  
  [libx264 @ 0x20b9c40] frame=   2 QP=19.40 NAL=2 Slice:B Poc:4   I:447  P:1581 SKIP:1572 size=24930 bytes
  
  [libx264 @ 0x20b9c40] frame=   3 QP=19.78 NAL=0 Slice:B Poc:2   I:199  P:1002 SKIP:2399 size=10717 bytes
  
  [libx264 @ 0x20b9c40] frame=   4 QP=20.19 NAL=0 Slice:B Poc:6   I:204  P:1155 SKIP:2241 size=15937 bytes
  
  [libx264 @ 0x20b9c40] frame=   5 QP=18.11 NAL=2 Slice:P Poc:16  I:990  P:2221 SKIP:389  size=64240 bytes
  
  [libx264 @ 0x20b9c40] frame=   6 QP=19.35 NAL=2 Slice:B Poc:12  I:439  P:1784 SKIP:1377 size=34048 bytes
  
  [libx264 @ 0x20b9c40] frame=   7 QP=19.88 NAL=0 Slice:B Poc:10  I:275  P:1035 SKIP:2290 size=16911 bytes
  
  [libx264 @ 0x20b9c40] frame=   8 QP=19.91 NAL=0 Slice:B Poc:14  I:257  P:1270 SKIP:2073 size=19172 bytes
  
  [libx264 @ 0x20b9c40] frame=   9 QP=17.90 NAL=2 Slice:P Poc:24  I:962  P:2204 SKIP:434  size=67439 bytes
  
  [libx264 @ 0x20b9c40] frame=  10 QP=18.84 NAL=2 Slice:B Poc:20  I:474  P:1911 SKIP:1215 size=37742 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame I:7     Avg QP:15.95  size:130124
  
  [libx264 @ 0x20b9c40] frame P:52    Avg QP:17.78  size: 64787
  
  [libx264 @ 0x20b9c40] frame B:138   Avg QP:19.32  size: 26231
  
  [libx264 @ 0x20b9c40] consecutive B-frames:  6.6%  0.0%  0.0% 93.4%
  
  [libx264 @ 0x20b9c40] mb I  I16..4: 30.2% 35.2% 34.6%
  
  [libx264 @ 0x20b9c40] mb P  I16..4: 13.9% 11.4%  0.3%  P16..4: 60.4%  0.0%  0.0%  0.0%  0.0%    skip:13.9%
  
  [libx264 @ 0x20b9c40] mb B  I16..4:  5.7%  3.3%  0.0%  B16..8: 15.8%  0.0%  0.0%  direct:25.7%  skip:49.5%  L0:43.2% L1:37.3% BI:19.5%
  
  [libx264 @ 0x20b9c40] 8x8 transform intra:39.4% inter:77.2%
  
  [libx264 @ 0x20b9c40] coded y,uvDC,uvAC intra: 90.7% 26.6% 3.0% inter: 34.0% 4.1% 0.0%
  
  [libx264 @ 0x20b9c40] i16 v,h,dc,p:  7%  7% 77%  9%
  
  [libx264 @ 0x20b9c40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 16% 51%  5%  4%  3%  5%  3%  7%
  
  [libx264 @ 0x20b9c40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 27% 20%  6%  6%  3%  6%  3%  6%
  
  [libx264 @ 0x20b9c40] i8c dc,h,v,p: 71% 15% 11%  3%
  
  [libx264 @ 0x20b9c40] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x20b9c40] kb/s:4807.16
  
  </snip></snip>

  I'm sure I'm missing something simple, but I can't for the life of me see what it is. Any assistance would be greatly appreciated.

• libavcodec/libx264 do not produce B-frames

  6 novembre 2013, par Rob Schmidt

  I am writing an application in C++ that uses libavcodec with libx264 to encode video. However, the encoded data ended up being much larger than I expected. I analyzed the results and discovered that my encoding never produced B-frames, only I- and P-frames.

  I created a standalone utility based on the ffmpeg source code and examples to test my encoder setup. It reads in an H.264 file, re-encodes the decoded frames, and outputs the result to a file using the ITU H.264 Annex B format. I also used ffmpeg to perform the same operation so I could compare against a known good implementation. My utility never outputs B-frames whereas ffmpeg does.

  I have since tried to figure out what ffmpeg does that my code doesn’t. I first tried manually specifying encoder settings related to B-frames. This had no effect.

  I then tried running both ffmpeg and my utility under gdb and comparing the contents of the AVStream, AVCodecContext, and X264Context prior to opening the encoder and manually setting any fields that appeared different. Even with identical settings, I still only produce I- and P-frames.

  Finally, I thought that perhaps the problem was with my timestamp handling. I reworked my test utility to mimic the pipeline used by ffmpeg and to output timestamp debugging output like ffmpeg does. Even with my timestamps identical to ffmpeg’s I still get no B-frames.

  At this point I don’t know what else to try. When I run ffmpeg, I run it with the command line below. Note that aside from the "superfast" preset, I pretty much use the default values.

  ffmpeg -v debug -i ~/annexb.264 -codec:v libx264 -preset superfast -g 30 -f h264 ./out.264

  The code that configures the encoder is listed below. It specifies the "superfast" preset too.

  static AVStream *add_video_stream(AVFormatContext *output_ctx, AVCodec **output_codec, enum AVCodecID codec_id)
  
  {
  
      *output_codec = avcodec_find_encoder(codec_id);
  
      if (*output_codec == NULL) {
  
          printf("Could not find encoder for '%s' (%d)\n", avcodec_get_name(codec_id), codec_id);
  
          return NULL;
  
      }
  
  
  
      AVStream *output_stream = avformat_new_stream(output_ctx, *output_codec);
  
      if (output_stream == NULL) {
  
          printf("Could not create video stream.\n");
  
          return NULL;
  
      }
  
      output_stream->id = output_ctx->nb_streams - 1;
  
      AVCodecContext *codec_ctx = output_stream->codec;
  
  
  
      avcodec_get_context_defaults3(codec_ctx, *output_codec);
  
  
  
      codec_ctx->width = 1280;
  
      codec_ctx->height = 720;
  
  
  
      codec_ctx->time_base.den = 15000;
  
      codec_ctx->time_base.num = 1001;
  
  
  
  /*    codec_ctx->gop_size = 30;*/
  
      codec_ctx->pix_fmt = AV_PIX_FMT_YUVJ420P;
  
  
  
      // try to force B-frame output
  
  /*    codec_ctx->max_b_frames = 3;*/
  
  /*    codec_ctx->b_frame_strategy = 2;*/
  
  
  
      output_stream->sample_aspect_ratio.num = 1;
  
      output_stream->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->sample_aspect_ratio.num = 1;
  
      codec_ctx->sample_aspect_ratio.den = 1;
  
  
  
      codec_ctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
  
  
  
      codec_ctx->bits_per_raw_sample = 8;
  
  
  
      if ((output_ctx->oformat->flags & AVFMT_GLOBALHEADER) != 0) {
  
          codec_ctx->flags |= CODEC_FLAG_GLOBAL_HEADER;
  
      }
  
  
  
      return output_stream;
  
  }
  
  
  
  
  
  int main(int argc, char **argv)
  
  {
  
      // ... open input file 
  
  
  
      avformat_alloc_output_context2(&output_ctx, NULL, "h264", output_path);
  
      if (output_ctx == NULL) {
  
          fprintf(stderr, "Unable to allocate output context.\n");
  
          return 1;
  
      } 
  
  
  
      AVCodec *output_codec = NULL;
  
      output_stream = add_video_stream(output_ctx, &output_codec, output_ctx->oformat->video_codec);
  
      if (output_stream == NULL) {
  
          fprintf(stderr, "Error adding video stream to output context.\n");
  
          return 1;
  
      }
  
      encode_ctx = output_stream->codec;
  
  
  
      // seems to have no effect
  
  #if 0
  
      if (decode_ctx->extradata_size != 0) {
  
          size_t extradata_size = decode_ctx->extradata_size;
  
          printf("extradata_size: %zu\n", extradata_size);
  
          encode_ctx->extradata = av_mallocz(extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
  
          memcpy(encode_ctx->extradata, decode_ctx->extradata, extradata_size);
  
          encode_ctx->extradata_size = extradata_size;
  
      }
  
  #endif // 0
  
  
  
      AVDictionary *opts = NULL;
  
      av_dict_set(&opts, "preset", "superfast", 0);
  
      // av_dict_set(&opts, "threads", "auto", 0); // seems to have no effect
  
  
  
      ret = avcodec_open2(encode_ctx, output_codec, &opts);
  
      if (ret < 0) {
  
          fprintf(stderr, "Unable to open output video cocec: %s\n", av_err2str(ret));
  
          return 1;
  
      }
  
  
  
      // ... decoding/encoding loop, clean up, etc.
  
  
  
      return 0;
  
  }

  My test utility produces the following debug output in which you can see there are no B-frames produced :

  [libx264 @ 0x1b8c9c0] using mv_range_thread = 56
  
  [libx264 @ 0x1b8c9c0] using SAR=1/1
  
  [libx264 @ 0x1b8c9c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x1b8c9c0] profile High, level 3.1
  
  Output #0, h264, to './out.264':
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122837 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   1 QP=18.03 NAL=2 Slice:P Poc:2   I:411  P:1825 SKIP:1364 size=25863 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   2 QP=17.03 NAL=2 Slice:P Poc:4   I:369  P:2159 SKIP:1072 size=37880 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   3 QP=16.90 NAL=2 Slice:P Poc:6   I:498  P:2330 SKIP:772  size=50509 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   4 QP=16.68 NAL=2 Slice:P Poc:8   I:504  P:2233 SKIP:863  size=50791 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   5 QP=16.52 NAL=2 Slice:P Poc:10  I:513  P:2286 SKIP:801  size=51820 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   6 QP=16.49 NAL=2 Slice:P Poc:12  I:461  P:2293 SKIP:846  size=51311 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   7 QP=16.65 NAL=2 Slice:P Poc:14  I:476  P:2287 SKIP:837  size=51196 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   8 QP=16.66 NAL=2 Slice:P Poc:16  I:508  P:2240 SKIP:852  size=51577 bytes
  
  [libx264 @ 0x1b8c9c0] frame=   9 QP=16.55 NAL=2 Slice:P Poc:18  I:477  P:2278 SKIP:845  size=51531 bytes
  
  [libx264 @ 0x1b8c9c0] frame=  10 QP=16.67 NAL=2 Slice:P Poc:20  I:517  P:2233 SKIP:850  size=51946 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x1b8c9c0] frame I:7     Avg QP:13.71  size:152207
  
  [libx264 @ 0x1b8c9c0] frame P:190   Avg QP:16.66  size: 50949
  
  [libx264 @ 0x1b8c9c0] mb I  I16..4: 27.1% 30.8% 42.1%
  
  [libx264 @ 0x1b8c9c0] mb P  I16..4:  6.8%  6.0%  0.8%  P16..4: 61.8%  0.0%  0.0%  0.0%  0.0%    skip:24.7%
  
  [libx264 @ 0x1b8c9c0] 8x8 transform intra:41.2% inter:86.9%
  
  [libx264 @ 0x1b8c9c0] coded y,uvDC,uvAC intra: 92.2% 28.3% 5.4% inter: 50.3% 1.9% 0.0%
  
  [libx264 @ 0x1b8c9c0] i16 v,h,dc,p:  7%  7% 77%  8%
  
  [libx264 @ 0x1b8c9c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 15% 49%  6%  4%  3%  5%  3%  8%
  
  [libx264 @ 0x1b8c9c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 25% 24%  6%  7%  4%  6%  3%  6%
  
  [libx264 @ 0x1b8c9c0] i8c dc,h,v,p: 72% 14% 10%  4%
  
  [libx264 @ 0x1b8c9c0] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x1b8c9c0] kb/s:6539.11
  
  </snip></snip>

  ffmpeg, on the other hand, produces the following output that is almost identical but includes B-frames :

  [libx264 @ 0x20b9c40] using mv_range_thread = 56
  
  [libx264 @ 0x20b9c40] using SAR=1/1
  
  [libx264 @ 0x20b9c40] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
  
  [libx264 @ 0x20b9c40] profile High, level 3.1
  
  [h264 @ 0x20b8160] detected 4 logical cores
  
  Output #0, h264, to './out.264':
  
    Metadata:
  
      encoder         : Lavf54.63.104
  
      Stream #0:0, 0, 1/90000: Video: h264, yuvj420p, 1280x720 [SAR 1:1 DAR 16:9], 1001/15000, q=-1--1, 90k tbn, 14.99 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> libx264)
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame=   0 QP=17.22 NAL=3 Slice:I Poc:0   I:3600 P:0    SKIP:0    size=122835 bytes
  
  [libx264 @ 0x20b9c40] frame=   1 QP=18.75 NAL=2 Slice:P Poc:8   I:984  P:2045 SKIP:571  size=54208 bytes
  
  [libx264 @ 0x20b9c40] frame=   2 QP=19.40 NAL=2 Slice:B Poc:4   I:447  P:1581 SKIP:1572 size=24930 bytes
  
  [libx264 @ 0x20b9c40] frame=   3 QP=19.78 NAL=0 Slice:B Poc:2   I:199  P:1002 SKIP:2399 size=10717 bytes
  
  [libx264 @ 0x20b9c40] frame=   4 QP=20.19 NAL=0 Slice:B Poc:6   I:204  P:1155 SKIP:2241 size=15937 bytes
  
  [libx264 @ 0x20b9c40] frame=   5 QP=18.11 NAL=2 Slice:P Poc:16  I:990  P:2221 SKIP:389  size=64240 bytes
  
  [libx264 @ 0x20b9c40] frame=   6 QP=19.35 NAL=2 Slice:B Poc:12  I:439  P:1784 SKIP:1377 size=34048 bytes
  
  [libx264 @ 0x20b9c40] frame=   7 QP=19.88 NAL=0 Slice:B Poc:10  I:275  P:1035 SKIP:2290 size=16911 bytes
  
  [libx264 @ 0x20b9c40] frame=   8 QP=19.91 NAL=0 Slice:B Poc:14  I:257  P:1270 SKIP:2073 size=19172 bytes
  
  [libx264 @ 0x20b9c40] frame=   9 QP=17.90 NAL=2 Slice:P Poc:24  I:962  P:2204 SKIP:434  size=67439 bytes
  
  [libx264 @ 0x20b9c40] frame=  10 QP=18.84 NAL=2 Slice:B Poc:20  I:474  P:1911 SKIP:1215 size=37742 bytes
  
  
  
  <snip>
  
  
  
  [libx264 @ 0x20b9c40] frame I:7     Avg QP:15.95  size:130124
  
  [libx264 @ 0x20b9c40] frame P:52    Avg QP:17.78  size: 64787
  
  [libx264 @ 0x20b9c40] frame B:138   Avg QP:19.32  size: 26231
  
  [libx264 @ 0x20b9c40] consecutive B-frames:  6.6%  0.0%  0.0% 93.4%
  
  [libx264 @ 0x20b9c40] mb I  I16..4: 30.2% 35.2% 34.6%
  
  [libx264 @ 0x20b9c40] mb P  I16..4: 13.9% 11.4%  0.3%  P16..4: 60.4%  0.0%  0.0%  0.0%  0.0%    skip:13.9%
  
  [libx264 @ 0x20b9c40] mb B  I16..4:  5.7%  3.3%  0.0%  B16..8: 15.8%  0.0%  0.0%  direct:25.7%  skip:49.5%  L0:43.2% L1:37.3% BI:19.5%
  
  [libx264 @ 0x20b9c40] 8x8 transform intra:39.4% inter:77.2%
  
  [libx264 @ 0x20b9c40] coded y,uvDC,uvAC intra: 90.7% 26.6% 3.0% inter: 34.0% 4.1% 0.0%
  
  [libx264 @ 0x20b9c40] i16 v,h,dc,p:  7%  7% 77%  9%
  
  [libx264 @ 0x20b9c40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7% 16% 51%  5%  4%  3%  5%  3%  7%
  
  [libx264 @ 0x20b9c40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 27% 20%  6%  6%  3%  6%  3%  6%
  
  [libx264 @ 0x20b9c40] i8c dc,h,v,p: 71% 15% 11%  3%
  
  [libx264 @ 0x20b9c40] Weighted P-Frames: Y:0.0% UV:0.0%
  
  [libx264 @ 0x20b9c40] kb/s:4807.16
  
  </snip></snip>

  I’m sure I’m missing something simple, but I can’t for the life of me see what it is. Any assistance would be greatly appreciated.