Recherche avancée

Sur d’autres sites (6504)

• using mediamtx to stream video to browser [closed]

  18 octobre 2024, par Maximilian

  I am using rtsp to feed a video stream to mediamtx.

  


  I want to display the feed in a browser but always get some errors.

  


  I use the following to start mediamtx

  


  podman run --rm -it -e MTX_PROTOCOLS=tcp -e MTX_WEBRTCADDITIONALHOSTS=192.168.x.x -p 8554:8554 -p 1935:1935 -p 8888:8888 -p 8889:8889 -p 8890:8890/udp -p 8189:8189/udp docker.io/bluenviron/mediamtx


  


  I use this ffmpeg line to feed mediamtx :

  


  ffmpeg -i "rtsp://127.0.0.1:10000/test" -f rtsp rtsp://127.0.0.1:8554/feed


  


  I can view the feed with

  


  ffplay  rtsp://localhost:8554/feed


  


  ffplay says some things about my stream

  


  the mediamtx stream

  


  Input #0, rtsp, from 'rtsp://localhost:8554/feed':
  Metadata:
    title           : Session streamed with GStreamer
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: mpeg4 (Simple Profile), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 30 tbr, 90k tbn, 30 tbc


  


  the source stream

  


  Input #0, rtsp, from 'rtsp://localhost:10000/test':
  Metadata:
    title           : Session streamed with GStreamer
    comment         : rtsp-server
  Duration: N/A, start: 0.199989, bitrate: N/A
  Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(tv, smpte170m, progressive), 320x240 [SAR 1:1 DAR 4:3], 30 fps, 30 tbr, 90k tbn, 60 tbc


  


  I use this html code try to display the video :

  


  
    



  


  mediamtx gives the following output when the browser tries to connect :

  


  2024/10/18 07:52:51 INF [RTSP] [session 7fe6a91a] created by 10.0.2.100:57542
2024/10/18 07:52:51 INF [RTSP] [session 7fe6a91a] is publishing to path 'feed', 1 track (MPEG-4 Video)
2024/10/18 07:52:52 INF [WebRTC] [session 9d4fb884] created by 10.0.2.100:55070
2024/10/18 07:52:52 INF [WebRTC] [session 9d4fb884] closed: the stream doesn't contain any supported codec, which are currently AV1, VP9, VP8, H264, Opus, G722, G711, LPCM


  


  The stream is clearly h264... why is it complaining ?

  


• Anomalie #4849 (Nouveau) : Lisibilité du tableau des statistiques

  12 juillet 2021, par JLuc -

  #2693 a été fermé suite à la correction du code, mais la présentation du tableau de résultat n’a pas évolué et pour le comprendre, il a fallu que j’étudie le code. Du coup j’ai compris qu’il y a un petit problème de conception que je signale ici, ainsi que le manque de clarté dans un énoncé.

  La colonne de gauche présente 2 listes à la suite.
  Ces 2 listes sont séparées par un intertitre centré "..." qui indique qu’il y a une forme d’interruption dans la continuité d’une même liste.
  Or ce n’est pas le cas puisque l’analyse du code révèle que :
  - la première liste présente les 30 articles les plus populaires
  - la 2eme liste présente la popularité des 10 articles les plus récents (classés du plus récent au plus ancien)
  L’ordonnancement étant totalement différent, il s’agit bien de 2 listes qui devraient être perçues comme totalement différentes...
  MAIS
  - il y a quand même une interférence entre ces 2 listes puisque les articles présents dans la première (les articles populaires) sont exclus de la seconde.
  - il n’y a qu’un seul titre pour ces 2 listes, qui reflète l’ambigüité du mélange (malheureusement sans l’éclairer) : « Afficher les visites pour les articles les plus populaires et pour les derniers articles publiés : « Afficher les visites pour les articles les plus populaires et pour les derniers articles publiés : »
  Mais ce n’est pas possible, de même qu’il n’est pas possible de lister dans une même liste des voitures triées par vitesse maximale et des pommes triées par teneur en sucre.

  Donc il faudrait
  - avoir un titre différent pour chacune de ces listes
  - à mon avis aussi retirer le doublon qui rend difficile la lecture de la 2eme liste car autant il est simple de dire "c’est la popularité des articles les plus récents" (et intéressant d’avoir une telle liste), autant il est complexe d’expliquer et de comprendre "C’est la popularité des articles les plus récents sauf s’ils font partie des 30 plus populaires du site" (et difficile à utiliser une telle information circonluée).
  - ne pas avoir de séparateur "[...]" entre ces 2 listes. Ce ne sera pas utile avec le 2eme intertitre.

  Par ailleurs le texte explicatif "Comment lire ce tableau" en bas de la colonne de droite contient une explication de ce qu’est la "popularité de l’article : (une estimation du nombre de visites quotidiennes qu’il recevra si le rythme actuel de consultation se maintient)". L’emploi du futur + l’hypothèse "si le rythme actuel de consultation se maintient" donnent des pistes incomplètes et ne permettent pas de comprendre ce que c’est.
  - Spontanément j’avais retenu le futur et compris que c’était le nombre total final de visite de cet article, à supposer que sa fréquentation s’épuise mais sur quelle durée ? ça ne voulait rien dire.
  - Maintenant je comprend que c’est une estimation du nombre de visite quotidienne à partir d’une "moyenne instantannée" de fréquentation. Mais sur quelle durée se fait cette moyenne instantanée ? La fréquentation estimée se fait elle aussi sur la base d’une moyenne instantanée pour les articles ayant plus d’une journée d’âge ou bien c’est la fréquentation de la veille qui est prise dans ce cas ? Ça ne veut pas dire grand chose encore...
  En bref : ça en dit trop ou pas assez. On peut en dire moins avec simplement "une estimation du nombre de visites quotidiennes". Mais pour en dire plus et être plus précis... faudrait donner les infos manquantes.

• Anomalie #4830 (Nouveau) : extraire_date extravagant

  22 juin 2021, par JLuc -

  cf https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres_dates.php#L24

  Le phpdoc commence par
  "Extrait une date d’un texte et renvoie le résultat au format de date SQL"
  et termine par
  "return string Date au format SQL tel que `2008-04-01`"

  MAIS au milieu du phpdoc on découvre un
  "Les jours ne sont pas pris en compte et le résultat est toujours le 1er du mois."
  et c’est effectivement ce que fait la fonction !!! !! !

  Avec un fonctionnement aussi extravagant, il n’est pas étonnant que la fonction ne soit présente nulle part sur la zone... et ne soit pas documentée en français sur spip.net .

  Pour être exhaustif, elle fait tout de même 2 apparitions :
  - son test unitaire,
  - dans le plugin "aspirateur" où l’autrice apprécierait visiblement avoir une vraie date complète puisqu’à défaut c’est `gmdate("Y-m-d\TH:i:s\Z") ;` qui est employé. cf https://git.spip.net/spip-contrib-extensions/aspirateur/src/branch/master/inc/aspirer_rss.php#L116

  Je propose donc de mettre une fin à cette extravagance : que extraire_date renvoie une vraie date SQL, complète, avec le jour.