Recherche avancée

Sur d’autres sites (11674)

• Evolution #4283 : Mettre en place un raccourcis typo pour lié la page du site dans notre site

  8 mars 2020, par YannX Spip

  Meme si le vocable est moins parlant (surtout maintenant que la syndication est souvent omise...), il suffit de se souvenir
  du nom originel de la boucle (SYNDIC) et non (SITES),
  pour écrire [->syndic1]....

  Mais il est vrai que la documentation [1] n’est pas bien explicite ; en particulier j’ai été "enduit avec de l’erreur" en lisant la définition de
  - #URL_SYNDIC affiche l’adresse (URL) du fichier de syndication de ce site, qui est elle vraiement dérogatoire...
  - et revenir à une boucle (SYNDIC) dans les exemples aiderait aussi les utilisateurs à dépasser cette exception historique.

  En allant rechercher dans l’aide SPIP [2] on retrouve bien l’origine de cette erreur, qu’il conviendrait de corriger
  

  Auteurs, mots-clés, sites, images, documents :
  lien vers un auteur ou le même auteur
  lien vers un mot
  lien vers un site syndiqué

  Et, sauf problème de rupture de compatibilité (à pallier dans un plugin additionnel ?),
  il serait effectivement logique d’uniformiser le traitement des sites, pour revenir au langage commun...
  Serait-il suffisant de différentier les traitements de* #URL_SITEnn_id* et #URL_SITE (encore que le problème ne se pose que dans une boucle portant sur un objet editorial comprenant aussi un champ #URL_SITE ou #URL_SYNDIC.....

• How can I quantitatively measure gstreamer H264 latency between source and display ?

  10 août 2018, par KevinM

  I have a project where we are using gstreamer , x264, etc, to multicast a video stream over a local network to multiple receivers (dedicated computers attached to monitors). We’re using gstreamer on both the video source (camera) systems and the display monitors.

  We’re using RTP, payload 96, and libx264 to encode the video stream (no audio).

  But now I need to quantify the latency between (as close as possible to) frame acquisition and display.

  Does anyone have suggestions that use the existing software ?

  Ideally I’d like to be able to run the testing software for a few hours to generate enough statistics to quantify the system. Meaning that I can’t do one-off tests like point the source camera at the receiving display monitor displaying a high resolution and manually calculate the difference...

  I do realise that using a pure software-only solution, I will not be able to quantify the video acquisition delay (i.e. CCD to framebuffer).

  I can arrange that the system clocks on the source and display systems are synchronised to a high accuracy (using PTP), so I will be able to trust the system clocks (else I will use some software to track the difference between the system clocks and remove this from the test results).

  In case it helps, the project applications are written in C++, so I can use C event callbacks, if they’re available, to consider embedding system time in a custom header (e.g. frame xyz, encoded at time TTT - and use the same information on the receiver to calculate a difference).

• How can I quantitatively measure gstreamer H264 latency between source and display ?

  16 décembre 2014, par KevinM

  I have a project where we are using gstreamer , x264, etc, to multicast a video stream over a local network to multiple receivers (dedicated computers attached to monitors). We’re using gstreamer on both the video source (camera) systems and the display monitors.

  We’re using RTP, payload 96, and libx264 to encode the video stream (no audio).

  But now I need to quantify the latency between (as close as possible to) frame acquisition and display.

  Does anyone have suggestions that use the existing software ?

  Ideally I’d like to be able to run the testing software for a few hours to generate enough statistics to quantify the system. Meaning that I can’t do one-off tests like point the source camera at the receiving display monitor displaying a high resolution and manually calculate the difference...

  I do realise that using a pure software-only solution, I will not be able to quantify the video acquisition delay (i.e. CCD to framebuffer).

  I can arrange that the system clocks on the source and display systems are synchronised to a high accuracy (using PTP), so I will be able to trust the system clocks (else I will use some software to track the difference between the system clocks and remove this from the test results).

  In case it helps, the project applications are written in C++, so I can use C event callbacks, if they’re available, to consider embedding system time in a custom header (e.g. frame xyz, encoded at time TTT - and use the same information on the receiver to calculate a difference).