Recherche avancée

Sur d’autres sites (8796)

• FFMPEG - frame PTS and DTS increasing faster than it should

  20 juillet 2022, par hi im Bacon

  I am pulling footage from an RTSP camera, standardising it, and then segmenting the footage for processing. I am standardising by reducing the resolution and setting the frame rate to 12 fps.

  


  I am encoding in the PTS times the wall time of each frame as the camera is a live source and I'd like to be able to know exactly when a frame is occurring (I'm not fussed that it's not going to be perfectly on, if it's all out by a second or two because of latency that is fine by me)

  


  FFMPEG is run from python subprocessing using the following command :

  


  command = [
    "ffmpeg", "-y",
    "-rtsp_transport", "tcp", URL,
    "-pix_fmt", "yuvj422p",
    "-c:v", "libx264", # Change the video codec to the kinesis required codec
    "-an", # Remove any audio channels
    "-vf", "scale='min(1280,iw)':'min(720,ih)':force_original_aspect_ratio=decrease",
    "-r", "12",
    "-vsync", "cfr",
    "-x264opts", "keyint=12:min-keyint=12",,
    "-f", "segment",  # Set the output format as chuncked segments
    "-segment_format", segment_format,  # Set each segments format E.G. matroska, mp4
    "-segment_time", str(segment_length),  # Set the length of the segment in seconds
    "-initial_offset", str(initial_pts_offset),
    "-strftime", "1",  # Use the strformat notication in naming of the video segements
    "{}/%Y-%m-%dT%H%M%S.{}".format(directory, extension)  # Define the name and location of the segments,
    '-loglevel', 'error'
]


  


  The problem I am having is that the timestamps of the frames increase at a faster than real time rate. The initial offset is set to the time that FFMPEG is kicked off, the frames received should always be less than right now. I am using a segment length of 30 seconds and after only 5 minutes, finished segments will have a start timestamp greater than the present wall time.

  


  The rate of increase looks around 3-4 times faster than it should.

  


  Why is this the case ? how can I avoid this ? is my understand of -r right ?

  


  I believed that -r drops extra frames, evens out the frame times creating new frames where needed, but not actually changing the perceived speed of the footage. The final frame time should not be greater than the segment length away from the first frame time.

  


  I have tried using a system (filter) that sets the PTS time according to the consumer wall time setpts='time(0)/TB' but this has led to quite choppy footage as the frames can be received/processed at different rates based on the connection.

  


  The quality of the segments is great, all the data is there... just getting the times right is seeming impossible.

  


• Evolution #2040 (Nouveau) : Accueil inistial sur un site nouvellement installé

  1er mai 2011, par Suske -

  Première arrivée dans le privé : contenu/accueil.html est vide => il y a mieux que le vide :-)

  un lien vers la config du site

  une phrase "Créez maintenant une rubrique puis publiez-y un premier article... bla."

  ... Un page "premiers pas en quelques sortes (...)

• Revision 122868 : Toujours sur ces vues de saisies fieldset. Champ extra se base sur le ...

  7 mars 2020, par Maïeul Rouquette — Log

  Toujours sur ces vues de saisies fieldset.
  Champ extra se base sur le classe vide pour ne pas afficher les saisies
  sans réponse. Le masquage est en css, contrairement à ce que je pensais
  (suis-je bête !)
  On ajoute donc la classe vide à la vie d’une saisie si l’ensemble de ses
  sous saisies sont vide.
  Permet d’éviter avec champ extra d’avoir un titre de fieldset qui se
  balade sans aucune réponse en dessous.