Recherche avancée

Médias (0)

Mot : - Tags -/performance

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

Autres articles (40)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 is the first MediaSPIP stable release.
    Its official release date is June 21, 2013 and is announced here.
    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 (...)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

Sur d’autres sites (6819)

  • Repairing corrupt MOV file

    28 août 2016, par Simon Ridley

    I’m attempting to recover / repair MOV files from a formatted SD card. In the first instance I’ve made a copy of the physical disk using the unix command-line utility "DD". Once that completed I’ve used a working MOV file from the same recording device as a reference file to manually extract the required files using a Hex editor and Python.

    I have attempted to use other recovery tools such as Photorec, and X-Ways, however the extractions appear damaged. This is why I’m using a Hex editor to manually inspect the data to determine what is damaged.

    The software FFMPEG is reporting "moov atom not found" when attempting to process the damaged MOV file.

    When the file is examined in a hex editor I can clearly see that the header appears intact. Offsets 4 to 10 show the ’ftypqt’ signature, then offsets 17 and 16 display ’qt’ and finally the ’mdat’ identifier is at offsets 36 to 39. This is identical to the reference file I have. The mdat container doesn’t appear to finish until ’moov’ which is found at offset 733093392 followed by ’lmvhd’.

    This all appears in the reference file too and as far as I can tell all seems intact. am I correct in thinking that the mdat data is broken in chunks, this is possibly what is referred to as atoms ?

    In which case I appreciate that the data could be damaged somewhere within the mdat. Is it possible to extract the raw data out and rebuild the container ? I’m happy to attempt this with python but I need to understand the structure of the file in more detail. Can anyone help with this please ?

  • ffmpeg sws_scale converting from YUV420P to RGB24 results in wrong color values

    3 novembre 2016, par Drazurh

    I’m using sws_scale to convert a video from YUV420P to RGB24. The resulting RGB values are wrong, looking much more saturated/contrasted. For example, the first pixel should have an RGB value of (223,73,30) but using sws_scale results in (153,0,0).

    Here’s the code I’m using :

    uint8_t *buffer = NULL;
    int numBytes;
    // Determine required buffer size and allocate buffer
    numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
                              pCodecCtx->height);
    buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));

    // Assign appropriate parts of buffer to image planes in pFrameRGB
    // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
    // of AVPicture
    std::cout << "Filling picture of size " << pCodecCtx->width <<" x "<height << std::endl;
    avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
                   pCodecCtx->width, pCodecCtx->height);



    // initialize SWS context for software scaling
    std::cout << "initializing SWS context\n";
    sws_ctx = sws_getContext(pCodecCtx->width,
       pCodecCtx->height,
       pCodecCtx->pix_fmt,
       pCodecCtx->width,
       pCodecCtx->height,
       PIX_FMT_RGB24,
       SWS_FAST_BILINEAR,
       NULL,
       NULL,
       NULL
    );

    while(frameFinished == 0)
    {
       if(av_read_frame(pFormatCtx, &packet)<0){
           std::cerr << "Could not read frame!\n";
           return false;
       }

       if(packet.stream_index==videoStream)
       {
           avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
       }

    }

    sws_scale(sws_ctx, (uint8_t const * const *)pFrame->data,
             pFrame->linesize, 0, pCodecCtx->height,
             pFrameRGB->data, pFrameRGB->linesize);

    The values in pFrameRGB are incorrect. I’ve tried troubleshooting this for hours :-( Any ideas on how to track down my mistake ?

    Here’s a link to the repo. The offending code is in Icosahedron Video Player/mesh.cpp, Mesh::LoadVideo and Mesh::NextFrame().

  • Cleaning up after av_frame_get_buffer

    4 novembre 2016, par Jason C

    There are two aspects of my question. I’m using libav, ffmpeg, 3.1.


    First, how do you appropriately dispose of a frame whose buffer has been allocated with av_frame_get_buffer ? E.g. :

    AVFrame *frame = av_frame_alloc();
    frame->width = ...;
    frame->height = ...;
    frame->format = ...;
    av_frame_get_buffer(frame, ...);

    Do any buffers have to be freed manually, beyond the call to av_frame_free(frame) ? The documentation doesn’t mention anything special, but in my experience the ffmpeg documentation often leaves out important details, or at least hides them in places far away from the obvious spots. I took a look at the code for av_frame_free and av_frame_unref but it branched out quite a bit and I couldn’t quite determine if it covered everything.


    Second, if something beyond av_frame_free needs to be done, then is there any catch-all way to clean up a frame if you don’t know how its data has been allocated ? For example, assuming someBuffer is already allocated with the appropriate size :

    AVFrame *frame2 = av_frame_alloc();
    frame2->width = ...;
    frame2->height = ...;
    frame2->format = ...;
    av_image_fill_arrays(frame2->data, frame2->linesize, someBuffer,
                        frame2->format, frame2->width, frame2->height, 1);

    Is there a way to free both frame and frame2 in the above examples using the exact same code ? That is frame and its data should be freed, and frame2 should be freed, but not someBuffer, since libav did not allocate it.