Recherche avancée

Sur d’autres sites (8849)

• How to solve file path error while using ffprobe to find length of video file in python ?

  4 février 2018, par Mitchell Faas

  So, I’m trying to find the length of a video file by the methods discussed here : How to get the duration of a video in Python ?, Using ffmpeg to obtain video durations in python. But in doing so I run in to a problem which I haven’t been able to solve : I get

  FileNotFoundError:[WinError 2] The system cannot find the file specified

  after trying a bunch of troubleshooting steps I’ve started running in IPython and in cmd seperately to see where things might break down. Using a stripped down version of this code in IPython gives me

  In [11]: subprocess.Popen([ffmpeg_path+'ffprobe'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  
  Out[11]: 

  which seems to be fine, as is CMD at this point. So to adding slight complexity :

  In [17]: subprocess.Popen([ffmpeg_path+'ffprobe -i "F:/tst.mp4"'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  
  ---------------------------------------------------------------------------
  
  FileNotFoundError                         Traceback (most recent call last)
  
   in <module>()
  
  ----> 1 subprocess.Popen([ffmpeg_path+'ffprobe -i "F:/tst.mp4"'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  
  
  
  C:\Python\Anaconda3\lib\subprocess.py in __init__(self, args, bufsize, executable, stdin, stdout, stderr, preexec_fn, close_fds, shell, cwd, env, universal_newlines, startupinfo, creationflags, restore_signals, start_new_session, pass_fds, encoding, errors)
  
      705                                 c2pread, c2pwrite,
  
      706                                 errread, errwrite,
  
  --> 707                                 restore_signals, start_new_session)
  
      708         except:
  
      709             # Cleanup if the child failed starting.
  
  
  
  C:\Python\Anaconda3\lib\subprocess.py in _execute_child(self, args, executable, preexec_fn, close_fds, pass_fds, cwd, env, startupinfo, creationflags, shell, p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite, unused_restore_signals, unused_start_new_session)
  
      988                                          env,
  
      989                                          cwd,
  
  --> 990                                          startupinfo)
  
      991             finally:
  
      992                 # Child is launched. Close the parent's copy of those pipe
  
  
  
  FileNotFoundError: [WinError 2] The system cannot find the file specified
  
  </module>

  This crashes IPython. Running the very same command ffprobe -i "F:/tst.mp4" in CMD works like a charm.

  Here’s what I tried : Changing / to \ and \ , adding and removing quotes around the file path, changing the path to C :\tst.mp4.

  Running the command os.system(ffmpeg_path+'ffprobe -i "F:/tst.mp4") does work.

  What could possibly be going wrong here ?

• Roadmap #3844 : Gérer la parenté dans la déclaration d’un objet éditorial.

  27 février 2018, par RastaPopoulos ♥

  Hello,
  j’ai possiblement besoin de rajouter la prise en compte directe du champ "id_parent" s’il existe lors de la création, qui est un cas vraiment simple et bateau, qui est donc détectable sans déclaration spéciale, lors de la création d’un objet quelconque.

  Actuellement objet_inserer() peut lui passer une variable générique nommée $id_parent, mais en fait dedans la fonction ne gère que le cas si y a un champ "id_rubrique" pour cet objet. Du coup j’ai ajouté le cas encore plus simple où ya un champ "id_parent", càd quand l’objet est parent de lui-même (comme les rubriques).

  Mais finalement je n’ai rien commité, car je me suis dit que ça rentrait dans la réflexion plus générale de ce ticket, et que mon petit bout de code devra bien être utilisé mais à l’intérieur d’un code plus large utilisant la déclaration explicite si elle existe. Je mets le diff de ma modif quand même pour historique.

  En gros pour moi dans objet_inserer(), c’est toute la partie qui teste si ya "id_rubrique" + mon ajout qui teste "id_parent" qui devrait être recodé avec cet algorithme :
  1) s’il y a un déclaration de parentée explicite, on l’utilise et on essaye de remplir les bons champs et la langue avec ça
  2) s’il y a un champ "id_rubrique" on remplit magiquement
  3) s’il y a un champ "id_parent" on remplit magiquement

  Pour le 2) et 3), je ne sais pas si ça doit être à chaque fois en ajout, ou bien en "elseif", càd seulement si le cas précédent n’existe pas ! Il faudra le décider.

  En attendant qu’on statue sur tout ça, je vais me débrouiller avec le pipeline "pre_insertion" pour lequel j’ai rajouté l’information "id_parent" tout à l’heure, car ça du coup je l’ai mis aussi en 3.2 puisque ça ne changeait rien…

• Roadmap #3844 : Gérer la parenté dans la déclaration d’un objet éditorial.

  12 mars 2018, par RastaPopoulos ♥

  J’ai continué dans la réflexion, ayant besoin de parent et enfants dans le plugin Duplicator. J’ai expliqué différents problèmes dans la liste Zone, mais pour pas le perdre, je vais copier ça dans ce ticket.

  Proposition de deux fonctions d’API génériques¶

  À mon avis il faut aller stable et plus abstrait que juste la déclaration dans l’objet, car
  1) ça peut éventuellement changer
  2) il faudrait pouvoir prendre en compte les cas courants magiquement même quand ya pas eu de déclaration explicite (id_rubrique, id_parent…)
  3) ça donne le parent d’un type d’objet pour remonter, mais ça ne donne pas l’inverse, les enfants

  Donc dans tous les cas il faudrait sûrement une fonction du genre
  array objet_info_parent($objet)
  dont l’algorithme serait :
  - s’il y a une déclaration explicite, c’est ça qu’on utilise
  - s’il y a un champ id_rubrique, on fait comme si ça avait été déclaré avec la rubrique array(type=>rubrique, champ=>id_rubrique)
  - s’il y a un champ id_parent, on considère que l’objet est arborescent de lui-même, et donc comme si ça avait été déclaré comme ça array(type=$objet, champ=>id_parent)

  Mais je pense aussi une fonction cette fois un peu plus longue, qui donnerait l’ensemble des enfants directs qu’on a réussi à trouver
  array objet_info_enfants($objet)
  dont l’algorithme serait :
  - un tableau de résultats en static pour toujours faire qu’une fois par hit
  - si $enfants[$objet] déjà rempli en renvoie
  - sinon on boucle sur tous les objets déclarés
  - pour chaque, si on trouve que l’objet peut avoir comme parent direct le $objet qu’on cherche, alors on l’ajoute à son tableau des enfants possibles
  - donc soit si dans sa clé "parent" ya $objet, soit s’il a un id_rubrique et qu’on cherchait pour "rubrique", soit s’il a un id_parent et qu’on cherchait pour son type

  Un parent direct dont l’objet n’est pas fixe¶

  Encore autre chose, je ne sais pas si c’est prévu, mais il faudrait pouvoir gérer les cas où le parent direct (on parle bien toujours de parentée directe, pas de liens multiples) peut être n’importe quel objet. Dans ce cas, il y a les champs objet et id_objet directement dans la table de l’objet.

  Un parent encore plus compliqué avec deux cas à tester pour le même contenu¶

  Mais il y a encore plus compliqué, et c’est le cas pour mes Chapitres, mais aussi le cas pour les Forums fournit par SPIP : le parent direct
  peut être
  - SOIT l’objet lui-même car il est arborescent avec un id_parent
  - SOIT n’importe quel autre contenu SI ET SEULEMENT SI le champ id_parent=0 !

  C’est bien le cas pour les forums :
  - le premier forum d’un fil a pour parent un objet SPIP, avec objet et id_objet remplis dans sa table ET id_parent=0
  - les sous-forums ont AUSSI gardé en mémoire objet et id_objet du forum racine, mais avec id_parent rempli avec l’identifiant id_forum de leur parent

  Dans ce cas on ne peut pas se baser uniquement sur le fait que objet et id_objet sont remplis. Le parent est un objet SPIP quelconque si objet et id_objet remplis ET id_parent=0. Et dès que id_parent>0 alors le parent direct est le même objet (forum, chapitre ou autre).

  Bref ya des cas comme ça qui sont plus complexes, mais pourtant légitimes, et en plus fournis dans la dist, maintenus par le core, donc il faut savoir les gérer aussi.

  Du coup pour conclure, j’ai pas forcément de solution directe pour la déclaration générique qui doit intégrer le noyau au final, mais c’est pour expliquer pourquoi peut-être, possiblement, il y aurait besoin d’un pipeline dédié dans Duplicator pour gérer ces enfantillages compliqués tant que dans l’API de parent c’est pas encore résolu.

  En tout cas ça fait avancer la réflexion :)