Recherche avancée

Sur d’autres sites (11404)

• Audio Slowly Desynchronizing When Segmenting

  14 avril 2018, par Nimble

  I use ffmpeg’s ability to segment video while I record so I can record constantly without my hard drive filling up.

  It works really well, expect the audio desynchronizes from the video when the file segments. The video seems to be uninterrupted but I can actually hear a tiny jump in the audio when I join segments later on. One would think that ffmpeg would store packets in a queue during segmentation so nothing is lost but that doesn’t seem to be the case... Any way I could force it to do something like that ?

  Here is my current block :

  ffmpeg -y -thread_queue_size 5096 -f dshow -video_size 3440x1440 -rtbufsize 2147.48M -framerate 100 -pixel_format nv12 ^
  
  -itsoffset 00:00:00.012 -i video="Video (00 Pro Capture HDMI 4K+)" -thread_queue_size 5096 -guess_layout_max 0 -f dshow ^
  
  -rtbufsize 2147.48M -i audio="SPDIF/ADAT (1+2) (RME Fireface UC)" -map 0:0,1:0 -map 1:0 -c:v h264_nvenc -preset: llhp ^
  
  -pix_fmt nv12 -b:v 250M -minrate 250M -maxrate 250M -bufsize 250M -b:a 384k -ac 2 -r 100 -vsync 1 ^
  
  -max_muxing_queue_size 5096 -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\PC\PC%02d.mp4 

  I am delaying the video stream because right out the gate it’s a little bit ahead of the audio.

  PS : aresample or async seem to have no effect or at least not a desirable one.

• Anomalie #3245 (Nouveau) : Formulaire editer_liens affiché inutilement dans certains cas

  24 juillet 2014, par tcharlss (*´_ゝ｀)

  Reproduire le comportement¶

  Pour observer le problème, je propose d’utiliser les mots-clés, qui se servent du formulaire « editer_liens ». Donc :

  • 1) Avoir au préalable des articles avec des mots-clés, et d’autres sans.
  • 2) Désactiver l’ajout de mots-clés aux articles pour tous les groupes de mots-clé.

  Résultat :

  • Les articles possédant des mots-clés comportent toujours le formulaire. Là, ça me semble normal.
  • Les articles ne possédant pas de mot-clé affichent eux aussi le formulaire. Là, ça me paraît erroné : il devrait être caché. Il n’a aucune utilité, et on a "désactivé" l’utilisation des mots-clés pour les articles, ça veut dire qu’on en veut pas.

  Continuons.

  • 3) Retirer tous les mots-clés liés aux articles.

  Résultat :

  • Maintenant, le formulaire n’est plus affiché, car plus aucun article ne possède de mot clé : on retrouve le comportement normal.

  Problème¶

  Le problème vient d’un test effectué dans charger : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L94

  Le raisonnement actuel est le suivant : quand le formulaire n’est pas éditable, il est caché s’il n’existe aucun lien pour le type d’objet.
  Ou pour reprendre l’exemple des mots, plus parlant : le formulaire est caché s’il n’existe aucun mot lié à un article (n’importe quel article).
  Or je pense qu’il devrait être caché s’il n’existe aucun mot lié à l’article en cours.

  Donc, en remplaçant :
  

  objet_trouver_liens(array($objet_lien=>’*’),array(($objet_lien==$objet_source ?$objet :$objet_source)=>’*’))

  
  par :
  

  objet_trouver_liens(array($objet_lien=>’*’),array(($objet_lien==$objet_source ?$objet :$objet_source)=>$id_objet))

  On retrouve le comportement qui me semble "normal".

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  18 avril 2021

  Bon stop (ou pas) !

  Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c’est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

  J’ai fait quelques tests en partant du formulaire de préférences des menus (tiens d’ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
  Il contient un fieldset + .editer-groupe.deux_colonnes (columns : 2)

  Ce que j’ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)
  

  <span class="CodeRay"><span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer</span>
      <span class="tag">div</span><span class="class">.editer</span>
      ...
  </span>
  Télécharger

  1) Si on applique un columns: 2 sur ce fieldset,
  - Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
  - Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

  2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
  - Tous : le legend est conservé comme tel
  - le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

  Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

  Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
  Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

  Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
  J’utilise .editer-section ensuite (mais peut importe)

  A) fieldset.editer-section > div.editer-groupe¶

  (le plus proche de l’actuel je pense)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe > div.editer-section¶

  L’autre possibilité si ça facilite vraiment le css, c’est d’inverser les classes (avec l’ennui principal de du coup devoir reprendre l’existant)

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-fieldset</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  B) fieldset.editer-groupe.editer-section > div.editer-groupe¶

  Ou du doubler d’une autre classe

  <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
        <span class="tag">div</span><span class="class">.editer</span>
        ...
    <span class="tag">fieldset</span><span class="class">.editer-groupe</span><span class="class">.editer-section</span>
      <span class="tag">legend</span>
      <span class="tag">div</span><span class="class">.editer-groupe</span>
          <span class="tag">div</span><span class="class">.editer</span>
          ...
  </span>
  Télécharger

  Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
  Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;