Recherche avancée

Médias (1)

Mot : - Tags -/biographie

Autres articles (36)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (4913)

  • Ffmpeg libx264rgb and libx264 yuv444p gives very different results

    1er février 2020, par Mustafa Akın Yılmaz

    I am trying to create a lossy compressed video from several .png files. I am using the following ffmpeg commdans :

    



    ffmpeg -i %8d.png -frames:v 4 -c:v libx264rgb -pix_fmt rgb24 -g 4 -qp 30 -r 25 out.mp4


    



    and

    



    ffmpeg -i %8d.png -frames:v 4 -c:v libx264 -pix_fmt yuv444p -g 4 -qp 30 -r 25 out.mp4


    



    Then I am extracting frames from the videos with the command :

    



    ffmpeg -i out.mp4 -r 25 %8d.png


    



    When I compare the bitrate and PSNR, I found that the yuv444p gives about 2 db gain at the same bitrate. Why such a huge difference is observed even I did set yuv444p which does not apply chroma subsampling ?

    


  • Ffmpeg libx264rgb and libx264 yuv444p gives very different results

    1er février 2020, par Mustafa Akın Yılmaz

    I am trying to create a lossy compressed video from several .png files. I am using the following ffmpeg commdans :

    ffmpeg -i %8d.png -frames:v 4 -c:v libx264rgb -pix_fmt rgb24 -g 4 -qp 30 -r 25 out.mp4

    and

    ffmpeg -i %8d.png -frames:v 4 -c:v libx264 -pix_fmt yuv444p -g 4 -qp 30 -r 25 out.mp4

    Then I am extracting frames from the videos with the command :

    ffmpeg -i out.mp4 -r 25 %8d.png

    When I compare the bitrate and PSNR, I found that the yuv444p gives about 2 db gain at the same bitrate. Why such a huge difference is observed even I did set yuv444p which does not apply chroma subsampling ?

  • Libav (ffmpeg) What is the most robust way to set the output stream time base ?

    29 octobre 2016, par Jason C

    This is a follow up to the solution to this question. My question is : When creating a new output stream, what is the most robust way to ensure that the output stream time base is set to a valid value for arbitrary formats ?

    Another way to phrase this question is : If I leave the output stream time base set to 0/0, will avformat_write_header always initialize it to something appropriate ?

    Consider the following snippet (assume, unlike the above linked question, that I’m just encoding video and I do not have any input video timing info to refer to or copy from) :

    AVFormatContext *formatx;
    AVCodec *codec;
    AVStream *stream;
    ...
    stream = avformat_new_stream(formatx, codec);
    stream->time_base = { 1, 10000 };
    ...
    avformat_write_header(formatx, NULL);

    Here, my rationale is as follows :

    • I observed, for MOV output formats, that if the stream time base is 0/0 when avformat_write_header is called, it is changed to 1/90000. Conclusion : At least one format (MOV) has a preferred time base that is set here, so others may be the same.
    • I do not know if avformat_write_header can be relied on to do this first, so I figure I’ll give it an initial reasonable value (1/10000) just in case.

    So this covers cases where avformat_write_header doesn’t set the time base. However, now I’ve observed two worrisome things :

    • If I do initialize the time base (to 1/10000 in this case), avformat_write_header does not modify it. No worries yet, except...
    • As an experiment I set it to 1/1000000. The MOV muxer issued a warning that the time base was too high. This means avformat_write_header seems to obey the time base that was set even if it’s not necessarily appropriate for the muxer.

    So my conflict is as follows :

    • If I don’t set the time base before writing the header, then I know that in at least some cases avformat_write_header will initialize it to something appropriate. However, I don’t know if this is true in all cases, so I run the risk of this failing (or do I ? that’s the question here).
    • If I do set the time base before writing the header, then I’m safe in situations where avformat_write_header doesn’t, but I run the risk of breaking the muxer, since I can’t know what time bases are valid for arbitrary muxers (or can I ?)
    • The time base can’t be changed after writing the header, of course. So I can’t initialize it to 0/0 then check it for validity and set it to something afterwards. That is, if I set it to 0/0, and avformat_write_header does not fill it in, then I’ve missed an opportunity to set it myself and the program unnecessarily fails.

    So what do I do ? How do I ensure that an output stream time base is both a) always set, and b) always set to something appropriate for the muxer ?