Recherche avancée

Médias (0)

Mot : - Tags -/metadatas

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (111)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

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

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

Sur d’autres sites (8211)

  • ARM compiler shoot-out, round 2

    http://samples.ffmpeg.org/V-codecs/h264/cathedral-beta2-400extra-crop-avc.mp4 http://samples.ffmpeg.org/V-codecs/h264/NeroAVC.mp4 http://samples.ffmpeg.org/V-codecs/h264/indiana_jones_4-tlr3_h640w.mov http://samples.ffmpeg.org/MPEG-4/NeroRecodeSample-MP4/NeroRecodeSample.mp4 http://samples.ffmpeg.org/A-codecs/MP3/Silent_Light.mp3 http://samples.ffmpeg.org/A-codecs/vorbis/Lumme-Badloop.ogg
    20 août 2009, par Mans — ARM, Compilers

    In my recent test of ARM compilers, I had to leave out Texas Instrument’s compiler since it failed to build FFmpeg. Since then, the TI compiler team has been busy fixing bugs, and a snapshot I was given to test was able to build enough of a somewhat patched FFmpeg that I can now present round two in this shoot-out.

    The contenders this time were the fastest GCC variant from round one, ARM RVCT, and newcomer TI TMS470. With the same rules as last time, the exact versions and optimisation options were like this :

    • CodeSourcery GCC 2009q1 (based on 4.3.3), -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a8 -std=c99 -fomit-frame-pointer -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize
    • ARM RVCT 4.0 Build 591, -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a8 -std=c99 -fomit-frame-pointer -O3 -fno-math-errno -fno-signed-zeros
    • TI TMS470 4.7.0-a9229, --float_support=vfpv3 -mv=7a8 -O3 -mf=5


    To keep things fair, I left the vectoriser off also with the TI compiler. The table below lists the decoding times for the sample files, this time normalised against the participating GCC compiler. Remember, smaller numbers are better. Also keep in mind that this test was done with a development snapshot of TMS470, not an approved release.

    Sample name Codec Code type GCC RVCT TI
    cathedral H.264 CABAC integer 1.00 0.95 1.02
    NeroAVC H.264 CABAC integer 1.00 0.96 1.05
    indiana_jones_4 H.264 CAVLC integer 1.00 0.92 1.02
    NeroRecodeSample MPEG-4 ASP integer 1.00 1.01 1.08
    Silent_Light MP3 64-bit integer 1.00 0.48 0.72
    When_I_Grow_Up FLAC integer 1.00 0.87 0.93
    Lumme-Badloop Vorbis float 1.00 0.94 1.05
    Canyon AC-3 float 1.00 0.88 1.01
    lotr DTS float 1.00 1.00 1.08

    Overall, the TI TMS470 compiler comes off slightly worse than GCC. In two cases, however, it was significantly better than GCC, but not as good as RVCT. Incidentally, those were also the ones where RVCT scored the biggest win over GCC.

    My conclusions from this test are twofold :

    • ARM’s own compiler is very hard to beat. They do seem to know how their chips work.
    • GCC is incredibly bad at 64-bit arithmetic on 32-bit machines.

    The logical next step is to test these compilers with vectorisation enabled. FFmpeg should offer plenty of opportunities for this feature to shine. Unfortunately, that test will have to wait until the RVCT vectoriser is fixed. The current release does not compile FFmpeg with vectorisation enabled.

  • dnn_backend_native_layer_mathunary : add round support

    10 août 2020, par Mingyu Yin
    dnn_backend_native_layer_mathunary : add round support

    Signed-off-by : Mingyu Yin <mingyu.yin@intel.com>
    
Reviewed-by : Guo, Yejun <yejun.guo@intel.com>
    • [DH] libavfilter/dnn/dnn_backend_native_layer_mathunary.c
    • [DH] libavfilter/dnn/dnn_backend_native_layer_mathunary.h
    • [DH] tests/dnn/dnn-layer-mathunary-test.c
    • [DH] tools/python/convert_from_tensorflow.py
    • [DH] tools/python/convert_header.py

  • avcodec/h264_slice : compute and export film grain seed

    17 août 2021, par Niklas Haas
    avcodec/h264_slice : compute and export film grain seed

    From SMPTE RDD 5-2006, the grain seed is to be computed from the
    
following definition of `pic_offset` :
    

    > When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
    
> follows :
    
>   - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
    
> where :
    
>   - PicOrderCnt(CurrPic) is the picture order count of the current frame,
    
>     which shall be derived from [the video stream].
    
>
    
>   - PicOrderCnt_offset is set to idr_pic_id on IDR frames. idr_pic_id
    
>     shall be read from the slice header of [the video stream]. On non-IDR I
    
>     frames, PicOrderCnt_offset is set to 0. A frame shall be classified as I
    
>     frame when all its slices are I slices, which may be optionally
    
>     designated by setting primary_pic_type to 0 in the access delimiter NAL
    
>     unit. Otherwise, PicOrderCnt_offset it not changed. PicOrderCnt_offset is
    
>     updated in decoding order.
    

    Co-authored-by : James Almer <jamrial@gmail.com>
    
Signed-off-by : Niklas Haas <git@haasn.dev>
    
Signed-off-by : James Almer <jamrial@gmail.com>
    • [DH] libavcodec/h264_slice.c
    • [DH] libavcodec/h264dec.c
    • [DH] libavcodec/h264dec.h
    • [DH] libavutil/film_grain_params.h

Navigation