Recherche avancée

Sur d’autres sites (9122)

• Image path with wildcard not working when launching FFmpeg as process

  26 mai 2015, par Léon Pelletier

  In an Xamarin Android project, I’m launching FFmpeg as a process. Thus, I’m sending my parameters in a array that looks like :
  "-i", "img%d.png" ... etc

  When converting from an MP4 to images, it handles the wildcard properly. But when doing the reverse process, it complains about the img%d.png file being missing.

  Does it complains about the real file (img0.png) being missing, or is it trying to really find a file named img%d.png ?

      public Clip ConvertImagesToVideo(string imagePattern, string outPath, ShellCallback sc)
  
      {
  
          List<string> cmd = new List<string>();
  
  
  
          // ffmpeg -f image2 -i ffmpeg_temp/%05d.png -b 512 video2.mpg
  
  
  
          cmd.Add(_ffmpegBin); // ffmpeg
  
  
  
          cmd.Add("-f");
  
          cmd.Add("image2");
  
          cmd.Add("-i");
  
          cmd.Add(imagePattern);
  
  
  
          cmd.Add("-b");
  
          cmd.Add("512");
  
  
  
          Clip mediaOut = new Clip ();
  
  
  
          File fileOut = new File(outPath);
  
  
  
          mediaOut.path = fileOut.CanonicalPath;
  
  
  
          cmd.Add(mediaOut.path);
  
  
  
          execFFMPEG(cmd, sc);
  
  
  
          return mediaOut;
  
      }
  
  </string></string>

  The process is executed like so :

      private int execProcess(IList<string> cmds, ShellCallback sc, File fileExec)
  
      {
  
          ProcessBuilder pb = new ProcessBuilder(cmds);
  
          pb.Directory(fileExec);
  
  
  
          var cmdlog = new Java.Lang.StringBuilder();
  
  
  
          foreach (string cmd in cmds)
  
          {
  
              cmdlog.Append(cmd);
  
              cmdlog.Append(' ');
  
          }
  
  
  
          sc.ShellOut(cmdlog.ToString());
  
  
  
          pb.RedirectErrorStream (true);
  
  
  
          Process process = pb.Start();
  
  
  
          StreamGobbler errorGobbler = new StreamGobbler(this, process.ErrorStream, "ERROR", sc);
  
  
  
          StreamGobbler outputGobbler = new StreamGobbler(this, process.InputStream, "OUTPUT", sc);
  
  
  
          errorGobbler.run();
  
          outputGobbler.run();
  
  
  
          int exitVal = process.WaitFor();
  
  
  
          sc.ProcessComplete(exitVal);
  
  
  
          return exitVal;
  
  
  
      }
  
  </string>

  Note that I haven’t switched my code from Java.Lang to System yet so it stinks a bit. But all calls are working except this call with a wildcard. So I feel it may have to do with how Java processes are handling working directory, maybe.

• fftools/ffmpeg : always use the same path for setting InputStream.[next_]dts

  26 avril 2023, par Anton Khirnov

  fftools/ffmpeg : always use the same path for setting InputStream.[next_]dts
  Currently those are set in different ways depending on whether the
  
  stream is decoded or not, using some values from the decoder if it is.
  
  This is wrong, because there may be arbitrary amount of delay between
  
  input packets and output frames (depending e.g. on the thread count when
  
  frame threading is used).
  Always use the path that was previously used only for streamcopy. This
  
  should not cause any issues, because these values are now used only for
  
  streamcopy and discontinuity handling.
  This change will allow to decouple discontinuity processing from
  
  decoding and move it to ffmpeg_demux. It also makes the code simpler.
  Changes output in fate-cover-art-aiff-id3v2-remux and
  
  fate-cover-art-mp3-id3v2-remux, where attached pictures are now written
  
  in the correct order. This happens because InputStream.dts is no longer
  
  reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees
  
  valid dts values.
  

  • [DH] fftools/ffmpeg.c
  • [DH] tests/ref/fate/cover-art-aiff-id3v2-remux
  • [DH] tests/ref/fate/cover-art-mp3-id3v2-remux

• avcodec/vc1 : Arm 64-bit NEON unescape fast path

  31 mars 2022, par Ben Avison

  avcodec/vc1 : Arm 64-bit NEON unescape fast path
  checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows.
  vc1dsp.vc1_unescape_buffer_c : 655617.7
  
  vc1dsp.vc1_unescape_buffer_neon : 118237.0
  Signed-off-by : Ben Avison <bavison@riscosopen.org>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/vc1dsp_init_aarch64.c
  • [DH] libavcodec/aarch64/vc1dsp_neon.S