Recherche avancée

Sur d’autres sites (17301)

• How to get the real, actual duration of an MP3 file (VBR or CBR) server-side

  25 septembre 2016, par SquareCat

  I used to calculate the duration of MP3 files server-side using ffmpeg - which seemed to work fine. Today i discovered that some of the calculations were wrong. Somehow, for some reason, ffmpeg will miscalculate the duration and it seems to happen with variable bit rate mp3 files only.

  When testing this locally, i noticed that ffmpeg printed two extra lines in green.

  Command used :

  ffmpeg -i song_9747c077aef8.mp3

  ffmpeg says :

  [mp3 @ 0x102052600] max_analyze_duration 5000000 reached at 5015510
  
  [mp3 @ 0x102052600] Estimating duration from bitrate, this may be inaccurate

  After a nice, warm google session, i discovered some posts on this, but no solution was found.

  I then tried to increase the maximum duration :

  ffmpeg -analyzeduration 999999999 -i song_9747c077aef8.mp3

  After this, ffmpeg returned only the second line :

  [mp3 @ 0x102052600] Estimating duration from bitrate, this may be inaccurate

  But in either case, the calculated duration was just plain wrong. Comparing it to VLC i noticed that there the duration is correct.

  After more research i stumbled over mp3info - which i installed and used.

  mp3info -p "%S" song_9747c077aef8.mp3

  mp3info then returned the CORRECT duration, but only as an integer, which i cannot use as i need a more accurate number here. The reason for this was explained in a comment below, by user blahdiblah - mp3info is simply pulling ID3 info from the file and not actually performing any calculations.

  I also tried using mplayer to retrieve the duration, but just as ffmpeg, mplayer is returning the wrong value.

• How to give real timestamp information to encoded frames inside mpeg1 container

  24 août 2021, par jackey balwani

  I referred following link for my implementation. https://ffmpeg.org/doxygen/trunk/muxing_8c_source.html
I am converting raw data rgb to yuv420 format through scaling and conversion apis available in FFMPEG and then passing the frames to MPEG1 encoder.
I observe that the encoded video plays too fast. Below is the code of encoding the frame and then writing it to output file.

  


    static int write_frame(AVFormatContext *fmt_ctx, AVCodecContext *c,
                    AVStream *st, AVFrame *frame)
  {
    int ret;

    // send the frame to the encoder
    ret = avcodec_send_frame(c, frame);
    if (ret < 0) {
     fprintf(stderr, "Error sending a frame to the encoder: %s\n",
             av_err2str(ret));
     exit(1);
   }

   while (ret >= 0) {
     AVPacket pkt = { 0 };

     ret = avcodec_receive_packet(c, &pkt);
     if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
         break;
     else if (ret < 0) {
         fprintf(stderr, "Error encoding a frame: %s\n", av_err2str(ret));
         exit(1);
     }

     /* rescale output packet timestamp values from codec to stream timebase */
     av_packet_rescale_ts(&pkt, c->time_base, st->time_base);
     pkt.stream_index = st->index;

     /* Write the compressed frame to the media file. */
     log_packet(fmt_ctx, &pkt);
     ret = av_interleaved_write_frame(fmt_ctx, &pkt);
     av_packet_unref(&pkt);
     if (ret < 0) {
         fprintf(stderr, "Error while writing output packet: %s\n", av_err2str(ret));
         exit(1);
     }
 }

 return ret == AVERROR_EOF ? 1 : 0;
}


  


  resulting mpeg video's playback time is very quick, hence video gets played so fast.

  


  so to match output video duration with input video coming from source, I am trying to pass following realtime information to Avframe structure before calling avcodec_send_frame() -

  


  


  1. realtime PTS value (current time + duration got through av_gettime() in microseconds) to AvFrame structure before calling avcodec_send_frame().

     


  


  2. populating pkt_duration with time difference between frames (current_PTS - previous_PTS)

     


  


  3. Removed this call av_packet_rescale_ts(&pkt, c->time_base, st->time_base) ; which is used after avcodec_receive_packet.

     


  


  


  below highlighted code are the changes done for real time info-

  


  **static int64_t m_currVideopts = 0;
static int64_t m_prevVideopts = 0;**

static int write_frame(AVFormatContext *fmt_ctx, AVCodecContext *c, AVStream *st, AVFrame *frame)
{
  **int64_t pts = av_gettime();  // returns current time in micro seconds
  int64_t duration = 90000/STREAM_FRAME_RATE;    /*duration for first frame taken default as 
   3600 as we dont have reference frame to compare diff */
  pts = av_rescale_q(pts, (AVRational){1, 1000000}, st->time_base);    //pAvStream->time_base - stream time base (1:90000)
  if((m_prevVideopts > 0LL) && (pts > m_prevVideopts))
  {
    duration = pts - m_prevVideopts;
  }
  else if (pts < m_prevVideopts)
  {
    pts = m_prevVideopts + duration;
  }
  m_prevVideopts = pts;
  /* Going with the approach of pts value is equal to pts value for every  packet */
  frame->pts = m_currVideopts;    /*AV_NOPTS_VALUE; */
  m_currVideopts += duration;
  //pFfmpegVidCtx->next_pts = m_currVideopts;
  frame->pkt_duration = duration;**

 // send the frame to the encoder
 ret = avcodec_send_frame(c, frame);
 if (ret < 0) {
     fprintf(stderr, "Error sending a frame to the encoder: %s\n",
             av_err2str(ret));
     exit(1);
 }
 ....
 // receive the packet avcodec_receive_packet()
 ...
 
 // removed or commented av_packet_rescale_ts
 **/* av_packet_rescale_ts(&pkt, c->time_base, st->time_base) */**
 ret = av_interleaved_write_frame(fmt_ctx, &pkt);


  


  }

  


  with the above changes, video is not playing proper.
There are couple of issues with respect to total duration (some time it is not proper on player) and also some frames are getting dropped or lost while playing in vlc or media player.

  


  

  


  I am unable to find the cause of these frames loss while playing. Is it the correct way of passing real time pts information to the encoder or any mistake in above code.
Any suggestion would help me proceed further,
thanks.

  


• Faster Real Time A.R Drone Video Streaming

  5 septembre 2017, par mike

  I’ve attempted ffplay tcp://192.168.1.1:5555 to video stream from the AR Drone 2.0 ; however, the delay is way too high.

  My second attempt was with the following :

  var arDrone = require('ar-drone');
  
  var http    = require('http');
  
  
  
  console.log('Connecting png stream ...');
  
  
  
  var pngStream = arDrone.createClient().getPngStream();
  
  
  
  var lastPng;
  
  pngStream
  
    .on('error', console.log)
  
    .on('data', function(pngBuffer) {
  
      lastPng = pngBuffer;
  
    });
  
  
  
  var server = http.createServer(function(req, res) {
  
    if (!lastPng) {
  
      res.writeHead(503);
  
      res.end('Did not receive any png data yet.');
  
      return;
  
    }
  
  
  
    res.writeHead(200, {'Content-Type': 'image/png'});
  
    res.end(lastPng);
  
  });
  
  
  
  server.listen(8080, function() {
  
    console.log('Serving latest png on port 8080 ...');
  
  });

  This only streamed images. I had to refresh browser every second.

  My third option was using this option :

  var arDrone=require('ar-drone')
  
  var client= arDrone.createclient();
  
  require('ar-drone-png-stream')(client,{port:8000})

  It streamed a lot of images in a short amount of time. The delay is still significant and I’m looking for a video.

  Are there other approaches that will significantly lower the delay of the video stream ?