Recherche avancée

Médias (0)

Mot : - Tags -/interaction

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

Autres articles (35)

  • Configuration spécifique d’Apache

    4 février 2011, par

    Modules spécifiques
    Pour la configuration d’Apache, il est conseillé d’activer certains modules non spécifiques à MediaSPIP, mais permettant d’améliorer les performances : mod_deflate et mod_headers pour compresser automatiquement via Apache les pages. Cf ce tutoriel ; mode_expires pour gérer correctement l’expiration des hits. Cf ce tutoriel ;
    Il est également conseillé d’ajouter la prise en charge par apache du mime-type pour les fichiers WebM comme indiqué dans ce tutoriel.
    Création d’un (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

Sur d’autres sites (5550)

  • x264 intrarefresh intra coded frame detection

    11 juillet 2011, par RobS

    I have used ffmpeg with libx264 to create a video using the intra-refresh flag.

    Using wireshark on the RTP stream when the flag is disabled, it is easy to locate the keyframes (I-slices). When the intra-refresh flag is enabled, the keyframes are replaced by an SEI frame of type Recovery point and only the very first frame is marked as an I-slice.

    All the others appear to be P-slices in my experiments.

    These findings are as expected. I was wondering if it is possible to detect the intra-coded columns in the RTP packet sequence at a high level or if it is only possible by detailed parsing of the payload content ?

    I would like to be able to create a filter for the intra only columns using the header information only.

  • Reverse Engineering Radius VideoVision

    3 avril 2011, par Multimedia Mike — Reverse Engineering

    I was called upon to help reverse engineer an old video codec called VideoVision (FourCC : PGVV), ostensibly from a company named Radius. I’m not sure of the details exactly but I think a game developer has a bunch of original FMV data from an old game locked up in this format. The name of the codec sounded familiar. Indeed, we have had a sample in the repository since 2002. Alex B. did some wiki work on the codec some years ago. The wiki mentions that there existed a tool to transcode PGVV data into MJPEG-B data, which is already known and supported by FFmpeg.

    The Software
    My contacts were able to point me to some software, now safely archived in the PGVV samples directory. There is StudioPlayer2.6.2.sit.hqx which is supposed to be a QuickTime component for working with PGVV data. I can’t even remember how to deal with .sit or .hqx data. Then there is RadiusVVTranscoder101.zip which is the tool that transcodes to MJPEG-B.

    Disassembling for Reverse Engineering
    Since I could actually unpack the transcoder, I set my sights on that. Unpacking the archive sets up a directory structure for a component. There is a binary called RadiusVVTranscoder under RadiusVVTranscoder.component/Contents/MacOS/. Basic deadlisting disassembly is performed via ’otool’ as shown :

      otool -tV RadiusVVTranscoder | c++filt

    This results in a deadlisting of both PowerPC and 32-bit x86 code, as the binary is a "fat" Mac OS X binary designed to run on both architectures. The command line also demangles C++ function signatures which gives useful insight into the parameters passed to a function.

    Pretty Pictures
    The binary had a lot of descriptive symbols. As a basis for reverse engineering, I constructed call graphs using these symbols. Here are the 2 most relevant portions (click for larger images).

    The codec initialization generates Huffman tables relevant to the codec :



    The main decode function calls AddMJPGFrame which apparently does the heavy lifting for the transcode process :



    Based on this tree, I’m guessing that luma blocks can be losslessly transcoded (perhaps with different Huffman tables) which chroma blocks may rely on a different quantization method.

    Assembly Constructs
    I started looking at the instructions (the x86 ones, of course). The binary uses a calling convention I haven’t seen before, at least not for the x86 : Rather than pushing function arguments onto the stack, the code manually subtracts, e.g., 12 from the ESP register, loads 3 32-bit arguments into memory relative to ESP, and then proceeds with the function call.

    I’m also a little unclear on constructs such as "call ___i686.get_pc_thunk.bx" seen throughout relevant functions such as MakeRadiusQuantizationTables().

    I’m just presenting what I have so far in case anyone else wants to try their hand.

  • Anomalie #2367 : Transmettre #ENV à propre() et aux modèles

    11 octobre 2011, par davu x

    Ah ok, merci des clarifications. Par contre tu ne peux pas changer le type silencieusement. J’ai pris la peine d’expliquer dans le ticket pourquoi après hésitations j’avais choisi de le mettre comme bug + priorité basse, et non comme évolution : d’un point de vue utilisateur l’écriture doit (...)

Navigation