Recherche avancée

Médias (91)

Autres articles (11)

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

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

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

Sur d’autres sites (2471)

  • hw_base_encode : Free pictures on close

    15 octobre 2024, par David Rosca
    hw_base_encode : Free pictures on close

    Fixes leaking recon surfaces with VAAPI.
    • [DH] libavcodec/hw_base_encode.c

  • OpenCV - suppress, hide or disable the error or warning messages outputted to the screen

    11 juillet 2023, par Amphagory

    I was wondering if there was a way to suppress, hide or disable the error or warning messages outputted to the screen from OpenCV, I think originating from cap.read() ?

    



    I think they come from OpenCV using FFMpeg and they either show up as follows :

    



    CASE 1 :

    



    [mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.
[mpeg2video @ 0x3430c00] Invalid frame dimensions 0x0.


    



    or

    



    CASE 2 :

    



    ...
[h264 @ 0x29e5a40] co located POCs unavailable
[h264 @ 0x2a6c3c0] co located POCs unavailable
[h264 @ 0x29d7b80] reference picture missing during reorder
[h264 @ 0x29d7b80] Missing reference picture, default is 65656
[h264 @ 0x298da80] mmco: unref short failure
[h264 @ 0x298da80] number of reference frames (0+6) exceeds max (5; probably corrupt input), discarding one
[h264 @ 0x29dc700] reference picture missing during reorder
[h264 @ 0x29dc700] Missing reference picture, default is 65672
[h264 @ 0x2a27180] mmco: unref short failure
[h264 @ 0x2af7680] co located POCs unavailable
[h264 @ 0x29e5a40] mmco: unref short failure
[h264 @ 0x29e5a40] number of reference frames (0+6) exceeds max (5; probably corrupt input), discarding one
[h264 @ 0x2af9040] mmco: unref short failure


    



    To my understanding CASE 1, is a known issue, as it is looking for a PES header. There are only a few of these messages until it finds the header.

    



    I do not understand CASE 2, I do not know what is happening, but it seems to read the image @ frame. There are many many of these messages which outputs to the console window and adds minutes to the processing time.

    


  • avcodec/nvdec : don't add thread buffer twice

    12 novembre 2017, par Timo Rothenpieler
    avcodec/nvdec : don't add thread buffer twice

    This is already added to the initial pool size in ff_decode_get_hw_frames_ctx,
    
so adding it here again increases the amount of surfaces needlessly.
    • [DH] libavcodec/nvdec.c

Navigation