Recherche avancée

Sur d’autres sites (5634)

• C# process and ffmpeg output pipe

  21 novembre 2018, par Konrad

  I’m trying to replicate the following call from command line in C# :

  C:\Temp\Proj\FFmpeg\bin\ffmpeg.exe -re -i C:\test\test.ts -map data-re -codec copy -f data - | java -jar C:\Temp\Proj\FFmpeg\bin\AnotherProj.jar 1

  As you can see, FFmpeg pipes the data into an app built with Java. And my implementation :

  var x = RunCmdProcess($"/C {_ffmpegPath} -re -i {_videoPath} - map data-re -codec copy -f data - | java -jar {_anotherProjPath} 1", out outputMessage);
  
  
  
  protected Process RunCmdProcess(string arguments, out string outputMessage)
  
              {
  
                  ProcessStartInfo p = new ProcessStartInfo("cmd.exe");
  
                  p.RedirectStandardOutput = true;
  
                  p.RedirectStandardError = true;
  
                  p.RedirectStandardInput = true;
  
                  p.UseShellExecute = false;
  
                  p.CreateNoWindow = true;
  
                  p.WindowStyle = ProcessWindowStyle.Hidden;
  
                  p.Arguments = arguments;
  
  
  
                  var sb = new StringBuilder();
  
  
  
                  var x = Process.Start(p);
  
  
  
                  var stdOut = x.StandardOutput.ReadToEnd();
  
                  var stdErr = x.StandardError.ReadToEnd();
  
  
  
                  sb.Append(stdOut);
  
                  if (!string.IsNullOrEmpty(stdErr)) sb.Append(stdErr);
  
                  x.WaitForExit();
  
                  outputMessage = sb.ToString();
  
                  return x;
  
              }

  The result of the following call is :

  [NULL @ 0000028335e82380] Unable to find a suitable output format for ’pipe :’
  pipe: : Invalid argument

  I double checked the paths to the files given in the RunCmdProcess function as well as tried enclosing the arguments (after /C) with quotation marks. No matter what I try, I still get the same error from FFmpeg.

• matroskaenc : Allow chapters to be written in trailer

  3 septembre 2013, par John Stebbins

  matroskaenc : Allow chapters to be written in trailer
  This allows creation of frame accurate chapter marks from sources like
  
  DVD and BD where the precise chapter location is not known until the
  
  chapter mark has been reached during reading.
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavformat/avformat.h
  • [DBH] libavformat/matroskaenc.c

• fftools : Use right function signature and pointers

  6 août 2019, par Andreas Rheinhardt

  fftools : Use right function signature and pointers
  The option tables of the various fftools (in particular ffprobe) are
  
  arrays of OptionDef ; said type contains a union of a pointer to void and
  
  a function pointer of type int (*)(void *, const char *, const char *)
  
  as well as a size_t. Some entries (namely the common entry for writing a
  
  report as well as several more of ffprobe's entries) used the pointer to
  
  void to store a pointer to functions of type int (*)(const char *) or
  
  type int (*)(const char *, const char *) ; nevertheless, when the functions
  
  are actually called in write_option (in cmdutils.c), it is done via a
  
  pointer of the first type.
  There are two things wrong here :
  
  1. Pointer to void can be converted to any pointer to incomplete or
  
  object type and back ; but they are nevertheless not completely generic
  
  pointers : There is no provision in the C standard that guarantees their
  
  convertibility with function pointers. C90 lacks a generic function
  
  pointer, C99 made every function pointer a generic function pointer and
  
  still disallows the convertibility with void *.
  
  2. The signature of the called function differs from the signature
  
  of the pointed-to type. This is undefined behaviour in C99 (given that
  
  C90 lacks a way to convert function pointers at all, it doesn't say
  
  anything about such a situation). It only works because none of the
  
  functions this patch is about make any use of their parameters at all.
  Therefore this commit changes the type of the relevant functions
  
  to match the type used for the call and uses the union's function
  
  pointer to store it. This is legal even in C90.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] fftools/cmdutils.c
  • [DH] fftools/cmdutils.h
  • [DH] fftools/ffprobe.c