Recherche avancée

Sur d’autres sites (2992)

• av_read_frame and time stamps C++

  19 avril 2014, par halfwaythru

  I am recording an RTSP H264 stream from an Axis IP camera using libavformat. This camera is supposed to stamp every frame with the time that the frame was acquired, and this information is supposed to be in the RTP packet header.

  This is the code that I am using to read in the frames.

  AVFormatContext *inputFormatCtxt = NULL;
  
  avformat_open_input(&inputFormatCtxt, inputURL, NULL, NULL) 
  
  avformat_find_stream_info(inputFormatCtxt, NULL )
  
  
  
  while(av_read_frame(inputFormatCtxt, &packet) >=0)
  
  {
  
      if(packet.stream_index == videoStreamIndex)
  
      {
  
         // Do something to video packet.
  
      }
  
      else
  
      {
  
         // Do something to audio packet. 
  
      }
  
  
  
      if (packet.pts != AV_NOPTS_VALUE)
  
          packet.dts = packet.pts    = av_rescale_q(packet.pts, stream->time_base, oStream->time_base);
  
      else
  
          NSLog(@"packet.pts == AV_NOPTS_VALUE");
  
  
  
      if(av_interleaved_write_frame(outputFormatCtxt, &packet) < 0)
  
          NSLog(@"Could not write out frame.");
  
  
  
      av_free_packet(&packet);
  
  }

  Now in AVPacket, the only time-related information is the pts and the dts. After converting them into seconds, these are supposed to be the offset of the packet (in seconds) from the start of the stream.

  My question is : How do I get the start time of the stream ?

  These are the many things that I have tried :

  1.) In AVFormatContext there is a variable start_time_realtime that is "supposed" to be the start time of the stream in real world time, in microseconds. This is exactly what I need. But no matter what I do, this value is always 0, and never changes. Am I missing a step in initialization that this never get set ?

  2.) Looking at this link, I added an RTPDemuxContext object to my code :

  RTSPState* rtsp_state = (RTSPState*) inputFormatCtxt->priv_data;
  
  RTSPStream* rtsp_stream = rtsp_state->rtsp_streams[0];
  
  RTPDemuxContext* rtp_demux_context = (RTPDemuxContext*) rtsp_stream->transport_priv;

  When I tried to look at the last_rtcp_reception_time, last_rtcp_ntp_time, last_rtcp_timestamp timestamps within the RTPDemuxContext object, these values are also 0 always, and dont change.

  3.) With the last point, I tried to force fetch a packet using ff_rtsp_fetch_packet(inputFormatCtxt, &packet). This did update the RTPDemuxContext timestamps, but only while stepping through code. If I just ran the code in a loop, it always remained the same as whatever was in the RTDemuxContext object before the loop.

  int64_t x = 0;
  
  x = rtp_demux_context->last_rtcp_reception_time;   // x is 0.
  
  while(ff_rtsp_fetch_packet(inputFormatCtxt, &packet))
  
  {
  
      x = rtp_demux_context->last_rtcp_reception_time;   // x changes only when stepping through code. else remains 0 
  
  }

  At this point I have no idea what I am doing wrong. I cant seem to get this timestamp information, no matter what I try. Any help is much appreciated. Thanks !

• Ffmpeg set duration using node-fluent-ffmpeg

  23 mai 2013, par Vprnl

  I'm really new to the world of ffmpeg so please excuses me if this is a stupid queston.

  I'm using the module Node-fluent-ffmpeg to stream a movie and convert it from avi to webm.
  So far so good (it plays the video), but I'm having trouble parsing the duration to the player. My ultimate goal is to be able to skip ahead in the movie. But first the player needs to know how long the video is.

  my code is as followed :

  var stat = fs.statSync(movie);
  
  
  
  var start = 0;
  
  var end = 0;
  
  var range = req.header('Range');
  
  if (range != null) {
  
  start = parseInt(range.slice(range.indexOf('bytes=')+6,
  
    range.indexOf('-')));
  
  end = parseInt(range.slice(range.indexOf('-')+1,
  
    range.length));
  
  }
  
  if (isNaN(end) || end == 0) end = stat.size-1;
  
  if (start > end) return;
  
  
  
  res.writeHead(206, { // NOTE: a partial http response
  
      'Connection':'close',
  
      'Content-Type':'video/webm',
  
      'Content-Length':end - start,
  
      'Content-Range':'bytes '+start+'-'+end+'/'+stat.size,
  
      'Transfer-Encoding':'chunked'
  
  });
  
  
  
  var  proc = new ffmpeg({ source: movie, nolog: true, priority: 1, timeout:15000})
  
      .toFormat('webm')
  
      .withVideoBitrate('1024k')
  
      .addOptions(['-probesize 900000', '-analyzeduration 0', '-bufsize 14000'])
  
      .writeToStream(res, function(retcode, error){
  
      if (!error){
  
          console.log('file has been converted succesfully',retcode);
  
      }else{
  
          console.log('file conversion error',error);
  
      }
  
  });

  I tried to set the header with a start and a end based on this article : http://delog.wordpress.com/2011/04/25/stream-webm-file-to-chrome-using-node-js/

  I also looked in the FFmpeg documentation and found -f duration and -ss.
  But I don't quite know how to convert the byte range to seconds.

  I feel like I'm pretty close to a solution but my inexperience with the subject matter prohibits me from getting it to work. If I'm unclear in any way please let me know. (I have a tendency of explaining things fuzzy.)

  Thanks in advance !

• arm : vp9 : Add NEON loop filters

  14 novembre 2016, par Martin Storsjö

  arm : vp9 : Add NEON loop filters
  This work is sponsored by, and copyright, Google.
  The implementation tries to have smart handling of cases
  
  where no pixels need the full filtering for the 8/16 width
  
  filters, skipping both calculation and writeback of the
  
  unmodified pixels in those cases. The actual effect of this
  
  is hard to test with checkasm though, since it tests the
  
  full filtering, and the benefit depends on how many filtered
  
  blocks use the shortcut.
  Examples of relative speedup compared to the C version, from checkasm :
  
                            Cortex       A7     A8     A9    A53
  
  vp9_loop_filter_h_4_8_neon :          2.72   2.68   1.78   3.15
  
  vp9_loop_filter_h_8_8_neon :          2.36   2.38   1.70   2.91
  
  vp9_loop_filter_h_16_8_neon :         1.80   1.89   1.45   2.01
  
  vp9_loop_filter_h_16_16_neon :        2.81   2.78   2.18   3.16
  
  vp9_loop_filter_mix2_h_44_16_neon :   2.65   2.67   1.93   3.05
  
  vp9_loop_filter_mix2_h_48_16_neon :   2.46   2.38   1.81   2.85
  
  vp9_loop_filter_mix2_h_84_16_neon :   2.50   2.41   1.73   2.85
  
  vp9_loop_filter_mix2_h_88_16_neon :   2.77   2.66   1.96   3.23
  
  vp9_loop_filter_mix2_v_44_16_neon :   4.28   4.46   3.22   5.70
  
  vp9_loop_filter_mix2_v_48_16_neon :   3.92   4.00   3.03   5.19
  
  vp9_loop_filter_mix2_v_84_16_neon :   3.97   4.31   2.98   5.33
  
  vp9_loop_filter_mix2_v_88_16_neon :   3.91   4.19   3.06   5.18
  
  vp9_loop_filter_v_4_8_neon :          4.53   4.47   3.31   6.05
  
  vp9_loop_filter_v_8_8_neon :          3.58   3.99   2.92   5.17
  
  vp9_loop_filter_v_16_8_neon :         3.40   3.50   2.81   4.68
  
  vp9_loop_filter_v_16_16_neon :        4.66   4.41   3.74   6.02
  The speedup vs C code is around 2-6x. The numbers are quite
  
  inconclusive though, since the checkasm test runs multiple filterings
  
  on top of each other, so later rounds might end up with different
  
  codepaths (different decisions on which filter to apply, based
  
  on input pixel differences). Disabling the early-exit in the asm
  
  doesn’t give a fair comparison either though, since the C code
  
  only does the necessary calcuations for each row.
  Based on START_TIMER/STOP_TIMER wrapping around a few individual
  
  functions, the speedup vs C code is around 4-9x.
  This is pretty similar in runtime to the corresponding routines
  
  in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
  
  vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
  
  to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
  
  and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
  
  and vertical is flipped between the libraries.)
  In order to have stable, comparable numbers, the early exits in both
  
  asm versions were disabled, forcing the full filtering codepath.
                             Cortex           A7      A8      A9     A53
  
  vp9_loop_filter_h_16_8_neon :             597.2   472.0   482.4   415.0
  
  libvpx vpx_lpf_vertical_16_neon :         626.0   464.5   470.7   445.0
  
  vp9_loop_filter_v_16_8_neon :             500.2   422.5   429.7   295.0
  
  libvpx vpx_lpf_horizontal_edge_8_neon :   586.5   414.5   415.6   383.2
  
  vp9_loop_filter_v_16_16_neon :            905.0   784.7   791.5   546.0
  
  libvpx vpx_lpf_horizontal_edge_16_neon : 1060.2   751.7   743.5   685.2
  Our version is consistently faster on on A7 and A53, marginally slower on
  
  A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
  
  three tests in this particular test run).
  This is an adapted cherry-pick from libav commit
  
  dd299a2d6d4d1af9528ed35a8131c35946be5973.
  Signed-off-by : Ronald S. Bultje <rsbultje@gmail.com>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/vp9dsp_init_arm.c
  • [DH] libavcodec/arm/vp9lpf_neon.S