Recherche avancée

Médias (1)

Mot : - Tags -/net art

Autres articles (37)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Soumettre améliorations et plugins supplémentaires

    10 avril 2011

    Si vous avez développé une nouvelle extension permettant d’ajouter une ou plusieurs fonctionnalités utiles à MediaSPIP, faites le nous savoir et son intégration dans la distribution officielle sera envisagée.
    Vous pouvez utiliser la liste de discussion de développement afin de le faire savoir ou demander de l’aide quant à la réalisation de ce plugin. MediaSPIP étant basé sur SPIP, il est également possible d’utiliser le liste de discussion SPIP-zone de SPIP pour (...)

Sur d’autres sites (7328)

  • avcodec/vulkan_decode : Factor creating session params out, fix leak

    14 septembre 2023, par Andreas Rheinhardt
    avcodec/vulkan_decode : Factor creating session params out, fix leak

    All Vulkan HWAccels share the same boilerplate code for creating
    
session params and this includes a common bug : In case actually
    
creating the video session parameters fails, the buffer destined
    
to hold them leaks ; in case of HEVC this is also true if
    
get_data_set_buf() fails.
    

    This commit factors this code out and fixes the leak.
    

    Reviewed-by : Lynne <dev@lynne.ee>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/vulkan_av1.c
    • [DH] libavcodec/vulkan_decode.c
    • [DH] libavcodec/vulkan_decode.h
    • [DH] libavcodec/vulkan_h264.c
    • [DH] libavcodec/vulkan_hevc.c

  • lavf/flvdec : replace a private option with a field in FFFormatContext

    13 octobre 2024, par Anton Khirnov
    lavf/flvdec : replace a private option with a field in FFFormatContext

    The demuxer's 'missing_streams' private option is used to communicate
    
information from the demuxer to avformat_find_stream_info(). However,
    
that is not only unnecessarily complicated, it also leaks internal
    
information to users, e.g. this option appears in the results of the
    
fate-flv-demux test.
    

    Use a new field in FFFormatContext to communicate this information
    
instead.
    • [DH] libavformat/demux.c
    • [DH] libavformat/flvdec.c
    • [DH] libavformat/internal.h
    • [DH] tests/ref/fate/flv-demux

  • avformat/matroskaenc : Remove allocations for Attachments

    29 décembre 2019, par Andreas Rheinhardt
    avformat/matroskaenc : Remove allocations for Attachments

    If there are Attachments to write, the Matroska muxer currently
    
allocates two objects : An array that contains an entry for each
    
AttachedFile containing just the stream index of the corresponding
    
stream and the FileUID used for this AttachedFile ; and a structure with
    
a pointer to said array and a counter for said array. These uids are
    
generated via code special to Attachments : It uses an AVLFG in the
    
normal and a sha of the attachment data in the bitexact case. (Said sha
    
requires an allocation, too.)
    

    But now that an uid is generated for each stream in mkv_init(), there is
    
no need any more to use special code for generating the FileUIDs of
    
AttachedFiles : One can simply use the uid already generated for the
    
corresponding stream. And this makes the whole allocations of the
    
structures for AttachedFiles as well as the structures itself superfluous.
    
They have been removed.
    

    In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
    
old ones which is the reason why the FATE-test lavf-mkv_attachment
    
needed to be updated. The old method had the drawback that two
    
AttachedFiles with the same data would have the same FileUID.
    
The new one doesn't.
    

    Also notice that the dynamic buffer used to write the Attachments leaks
    
if an error happens when writing the buffer. By removing the
    
allocations potential sources of errors have been removed.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    • [DH] libavformat/matroskaenc.c
    • [DH] tests/ref/lavf/mkv_attachment

Navigation