Recherche avancée

Sur d’autres sites (6509)

• ffmpeg process not terminating - stuck in code

  17 juillet 2023, par hello world

  using (Process process = new Process())
{
    process.StartInfo.FileName = "ffmpeg.exe";
    process.StartInfo.Arguments = "-i video.mp4 -loop 1 -i a.jpg -c:v copy -c:a copy -shortest output_temp.mp4";
    process.StartInfo.UseShellExecute = false;
    process.StartInfo.RedirectStandardOutput = true;
    process.StartInfo.RedirectStandardError = true;
    process.StartInfo.CreateNoWindow = true;
    process.Start();
    process.WaitForExit();
}


  


  I have verified that the input files, video.mp4 and a.jpg, exist in the specified paths and are accessible. Additionally, I've tried removing the -shortest option to rule out an infinite loop, but the issue persists.

  


  I've also redirected the standard output and error streams to log files, but there are no error messages reported.

  


  I'm using the last version of ffmpeg on Windows.

  


  What could be causing the ffmpeg process to get stuck and not terminate as expected ? Are there any other potential reasons I should investigate ? Any help or suggestions would be greatly appreciated. Thank you !

  


  Edit : Also in the mean time ffmpeg command is not working.

  


• avcodec/refstruct : Add simple API for refcounted objects

  4 août 2022, par Andreas Rheinhardt

  avcodec/refstruct : Add simple API for refcounted objects
  For now, this API is supposed to replace all the internal uses
  
  of reference counted objects in libavcodec ; "internal" here
  
  means that the object is created in libavcodec and is never
  
  put directly in the hands of anyone outside of it.
  It is intended to be made public eventually, but for now
  
  I enjoy the ability to modify it freely.
  Several shortcomings of the AVBuffer API motivated this API :
  
  a) The unnecessary allocations (and ensuing error checks)
  
  when using the API. Besides the need for runtime checks it
  
  imposes upon the developer the burden of thinking through
  
  what happens in case an error happens. Furthermore, these
  
  error paths are typically not covered by FATE.
  
  b) The AVBuffer API is designed with buffers and not with
  
  objects in mind : The type for the actual buffers used
  
  is uint8_t* ; it pretends to be able to make buffers
  
  writable, but this is wrong in case the buffer is not a POD.
  
  Another instance of this thinking is the lack of a reset
  
  callback in the AVBufferPool API.
  
  c) The AVBuffer API incurs unnecessary indirections by
  
  going through the AVBufferRef.data pointer. In case the user
  
  tries to avoid this indirection and stores a pointer to
  
  AVBuffer.data separately (which also allows to use the correct
  
  type), the user has to keep these two pointers in sync
  
  in case they can change (and in any case has two pointers
  
  occupying space in the containing context). See the following
  
  commit using this API for H.264 parameter sets for an example
  
  of the removal of such syncing code as well as the casts
  
  involved in the parts where only the AVBufferRef* pointer
  
  was stored.
  
  d) Given that the AVBuffer API allows custom allocators,
  
  creating refcounted objects with dedicated free functions
  
  often involves a lot of boilerplate like this :
  
  obj = av_mallocz(sizeof(*obj)) ;
  
  ref = av_buffer_create((uint8_t*)obj, sizeof(*obj), free_func, opaque, 0) ;
  
  if (!ref) 
  
      av_free(obj) ;
  
      return AVERROR(ENOMEM) ;
  
  
  
  (There is also a corresponding av_free() at the end of free_func().)
  
  This is now just
  
  obj = ff_refstruct_alloc_ext(sizeof(*obj), 0, opaque, free_func) ;
  
  if (!obj)
  
      return AVERROR(ENOMEM) ;
  
  See the subsequent patch for the framepool (i.e. get_buffer.c)
  
  for an example.
  This API does things differently ; it is designed to be lightweight*
  
  as well as geared to the common case where the allocator of the
  
  underlying object does not matter as long as it is big enough and
  
  suitably aligned. This allows to allocate the user data together
  
  with the API's bookkeeping data which avoids an allocation as well
  
  as the need for separate pointers to the user data and the API's
  
  bookkeeping data. This entails that the actual allocation of the
  
  object is performed by RefStruct, not the user. This is responsible
  
  for avoiding the boilerplate code mentioned in d).
  As a downside, custom allocators are not supported, but it will
  
  become apparent in subsequent commits that there are enough
  
  usecases to make it worthwhile.
  Another advantage of this API is that one only needs to include
  
  the relevant header if one uses the API and not when one includes
  
  the header or some other component that uses it. This is because there
  
  is no RefStruct type analog of AVBufferRef. This brings with it
  
  one further downside : It is not apparent from the pointer itself
  
  whether the underlying object is managed by the RefStruct API
  
  or whether this pointer is a reference to it (or merely a pointer
  
  to it).
  Finally, this API supports const-qualified opaque pointees ;
  
  this will allow to avoid casting const away by the CBS code.
  * : Basically the only exception to the you-only-pay-for-what-you-use
  
  rule is that it always uses atomics for the refcount.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/Makefile
  • [DH] libavcodec/refstruct.c
  • [DH] libavcodec/refstruct.h

• lavu/fixed_dsp : optimise R-V V fmul_reverse

  19 novembre 2023, par Rémi Denis-Courmont

  lavu/fixed_dsp : optimise R-V V fmul_reverse
  Gathers are (unsurprisingly) a notable exception to the rule that R-V V
  
  gets faster with larger group multipliers. So roll the function to speed
  
  it up.
  Before :
  
  vector_fmul_reverse_fixed_c :       2840.7
  
  vector_fmul_reverse_fixed_rvv_i32 : 2430.2
  After :
  
  vector_fmul_reverse_fixed_c :       2841.0
  
  vector_fmul_reverse_fixed_rvv_i32 :  962.2
  It might be possible to further optimise the function by moving the
  
  reverse-subtract out of the loop and adding ad-hoc tail handling.
  

  • [DH] libavutil/riscv/fixed_dsp_rvv.S