Recherche avancée

Sur d’autres sites (11696)

• Streaming an Updating Folder of Images with FFmpeg Without Restarting the Script

  11 juillet 2024, par Roy Raihenshtein

  I'm working on a project where I need to stream a series of images stored in a folder using FFmpeg.
My current command looks like this :

  


  ffmpeg -stream_loop -1 -f image2 -framerate 5 -i "C:\Images\%d.bmp" -c:v libx264 -preset ultrafast -tune zerolatency -crf 35 -pix_fmt bgra -vf format=bgra -f mpegts "udp://127.0.0.1:8554?pkt_size=1316&buffer_size=64k"


  


  Initially, the folder contains :

  


  Input:
1.bmp
2.bmp
3.bmp
.
.
.
N.bmp


  


  Running this command successfully streams the images. However, new images (e.g., N2.bmp) might be added to the folder during runtime, and I need these new images to be included in the stream without restarting FFmpeg.

  


  Challenges :

  


  

  1. I need to include newly added images in the ongoing stream without rerunning the FFmpeg command.

  


  2. I delete the .bmp files after they are streamed to avoid filling up my hard disk, so rerunning the command is not an option.

  


  


  Additional Context :

  


  The FFmpeg command is embedded within my .NET program, which handles the deletion of images after they are streamed. This ensures that my PC's hard disk does not fill up, but it also means I cannot simply restart the FFmpeg command whenever new images are added.

  


  Question :

  


  Is there a way to configure FFmpeg or use an additional tool to dynamically update the input source to include newly added images without stopping and restarting the FFmpeg command ?

  


  Any guidance or suggestions on how to achieve this would be greatly appreciated. Thank you !

  


• avcodec/videotoolbox : fix decoding of some HEVC videos

  5 mai 2018, par Aman Gupta

  avcodec/videotoolbox : fix decoding of some HEVC videos
  In a normal hwaccel, the AVHWFramesContext sets AVFrame.hw_frames_ctx
  
  when it initializes a new AVFrame in av_hwframe_get_buffer().
  But the VT hwaccel doesn't know what hw_frames_ctx to assign when
  
  the AVFrame is first created, because it depends on the format of
  
  the pixbuf that the decoder eventually decides to return. Thus
  
  newly created AVFrames always have a NULL hw_frames_ctx, and the
  
  hwaccel would only assign the ctx once a frame was done decoding.
  
  This worked fine with the H264 decoder, but with the HEVC decoder
  
  the frame's data may be moved to another empty AVFrame. Since the
  
  empty AVFrame never had hw_frames_ctx set, a frame with a NULL
  
  ctx could be returned to the API user.
  This patch works around the issue by moving the derived
  
  hw_frames_ctx from the AVFrame to a new VTHWFrame which now holds
  
  both the CVPixelBufferRef and the AVBuffer. The hw_frames_ctx
  
  is only copied to the AVFrame right before it is about to be
  
  returned to the user in videotoolbox_postproc_frame() (since
  
  in the case of VT, the hw_frames_ctx is only there for the API
  
  user anyway).
  Fixes playback on macOS and iOS of some hevc videos like
  
  https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  

  • [DH] libavcodec/videotoolbox.c

• Révision 22576 : Suppression d’un code mort, mort depuis longtemps.

  23 novembre 2015, par marcimat@rezo.net

  Déjà signalé par rénato en 2006 (http://spip-dev.rezo.narkive.com/mHG6Qlt6/small-bug-in-phraser-champs),
  ce if () vaut toujours true. On l’enlève du coup.

  Précisément, cela vient tout à l’origine d’une erreur lors d’un passage de ereg à strpos en r3964, strpos ne comprennant
  pas l’expression [0-9]. Redmine n’affichant plus les révisions / diff avant la révision 9600, je mais des liens git :
  https://git.spip.net/rCSPIP57683758d1ebe3a6ffa5095035e88768b14d86f2 ou https://github.com/spip/SPIP/commit/57683758d1ebe3a6ffa5095035e88768b14d86f2

  C’était à une époque ou la constante NOM_DE_CHAMP coupait les balises nommées en héxadécimal en 2 : `#FF3300` par exemple avait `#FF` en balise, et
  le reste était dans la suite, et il fallait potentiellement recorriger ce problème.
  Cette constante a été améliorée ensuite, pas longtemps après en r4407, pour attraper tout le contenu de ces balises :
  https://github.com/spip/SPIP/commit/fef3ff59fad8896d1c8946346eac1b47befc588f

  Donc, en théorie, depuis cette date, le test if() n’a plus lieu d’être.