Sur d’autres sites (3440)

• How do I alter my FFMPEG command to make my HTTP Live Streams more efficient ?

  17 octobre 2014, par Robert

  I want to reduce the muxing overhead when creating .ts files using FFMPEG.

  Im using FFMPEG to create a series of transport stream files used for HTTP live streaming.

  ./ffmpeg -i myInputFile.ismv \
  
           -vcodec copy \
  
           -acodec copy \
  
           -bsf h264_mp4toannexb \
  
           -map 0 \
  
           -f segment \
  
           -segment_time 10\
  
           -segment_list_size 999999 \
  
           -segment_list output/myVarientPlaylist.m3u8 \
  
           -segment_format mpegts \
  
           output/myAudioVideoFile-%04d.ts

  My input is in ismv format and contains a video and audio stream :

  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 320x240, 348 kb/s, 29.97 tbr, 10000k tbn, 59.94 tbc
  
  Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 63 kb/s

  There is an issues related to muxing that is causing a large amout of overhead to be added to the streams. This is how the issue was described to me for the audio :

  

  So for a given aac stream, the overhead will be 88% (since 200 bytes will map to 2 x 188 byte packets).

  For video, the iframe packets are quite large, so they translate nicely into .ts packets, however, the diffs can be as small as an audio packet, therefore they suffer from the same issue.

  The solution is to combine several aac packets into one larger stream before packaging them into .ts. Is this possible out of the box with FFMPEG ?

• Anomalie #3894 (Nouveau) : Jointures (erronées ?) avec les boucles documents et leurs critères

  26 janvier 2017, par marcimat ☺☮☯♫

  Soit le cas suivant :

  - une document A, attaché à une rubrique R1 et R2
  - <doca></doca> mis dans le texte de R1 (il est donc "vu" dans R1, mais pas dans R2)
  - une boucle documents simplifiée (issue de squelettes-dist/inclure/documents.html) dans le squelette test.html :
  

  Test
  #FICHIER

  Constats¶

  Paramètre id_rubrique :¶

  Si on appelle ?page=test&id_rubrique=1 le document A sera retourné, malgré le critère {vu=non}.
  Effectivement la boucle effectue 2 jointures différentes sur spip_documents_liens, une pour lier le champ "vu" et l’autre pour lier objet/id_objet.
  Du coup, la requête SQL trouve effectivement un document A non vu (dans la rubrique 2) et le retourne (vu qu’il est lié aussi à la rubrique 1).

  On obtient la requête suivante :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.id_objet = 1)
      AND (L2.objet = ’rubrique’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Paramètres objet / id_objet :¶

  Si on appelle page=test&objet=rubrique&id_objet=1, soit logiquement la même chose, on obtient 3 jointures sur spip_documents_liens.
  Là, les documents retournés ne soient pas forcément ceux de l’objet demandé ! La jointure cherche des documents liés à objet=rubrique, id_objet=1, mais pas forcément dans la même liaison !
  Les documents retournés ici sont parfois un peu farfelus donc là.

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L4 ON ( L4.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L3.objet = ’rubrique’)
      AND (L4.id_objet = 1)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Paramètre id_article¶

  Si on appelle page=test&id_article=1, on obtient, ô magie, une seule jointure. La boucle est correcte cette fois-ci donc. Je n’ai pas encore cherché pourquoi ça marche avec id_article, et pas id_rubrique…

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L1.id_objet = 1)
      AND (L1.objet = ’article’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

• Anomalie #4129 (En cours) : Echec de la première connexion des utilisateurs LDAP et non création d...

  11 avril 2018, par Franck R

  version de SPIP : 3.2.1 [23954]
  version de PHP : 5.6.33
  version de MySQL : 14.14

  Jusqu’à il n’y a pas si longtemps (désolé pour l’imprécision, on ajoute pas des utilisateurs si fréquemment), les utilisateurs LDAP pouvaient s’authentifier sur SPIP et l’utilisateur SPIP était créé dans la base de donnée. J’ai remarqué récemment que les nouveaux arrivants ne pouvaient plus s’authentifier, et donc créer leur compte, de cette manière.

  Problème¶

  Ce problème a été remarqué sur le site en production mis à jour en 3.2.1, ainsi que sur une installation de test 3.2.1 propre (attention au bug de config LDAP ).

  1. Le site SPIP est configuré pour utiliser l’authentification LDAP ;
  2. Un nouvel utilisateur est créé dans le LDAP ;
  3. Il se connecte au site SPIP avec ses identifiants LDAP ;
  4. La connexion échoue systématiquement.

  La demande #3824 offre une solution avec _AUTORISER_AUTH_FAIBLE mais elle ne me semble pas satisfaisante sachant que LDAP est configurable à l’installation de SPIP, le mode par défaut devrait assurer que l’on puisse se connecter.

  Workaround¶

  Il y a au moins deux solutions qui fonctionnent :

  1. La création de l’utilisateur à la main dans la base de donnée permet à l’utilisateur de se connecter (insert into spip_auteurs ...)
  2. Mettre define ('_AUTORISER_AUTH_FAIBLE', true);

  Analyse¶

  Lors de la toute première authentification d’un utilisateur inconnu de SPIP, le mot de passe est envoyé sécurisé par défaut (hachage réalisé par le javascript avec les aleas actuel/futur). Seulement l’authentification LDAP requiert le mot de passe en clair. Lorsque l’utilisateur existe déjà et que la source est ldap, alors la sécurisation du mot de passe est désactivée (login.js, login-sha-min.js, le cadenas à côté du champ mot de passe disparait), d’où le fonctionnement du workaround 1. Si on désactive la sécurisation du mot de passe, workaround 2, alors cela fonctionne lors de la première authentification, et l’utilisateur est bien créé dans SPIP.

  Remarque¶

  L’envoi en clair n’est pas un gros problème dans notre cas, le site est forcé en HTTPS.