Recherche avancée

Sur d’autres sites (8862)

• FFmpeg HLS streaming - Why the program date time of older segment changing when re-streaming after discontinuity

  9 novembre 2020, par Suriya Krish

  Following is the ffmpeg command to stream the data.

  


  ffmpeg -re -f avfoundation 
-framerate 30 -i 0 
-codec:v h264_videotoolbox -x264-params keyint=120:scenecut=0 
-codec:a copy -f hls 
-hls_list_size 60 
-hls_time 10 
-hls_flags delete_segments 
-hls_flags +append_list 
-hls_flags +discont_start 
-hls_flags +program_date_time 
-strftime 1 
-strftime_mkdir 1 
-hls_segment_filename 
'%Y%m%dT%H%M%S%z.ts' playlist.m3u8


  


  Following is the playlist.m3u8 content which generated for few seconds.

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:07:53.000+0530
20201109T220753+0530.ts
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:08:03.000+0530
20201109T220803+0530.ts
#EXT-X-ENDLIST


  


  When the re-stream happens(in case of restarting the streaming service), the program date time of older segments(before #EXT-X-DISCONTINUITY) also get changed like below, which is unexpected.

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:12:50.633+0530
20201109T220753+0530.ts
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:00.633+0530
20201109T220803+0530.ts
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:12.000+0530
20201109T221312+0530.ts
#EXTINF:5.400000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:22.000+0530
20201109T221322+0530.ts
#EXT-X-ENDLIST


  


  Why the program date time of older segment should change ? Should we add any arguments in ffmpeg command to handle this ?

  


• Anomalie #4543 (Nouveau) : Accessibilité des chargements ajax (live regions)

  2 septembre 2020, par nicod _

  Suite à un audit de site par Temesis, il remonte que les attributs aria qu’on utilise sont mal placés.

  Je cite :

  Il semble qu’il y a un problème plus global avec l’utilisation des live region :
  Je rencontre à nouveau le div englobant div.ariaformprop qui possèdent les attributs

  aria-live
  aria-atomic
  aria-relevant

  Cette utilisation de ces attributs est erronée :

  elle ne donne pas le résultat probablement attendu
  le support d’aria-relevant dans les assistances technologiques n’est pas assuré

  Il est donc nécessaire de ne pas utiliser de live region sur une div englobante comme là.
  Il faut supprimer ces attributs et utiliser aria-live et aria-atomic avec parcimonie.

  J’ai regardé l’exemple que tu donnes sur spip.net également.

  L’exemple était : https://www.spip.net/spip.php?page=recherche&recherche=plugin&debut_articles=0#pagination_articles

  Cette prolifération d’aria-live + aria-atomic part probablement d’un bon sentiment, mais comme parfois avec l’accessibilité, le mieux est l’ennemi du bien.

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.
  Ensuite, il faut bien entendu prendre en compte le contexte. Il pourrait arriver que ce comportement soit pertinent. Ce n’est pas le cas ici.

  Dans le cas de rechargement ajax, il faut étudier chaque cas et son contexte, mais le plus souvent le principe est :

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region. En théorie, la présence de ces attributs s’il n’y a pas de rechargement ne devrait pas gêner. Mais certains lecteurs d’écran peuvent prendre des libertés par rapport aux spécifications et vocaliser des contenus tout de même. C’est pourquoi il faut être parcimonieux.

  Lorsqu’ils sont utiles et nécessaires, utiliser ces attributs pour informer d’un changement. Exemple : donner le nouveau nombre de résultats après utilisation de filtre. Mais il faut bien penser que dans plusieurs cas ils ne sont pas nécessaires, en effet, un bouton d’action doit être explicite avant qu’on appuie dessus. Donc par exemple : lorsque je demande à afficher la page 2 dans une pagination de résultat, il n’y a pas d’info à vocaliser automatiquement, le fait que le bouton dise "afficher la page 2" est suffisant, il serait superflu, voire gênant d’aller plus loin dans ce qui est vocalisé.

  Enfin, il faut gérer le focus clavier. Cet aspect est essentiel dès qu’il y a des interactions ajax, mais il dépend totalement du contexte. Et cet aspect est indépendant de la nécessité d’utiliser les live regions. Exemple : dans une série de filtre on va laisser le focus sur le filtre pour que l’utilisateur puisse parcourir la série de filtre. A contrario, dans une pagination (ou quand on a un bouton de type "afficher plus d’articles", dans des news ou dans une page de produits pour un site de e-commerce) on va déplacer le focus sur le 1er nouveau élément qui vient de s’afficher (la zone qui a été mise à jour).

• Evolution #2969 : Retourner message_ok et message_erreur sur un traitement CVT

  18 novembre 2013, par cam.lafit -

  Salut

  Oui retourner une erreur si il y a est logique :) Je ne remettais pas
  en doute ce point.
  C’est le fait de ne pouvoir dire que le verre est à moitié plein et à
  moitié vide. Pour le moment c’est soit plein soit vide.

  Si on injecte le résultat positif dans le message d’erreur, il se
  retrouver noyé dans le bloc erreur et ne profite pas de la mise en
  forme réussie. On peut trouver des cas où l’erreur n’interdit pas la
  réussite et vice versa.