Recherche avancée

Médias (1)

Mot : - Tags -/MediaSPIP 0.2

Autres articles (38)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • Menus personnalisés

    14 novembre 2010, par

    MediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
    Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
    Menus créés à l’initialisation du site
    Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...)

  • Gestion des droits de création et d’édition des objets

    8 février 2011, par

    Par défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;

Sur d’autres sites (6484)

  • arm : Consistently use proper interworking function returns

    3 octobre 2024, par Martin Storsjö
    arm : Consistently use proper interworking function returns
    

    Use "bx lr", or "pop lr", which do proper mode switching
    between thumb and arm modes. A plain "mov pc, lr" does not switch
    from thumb mode to arm mode (while in arm mode, it does switch
    mode for a thumb caller).

    This is normally not an issue, as CONFIG_THUMB only is enabled if
    the C compiler defaults to thumb ; but stick to patterns that can
    do mode switching if needed, for consistency.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] libswresample/arm/resample.S
    • [DH] libswscale/arm/hscale.S
    • [DH] libswscale/arm/output.S
    • [DH] libswscale/arm/yuv2rgb_neon.S
  • Using ffmpeg avcodec_decode_video2 got_picture_ptr returns 0

    3 septembre 2014, par kaiken

    I’m trying to playback the gopro live feed which consists of a series of very short .ts files encoded using H264. I tested it on videos with different containers (mkv,avi,mp4) and different codecs (MPEG4, H264, MSVIDEO1). However, the files from the gopro always returns got_picture_ptr as 0 from avcodec_decode_video2 while the function returns the packet’s size. If I use ffplay or vlc it play the file without problem. I’m not sure what I’m doing wrong. I’m not very experienced with ffmpeg or video in general.

    Here is my test code. I based it off of this tutorial which is out of date but I was able to update the depreciated functions.

    AVFormatContext *pFormatCtx = NULL;
    AVCodecContext *pCodecCtx;
    AVStream *pStream = NULL;
    int videoStream;
    AVCodec *pCodec;
    AVFrame *pFrame=NULL, *pFrameRGB=NULL;
    HBITMAP membmp;
    int widht,height;
    BYTE *membits;
    int frameFinished;
    AVPacket packet;
    img_convert_ctx = NULL;
    uint8_t *buffer;
    int numBytes;

    // Open video file
    if(avformat_open_input(&amp;pFormatCtx,params->fname,NULL,NULL)!=0)
      return -1;
    // Retrieve stream information
    if(avformat_find_stream_info(pFormatCtx,NULL)&lt;0)
      return -1;
    //av_dump_format(pFormatCtx, 0, path, 0);

    // Find the first video stream
    for(int i=0; inb_streams; i++)
      if(pFormatCtx->streams[i]->codec->codec_type==AVMEDIA_TYPE_VIDEO)
      {
         pStream=pFormatCtx->streams[i];
         videoStream = i;
         break;
      }
    if(pStream==NULL)
      return -1; // Didn't find a video stream

    // Get a pointer to the codec context for the video stream
    pCodecCtx=pStream->codec;

    // Find the decoder for the video stream
    pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
    if(pCodec==NULL) {
      fprintf(stderr, "Unsupported codec!\n");
      return -1; // Codec not found
    }

    // Open codec
    if(avcodec_open2(pCodecCtx, pCodec, NULL)&lt;0)
      return -1;

    // Allocate an AVFrame structure
    pFrame=avcodec_alloc_frame();
    pFrameRGB=avcodec_alloc_frame();
    if(pFrameRGB==NULL)
      return -1;

    MakeBitmap(*params->memdc,membmp,(void**)&amp;membits,pCodecCtx->width,pCodecCtx->height);
    // Assign appropriate parts of buffer to image planes in pFrameRGB
    // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
    // of AVPicture
    avpicture_fill((AVPicture *)pFrameRGB, membits, PIX_FMT_RGB24,
                  pCodecCtx->width, pCodecCtx->height);

    while (av_read_frame(pFormatCtx, &amp;packet) >= 0)
    {
       // Is this a packet from the video stream?
       if (packet.stream_index == videoStream)
       {
           // Decode video frame
           int bytesUsed = avcodec_decode_video2(pCodecCtx, pFrame, &amp;frameFinished, &amp;packet);
           // Did we get a video frame?
           if(frameFinished)
           {
              //Do stuff with frame
           }
       }
       // Free the packet that was allocated by av_read_frame
       av_free_packet(&amp;packet);
       //if(i++>500)
       //   break;
    }
    DeleteObject(membmp);


    // Free the frames
    av_free(pFrameRGB);
    av_free(pFrame);
    // Close the codec
    avcodec_close(pCodecCtx);
    // Close the video file
    avformat_close_input(&amp;pFormatCtx);

    return  -1;

    For reference I’m doing this on Windows with the versions of the dlls :

    • avcodec-56.dll
    • avdevice-56.dll
    • avfilter-5.dll
    • avformat-56.dll
    • avutil-54.dll
    • postproc-53.dll
    • swresample-1.dll
    • swscale-3.dll

    and sample video file https://www.dropbox.com/s/htlinnv3qk5dfiu/amba_hls-2.ts?dl=0

  • lavd/v4l2 : do not fail when VIDIOC_ENUMSTD returns ENODATA

    18 août 2014, par Andre Wolokita
    lavd/v4l2 : do not fail when VIDIOC_ENUMSTD returns ENODATA
    

    As of September 14 2012, v4l_enumstd() will return ENODATA
    when a device’s std field is set to 0. That is, the device
    does not have a standard format. In order to properly
    handle this case, v4l2_set_parameters should catch the
    ENODATA code and break instead of failing.

    Below is the v4l2-core commit describing this change.

    >>commit a5338190efc7cfa8c99a6856342a77d21c9a05cf
    >>Author : Hans Verkuil <hans.verkuil@cisco.com>
    >>Date : Fri Sep 14 06:45:43 2012 -0300
    >>
    >> [media] v4l2-core : tvnorms may be 0 for a given input, handle that case
    >>
    >> Currently the core code looks at tvnorms to see whether ENUMSTD
    >> or G_PARM should be enabled. This is not a good check for drivers
    >> that support the STD API on one input and the DV Timings API on another.
    >> In that case tvnorms may be 0.
    >> Instead check whether s_std is present (for ENUMSTD) or whether g_std or
    >> current_norm is present for g_parm.
    >> Also, in the enumstd core function return ENODATA if tvnorms is 0,
    >> because in that case the current input does not support the STD API
    >> and ENUMSTD should return ENODATA for that.
    >>
    >> Signed-off-by : Hans Verkuil <hans.verkuil@cisco.com>
    >> Reviewed-by : Sakari Ailus <sakari.ailus@iki.fi>
    >> Signed-off-by : Mauro Carvalho Chehab <mchehab@redhat.com>

    • [DH] libavdevice/v4l2.c