Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (22)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (4986)

  • lavu/pixfmt : Add P012, Y212, XV30, and XV36 formats

    13 août 2022, par Philip Langdale
    lavu/pixfmt : Add P012, Y212, XV30, and XV36 formats
    

    These are the formats we want/need to use when dealing with the Intel
    VAAPI decoder for 12bit 4:2:0, 12bit 4:2:2, 10bit 4:4:4 and 12bit 4:4:4
    respectively.

    As with the already supported Y210 and YUVX (XVUY) formats, they are
    based on formats Microsoft picked as their preferred 4:2:2 and 4:4:4
    video formats, and Intel ran with it.

    P12 and Y212 are simply an extension of 10 bit formats to say 12 bits
    will be used, with 4 unused bits instead of 6.

    XV30, and XV36, as exotic as they sound, are variants of Y410 and Y412
    where the alpha channel is left formally undefined. We prefer these
    over the alpha versions because the hardware cannot actually do
    anything with the alpha channel and respecting it is just overhead.

    Y412/XV46 is a normal looking packed 4 channel format where each
    channel is 16bits wide but only the 12msb are used (like P012).

    Y410/XV30 packs three 10bit channels in 32bits with 2bits of alpha,
    like A/X2RGB10 style formats. This annoying layout forced me to define
    the BE version as a bitstream format. It seems like our pixdesc
    infrastructure can handle the LE version being byte-defined, but not
    when it's reversed. If there's a better way to handle this, please
    let me know. Our existing X2 formats all have the 2 bits at the MSB
    end, but this format places them at the LSB end and that seems to be
    the root of the problem.

    • [DH] doc/APIchanges
    • [DH] libavutil/pixdesc.c
    • [DH] libavutil/pixfmt.h
    • [DH] libavutil/version.h
    • [DH] tests/ref/fate/imgutils
    • [DH] tests/ref/fate/sws-pixdesc-query
  • How do I configure ffmpeg & openh264 so that the video file can be opened in Windows Media Player 12

    10 mars 2017, par Sacha Guyer

    I have successfully created h264/mp4 movie files with ffmpeg and the x264 library.

    Now I would like to change the h264 library from x264 to openH264. I could replace the x264 library with openH264, recompile ffmpeg and produce movie files, without changing my sources that produce the movie. The resulting movie opens fine in Quicktime on Mac, but on Windows, Windows Media Player 12 cannot play it.

    The documentation about Windows Media Player support for h264 is unclear. File types supported by Windows Media Player states in the table that Windows Media Player 12 supports mp4, but the text below says :

    Windows Media Player does not support the playback of the .mp4 file format.

    From what I have observed, Windows Media Player 12 IS capable of playing h264/mp4 files, but only when created with x264.

    Does anyone know how I need to adjust the configuration of the codec/context so that the movie plays in Windows Media Player ? Does Windows Media Player only support certain h264 profiles ?

    I noticed the warning :

    [libopenh264 @ 0x...] [OpenH264] this = 0x..., Warning:bEnableFrameSkip = 0,bitrate can’t be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame

    With the configuration :

    av_dict_set(&options, "allow_skip_frames", "1", 0);

    I could get rid of this warning, but the movie still does not play. Are there other options that need to be set so that the movie plays in Windows Media Player ?

    Thank you for your help

    ffprobe output of the file that does play fine in Windows Media Player :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_x264.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       title           : retina
       encoder         : Lavf57.56.100
       comment         : Creation Date: 2017-03-10 07:47:39.601
     Duration: 00:00:04.17, start: 0.000000, bitrate: 17497 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661),
         yuv420p, 852x754, 17495 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default)
       Metadata:
         handler_name    : VideoHandler

    ffprobe output of the file that does not play in Windows Media Player :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_openh264.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       title           : retina
       encoder         : Lavf57.56.100
       comment         : Creation Date: 2017-03-10 07:49:27.024
     Duration: 00:00:04.17, start: 0.000000, bitrate: 17781 kb/s
       Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661),
         yuv420p, 852x754, 17779 kb/s, 24 fps, 24 tbr, 24k tbn, 48k tbc (default)
       Metadata:
         handler_name    : VideoHandler
  • strange artifacts in image - where does a frame start ?

    26 mai 2017, par user3387542

    We are live broadcasting a webcam stream. No audio, video only. The current command that works great :

    # Direct replay works well:
    ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - | \
    ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

    but as soon as we try to send this data over the network (udp broadcast / gigabit lan) we are getting strange artefacts into the image.

    # server command:
    ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - | \
    socat - UDP-DATAGRAM:10.0.0.255:12345,broadcast

    # client command:
    socat -u udp-recv:12345,reuseaddr - | \
    ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

    Where do these artifacts come from and how to get rid of them ? Does this has something to do with the client not knowing where a certain video frame starts ?

    We have chosen to stream raw video to reduce latency. The final goal would be to apply opencv tools to the video and react live depending on the situation. Which works great, as long as the camera is plugged in directly into this computer. But we need to set it apart and need multiple clients.

    enter image description here

    The camera used is a Microsoft® LifeCam Studio(TM).

    $ v4l2-ctl -d 0 --list-formats
    ioctl: VIDIOC_ENUM_FMT
    Index       : 0
    Type        : Video Capture
    Pixel Format: 'YUYV'
    Name        : YUYV 4:2:2

    Index       : 1
    Type        : Video Capture
    Pixel Format: 'MJPG' (compressed)
    Name        : Motion-JPEG

    Index       : 2
    Type        : Video Capture
    Pixel Format: 'M420'
    Name        : YUV 4:2:0 (M420)

    Update

    To narrow down the issue, I tried to split it up into different tasks :

    1.0. Writing the stream to a file :

    ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - > ~/deltemp/rawout

    1.1. Reading the file : The result looks great, no artefacts :

    cat ~/deltemp/rawout | ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

    2.0 Starting the stream and broadcasting the stream as mentioned in the server command above

    2.1 Writing the UDP stream to a file. And watching the file (artifacts are back again)

    socat -u udp-recv:12345,reuseaddr - > ~/deltemp/rawout
    cat ~/deltemp/rawout | ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

    As test 1 showed no artifacts and test 2 did, it must be something with udp packet loss.

    Test 3 : Reducing quality to 640x480 did not help either.