Recherche avancée

Sur d’autres sites (5321)

• ffmpeg Get time of frames from trimmed video

  17 novembre 2017, par TheOtherguyz4kj

  I am using FFmpeg in my application to extract frames from a video, the frames will be added to a trim video view where you get an illustration as to what is happening in the video at a specific time within the video. So each frame needs to represent some time within the video.

  I dont quite understand how FFmpeg is producing the frames. Here is my code :

  "-i",
  
  videoCroppedFile.getAbsolutePath(),
  
  "-vf",
  
  "fps=1/" + frameSeperation,
  
  mediaStorageDir.getAbsolutePath() +
  
  "/%d.jpg"

  My app allows you to record a video at a max length of 20s. The number of frames extracted from the video depnds on how long the captured video is. frameSeperation is calculated doing the below code.

  String time = retriever.extractMetadata(MediaMetadataRetriever.METADATA_KEY_DURATION);
  
      long videoLength = Long.parseLong(time) / 1000;
  
      double frameSeperationDouble = (double) videoLength;
  
      // Divide by 11 because there is a maximum of 11 frames on trim video view
  
      frameSeperationDouble /= 11;
  
      frameSeperationDouble = Math.ceil(frameSeperationDouble);
  
      int frameSeperation = (int) frameSeperationDouble;

  Maybe the above logic is very bad, if there is a better way please can somebody tell me.

  Anyway I run the code and below are a few test cases :

  • A video captured with a length of 6 seconds has 7 frames.
  • A video captured with a length of 2 seconds has 3 frames.
  • A video captured with a length of 10 seconds has 12 frames.
  • A video captured with a length of 15 seconds has 9 frames.
  • A video captured with a length of 20 seconds has 11 frames.

  There is no consistency, and I find it hard to put timestamps against each frame because of this. I feel like my logic is wrong or im not understanding. Any help is much appreciated

  Update 1

  So I did what you said in comments :

   final FFmpeg ffmpeg = FFmpeg.getInstance(mContext);
  
          final File mediaStorageDir = new File(Environment.getExternalStorageDirectory()
  
                  + "/Android/data/"
  
                  + mContext.getPackageName()
  
                  + "/vFrames");
  
  
  
      if (!mediaStorageDir.exists()){
  
          mediaStorageDir.mkdirs();
  
      }
  
  
  
      MediaMetadataRetriever retriever = new MediaMetadataRetriever();
  
      retriever.setDataSource(mContext, Uri.fromFile(videoCroppedFile));
  
      String time = retriever.extractMetadata(MediaMetadataRetriever.METADATA_KEY_DURATION);
  
      long videoLength = Long.parseLong(time) / 1000;
  
      double frameSeperationDouble = (double) videoLength / 8;
  
  
  
      retriever.release();
  
  
  
      final String cmd[] = {
  
  
  
              "-i",
  
              videoCroppedFile.getAbsolutePath(),
  
              "-vf",
  
              "fps=1/" + frameSeperationDouble,
  
              "-vframes," + 8,
  
              mediaStorageDir.getAbsolutePath() +
  
              "/%d.jpg"
  
      };

  I also tried "-vframes=" + 8 at the same point where I put vFrames in cmd. It doesnt seem to work at all now no frames are being extracted from the video

• lavd/x11grab : fix vertical repositioning

  28 mars 2019, par Octavio Alvarez

  lavd/x11grab : fix vertical repositioning
  There is a calculation error in xcbgrab_reposition() that breaks
  
  vertical repositioning on follow_mouse. It made the bottom
  
  reposition occur when moving the mouse lower than N pixels after
  
  the capture bottom edge, instead of before.
  This commit fixes the calculation to match the documentation.
  follow_mouse : centered or number of pixels. The documentation says :
  When it is specified with "centered", the grabbing region follows
  
  the mouse pointer and keeps the pointer at the center of region ;
  
  otherwise, the region follows only when the mouse pointer reaches
  
  within PIXELS (greater than zero) to the edge of region.
  

  • [DH] libavdevice/xcbgrab.c

• Anomalie #3152 (Nouveau) : Écriture raccourcie des propriétés typos avec font

  20 janvier 2014, par b b

  Sur un site je déclare les règles css suivantes sur un élément :

  font-size : 2.62em ; font-family : dosis, sans-serif ;
  

  Si j’active le compresseur, elles sont condensée dans une déclaration font comme ceci :

  font : 2.62em dosis, sans-serif ;
  

  Cette écriture ne donne pas le même rendu car j’ai une règle plus haut dans la feuille de style qui colle l’élément en question en bold. L’utilisation de la déclaration font annule la règle en question car :

  Les propriétés pour lesquelles aucune valeur n’est spécifiée sont définies à leur valeur initiale, qui est normal pour toutes les propriétés pouvant être omises : (font-style, font-variant, font-weight et line-height).

  https://developer.mozilla.org/fr/docs/CSS/font

  Je précise que la css en question contient au moins un @media et un @font-face car Cedric me signale ceci :

  Si ta css est simple, c’est une compression simple qui est a l’oeuvre sans regroupement des regles en une seule. Mais si ta css contient des @media ou @fontface alors la compression passe par CSSTidy.