Newest 'x264' Questions - Stack Overflow

Les articles publiés sur le site

• What are VP9 Codec settings comparable to x264 encoder with preset=ultrafast setting regarding CPU ?

  11 juin 2021, par xKubo

  I'd like to replace the x264 codec [codec settings: preset=ultrafast] with the vp9 codec. My primary requirement is that the encoding has less or approximately equal CPU, while keeping the quality of the video roughly the same. I tried the following settings, however my CPU is still roughly 30% higher.

  VP9 codec settings: crf=30;quality=realtime;speed=15;lag-in-frames=7

  x264 codec settings: preset=ultrafast;

  Is there any codec setting that can lower my CPU during encoding even more?

  I am constrained to only a single thread. Screenshot of my simple testing app

• FFMPEG X264 reduce bitrate for unchanging input

  8 juin 2021, par GroovyDotCom

  ffmpeg -f lavfi -i smptebars=duration=1000:size=640x360:rate=30 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 -f mpegts video.ts
  

  As can be seen when running this command, the encode size continues to grow rapidly even though:

  1. The input source never changes. It is exactly the same image again and again.
  2. The encoder has been told to insert a keyframe only once every 1000 frames

  Is there some configuration option I could add to change this behaviour? I can understand it would need to send an empty P frame but right now it seems to be sending much much more?

  UPDATE After Tim Roberts comment, I realized we can get a clearer picture of the file growth if I change the command to 1 FPS and do the encode in real-time.

  ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.ts

  Now I see that it is going up almost exactly 1KB per frame. That seems like a lot for a P-frame that does nothing.

  So, just for kicks, I got rid of the TS muxing.

  ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.h264

  Now the file grows by 1k every 17 frames - a 17X improvement!

  This seems to point to ffmpeg doing something weird in the TS muxer that inflates an 80 byte P-frame into 1K.

• x264 / libx264 : Can only one I/P frame to be used as reference for B-frames ?

  29 mai 2021, par Maria

  As you know ref parameter can set the number of previous frames each P-frame can use as references.

  I need the same thing for B-Frames, but ref=1 does not work for B-Frames.

  I mean an I/P frame to be used as reference for B-frames only.

  is it possible with a command line? , or by change the following function in the source code ?

  static inline int reference_update( x264_t *h )
  {
  if( !h->fdec->b_kept_as_ref )
  {
      if( h->i_thread_frames > 1 )
      {
          x264_frame_push_unused( h, h->fdec );
          h->fdec = x264_frame_pop_unused( h, 1 );
          if( !h->fdec )
              return -1;
      }
      return 0;
  }
  
  /* apply mmco from previous frame. */
  for( int i = 0; i < h->sh.i_mmco_command_count; i++ )
      for( int j = 0; h->frames.reference[j]; j++ )
          if( h->frames.reference[j]->i_poc == h->sh.mmco[i].i_poc )
              x264_frame_push_unused( h, x264_frame_shift( &h->frames.reference[j] ) );
  
  /* move frame in the buffer */
  x264_frame_push( h->frames.reference, h->fdec );
  if( h->frames.reference[h->sps->i_num_ref_frames] )
      x264_frame_push_unused( h, x264_frame_shift( h->frames.reference ) );
  h->fdec = x264_frame_pop_unused( h, 1 );
  if( !h->fdec )
      return -1;
  return 0;
  }
  

• Extract Motion Vectors From x264 source code

  27 mai 2021, par Essam Aly

  If you are familiar with the x264 source code, where in the code I can extract the MV (motion vectors) of each frame? Can you point please to a line of code I can intercept and save the MVs to disk? Thank you.

• how does decoder handle media packet lose/out of order/repeat ?

  20 mai 2021, par woder

  this might not be a good question, because it is big, but sincerely, I want to get the overall knowledge of Quality guarantee of video communication：

  we know it media packet will lose or out of order or repeat in network realtime communication:

  In transport layer, assume that we use rtp to transport media and rtcp to control and feedback; we can use a buffer to save rtp packets, so we can reorder packets by rtp sequence to solve problem out of order, and filter repeat packets to solve repeat, use rtcp packet to tell the sender that I have lost rtp packet of sequence xxx to solve lose;

  But I have a lot of confusions on decode layer, assume that we have got media packets now and start decoding packets:

  Question 1: We know what if we lose a I frame, the subsequent P/B frames will fail to decode, but what will hapen if we lose a P/B frame? In h.264, there are inter-predict, what if the lost P/B frame was referred by subsequent frames, does subsequent frames will totally fail to decode? Or just the inter-predict macroblocks of subsequent frames will fail to decode while intra-predict macroblocks can be decoded then the decoder still can generate a broken frame to us?

  Question 2: one frame might be consisted of multiple packets, what if we lose a packet, does this frame will totally fail to decode? Or we can get a broken frame?

  Question 3: Do media decoders like x264/openh264 will handle packets repeat and out of order?