Sur d’autres sites (14094)

• 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
  

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

• Revision 17292 : Update Skeleton/OggIndex support to Skeleton 4.0. ffmpeg2theora now ...

  16 juin 2010, par j — Log

  Update Skeleton/OggIndex ? support to Skeleton 4.0.
  ffmpeg2theora now writes Skeleton 4.0 with index by default.
  Patch by Chris Pearce