Recherche avancée

Médias (1)

Mot : - Tags -/ogg

Autres articles (29)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (4482)

  • Split a movie into 1000+ shots using PyAV in a single pass ?

    3 mai 2019, par Andrew Klaassen

    I need to split a 44 minute MP4 into 1000 shots (i.e. separate MP4s) with ffmpeg. I want to do it quickly (i.e. in a single pass rather than 1000 passes), I need perfect frame accuracy, and I need to do it in Windows.

    The Windows command-line length limit is stopping me from doing this, and I’m wondering if someone could show me an example of how to do this using a library like PyAV or Avpy. (Libraries like ffmpeg-python and ffmpy won’t help, since they simply construct an ffmpeg command line and run it, leading to the same Windows command-line length issue that I already have.)

    After much testing and gnashing of teeth, I’ve learned that the only way to get perfect frame accuracy from ffmpeg, 100% of the time, is to use the "select" filter. ("-ss" in the newest versions of ffmpeg is frame accurate 99% of the time ; unfortunately, that’s not good enough for this application.)

    There are two ways to use "select" for this. There’s the slow way, which I’m doing now, and which requires having ffmpeg open the file 1000 times :

    for (start, end, name) in shots:
       audio_start = start / frame_rate
       audio_end = end + 1 / frame_rate
       cmd = [
           path_to_ffmpeg,
           '-y',
           '-i', input_movie,
           '-vf', r'select=between(n\,%s\,%s),setpts=PTS-STARTPTS' % (start, end),
           '-af', 'atrim=%s:%s,asetpts=PTS-STARTPTS' % (audio_start, audio_end),
           '-c:v', 'libx264',
           '-c:a', 'aac',
           '-write_tmcd', '0',
           '-g', '1',
           '-r', str(frame_rate),
           name + '.mp4',
           '-af', 'atrim=%s:%s' % (audio_start, audio_end),
           name + '.wav',
       ]
       subprocess.call(cmd)

    And there’s the fast way, which causes the Windows command line to explode when there are too many shots. The long command line leads to a failure to run :

    cmd = [
       path_to_ffmpeg,
       '-y',
       '-i',
       input_movie,
    ]
    for (start, end, name) in shots:
       audio_start = start / frame_rate
       audio_end = end + 1 / frame_rate
       cmd.extend([
           '-vf', r'select=between(n\,%s\,%s),setpts=PTS-STARTPTS' % (start, end),
           '-af', 'atrim=%s:%s,asetpts=PTS-STARTPTS' % (audio_start, audio_end),
           '-c:v', 'libx264',
           '-c:a', 'aac',
           '-write_tmcd', '0',
           '-g', '1',
           '-r', str(frame_rate),
           name + '.mp4',
           '-af', 'atrim=%s:%s' % (audio_start, audio_end),
           name + '.wav',
       ]
    subprocess.call(cmd)

    I’ve looked through the documentation of PyAV and Avpy, but I haven’t been able to figure out whether the second form of my function is something I could do there, or how I’d go about doing it. If it is possible, would someone be able to write a function equivalent to my second function, using either library ?

  • Anomalie #4342 (Fermé) : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 ...

    26 mai 2019

    Bonjour,

    Après avoir configuré MariaDB pour être en UTF8MB4, je n’ai pas pu installer un plugin (comme il y a aussi un bug SVP, je vais faire un autre ticket spécifique).
    Pour être précis, un table du plugin n’a pas été créée et sql.log contient :

    2019-05-25 16:23:59 78.205.175.37 (pid 16091) :Pri:ERREUR : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 bytes
    in ecrire/base/create.php L73 [sql_create(),creer_ou_upgrader_table(),alterer_base(),maj_tables(),serie_alter(),maj_while(),maj_plugin(),referer_spam_upgrade(),spip_plugin_install(),plugins_installer_dist(),installer_plugin(),do_install(),do_action(),one_action(),action_actionner_dist(),traiter_appels_actions()]
    CREATE  TABLE IF NOT EXISTS `mutu_pro2spipf126`.spip_referer_spam (
            date DATE NOT NULL,
            referer VARCHAR (255) ,
            PRIMARY KEY (referer)) ENGINE=MyISAM
    

    La documentation sur ce sujet est abondante.
    Ceci m’a semblé un bon résumé du problème : https://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes
    Et la solution générale consiste à faire un index de seulement 191 : https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-conversion.html :

    In an InnoDB table that uses COMPACT or REDUNDANT row format, these column and index definitions are legal :
    col1 VARCHAR(500) CHARACTER SET utf8, INDEX (col1(255))
    

    To use utf8mb4 instead, the index must be smaller :
    col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))

  • Anomalie #4342 : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 bytes

    7 avril 2020

    Une autre piste donnée par b_b sur IRC :

    https://florent.poinsaut.fr/2018/08/17/mysql-mariadb-index-column-size-too-large-the-maximum-column-size-is-767-bytes/ :

    - 767 octets est la limite de préfixe déclaré pour les tables InnoDB dans les versions antérieures à la 5.7 de MySQL et dans les versions antérieurs à la 10.2 de MariaDB.
    - A partir de la version 5.7 de MySQL et la 10.2 de MariaDB, cette limite a été augmentée à 3072 octets.

    => bingo on est en 10.1.41-MariaDB-1 stretch

    - L’encodage (latin1, UTF8, UTF8mb4, etc.) peut jouer sur cette taille. Puisqu’en UTF8 un caractère prend 3 octets, il faut diviser la taille disponible par 3 pour trouver la longueur maximale de préfixe d’index. Et par 4 si on utilise UTF8mb4.

    => re bingo on est en utf8

    Une piste ici :

    global.innodb_large_prefix = 1

    https://stackoverflow.com/a/22873006
    https://github.com/go-gitea/gitea/issues/2979#issuecomment-412607116
    https://answers.launchpad.net/maria/+question/241612

    Amha c’est l’option qu’il nous faut tant qu’on est pas en mariadb > 10.1, sinon il faut passer en mariadb 10.3 cf :

    https://github.com/go-gitea/gitea/issues/2979#issuecomment-421000381

    PS : j’utilise mariadb 10.3 en local et je n’ai pas ce problème.