Recherche avancée

Médias (1)

Mot : - Tags -/école

Autres articles (50)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

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

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

Sur d’autres sites (7540)

  • Making colour of MP4 video consistent in Chrome

    21 septembre 2021, par OneWorld

    I see a difference in the colour of a video between different machines using different browsers. I was wondering what the cause of the difference is ?

    


    I use FFMPEG to create the video. I sent the video to three different people with slightly different machines, and slightly different Chrome versions, to try and see where the differences are.

    


    The FFMPEG output from the video is as follows :-

    


    ffmpeg version 3.2.2-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.1 (Debian 5.4.1-4) 20161202
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-5 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg
  libavutil      55. 34.100 / 55. 34.100
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.100 / 57. 56.100
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'red_and_yellow_uat.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.56.100
  Duration: 00:00:03.00, start: 0.000000, bitrate: 84 kb/s
    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p(tv, unknown/bt709/bt709), 1080x1080, 81 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler


    


    From the same UAT rendered Video, with screenshots taken in Chrome from person 1, person 2, person 3, and person 4, and using GIMP colour picker on my machine from the screenshots, the results for red, and yellow are as follows.

    


    Person 1:- #A83833  and  #FFCB2E  Chrome Version 92.0.4515.131 (Official Build) (64-bit)
Person 2:- #AB3334  and  #FFCA38  Chrome Version 92.0.4515.107


    


    (Note : these colours Match / are very close to the original).

    


    Both these machines above are 64 bit Ubuntu machines, using Ubuntu 18.04.5 LTS
We both use the gnome screenshot tool in Ubuntu to take the screenshot, which creates an 8bit PNG.

    


    Person 3:-    #B14039  and  #FED303  Chrome Version 93.0.4577.63 (Official Build) (x86_64)
Person 4:-    #B2403A  and  #FFD201  Chrome Version 92.0.4515.159 (Official Build) (x86_64)


    


    Mac screenshots are taken using cmd shift 4, and generate an 8bit PNG file.

    


    Person 3 Machine Spec :-
Machine :- Macbook Pro (2019)
OS : macOS Big Sur Version 11.5.2
Processor :- 2.6Ghz Intel Core i7 processor. 32bit architecture (typing arch in her tty terminal returns i386).
Graphics :- Intel UHD Graphics 630 1536

    


    Person 4 Machine Spec :-
Machine :- Macbook Pro (Retina, 2015)
OS :- MacOS Mojave, Version 10.14.6
Processor :- 2.5GHz, Intel Core i7
Graphics :- AMD Radeon R9, M370X 2 GB Intel Iris Pro 1536 MB

    


    Person 1 screenshot

    


    enter image description here

    


    Person 2 screenshot

    


    enter image description here

    


    Person 3 screenshot

    


    enter image description here

    


    Person 4 screenshot

    


    enter image description here

    


    Any suggestions anyone has to make these colours consistent would be much appreciated. Would love to know why it happens also ? If anyone can explain ?

    


  • Merge commit 'a1a143adb0fd11c474221431417cff25db7d920f'

    26 septembre 2017, par James Almer
    Merge commit 'a1a143adb0fd11c474221431417cff25db7d920f'
    

    * commit 'a1a143adb0fd11c474221431417cff25db7d920f' :
    rtmp : Rename packet types to closer match the spec

    Merged-by : James Almer <jamrial@gmail.com>

    • [DH] libavformat/rtmppkt.c
    • [DH] libavformat/rtmppkt.h
    • [DH] libavformat/rtmpproto.c
  • lavf/webmdashenc : Representation IDs should be unique.

    11 novembre 2014, par Vignesh Venkatasubramanian
    lavf/webmdashenc : Representation IDs should be unique.
    

    According to the DASH spec, Representation IDs should be unique
    across all adaptation sets. Fixing that and updating the fate
    reference file to reflect this change.

    Signed-off-by : Vignesh Venkatasubramanian <vigneshv@google.com>
    Signed-off-by : Michael Niedermayer <michaelni@gmx.at>

    • [DH] libavformat/webmdashenc.c
    • [DH] tests/ref/fate/webm-dash-manifest