Recherche avancée

Sur d’autres sites (13917)

• ffmpeg avformat_open_input() function causes memory leak when receiving live stream

  12 septembre 2023, par george_d

  I have live streams (can be UDP or HLS, video codec is H264), from which I grab frames for further processing.

  


  For this purpose, I use ffmpeg + nvjpeg + cuda libraries.

  


  However I noticed memory leak - memory usage periodically (every 10-20 seconds) is increased by 100-400 KB, the amount and period may vary.

  


  After disabling pieces of code one by one, I realized that it is avformat_open_input() which causes memory leak.

  


  No matter which buffer settings (https://ffmpeg.org/ffmpeg-protocols.html#udp) I choose for UDP, the leak still persists. Same goes for HLS streams.

  


  I tried to find anything related to this problem, but all the sources I found claimed that this problem took place in the past and has been fixed.

  


  Is there some mysterious setting I am missing, so that memory could be freed properly ?

  


  Or is this memory supposed to be freed when processing frames (i.e. using av_read_frame() and av_packet_unref(), etc) ?

  


  Minimal example of code to reproduce the problem :

  


  avformat_example.cpp

  


  #include &#xA;extern "C" {&#xA;    #include <libavformat></libavformat>avformat.h>&#xA;    #include <libavcodec></libavcodec>avcodec.h>&#xA;}&#xA;&#xA;int main(int argc, char *argv[]){&#xA;    if (argc &lt; 2) {&#xA;      return 1;&#xA;    }&#xA;&#xA;    char* inputSource = argv[1];&#xA;    AVFormatContext *ctx = NULL;&#xA;&#xA;    if (avformat_open_input(&amp;ctx, inputSource, NULL, NULL) != 0) {&#xA;        av_log(NULL,&#xA;               AV_LOG_ERROR,&#xA;               "Cannot open &#x27;%s&#x27;",&#xA;               inputSource);&#xA;        return 1;&#xA;    }&#xA;&#xA;    /*&#xA;    This loop is placed here to demonstrate&#xA;    avformat_open_input() causing leak.&#xA;    Actually, instead of noop loop there is logic of getting and processing frames,&#xA;    but it doesn&#x27;t matter now.&#xA;    As loop goes on, the amount of leaked memory increases.&#xA;    */&#xA;    while(true) {&#xA;      sleep(1);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;

  


  Compile with :

  


  g++ avformat_example.cpp -lavcodec -lavutil -lavformat -I/usr/include/ffmpeg-cuda -o avformat_open_input_example


  


  Run :

  


  ./avformat_open_input_example "udp://127.0.0.1:5000?reuse=1&pkt_size=1316&buffer_size=1310720&fifo_size=40000"


  


  Version of ffmpeg underlying libraries :

  


  libavutil      58.  7.100 / 58.  7.100
libavcodec     60. 11.100 / 60. 11.100
libavformat    60.  5.100 / 60.  5.100
libavdevice    60.  2.100 / 60.  2.100
libavfilter     9.  8.100 /  9.  8.100
libswscale      7.  2.100 /  7.  2.100
libswresample   4. 11.100 /  4. 11.100


  


• Inconsistent behaviour of ffmpeg -i flag

  19 mai 2021, par zeebrah

  I'm trying to write a Bash script that would download an audio track from youtube and convert it to Apple ringtone format, which is .m4r. The tools I employ are youtube-dl and ffmpeg. The former seems to work fine but I have a strange issue with the latter. When I try to pass the name of the file parametrically, shell prints that file or directory can't be found.

  


  I use the same method for unwraping user input (or my defaults) for both commands but it only seems to work with youtube-dl.

  


  Example of what doesn't work and print the text above. Obviously, all the files are in fact there and accessible

  


  youtube-dl -i --extract-audio --audio-format m4a -o $filepath_interim  --audio-quality 0 $video_link
ffmpeg -i $filepath_interim -acodec copy -f ipod -ss $offset  -t $length $filepath_out


  


  So, I tried to do it with '' strings, $(command) syntax, it all failed. I only found one way to make it work, which is to hard code the values of the paths but this defeats the whole purpose of my script.

  


  youtube-dl -i --extract-audio --audio-format m4a -o $filepath_interim  --audio-quality 0 $video_link
ffmpeg -i ~/Downloads/ringtone.m4a -acodec copy -f ipod -ss $offset  -t $length ~/Downloads/ringtone.m4r


  


  I want to figure out why this keeps happening, whether it is in any way specific to ffmpeg or am I just missing some piece of knowledge about $ name unwrapping.

  


  Minimal Working Example. Run with bash or pack in script and run. If your path to bash is different, please change the shebang :

  


  #!/usr/local/bin/bash
# initialise
filepath_interim="~/Downloads/ringtone.m4a"
filepath_out="~/Downloads/ringtone.m4r"
video_link="https://www.youtube.com/watch?v=dQw4w9WgXcQ"
offset=0
length=30

# main part
youtube-dl -i --extract-audio --audio-format m4a -o $filepath_interim  --audio-quality 0 $video_link
ffmpeg -i $filepath_interim -acodec copy -f ipod -ss $offset  -t $length $filepath_out


  


• SDL2 won't play with more than 6 audio channels

  13 juin 2020, par Hiko Haieto

  I am trying to stream (raw) video and audio from a capture device as part of my home media setup (with my pc acting similarly to a receiver in a typical home theatre setup), but the biggest problem I haven't been able to get past is that I haven't been able to get ffplay (using SDL2 as its audio backend) to work with all 8 channels in 7.1 streams - two simply get dropped, despite it recognising 8 channel input or me specifying a 7.1 layout.

  



  I have been able to confirm that all 8 channels are present in the source by first using ffmpeg to save the output of a speaker test to a file and playing that back with both mplayer (which works) and ffplay (which doesn't). I also wrote some minimal code to play the audio directly through SDL's API with the same result, so it's not the fault of ffplay. I might simply use mplayer if it weren't for the fact that piping output from ffmpeg adds too much latency for real-time use. I am using libSDL version 2.0.12 and ffplay 4.2.3, both of which are the latest at the time of writing and are ostensibly supposed to support 7.1 audio.

  



  Using output recorded from speaker-test -c 8, I am using the following to play it back in mplayer :

  



  mplayer -channels 8 -rawaudio channels=8 -format s16le -demuxer rawaudio speaker-test.pcm


  



  and the following to play it back in ffplay :

  



  ffplay -f s16le -ac 8 -af 'channelmap=channel_layout=7.1' speaker-test.pcm


  



  No matter what I try, the two side channels get dropped. I couldn't figure out how to play raw pcm in SDL, so I repeated the same tests with wav output and used the following code to play it back :

  



  #include <sdl2></sdl2>SDL.h>&#xA;&#xA;int main(int argc, char **argv) {&#xA;    SDL_Init(SDL_INIT_AUDIO);&#xA;    SDL_AudioSpec wavSpec;&#xA;    Uint32 wavLength;&#xA;    Uint8 *wavBuffer;&#xA;    SDL_LoadWAV("speaker-test.wav", &amp;wavSpec, &amp;wavBuffer, &amp;wavLength);&#xA;    SDL_AudioDeviceID deviceID = SDL_OpenAudioDevice(NULL, 0, &amp;wavSpec, NULL, 0);&#xA;    SDL_QueueAudio(deviceID, wavBuffer, wavLength);&#xA;    SDL_PauseAudioDevice(deviceID, 0);&#xA;    SDL_Delay(30000);&#xA;    SDL_CloseAudioDevice(deviceID);&#xA;    SDL_FreeWAV(wavBuffer);&#xA;    SDL_Quit();&#xA;    return 0;&#xA;}&#xA;

  



  The above code exhibits the same behaviour of dropping the two additional side channels, despite it being the latest version of SDL that should have supported 7.1 for many releases now. Why might this be happening, and how might I fix it ?