Recherche avancée

Sur d’autres sites (11598)

• Merge remote-tracking branch ’qatar/master’

  28 mai 2013, par Michael Niedermayer

  Merge remote-tracking branch ’qatar/master’
  * qatar/master :
  
    smacker : add a clarification notice about audio decoding
  
    configure : make jack depend on pthreads
  Conflicts :
  
  	configure
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] configure
  • [DH] libavcodec/smacker.c

• ffmpeg dshow Frame dropped on removal and re-insertion of headset

  11 février 2019, par Debendra Modi

  I am using avformat_open_input and av_read_frame to capture audio frames from my usb headset (speaker and mic - "audio=virtual-audio-capturer" and my usb mic device) and then further processing of the frame. Everything works fine. I can run my code for days without any issue. However, when I remove my headset from the usb jack, as expected av_read_frame gives an error code -5.

  At this time, I close my input device using avformat_close_input and try to open the input device. This continues to fail till I re-insert my headset. I am then again able to capture the frames and process them. However, after some time, I get messages as follows from the ffmpeg library -

  [dshow @ 0a529040] real-time buffer [virtual-audio-capturer] [audio input] too full or near too full (99% of size : 3041280 [rtbufsize parameter]) ! frame dropped !

  It appears dshow continues to capture frames although I have closed the input. Most forums mention to increase the rtbufsize, but that may not be a proper solution specially if I want to remove my headset for long duration.

  Isn’t there any way to stop dshow from capturing frames so that i am able to run my code without dropping frames, regardless of how many times or how long I remove the headset ?

  Thanks in advance.

• Best Settings for H264_Nvenc To Minimize Latency ? (FFMPEG)

  1er novembre 2022, par M. Ying

  I'm currently using Libavcodec to encode video frames using H.264. Because I'm streaming this video frames after they're encoded, minimizing latency is crucial to me. My current settings are :

  



  avcodec_register_all();
codec = avcodec_find_encoder(AV_CODEC_ID_H264);

// allocate and set ffmpeg context
context = avcodec_alloc_context3(encoder->codec);
context->bit_rate = bitrate;
context->width = out_width;
context->height = out_height;
context->time_base.num = 1;
context->time_base.den = 30;
context->gop_size = 1; // send SPS/PPS headers every packet
context->max_b_frames = 0;
context->pix_fmt = AV_PIX_FMT_YUV420P;

// set encoder parameters to max performance
av_opt_set(context->priv_data, "preset", "ultrafast", 0);
av_opt_set(context->priv_data, "tune", "zerolatency", 0);

// open capture encoder
avcodec_open2(context, codec, NULL);


  



  These settings work well, but I am trying to switch to hardware-based encoding to take the workload off my CPU. I currently have an NVIDIA GPU, so I tried using the following settings with h264_nvenc :

  



  codec = avcodec_find_encoder_by_name("h264_nvenc");

// allocate and set ffmpeg context
context = avcodec_alloc_context3(encoder->codec);
context->dct_algo = FF_DCT_FASTINT;
context->bit_rate = bitrate;
context->width = out_width;
context->height = out_height;
context->time_base.num = 1;
context->time_base.den = 30;
context->gop_size = 1; // send SPS/PPS headers every packet
context->max_b_frames = 0;
context->pix_fmt = AV_PIX_FMT_YUV420P;

// set encoder parameters to max performancen
av_opt_set(context->priv_data, "preset", "llhq", 0);
av_opt_set(context->priv_data, "tune", "zerolatency", 0);


  



  The issue is, I noticed that the latency with h264_nvenc is significantly more than the latency with AV_CODEC_ID_H264 (the software-based version). I think that my settings or setup of h264_nvenc must be wrong, since GPU-based encoding should be faster than software-based encoding. Could anyone point me in the right direction ? Thanks so much !