Recherche avancée

Médias (0)

Mot : - Tags -/logo

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (65)

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

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

  • XMP PHP

    13 mai 2011, par

    Dixit Wikipedia, XMP signifie :
    Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
    Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
    XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)

Sur d’autres sites (10397)

  • Revision 95026 : - ajout de l’export des metas du plugin menu , vu qu’il est configurable ...

    8 février 2016, par arnaud.berard@… — Log

    - ajout de l’export des metas du plugin menu , vu qu’il est configurable
    +z

  • Revision 123059 : Éviter un petit écart avec le menu déroulant

    23 mars 2020, par Charles Razack — Log

    Éviter un petit écart avec le menu déroulant

  • How does mp4 block matching work

    19 juin 2019, par YAHsaves

    I’ve been working on a video encoder that uses block matching to find similar blocks on previous frames.

    For the sake of simplicity I’ll leave out most of the details, but I’m wondering if I got the block matching algorithm right.

    In order to find a block on a previous frame my encoder uses the mean squared algorithm for the Y channel in YUV color space.

    This works by comparing each pixel of the block we want to match, with the block on the previous frame. It takes the difference of each pixel and squares it.

    After all the pixels are compared the block that has the least average difference is chosen as the desired block.

    Now this is where I need help. My encoder looks at every possible block in a 256x256 area and uses half pixel searches as well. The smallest block size it can use is 4x4.

    From what I’ve read online this is the same things mp4 uses.

    However I can’t find nearly as many blocks as mp4 appears to be able to find.

    For example here are 2 frames I want to compress. The first will be the I frame and the second is the P frame :

    enter image description here

    Now after my encoder has run it is able to reduce the second frame by 80% and, what it can’t match close enough it saves as "difference" blocks. Which are grey blocks only recording the difference. They look like this :

    enter image description here

    Now what I don’t get is to save these "difference" blocks as a jpg takes roughly 90kb to be accurate enough.

    Multiply that by 24 (24 frames per second) you get 2070kb per second. That’s not including how much space the actual motion vectors take up or anything else.

    However somehow mp4 is able to compress the video of the images above into a mere 700kb per second and still look better than my encoder at much larger data amounts.

    Why is this ? Is there something I’m doing wrong when looking for blocks ? Any help would be much appreciated.