Recherche avancée

Sur d’autres sites (7677)

• FFMPEG h264 grey frame and artifacts at beginning

  28 novembre 2011, par marce002

  I'm splitting my "zi6 quicktime mov" hd videos, I have 250 clips of around 10 or 15 seconds each, from lot of places, locationes around the globe and want to combine them in a single big clip.

  I can merge them very good with "mkvmerge".

  The problem is that the first frames of all videos in the collection (splitted with ffmpeg), are gray or with artifacts at beggining, I do not know how to explain, maybe wrong ffmpeg commands, I'm doing this (with batch command line, which is great / fast for me) :

  =======begin of batch file

  ffmpeg -i jockey_club_fpv.mov -ss 00:00:17 -t 00:00:24 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3a.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:04:40 -t 00:00:20 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3b.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:05:35 -t 00:01:00 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3c.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:07:11 -t 00:00:10 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3d.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:07:45 -t 00:00:21 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3e.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:08:47 -t 00:00:05 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3f.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:09:18 -t 00:00:10 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3g.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:09:35 -t 00:00:09 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3h.mov
  
  ffmpeg -i jockey_club_fpv.mov -ss 00:10:07 -t 00:00:16 -g 1 -sameq -vcodec copy -vf fade=in:0:30 partes3i.mov
  
  mkvmerge -o join4.mov partes3a.mov + partes3b.mov + partes3c.mov + partes3d.mov + partes3e.mov + partes3f.mov + partes3g.mov + partes3h.mov + partes3i.mov

  =======end of batch file

  Thanks a lot for any answer !!

• Java library for converting MP4 to MPEG-2 TS in memory ?

  30 avril 2014, par Lane

  SO...

  I have a Java FX application that runs an embedded HTTP Live Streaming server for video playback using the Media class (NOT live streaming, video on demand). The video playback consists of multiple files that are actually storing a collection of RTP packets. When my HttpHandler is called to handle the get request for the files (entries in the .m3u8 index file), I plan on...

  • Loading the file into memory
  • Creating a byte array of the RAW H264 packets
  • Convert (wrap ?) the RAW H264 to a MPEG-2 TS (ffmpeg -i video.h264 video.ts)
  • Write the MPEG-2 TS contents to the response body so that it can be played

  ...one of my requirements is that I am not able to create local files, even temp ones. So I cannot create a .h264 file, use ffmpeg to create a .ts file, read the ts file and then write the contents to the response body.

  As far as I can tell, Xuggler does not work with streams and JCodec is slow. I am fairly confident that I can dig into and understand the MPEG-2 TS format and simply convert the RAW H264 into the appropriate format, but this seems like a lot of needless work that should have been done before.

  Anyone know of a simple way to convert RAW H264 to MPEG-2 TS ? Or MP4 to MPEG-2 TS ? I can use MP4Parser to create the MP4 data in memory quickly, I just need a java library that can generate MPEG-2 TS data, thanks !

• 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