Recherche avancée

Sur d’autres sites (5413)

• Confusion about PTS in video files and media streams

  11 novembre 2014, par user2452253

  Is it possible that the PTS of a particular frame in a file is different with the PTS of the same frame in the same file while it is being streamed ?

  When I read a frame using av_read_frame I store the video stream in an AVStream. After I decode the frame with avcodec_decode_video2, I store the time stamp of that frame in an int64_t using av_frame_get_best_effort_timestamp. Now if the program is getting its input from a file I get a different timestamp from when I stream the input (from the same file) to the program.

  To change the input type I simply change the argv argument from "/path/to/file.mp4" to something like "udp ://localhost:1234", then I stream the file with ffmpeg in command line : "ffmpeg -re -i /path/to/file.mp4 -f mpegts udp ://localhost:1234". Can it be because the "-f mpegts" arguments change some characteristics of the media ?

  Below is my code (simplified). By reading the ffmpeg mailing list archives I realized that the time_base that I’m looking for is in the AVStream and not the AVCodecContext. Instead of using av_frame_get_best_effort_timestamp I have also tried using the packet.pts but the results don’t change.
  I need the time stamps to have a notion of frame number in a streaming video that is being received.
  I would really appreciate any sort of help.

  //..
  
  //argv[1]="/file.mp4";
  
  argv[1]="udp://localhost:7777";
  
  // define AVFormatContext, AVFrame, etc.
  
  // register av, avcodec, avformat_network_init(), etc.
  
  avformat_open_input(&pFormatCtx, argv, NULL, NULL);
  
  avformat_find_stream_info(pFormatCtx, NULL);
  
  // find the video stream...
  
  // pointer to the codec context...
  
  // open codec...
  
  pFrame=av_frame_alloc();
  
  while(av_read_frame(pFormatCtx, &packet)>=0) {
  
          AVStream *strem = pFormatCtx->streams[videoStream];
  
          if(packet.stream_index==videoStream) {
  
              avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
  
              if(frameFinished) {
  
                  int64_t perts = av_frame_get_best_effort_timestamp(pFrame);
  
                  if (isMyFrame(pFrame)){
  
                       cout << perts*av_q2d(strem->time_base) << "\n";
  
                  }
  
               }
  
  }
  
  //free allocated space
  
  }
  
  //..

• Anomalie #3227 : Bug date de publication

  17 septembre 2014, par 毎日 erational -

  quelqu’un sur le forum http://forum.spip.net/fr_258722.html signale une erreur de type avec le mktime

• lavc/flacdsp : optimise RVV vector type for lpc16

  14 mai 2024, par Rémi Denis-Courmont

  lavc/flacdsp : optimise RVV vector type for lpc16
  This calculates the optimal vector type value at run-time based on the
  
  hardware vector length and the FLAC LPC prediction order. In this
  
  particular case, the additional computation is easily amortised over
  
  the loop iterations :
  T-Head C908 :
  
      C     V before  V after
  
   1   48.0    214.7     95.2
  
   2   64.7    214.2     94.7
  
   3   79.7    213.5     94.5
  
   4   96.2    196.5     94.2 #
  
   5  111.0    195.7    118.5
  
   6  127.0    211.2    102.0
  
   7  143.7    194.2    101.5
  
   8  175.7    193.2    101.2 #
  
   9  176.2    224.2    126.0
  
  10  191.5    192.0    125.5
  
  11  224.5    191.2    124.7
  
  12  223.0    190.2    124.2
  
  13  239.2    189.5    123.7
  
  14  253.7    188.7    139.5
  
  15  286.2    188.0    122.7
  
  16  284.0    187.0    122.5 #
  
  17  300.2    186.5    186.5
  
  18  314.0    185.5    185.7
  
  19  329.7    184.7    185.0
  
  20  343.0    184.2    184.2
  
  21  358.7    199.2    183.7
  
  22  371.7    182.7    182.7
  
  23  387.5    181.7    182.0
  
  24  400.7    181.0    181.2
  
  25  431.5    180.2    196.5
  
  26  443.7    195.5    196.0
  
  27  459.0    178.7    196.2
  
  28  470.7    177.7    194.2
  
  29  470.0    177.0    193.5
  
  30  481.2    176.2    176.5
  
  31  496.2    175.5    175.7
  
  32  507.2    174.7    191.0 #
   # Power of two boundary.
  With 128-bit vectors, improvements are expected for the first two
  
  test cases only. For the other two, there is overhead but below noise.
  
  Improvements should be better observable with prediction order of 8
  
  and less, or on hardware with larger vector sizes.
  

  • [DH] libavcodec/riscv/flacdsp_init.c
  • [DH] libavcodec/riscv/flacdsp_rvv.S