Recherche avancée

Sur d’autres sites (13277)

• How do I prevent an extended frame when suspending and resuming an ffmpeg process in C# ?

  13 juin 2024, par this_is_a_display_name

  I have a c# application where I have control of an ffmpeg (https://www.ffmpeg.org/) process. I am using it to capture video and audio, either from desktop or webcam. I am using code similar to the answer from this question (How to pause/resume ffmpeg video capture in windows from C# application) to suspend and resume the process. However, while suspended, the captured video extends the frame it was suspended on for the entire duration of the suspension.

  


  My arguments passed into the process :
-f gdigrab -framerate 30 -i desktop -f dshow -i audio=\"Stereo Mix (Realtek(R) Audio)\" -preset ultrafast -pix_fmt rgb24 output.mp4

  


  I have tried adding -vf setpts=N/FR/TB to my arguments, and this works partially. It successfully prevents the extended frame, but then seriously affects the playback speed of the video.

  


  How do I prevent this extended frame from occurring, or prevent the additional argument from affecting the playback speed of the video ? I am hoping for a solution in C#, although if there is an issue with my command line arguments that is an easier fix, that is great also.

  


  My ideal outcome is to have the process record, be suspended then resumed, and have the video play normally without having captured anything while suspended.

  


  Record for 10 seconds, suspend for 20 seconds, record for 30 seconds, end recording -> should result in a 40 second video.

  


  I'm aware that this question may be better suited for the super user stack exchange, but as I am primarily looking for a c# solution, I am asking here first.

  


• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  9 octobre 2020

  la hiérarchie est alors super bien cohérente avec le sens de chaque élément

  J’arrivais pas à mettre le doigt dessus exactement sur ce qui me faisait tiquer, mais en fait crois que c’est ça.
  La hiérarchie est cohérente dans cette zone de la page – en gros ce qu’il y a à l’intérieur et autour de afficher_milieu – ça je suis d’accord.

  Mais quand on considère la page dans son ensemble, du coup ces boutons primary me semblent plus attirer l’attention que le bouton pour modifier l’article. Et par ordre d’importance c’est quand même lui le bouton principal de la page, qu’on est censé cliquer le plus souvent. Il est certes plus grand mais l’oeil est quand même plus attiré par des blocs avec du texte blanc sur fond sombre.

  C’est pour ça que des .link me semblent une option acceptable dans ce cas.
  Même avec cette variante je pense qu’on identifie quand même rapidement qu’il s’agit de boutons : ils sont à droite comme tous les autres boutons, ils sont en gras avec des icônes de couleurs vives, et surtout une fois qu’on s’en est servi une fois, bah voilà, l’info est gravée dans le cerveau.

  Après je sais pas, si ces choses étaient pas collées en plein milieu de la page, peut-être que ça me poserait moins problème que des boutons attirent plus l’attention. Moi j’ai un problème avec ce affiche_milieu :p

• avfilter/vf_libplacebo : don't force dovi frames to bt.2020-ncl

  30 octobre 2023, par Niklas Haas

  avfilter/vf_libplacebo : don't force dovi frames to bt.2020-ncl
  This is at odds with the YUV matrix negotiation API, in which such
  
  dynamic changes in YUV encoding are no longer easily possible. There is
  
  also no really strong motivating reason to do this, since the choice of
  
  YUV matrix is essentially arbitrary and not actually related to the
  
  Dolby Vision decoding process.
  

  • [DH] libavfilter/vf_libplacebo.c