Recherche avancée

Médias (1)

Mot : - Tags -/bug

Autres articles (9)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

  • D’autres logiciels intéressants

    12 avril 2011, par

    On ne revendique pas d’être les seuls à faire ce que l’on fait ... et on ne revendique surtout pas d’être les meilleurs non plus ... Ce que l’on fait, on essaie juste de le faire bien, et de mieux en mieux...
    La liste suivante correspond à des logiciels qui tendent peu ou prou à faire comme MediaSPIP ou que MediaSPIP tente peu ou prou à faire pareil, peu importe ...
    On ne les connais pas, on ne les a pas essayé, mais vous pouvez peut être y jeter un coup d’oeil.
    Videopress
    Site Internet : (...)

  • 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 (1349)

  • Revision 106594 : Quand il y a changement de borne, il faut faire un z+1 mini pour que ...

    8 octobre 2017, par spip.franck@… — Log

    Quand il y a changement de borne, il faut faire un z+1 mini pour que les sites utilisant déjà le plug le sachent

  • How does FFmpeg calculate linesize alignment ?

    27 août 2024, par yaskovdev

    I am new to video encoding. I am using FFmpeg library to decode the H.264 frame. I have the below C++ code (full code is here) :

    


    AVCodecContext *context = create_codec_context();
AVFrame *decoded_frame = av_frame_alloc();
avcodec_send_packet(context, encoded_packet);
avcodec_receive_frame(context, decoded_frame);

std::cout << decoded_frame->width << "\n"; // prints 1620, as expected
std::cout << decoded_frame->linesize[0] << "\n"; // prints 1664!


    


    What looks strange to me is the linesize of the decoded frame. Although the width of the frame is 1620, the linesize[0] is 1664. According to this answer, the linesize is calculated taking alignment into consideration. In order to get 1664 from 1620, one should apply 64 as an alignment to the initial width.

    


    My question is, where does this 64 alignment come from ? Searching through FFmpeg code did not give any results. Does the encoded frame itself already have this information ?

    


    If afterwards I decide to "flatten" the decoded frame into a one-dimensional array using av_image_copy_to_buffer(), what alignment should I use ? Should it also be 64 ?

    


  • FFmpeg : how does FFmpeg calculate linesize alignment ?

    10 août 2021, par yaskovdev

    I am new to video encoding. I am using FFmpeg library to decode a H.264 frame. I have the below C++ code (full code is here) :

    


    AVCodecContext *context = create_codec_context();
AVFrame *decoded_frame = av_frame_alloc();
int got_frame;
avcodec_decode_video2(context, decoded_frame, &got_frame, &encoded_frame);

std::cout << decoded_frame->width << std::endl; // prints 1620, as expected
std::cout << decoded_frame->linesize[0] << std::endl; // prints 1664!


    


    What looks strange to me is the linesize of the decoded frame. Although the width of the frame is 1620, the linesize[0] is 1664. According to this answer, the linesize is calculated taking alignment into consideration. In order to get 1664 from 1620, one should apply 64 as an alignment to the initial width.

    


    My question is, where does this 64 alignment come from ? Searching through FFmpeg code did not give any results. Does the encoded frame itself already have this information ?

    


    If afterwards I decide to "flatten" the decoded frame into a one-dimensional array using av_image_copy_to_buffer(), what alignment should I use ? Should it also be 64 ?

    


Navigation