Recherche avancée

Médias (91)

Autres articles (41)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

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

Sur d’autres sites (7987)

  • avcodec : disallow hwaccel with frame threads

    23 octobre 2015, par Hendrik Leppkes
    avcodec : disallow hwaccel with frame threads
    

    HWAccels with frame threads are fundamentally flawed in avcodecs current
    design, and there are several known problems ranging from image corruption
    to driver crashes.

    These problems come down to two design problems in the interaction of
    threads and HWAccel decoding :

    (1)
    While avcodec prevents parallel decoding and as such simultaneous access
    to the hardware accelerator from the decoding threads, it cannot account
    for the user code and its access to the hardware surfaces and the hardware
    itself.

    This can result in image corruption or even driver crashes if the
    user code locks image surfaces while they are being used by the decoder
    threads as reference frames.

    The current HWAccel API does not offer any way to ensure exclusive access
    to the hardware or the surfaces if frame threading is used.

    (2)
    Initialization of the HWAccel with frame threads is non-trivial, and many
    decoders had and still have issues that cause excess calls to the
    get_format callback.

    This will potentially cause duplicate HWAccel initialization, which in
    extreme cases can even lead to driver crashes if the HWAccel is
    re-initialized while the user code is actively accessing the hardware
    surfaces associated with it, or lead to image corruption due to lost
    reference frames.

    While both of these issues are solvable, fixing (1) would at least require
    a huge API redesign which would move a lot of complexity into the user
    code.

    The only reason the combination of frame threads and HWAccel was
    considered useful is to allow a seamless fallback to multi-threaded
    software decoding if the HWAccel is not available, however the issues
    outlined above far outweigh this.

    The proper solution for a fallback is to re-open the AVCodecContext with
    threading enabled if the HWAccel failed, which is a practice commonly used
    by various user applications using avcodec today already.

    Reviewed-by : Gwenole Beauchesne <gb.devel@gmail.com>
    Reviewed-by : wm4 <nfxjfg@googlemail.com>
    Signed-off-by : Hendrik Leppkes <h.leppkes@gmail.com>

    • [DH] libavcodec/utils.c
  • ffserver : refactor build_feed_streams()

    17 décembre 2015, par Reynaldo H. Verdejo Pinochet
    ffserver : refactor build_feed_streams()
    

    * Avoid excesive nesting that made it really hard to follow
    * Drop unneeded vars
    * Factor out codec compatibility check routine
    * Ensure inputs are closed and contexts are freed as needed
    before returning

    Signed-off-by : Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>

    • [DH] ffserver.c
  • avcodec/decode : ignore unsupported skip samples packet side data values

    1er février 2022, par James Almer
    avcodec/decode : ignore unsupported skip samples packet side data values
    

    Same as in the AV_FRAME_FLAG_DISCARD codepath, ensure avci->skip_samples is not
    negative.

    Signed-off-by : James Almer <jamrial@gmail.com>

    • [DH] libavcodec/decode.c