Recherche avancée

Sur d’autres sites (7919)

• Correct Use Of avcodec_encode_video2() Flush

  5 février 2016, par mFeinstein

  I have a camera sending pictures to a callback function and I want to make a movie with this pictures using FFmpeg. I have followed the decoding_encoding example here but am not sure how to use the got_output for flushing the encoder and getting the delayed frames.

  1. Shoud I encode all my camera’s pictures when they arrive, and later when I want to stop capturing and close the video, I do the flush loop ?

  Or

  2. Should I do the flush periodically, let’s say, every 100 pictures received ?

  My video capture program could be running for hours, so I am worried about how this delayed frames work in memory consumption, if they stack up there until the flush, this could take all my memory.

  ---

  This is the encoding performed by the example, it makes 25 dummy Frames for 1 second of video, and later, in the end, it loop through avcodec_encode_video2() looking for got_output for delayed frames :

  /////  Prepare the Frame, CodecContext and some aditional logic.....
  
  
  
  /* encode 1 second of video */
  
  for (i = 0; i < 25; i++) {
  
      av_init_packet(&pkt);
  
      pkt.data = NULL;    // packet data will be allocated by the encoder
  
      pkt.size = 0;
  
      fflush(stdout);
  
      /* prepare a dummy image */
  
      /* Y */
  
      for (y = 0; y < c->height; y++) {
  
          for (x = 0; x < c->width; x++) {
  
              frame->data[0][y * frame->linesize[0] + x] = x + y + i * 3;
  
          }
  
      }
  
      /* Cb and Cr */
  
      for (y = 0; y < c->height/2; y++) {
  
          for (x = 0; x < c->width/2; x++) {
  
              frame->data[1][y * frame->linesize[1] + x] = 128 + y + i * 2;
  
              frame->data[2][y * frame->linesize[2] + x] = 64 + x + i * 5;
  
          }
  
      }
  
      frame->pts = i;
  
      /* encode the image */
  
      ret = avcodec_encode_video2(c, &pkt, frame, &got_output);
  
      if (ret < 0) {
  
          fprintf(stderr, "Error encoding frame\n");
  
          exit(1);
  
      }
  
      if (got_output) {
  
          printf("Write frame %3d (size=%5d)\n", i, pkt.size);
  
          fwrite(pkt.data, 1, pkt.size, f);
  
          av_free_packet(&pkt);
  
      }
  
  }
  
  /* get the delayed frames */
  
  for (got_output = 1; got_output; i++) {
  
      fflush(stdout);
  
      ret = avcodec_encode_video2(c, &pkt, NULL, &got_output);
  
      if (ret < 0) {
  
          fprintf(stderr, "Error encoding frame\n");
  
          exit(1);
  
      }
  
      if (got_output) {
  
          printf("Write frame %3d (size=%5d)\n", i, pkt.size);
  
          fwrite(pkt.data, 1, pkt.size, f);
  
          av_free_packet(&pkt);
  
      }
  
  }
  
  
  
  /////  Closes the file and finishes.....

• Can I specify unique pts for each frame in commandline ? [closed]

  24 septembre 2024, par postscripter

  I have a bunch of jpeg pictures, say four : 01.jpg, 05jpg, 12.jpg and 13.jpg. Can I create an mjpeg/mp4 with variable framerate, consisting of exactly four frames with pts = 01 sec, 05 sec, 12 sec and 13 sec respectively ? Without duplicating or looping them ? I believe it can be done with ffmpeg API, but I'm limited to cmd only.

  


• avformat/asfdec_o : Don't segfault with lots of attached pics

  12 novembre 2020, par Andreas Rheinhardt

  avformat/asfdec_o : Don't segfault with lots of attached pics
  The ASF file format has a limit of 127 streams and the "asf_o" demuxer
  
  (the ASF demuxer from Libav) has an array of pointers for a structure
  
  called ASFStream that is allocated on demand for every stream. Attached
  
  pictures are not streams in the sense of the ASF specification, yet the
  
  demuxer created an ASFStream for them ; and in one codepath it also
  
  forgot to check whether the array of ASFStreams is already full. The
  
  result is a write beyond the end of the array and a segfault lateron.
  Fixing this is easy : Don't create ASFStreams for attached picture
  
  streams.
  (Other results of the current state of affairs are unnecessary allocations
  
  (of ASFStreams structures), the misparsing of valid files (there might not
  
  be enough ASFStreams left for the valid streams if attached pictures take
  
  up too many) ; furthermore, the ASFStreams created for attached pictures all
  
  have the stream number 0, an invalid stream number (the valid range is
  
  1-127). This means that invalid data (packets for a stream with stream
  
  number 0) won't get rejected lateron.)
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/asfdec_o.c