Recherche avancée

Sur d’autres sites (7653)

• Playback of x264 encoded video in FLV is very slow (screen recording)

  23 août 2020, par NewbieCoder

  Task :
  
I am recording the screen in 30 FPS and saving it to an FLV file. Images of the screen are obtained using the DXGI API in Windows. These images are then encoded into a video using libx264. Then the video data is stored in FLV container.

  


  Issue/Problem :
  
When the video is played in any video player, it is very slow. The frame rate information shows as 30 FPS but the playback feels like 15 FPS.

  


  Details :
  
Pseudo-code for the whole software :

  

  


  FPS = 30
target_time_for_each_frame = 1/FPS;
timestamp = 0;
while (true)
{
    start_time = current_time();

    image = capture_screen();
    video_data = encode(image);
    writeToFLV(video_data, timestamp);
    timestamp += target_time_for_each_frame;

    end_time = current_time();
    time_taken_for_current_frame = (end_time - start_time)

    // put the app to sleep to take screenshots only at 1/FPS or 33ms intervals. (delaying)
    if (time_taken_for_current_frame < target_time_for_each_frame)
    {
        sleep(target_time_for_each_frame - time_taken_for_current_frame)
    }
}


  


  I am encoding with these parameters :

  


  void init_encoder()
{
        x264_param_default_preset(&param, "veryfast", 0);

        param.i_width = 1920;
        param.i_height = 1080;
        param.i_fps_num = 30;
        param.i_fps_den = 1;
        param.i_timebase_num = param.i_fps_den;
        param.i_timebase_den = param.i_fps_num;
        param.rc.i_bitrate = 2500;
        param.i_bframe = 0;
        param.rc.i_rc_method = X264_RC_ABR;
        param.rc.f_rf_constant = 0;
        //param.rc.b_filler = true;
        param.rc.i_vbv_max_bitrate = param.rc.i_bitrate;
        param.rc.i_vbv_buffer_size = param.rc.i_bitrate;
        param.b_repeat_headers = 0;
        param.b_annexb = 1;

        x264_param_apply_profile(&param, 0);
}


  


  The timestamp given for the FLV file is correct :

  


  timestamp += (1/30)   // It is increased by 33 ms every loop


  


  I am setting pts of the input picture in this code :

  


  int encodeYUV(uint8_t* data)
    {
        // convert BGRA to YUV using FFmpeg
        BGRA.data[0] = data;
        sws_scale(sws, BGRA.data, BGRA.linesize, 0, param.i_height, picIn.img.plane, picIn.img.i_stride);

        nal_size = x264_encoder_encode(h, &nals, &nal_count, &picIn, &picOut);
        picIn.i_pts += 1; // pts += 1 because timebase_num = 1, timebase_den = 30. So it increases by 33 ms

        return 0;
    }


  


  Increasing the pts to a very high value every loop (pts += 1000) makes the playback very pixelated and also plays very fast and repeats the same frame again and again sometimes.

  


  Before this problem, I used tune as "zerolatency" and the playback was fine. But the video quality was not good so I had to remove it. And once I removed it, these problems came.

  
The parameters I'm using are not recommended for recording a video, but they are good for live streaming. My main purpose is a screen sharing app. I am using it as a screen recorder only to test if it works.

  

  

  


  I am not sure if the problem is in the way I increase PTS or timestamp or if it is in the way I coded the delay in the app (to cap the FPS correctly). The problem really feels like it's related to only these factors (x264 PTS or FLV timestamp or delay code).

  


  Any hints would be very much appreciated.

  


• avfilter/formats : allow unknown channel layouts by default

  22 novembre 2016, par Marton Balint

  avfilter/formats : allow unknown channel layouts by default
  Since the default in the libav fork is to only allow known layouts, making
  
  unknown layouts allowed by default here can be a security risk for filters
  
  directly merged from libav. However, usually it is simple to detect such cases,
  
  use of av_get_channel_layout_nb_channels is a good indicator, so I suggest we
  
  change this regardless.
  See http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203204.html.
  This patch indirectly adds unknown channel layout support for filters where
  
  query_formats is not specified :
  abench
  
  afifo
  
  ainterleave
  
  anullsink
  
  apad
  
  aperms
  
  arealtime
  
  aselect
  
  asendcmd
  
  asetnsamples
  
  asetpts
  
  asettb
  
  ashowinfo
  
  azmq
  It introduces a query_formats callback for the asyncts filter, which only
  
  supports known channel layouts since it is using libavresample.
  And it removes .query_formats callback from filters where it was only there to
  
  support unknown layouts, as this is now the default :
  aloop
  
  ametadata
  
  anull
  
  asidedata
  
  asplit
  
  atrim
  Acked-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavfilter/af_anull.c
  • [DH] libavfilter/af_asyncts.c
  • [DH] libavfilter/f_loop.c
  • [DH] libavfilter/f_metadata.c
  • [DH] libavfilter/f_sidedata.c
  • [DH] libavfilter/formats.c
  • [DH] libavfilter/formats.h
  • [DH] libavfilter/split.c
  • [DH] libavfilter/trim.c

• avcodec/cbs : Factor out common code for writing units

  17 novembre 2019, par Andreas Rheinhardt

  avcodec/cbs : Factor out common code for writing units
  All cbs-functions to write units share a common pattern :
  
  1. They check whether they have a write buffer (that is used to store
  
  the unit's data until the needed size becomes known after writing the
  
  unit when a dedicated buffer will be allocated).
  
  2. They use this buffer for a PutBitContext.
  
  3. The (codec-specific) writing takes place through the PutBitContext.
  
  4. The return value is checked. AVERROR(ENOSPC) here always indicates
  
  that the buffer was too small and leads to a reallocation of said
  
  buffer.
  
  5. The final buffer will be allocated and the data copied.
  This commit factors this common code out in a single function in cbs.c.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/cbs.c
  • [DH] libavcodec/cbs.h
  • [DH] libavcodec/cbs_av1.c
  • [DH] libavcodec/cbs_av1.h
  • [DH] libavcodec/cbs_h2645.c
  • [DH] libavcodec/cbs_h2645.h
  • [DH] libavcodec/cbs_internal.h
  • [DH] libavcodec/cbs_jpeg.c
  • [DH] libavcodec/cbs_jpeg.h
  • [DH] libavcodec/cbs_mpeg2.c
  • [DH] libavcodec/cbs_mpeg2.h
  • [DH] libavcodec/cbs_vp9.c
  • [DH] libavcodec/cbs_vp9.h