
Recherche avancée
Médias (91)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
-
avec chosen
13 septembre 2013, par
Mis à jour : Septembre 2013
Langue : français
Type : Image
-
sans chosen
13 septembre 2013, par
Mis à jour : Septembre 2013
Langue : français
Type : Image
-
config chosen
13 septembre 2013, par
Mis à jour : Septembre 2013
Langue : français
Type : Image
-
SPIP - plugins - embed code - Exemple
2 septembre 2013, par
Mis à jour : Septembre 2013
Langue : français
Type : Image
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
Autres articles (33)
-
Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs
12 avril 2011, parLa manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras. -
Other interesting software
13 avril 2011, parWe don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
We don’t know them, we didn’t try them, but you can take a peek.
Videopress
Website : http://videopress.com/
License : GNU/GPL v2
Source code : (...) -
Les statuts des instances de mutualisation
13 mars 2010, parPour des raisons de compatibilité générale du plugin de gestion de mutualisations avec les fonctions originales de SPIP, les statuts des instances sont les mêmes que pour tout autre objets (articles...), seuls leurs noms dans l’interface change quelque peu.
Les différents statuts possibles sont : prepa (demandé) qui correspond à une instance demandée par un utilisateur. Si le site a déjà été créé par le passé, il est passé en mode désactivé. publie (validé) qui correspond à une instance validée par un (...)
Sur d’autres sites (5225)
-
Top 4 CRO Tools to Boost Your Conversion Rates in 2024
31 octobre 2023, par Erin -
Custom Segmentation Guide : How it Works & Segments to Test
13 novembre 2023, par Erin — Analytics Tips, Uncategorized -
FFMPEG : Recurring onMetaData for RTMP ? [on hold]
30 novembre 2017, par stevendesuFor whatever reason this was put on hold as "too broad", although I felt I was quite specific. So I’ll try rephrasing here :
My former understanding :
The RTMP Protocol involves sending several parallel streams of data as a series of packets, with an ID correlating to which stream they are a part of. For instance :
[VIDEO] <data>
[AUDIO] <data>
[VIDEO] <data>
[VIDEO] <data>
[SERVER] <metadata about="about" bandwidth="bandwidth">
[VIDEO] <data>
[AUDIO] <data>
...
</data></data></metadata></data></data></data></data>Then on the player side these packets are split up into separate buffers based on type (all video data is concatenated, all audio data is concatenated, etc)
One of the packet types is called
onMetaData
(ID : 0x12)An
onMetaData
packet includes a timestamp for when to trigger the metadata (this way it can be synchronized with the video) as well as the contents of the metadata (a text string)My setup :
I’m using Red5Pro as my ingest server to take in an RTMP stream and then watch this stream via WebRTC. When an
onMetaData
packet is received by Red5, it sends out a JSON object to all subscribers of the stream over WebSockets with the contents of the stream.What I want :
I want to take advantage of this
onMetaData
channel to embed the server’s system clock into a stream. This way anyone viewing the stream can determine when (according to the server) a stream was encoded and, if they synchronize their clock with the server, they can then compute the end-to-end latency of the stream. Due to Red5’s use of WebSockets to send metadata this isn’t a perfect solution (you may receive the metadata before or after you actually receive the video information), however I have some plans to work around this.In other words, I want my stream to look like this :
[VIDEO] <data>
[AUDIO] <data>
[ONMETADATA] time: 2:05:77.382
[VIDEO] <data>
[VIDEO] <data>
[SERVER] <metadata about="about" bandwidth="bandwidth">
[VIDEO] <data>
[ONMETADATA] time: 2:05:77.423
[AUDIO] <data>
...
</data></data></metadata></data></data></data></data>What I would like is to generate this stream (with the server’s current time periodically embedded into the
onMetaData
channel) using FFMPEGSimpler problem :
FFMPEG offers a
-metadata
command-line parameter.In my experiments, using this parameter caused a single
onMetaData
event to be fired including things like "title", "author", etc. I could not inject additionalonMetaData
packets periodically as the stream progressed.Even if the metadata packets do not contain the system clock, if I could send any metadata packets periodically using FFMPEG then I could include something static like "the server’s clock at the time the broadcast started". I can then compare this to the current timestamp of the video and calculate the latency.
My confusion :
Continuing to look into this after creating my post, there are a couple things that I don’t fully understand or which don’t quite make sense to me. For one, if FFMPEG is only injecting a single
onMetaData
packet into the stream, then I would expect anyone joining the stream late to miss it. However when I join the stream 8 hours later I see Red5 send me the metadata packet complete with title, author, etc. So it’s almost like the metadata packet doesn’t have a timestamp associated with it but instead is just generic metadata about the videoFurthermore, there’s something called "AMF" which I’m not familiar with, but it may be important ?
Original Post
I spent today playing around with methods to embed the system clock at time of encode into a stream, so that I could compare this value to the same system clock at time of decode to get a rough estimate of RTMP latency. Unfortunately the majority of techniques I used ended up failing.
One thing I wanted to try next was taking advantage of RTMP’s
onMetaData
to send the current system clock periodically (maybe every 5 seconds) as part of the stream for any clients to listen for.Unfortunately FFMPEG’s
-metadata
option seems to only be for one-time metadata when the stream first loads. I can’t figure out how to add continuous (and generated) values to a stream.Is there a way to do this ?