Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (41)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

Sur d’autres sites (5857)

  • sh4 : Remove dubious aligned dsputil code

    18 avril 2013, par Diego Biurrun
    sh4 : Remove dubious aligned dsputil code
    

    The code represents a considerable maintenance burden and it is not
    clear that it gives a noticeable benefit to outweigh this after 10
    years of improvements in compiler technology since its creation.

    • [DBH] libavcodec/h264chroma.c
    • [DBH] libavcodec/h264chroma.h
    • [DBH] libavcodec/hpeldsp.c
    • [DBH] libavcodec/hpeldsp.h
    • [DBH] libavcodec/sh4/Makefile
    • [DBH] libavcodec/sh4/dsputil_align.c
    • [DBH] libavcodec/sh4/dsputil_sh4.c
    • [DBH] libavcodec/sh4/dsputil_sh4.h
    • [DBH] libavcodec/sh4/h264chroma_init.c
    • [DBH] libavcodec/sh4/hpeldsp.c
    • [DBH] libavcodec/sh4/qpel.c
  • Enabling libfdk_aac in ffmpeg installed with Homebrew

    3 septembre 2019, par RocketNuts

    On macOs I always used to install or update ffmpeg through Homebrew. I use the libfdk_aac audio codec a lot so I always did this :

    brew reinstall ffmpeg --with-fdk-aac

    For some reason, since one or two brew updates, ffmpeg can no longer be installed with libfdk_aac.

    When converting a video and using -acodec libfdk_aac which has been working fine for years, I now get :

    Unknown encoder ’libfdk_aac’

    Is there a way to fix this ?

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