Sur d’autres sites (9126)

• Best practice to play segments of larger video files in HTML5 video format

  8 octobre 2015, par zx98

  I have to migrate a legacy project from Windows Media to HTML5 video/audio. The system should provide video/audio content to the web user meeting following criteria :

  1. Playout : Segments (TcIn to TcOut) of large video/audio files should be played "on the fly" to the web user. (Cutting the source material into segments does not work because there is a high overlap rate between segments, so 3-4 times more HDD space and a lot of extra programming would be needed. Markered playout of the large source files is not an option either as there are forbidden parts of the source material which should never be available to the user).
  2. Cutting : In general, users are permitted to make copies of the material. Indeed, by using the dowload function, users can download selected segments. I guess, this is not a problem : a service starts a cutting software (probably ffmpeg) that cuts the video, and the user is notified by email to download the product. (That’s the way I do it now but there might be a more simple option).
  3. Formats : what is the preferred video/audio format that most browsers (Chrome, Firefox, Opera, Android) support ?
  4. Server : If possible, I would keep Windows Server because the database behind is MS SQL Server.

  (Windows Media Server and WMEncoder currently works fine for all the above, however WM is not suppored by browsers any more. That is the reason for reengineering).

  I would appreciate any of your suggestions on how to rebuild this video/audio system. (What software elements to use and how).

  Thank you.

  -------- addition -------
  Dear commenters,
  Thank you for your comments. Please note that the above is one single question, the rest is just a detailed description of the issue/conditions, as recommended by stackoverflow.com. I guess, the answer is also very simple, I try to write it myself :

  1. You should keep the large video/audio files in xxx format because...
  2. You create a playlist file like this example... for each of the the segments.
  3. You install the xxx streaming software component on the web/media server to playout the segments.
  4. You can address and play the segments from the client side web browser like this :...
  5. For asynchronous cutting, yes, I recommend ffmpeg, try these profile settings.

  Just a few parts in bold are missing. Thanks to anyone who can fill them.

• 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.

• 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