Recherche avancée

Médias (0)

Mot : - Tags -/presse-papier

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

Autres articles (84)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

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

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

Sur d’autres sites (15833)

  • swscale/x86/output : add AVX2 version of yuv2nv12cX

    26 avril 2020, par Nelson Gomez
    swscale/x86/output : add AVX2 version of yuv2nv12cX
    

    256 bits is just wide enough to fit all the operands needed to vectorize
    the software implementation, but AVX2 is needed to for a couple of
    instructions like cross-lane permutation.

    Output is bit-for-bit identical to C.

    Signed-off-by : Nelson Gomez <nelson.gomez@microsoft.com>

    • [DH] libswscale/x86/output.asm
    • [DH] libswscale/x86/swscale.c
  • Making Sure The PNG Gets There

    14 juin 2013, par Multimedia Mike — General

    Rewind to 1999. I was developing an HTTP-based remote management interface for an embedded device. The device sat on an ethernet LAN and you could point a web browser at it. The pitch was to transmit an image of the device’s touch screen and the user could click on the picture to interact with the device. So we needed an image format. If you were computing at the time, you know that the web was insufferably limited back then. Our choice basically came down to GIF and JPEG. Being the office’s annoying free software zealot, I was championing a little known up and coming format named PNG.

    So the challenge was to create our own PNG encoder (incorporating a library like libpng wasn’t an option for this platform). I seem to remember being annoyed at having to implement an integrity check (CRC) for the PNG encoder. It’s part of the PNG spec, after all. It just seemed so redundant. At the time, I reasoned that there were 5 layers of integrity validation in play.

    I don’t know why, but I was reflecting on this episode recently and decided to revisit it. Here are all the encapsulation layers of a PNG file when flung over an ethernet network :


    PNG Network Encapsulation

    So there are up to 5 encapsulations for the data in this situation. At the innermost level is the image data which is compressed with the zlib DEFLATE method. At first, I thought that this also had a CRC or checksum. However, in researching this post, I couldn’t find any evidence of such an integrity check. Further, I don’t think we bothered to compress the PNG data in this project long ago. It was a small image, monochrome, and transferring via LAN, so the encoder could get away with signaling uncompressed data.

    The graphical data gets wrapped up in a PNG chunk and all PNG chunks have a CRC. To transmit via the network, it goes into a TCP frame, which also has a checksum. That goes into an IP packet. I previously believed that this represented another integrity check. While an IP frame does have a checksum, the checksum only covers the IP header and not the payload. So that doesn’t really count towards this goal.

    Finally, the data gets encapsulated into an ethernet frame which has — you guessed it — a CRC.

    I see that other link layer protocols like PPP and wireless ethernet (802.11) also feature frame CRCs. So I guess what I’m saying is that, if you transfer a PNG file over the network, you can be confident that the data will be free of any errors.

  • Are there people interested in converting ffmpeg source to Go ?

    30 septembre 2018, par No One

    After seeing that Go compiler have been converted from C to Go I thought same for ffmpeg ? Don’t want to go deep into reasons as I think they are obvious. It was very hard to be so close to the have rich library as ffmpeg in other language. It was even hard to make bindings for that scale of library. I’m not enough advanced to start something like this myself, so is there anybody else interested in this ? If yes then where this question worth to be addressed, so people interested in this may have discussion ?

    (Seems not enough obvious so adding some details.)

    For applications which use large amount of commands with different complexity it is hard to read the code as it’s not actually a code. Instead, it’s commands which you will need to understand by reading docs from ffmpeg’s docs page. I had used ffmpeg before in Nodejs and there was lots of logic of manipulating command string. Also sometimes in windows it was ending with cmd limitations error. When you are working with some language it is nice to see whole logic in that language. So you know go ? than you know everything that is happening with this code without even going off from code and reading docs of another application.

    There may be some benefits from executing stuff in goroutines so you can handle concurrency in the way you want not in the way it is implemented in ffmpeg.

    Build faster with Go.

    Less code.

    Possibility to split code into smaller packages.

    Also if you are familiar why community converted compiler from C to Go than I think some reasons will fit too.