Recherche avancée

Médias (91)

Autres articles (16)

  • La file d’attente de SPIPmotion

    28 novembre 2010, par

    Une file d’attente stockée dans la base de donnée
    Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
    Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...)

  • Contribute to documentation

    13 avril 2011

    Documentation is vital to the development of improved technical capabilities.
    MediaSPIP welcomes documentation by users as well as developers - including : critique of existing features and functions articles contributed by developers, administrators, content producers and editors screenshots to illustrate the above translations of existing documentation into other languages
    To contribute, register to the project users’ mailing (...)

  • Selection of projects using MediaSPIP

    2 mai 2011, par

    The examples below are representative elements of MediaSPIP specific uses for specific projects.
    MediaSPIP farm @ Infini
    The non profit organizationInfini develops hospitality activities, internet access point, training, realizing innovative projects in the field of information and communication technologies and Communication, and hosting of websites. It plays a unique and prominent role in the Brest (France) area, at the national level, among the half-dozen such association. Its members (...)

Sur d’autres sites (2781)

  • FFmpeg av_hwdevice_ctx_create returns ENOMEM

    4 mars 2021, par lnogueir

    I am trying to perform h264 video encoding on a GPU using the ffmpeg's vaapi library.

    


    I have been following this example from ffmpeg Github repo.

    


    It fails for me here :

    


    AVBufferRef* vaapi_encoder;
int err = av_hwdevice_ctx_create(&vaapi_encoder, AV_HWDEVICE_TYPE_VAAPI,
                                 NULL, NULL, 0);


    


    This returns -12, which maps to ENOMEM (out of memory) error, but that doesn't make sense to me because I have plenty of memory.

    


    For reference, this is my output after running 'vainfo' :

    


    libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 ()
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD


    


    Thanks !

    


  • hwcontext_vaapi : remove duplicate formats from sw_format list

    24 juillet 2020, par Haihao Xiang
    hwcontext_vaapi : remove duplicate formats from sw_format list

    hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
    
plane swap cases, however duplicate formats are not expected in sw_format
    
list when merging formats.
    

    For example :
    
ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \

    - f lavfi -i smptebars -vf \
    
"hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \

    - vframes 1 -f null -
    

    Without this fix, an auto scaler is required for the above command
    
   Duplicate formats in ff_merge_formats detected
    
   [auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic'
    
   [auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags :'bicubic' interl:0
    
   [Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter
    
   'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
    
   the filter 'Parsed_hwupload_0'
    

    Signed-off-by : Haihao Xiang <haihao.xiang@intel.com>
    • [DH] libavutil/hwcontext_vaapi.c

  • sws/rgb2rgb : fix unaligned accesses in R-V V YUYV to I422p

    9 novembre 2023, par Rémi Denis-Courmont
    sws/rgb2rgb : fix unaligned accesses in R-V V YUYV to I422p

    In my personal opinion, we should not need to support unaligned YUY2
    
pixel maps. They should always be aligned to at least 32 bits, and the
    
current code assumes just 16 bits. However checkasm does test for
    
unaligned input bitmaps. QEMU accepts it, but real hardware dose not.
    

    In this particular case, we can at the same time improve performance and
    
handle unaligned inputs, so do just that.
    

    uyvytoyuv422_c :      104379.0
    
uyvytoyuv422_c :      104060.0
    
uyvytoyuv422_rvv_i32 : 25284.0 (before)
    
uyvytoyuv422_rvv_i32 : 19303.2 (after)
    • [DH] libswscale/riscv/rgb2rgb.c
    • [DH] libswscale/riscv/rgb2rgb_rvv.S

Navigation