Recherche avancée

Médias (91)

Autres articles (30)

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

  • Les formats acceptés

    28 janvier 2010, par

    Les commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
    ffmpeg -codecs ffmpeg -formats
    Les format videos acceptés en entrée
    Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
    Les formats vidéos de sortie possibles
    Dans un premier temps on (...)

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

Sur d’autres sites (4150)

  • dump_extra : Don't add extradata if it already exists

    13 juillet 2019, par Andreas Rheinhardt
    dump_extra : Don't add extradata if it already exists

    The dump_extra bitstream filter currently simply adds the extradata to
    
the packets indicated by the user without checking whether said
    
extradata already exists in the packets. Besides wasting space
    
duplicated extradata in the same packet/access unit is also forbidden
    
for some codecs, e.g. MPEG-2.
    

    This check has been added to be able to use the mpeg2_qsv encoder (which
    
only adds the sequence headers to the first packet) in broadcast
    
scenarios where repeating sequence headers are required.
    

    The check used here is not perfect : E.g. dump_extra would add the
    
extradata to a H.264 access unit consisting of an access unit delimiter,
    
SPS, PPS and slices.
    

    Fixes #8007.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] doc/bitstream_filters.texi
    • [DH] libavcodec/dump_extradata_bsf.c

  • how to use the pts in fffmpeg

    1er décembre 2016, par Allan

    I have a library with can provide video data and PTS. The library head file Like this：

     /**
    
 * \brief           Write mirror video H.264 frame to player.
    
 * \param p_src     Pointer to source buffer.
    
 * \param size      H.264 frame size. (unit: byte)
    
 * \param ptsValue  PTS value.
    
 * \return          Copied size. (unit: byte)
    
 */
    
int (*WriteMirrorVideoData)(const std::string&amp; ip, const void *p_src, int size, double ptsValue);

    As you see, the library give me video frame buffer address and PTS.

    I use FFMpeg to decode video data correctly.

    My question is how to control the display time by ptsValue which provided by library.

    Did I need to set the ptsValue to AVFrame ? then FFMPeg can control the display time itself.
    Or I need to control the display by my own code ?

    I am a newer to FFMpeg. please help me. Thank you very much !

  • lavc/vvc : Store MIP information over entire CU area

    28 novembre 2024, par Frank Plowman
    lavc/vvc : Store MIP information over entire CU area

    Previously, the code only stored the MIP mode and transpose flag in the
    
relevant tables at the top-left corner of the CU.  This information ends
    
up being retrieved in ff_vvc_intra_pred_* not based on the CU position
    
but instead the transform unit position (specifically, using the x0 and
    
y0 from get_luma_predict_unit).  There might be multiple transform units
    
in a CU, hence the top-left corner of the transform unit might not
    
coincide with the top-left corner of the CU.  Consequently, we need to
    
store the MIP information at all positions in the CU, not only its
    
top-left corner, as we already do for the MIP flag.
    

    Signed-off-by : Frank Plowman <post@frankplowman.com>
    • [DH] libavcodec/vvc/ctu.c

Navigation