Recherche avancée

Médias (91)

Autres articles (36)

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

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

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

  • Need help on handling MPEG4V1 data

    31 janvier 2021, par Gediminas

    I'm in situation where I need to get a chunk of MPEG4V1 (Microsoft MPEG-4 VKI
Codec V1) data located in the beginning of a packet (that was sent by some DVR unit).

    



    Packet structure looks something like this :

    



      

    • Compressed MPEG4 data.
    • 


    • Long integer - Number of events and tripwires.
    • 


    • Long integer - Number of events.
    • 


    • Event - Event's sequence.
    • 


    • Long integer - Number of tripwires.
    • 


    • Tripwire - Tripwires sequence.
    • 


    • Long integer - Cyclical redundant code (CRC).
    • 


    



    So there is no indication of how to know where does the MPEG4 data ends (Or is there ?),
and from where should I start reading this additional data like "Number of events and tripwires" and etc...

    



    I uploaded two packet's so you could see how the actual data looks like :
recvData1.txt,
recvData2.txt.

    



    I've tried to decode those packets using FFmpeg library with avcodec_decode_video function and by removing byte by byte from the end of my recvData buffer in a hope for any results,
    
but FFmpeg just allways returned with an error messages like this :

    



    


    "[msmpeg4v1 @ 038865a0] invalid startcode",
 "[msmpeg4v1 @ 038865a0] header damaged".

    


    



    I'm not that good specialist on knowing of how does the MPEG4 works from the inside,
but judging by the error messages it's clearly seen that I'm missing some data for decoding at the start of the buffer.

    



    So I'm not sure of what part / kind of MPEG data I'm getting here..
    
Maybe it's some kind of MPEG's "frame" data with it's "end" indication or something ?

    



    I've even compared the start of my recvData buffer to some of MPEG4V1 encoded video files I found on the net "http://www.trekmania.net/clips/video_clips4.htm" to check if the start of my buffer really contains the MPEG data ..and not some kind of DVR vendor specific stuff..

    



    And I noticed that there are about 20bytes of data 
(at the start of my packet data, and in .avi files right after about 180bytes..) 
that looks like some kind of header or something..

    



    Please check this image : "http://ggodis.gamedev.lt/stackOverflow/recvData.jpg"

    



    Maybe someone knows what this part of MPEG4V1 data represents ?

    



    P.S. ..I've checked the CRC values for my received packets and they were correct..

    


  • Need help on handling MPEG4V1 data

    14 septembre 2011, par Gediminas

    I'm in situation where I need to get a chunk of MPEG4V1 (Microsoft MPEG-4 VKI
    Codec V1
    ) data located in the beginning of a packet (that was sent by some DVR unit).

    Packet structure looks something like this :

    • Compressed MPEG4 data.
    • Long integer - Number of events and tripwires.
    • Long integer - Number of events.
    • Event - Event's sequence.
    • Long integer - Number of tripwires.
    • Tripwire - Tripwires sequence.
    • Long integer - Cyclical redundant code (CRC).

    So there is no indication of how to know where does the MPEG4 data ends (Or is there ?),
    and from where should I start reading this additional data like "Number of events and tripwires" and etc...

    I uploaded two packet's so you could see how the actual data looks like :
    recvData1.txt,
    recvData2.txt.

    I've tried to decode those packets using FFmpeg library with avcodec_decode_video function and by removing byte by byte from the end of my recvData buffer in a hope for any results,
    but FFmpeg just allways returned with an error messages like this :

    "[msmpeg4v1 @ 038865a0] invalid startcode",
    "[msmpeg4v1 @ 038865a0] header damaged".

    I'm not that good specialist on knowing of how does the MPEG4 works from the inside,
    but judging by the error messages it's clearly seen that I'm missing some data for decoding at the start of the buffer.

    So I'm not sure of what part / kind of MPEG data I'm getting here..
    Maybe it's some kind of MPEG's "frame" data with it's "end" indication or something ?

    I've even compared the start of my recvData buffer to some of MPEG4V1 encoded video files I found on the net "http://www.trekmania.net/clips/video_clips4.htm" to check if the start of my buffer really contains the MPEG data ..and not some kind of DVR vendor specific stuff..

    And I noticed that there are about 20bytes of data
    (at the start of my packet data, and in .avi files right after about 180bytes..)
    that looks like some kind of header or something..

    Please check this image : "http://ggodis.gamedev.lt/stackOverflow/recvData.jpg"

    Maybe someone knows what this part of MPEG4V1 data represents ?

    P.S. ..I've checked the CRC values for my received packets and they were correct..

  • avformat/riffenc : don't force WAVEFORMATEXTENSIBLE for flt/dbl LPCM

    21 décembre 2023, par Gyan Doshi
    avformat/riffenc : don't force WAVEFORMATEXTENSIBLE for flt/dbl LPCM
    

    2c2a167ca7 forced WAVEFORMATEXTENSIBLE for all LPCM streams with greater
    than 16 bits per sample. However, WAVEFORMATEX allows IEEE Float samples
    or any depth where raw depth == coded depth, see Remarks section at
    https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatex
    and samples M1F1-float32-AFsp, M1F1-float64-AFsp at
    https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html

    There are hardware devices and likely software players requiring float samples
    that fail to qualify files with WAVEFORMATEXTENSIBLE headers.

    • [DH] libavformat/riffenc.c
    • [DH] tests/ref/acodec/pcm-f32le
    • [DH] tests/ref/acodec/pcm-f64le
    • [DH] tests/ref/seek/acodec-pcm-f32le
    • [DH] tests/ref/seek/acodec-pcm-f64le