Recherche avancée

Médias (91)

Autres articles (25)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Création définitive du canal

    12 mars 2010, par

    Lorsque votre demande est validée, vous pouvez alors procéder à la création proprement dite du canal. Chaque canal est un site à part entière placé sous votre responsabilité. Les administrateurs de la plateforme n’y ont aucun accès.
    A la validation, vous recevez un email vous invitant donc à créer votre canal.
    Pour ce faire il vous suffit de vous rendre à son adresse, dans notre exemple "http://votre_sous_domaine.mediaspip.net".
    A ce moment là un mot de passe vous est demandé, il vous suffit d’y (...)

  • MediaSPIP Init et Diogène : types de publications de MediaSPIP

    11 novembre 2010, par

    À l’installation d’un site MediaSPIP, le plugin MediaSPIP Init réalise certaines opérations dont la principale consiste à créer quatre rubriques principales dans le site et de créer cinq templates de formulaire pour Diogène.
    Ces quatre rubriques principales (aussi appelées secteurs) sont : Medias ; Sites ; Editos ; Actualités ;
    Pour chacune de ces rubriques est créé un template de formulaire spécifique éponyme. Pour la rubrique "Medias" un second template "catégorie" est créé permettant d’ajouter (...)

Sur d’autres sites (5221)

  • Anomalie #3920 (Nouveau) : sur Sauvegarde SQLite (SPIP 3.1.3 et 3.1.4 mini)

    11 mars 2017, par YannX DYX

    En SPIP 3 la sauvegarde standard pose parfois des problèmes, que j’ai trop souvent vus...
    Cette fois j’ai investigué sur un SPIP 3.1.4 OVH (avec prefix spécifique), toutes les tables ne sont pas sauvegardées, au contraire de la sauvegarde SQL : certes un message existe mais !
    - d’une part des tables vides ou non déclarées dans un plugin activé sont omises : pourquoi ?
    (encore une fois au contraire de la sauvegarde SQL encore disponible en plugin !)
    => est-il possible d’apporter un lien vers une aide plus détaillée, explicitant les causes possibles ?
    (cf. http://forum.spip.net/fr_262960.html & http://forum.spip.net/fr_266342.html par exemple).
    - le long libellé affiché <:dump:texte_sauvegarde:> ne signale aucunement ces aspects et indications ; le lien vers http://www.spip.net/fr_article1489.html est-il encore pertinent (je n’ai jamais tenté une restauration d’une autre version SQLite : comment se passerait une table non déclarée ou non connue dans le SPIP cible ? ) ?
    - d’autre part la lecture du message en fin des erreurs est peu explicite à la lecture (cf. ci-dessous),
    il me semblerait plus significatif d’afficher : Nombre de tables non sauvegardées : 12/58
    - d’ailleurs l’affichage est incorrect, car il n’indique pas le bon préfixe (en cas de préfixe non-standard !!)
    (et de ce fait, je vais avouer avoir jusqu’à présent négligé ces erreurs incomprises, et... patatras !)
    _ S’il est intéressant de faire une sauvegarde dé-préfixée (ce que j’ai parfois trouvé utile), peut-etre serait-il intéressant de faire apparaitre (dans un commentaire ou une meta) le préfixe d’origine, à titre de documentation !

    En recherchant de la documentation, je n’ai trouvé que http://www.spip.net/fr_article3418.html qui mériterait peut-etre d’etre complété avec les informations/explications ci-dessus (et leurs conséquences)...

    En complément, le site exemple ayant été migré d’anciennes versions SPIP 2, montre encore les anciennes tables@ spip_mots_xx@
    je ne me souviens pas d’un plugin qui éliminerait ces anciennes tables résiduelles (pour ceux qui ne savent utiliser phpMyAdmin ou Adminer)... ce qui supprimerait ensuite ces erreurs / voir par exemple sur les forums SPIP)

  • Evolution #4080 : Raccourci puce : se débarasser de l’image

    1er octobre 2018

    Je vote pour le caractère
    https://unicode-table.com/fr/2023/

    Voici un test chez moi en local sur SPIP 3.2, la dist et Firefox Windows (bref 100% vanille)

  • FFmpeg - MJPEG decoding - getting different values

    27 décembre 2016, par ahmadh

    I have a set of JPEG frames which I am muxing into an avi, which gives me a mjpeg video. This is the command I run on the console :

    ffmpeg -y -start_number 0 -i %06d.JPEG -codec copy vid.avi

    When I try to demux the video using ffmpeg C api, I get frames which are slightly different in values. Demuxing code looks something like this :

    AVFormatContext* fmt_ctx = NULL;
    AVCodecContext* cdc_ctx = NULL;
    AVCodec* vid_cdc = NULL;
    int ret;
    unsigned int height, width;

    ....
    // read_nframes is the number of frames to read
    output_arr = new unsigned char [height * width * 3 *
                                   sizeof(unsigned char) * read_nframes];

    avcodec_open2(cdc_ctx, vid_cdc, NULL);

    int num_bytes;
    uint8_t* buffer = NULL;
    const AVPixelFormat out_format = AV_PIX_FMT_RGB24;

    num_bytes = av_image_get_buffer_size(out_format, width, height, 1);
    buffer = (uint8_t*)av_malloc(num_bytes * sizeof(uint8_t));

    AVFrame* vid_frame = NULL;
    vid_frame = av_frame_alloc();
    AVFrame* conv_frame = NULL;
    conv_frame = av_frame_alloc();

    av_image_fill_arrays(conv_frame->data, conv_frame->linesize, buffer,
                        out_format, width, height, 1);

    struct SwsContext *sws_ctx = NULL;
    sws_ctx = sws_getContext(width, height, cdc_ctx->pix_fmt,
                            width, height, out_format,
                            SWS_BILINEAR, NULL,NULL,NULL);

    int frame_num = 0;
    AVPacket vid_pckt;
    while (av_read_frame(fmt_ctx, &vid_pckt) >=0) {
       ret = avcodec_send_packet(cdc_ctx, &vid_pckt);
       if (ret < 0)
           break;

       ret = avcodec_receive_frame(cdc_ctx, vid_frame);
       if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
           break;
       if (ret >= 0) {
           // convert image from native format to planar GBR
           sws_scale(sws_ctx, vid_frame->data,
                     vid_frame->linesize, 0, vid_frame->height,
                     conv_frame->data, conv_frame->linesize);

           unsigned char* r_ptr = output_arr +
               (height * width * sizeof(unsigned char) * 3 * frame_num);
           unsigned char* g_ptr = r_ptr + (height * width * sizeof(unsigned char));
           unsigned char* b_ptr = g_ptr + (height * width * sizeof(unsigned char));
           unsigned int pxl_i = 0;

           for (unsigned int r = 0; r < height; ++r) {
               uint8_t* avframe_r = conv_frame->data[0] + r*conv_frame->linesize[0];
               for (unsigned int c = 0; c < width; ++c) {
                   r_ptr[pxl_i] = avframe_r[0];
                   g_ptr[pxl_i]   = avframe_r[1];
                   b_ptr[pxl_i]   = avframe_r[2];
                   avframe_r += 3;
                   ++pxl_i;
               }
           }

           ++frame_num;

           if (frame_num >= read_nframes)
               break;
       }
    }

    ...

    In my experience around two-thirds of the pixel values are different, each by +-1 (in a range of [0,255]). I am wondering is it due to some decoding scheme FFmpeg uses for reading JPEG frames ? I tried encoding and decoding png frames, and it works perfectly fine.

    In short my goal is to get the same pixel by pixel values for each JPEG frame as I would I have gotten if I was reading the JPEG images directly. Here is the stand-alone code I used. It includes cmake files to build code, and a couple of jpeg frames with the converted avi file to test this problem. (give —filetype png to test the png decoding).