Recherche avancée

Médias (91)

Autres articles (97)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

Sur d’autres sites (7983)

  • Dreamcast Track Sizes

    1er mars 2015, par Multimedia Mike — Sega Dreamcast

    I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

    You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

    The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :


    Dreamcast Track Sizes

    Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

    I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

    One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

  • ffmpeg / libav encoding 264 from YUV420P [on hold]

    4 janvier 2017, par MrSmith

    I am having issues getting this thing to encode correctly. Either I get the container wrong or the content it seems.
    This code encodes a file just fine, but viewing it with VLC or Totem will just yield the first picture, not the remaining 100 frames.
    This is a step up from before as I dont get warnings that my container (mp4) is borked, however now the video wont play at all.. at least it played before :).

    If someone could put a finger somewhere on this code and call me a dumbass, that would be nice :)

    void encode_video(char *carrarr[]){
    av_log_set_level(AV_LOG_DEBUG);
    av_register_all();
    avcodec_register_all();
    AVCodec *codec = avcodec_find_encoder(AV_CODEC_ID_H264);
    AVOutputFormat * outputFormat = av_guess_format("mp4", NULL, NULL);

    int test = avformat_alloc_output_context2(&outFmtCtx, outputFormat, NULL, NULL);
    if(test<0) exit(-1);

    AVStream * outStrm = avformat_new_stream(outFmtCtx, codec);
    avcodec_get_context_defaults3(outStrm->codec, codec);

    outStrm->codec->codec_id = AV_CODEC_ID_H264;
    outStrm->codec->coder_type = AVMEDIA_TYPE_VIDEO;

    outStrm->codec->bit_rate = 400000;
    outStrm->codec->width = 320;
    outStrm->codec->height = 240;
    outStrm->codec->time_base= (AVRational){1,25};
    outStrm->time_base=(AVRational){1,25};
    outStrm->codec->gop_size = 10; // emit one intra frame every ten frames
    outStrm->codec->max_b_frames=1;
    outStrm->codec->pix_fmt = AV_PIX_FMT_YUV420P;
    outStrm->codec->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
    // FOR H264 ONLY
    test = av_opt_set(outStrm->codec->priv_data, "preset", "slow", 0);
    if(test<0) exit(-2);
    test = avcodec_open2(outStrm->codec, codec, NULL);
    if(test<0) exit(-3);
    test = avio_open2(&outFmtCtx->pb, "myoutputfile.avi", AVIO_FLAG_WRITE, NULL, NULL);
    if(test<0) exit(-4);

    test = avformat_write_header(outFmtCtx, NULL);
    if(test<0) exit(-5);
    AVFrame * frame = avcodec_alloc_frame();
    if (!frame) exit(-6);

    frame->format = outStrm->codec->pix_fmt;
    frame->width  = outStrm->codec->width;
    frame->height = outStrm->codec->height;

    ret = av_image_alloc(frame->data, frame->linesize, frame->width, frame->height, outStrm->codec->pix_fmt, 32);
    if (ret < 0) exit(-7);

    av_init_packet(&pkt);
    pkt.data = NULL;
    pkt.size = 0;

    int yrange = 240*320;
    int vrange = 240*320*0.25;

    for(int i=0;i<100;i++){
       char *carr = carrarr[i];

       char* Y = carr;
       char* U = carr+yrange;
       char* V = carr+yrange+vrange;
       frame->data[0] = (uint8_t*)Y;
       frame->data[1] = (uint8_t*)U;
       frame->data[2] = (uint8_t*)V;
       frame->pts = i;

       ret = avcodec_encode_video2(outStrm->codec, &pkt, frame, &got_output);
       if (ret < 0) {
           fprintf(stderr, "Error encoding frame\n");
           exit (EXIT_FAILURE);
       }
       if (got_output) {
           printf("Write frame %3d (size=%5d)\n", i, pkt.size);
           //fwrite(pkt.data, 1, pkt.size, file_encoded_video);
           av_interleaved_write_frame(outFmtCtx, &pkt);
           av_free_packet(&pkt);
       }
    }
    av_write_trailer(outFmtCtx);
    avio_close(outFmtCtx->pb);
    }

    carrarr is holding 100 frames of nice valid YUV420P data, I know this cause I’ve encoded it before AND I can output it to screen with SDL.

    Any ideas welcome. Thanks !

  • avformat/mov : Increase support for common encryption.

    7 décembre 2017, par Jacob Trimble
    avformat/mov : Increase support for common encryption.
    

    - Parse schm atom to get different encryption schemes.
    - Allow senc atom to appear in track fragments.
    - Allow 16-byte IVs.
    - Allow constant IVs (specified in tenc).
    - Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
    - Use sample descriptor to detect clear fragments.

    This doesn't support :
    - Different sample descriptor holding different encryption info.
    - Only first sample descriptor can be encrypted.
    - Encrypted sample groups (i.e. seig).
    - Non-'cenc' encryption scheme when using -decryption_key.

    Signed-off-by : Jacob Trimble <modmaker@google.com>
    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>

    • [DH] libavformat/isom.h
    • [DH] libavformat/mov.c
    • [DH] libavutil/encryption_info.h
    • [DH] tests/fate/mov.mak
    • [DH] tests/ref/fate/mov-frag-encrypted
    • [DH] tests/ref/fate/mov-tenc-only-encrypted