Recherche avancée

Médias (1)

Mot : - Tags -/publier

Autres articles (28)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

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

  • avcodec/asvdec : Use rounded up dimenensions in input size check

    1er juin 2017, par Michael Niedermayer
    avcodec/asvdec : Use rounded up dimenensions in input size check

    Fixes : Timeout
    
Fixes : 2001/clusterfuzz-testcase-minimized-6187599389523968
    

    Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavcodec/asvdec.c

  • FFMPEG .oma to .mp3 "Unsupported codec 5 !" with a big file

    27 mars 2017, par Ventura

    I’m trying to convert a .OMA file to .MP3 but no success with a specific file.

    If I try :

    ffmpeg -i audio1.oma -f mp3 output.mp3

    The file is converted successfully. The file audio1.oma is a 3 MB file.

    Full output :

    ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
    
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
    
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.2.4 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --disable-lzma --enable-vda
    
  libavutil      55. 34.101 / 55. 34.101
    
  libavcodec     57. 64.101 / 57. 64.101
    
  libavformat    57. 56.101 / 57. 56.101
    
  libavdevice    57.  1.100 / 57.  1.100
    
  libavfilter     6. 65.100 /  6. 65.100
    
  libavresample   3.  1.  0 /  3.  1.  0
    
  libswscale      4.  2.100 /  4.  2.100
    
  libswresample   2.  3.100 /  2.  3.100
    
  libpostproc    54.  1.100 / 54.  1.100
    
[oma @ 0x7f8fc4000000] Estimating duration from bitrate, this may be inaccurate
    
Input #0, oma, from 'audio1.oma':
    
  Metadata:
    
    title           : Is This It
    
    artist          : The Strokes
    
    album           : Is This It
    
    genre           : Rock
    
    OMG_TRLDA       : 2001/01/01 00:00:00
    
    TLEN            : 153000
    
  Duration: 00:02:33.36, start: 0.000000, bitrate: 128 kb/s
    
    Stream #0:0: Audio: mp3 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s16p, 128 kb/s
    
Output #0, mp3, to 'output.mp3':
    
  Metadata:
    
    TIT2            : Is This It
    
    TPE1            : The Strokes
    
    TALB            : Is This It
    
    TCON            : Rock
    
    OMG_TRLDA       : 2001/01/01 00:00:00
    
    TLEN            : 153000
    
    TSSE            : Lavf57.56.101
    
    Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p
    
    Metadata:
    
      encoder         : Lavc57.64.101 libmp3lame
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
    
Press [q] to stop, [?] for help
    
size=    2397kB time=00:02:33.35 bitrate= 128.0kbits/s speed=37.2x    
    
video:0kB audio:2397kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.016094%

    If I try the same with another .oma (53 MB) I’m getting the error :

    Unsupported codec 5 ! audio2.oma : Function not implemented

    Full output :

    ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
    
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
    
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.2.4 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --disable-lzma --enable-vda
    
  libavutil      55. 34.101 / 55. 34.101
    
  libavcodec     57. 64.101 / 57. 64.101
    
  libavformat    57. 56.101 / 57. 56.101
    
  libavdevice    57.  1.100 / 57.  1.100
    
  libavfilter     6. 65.100 /  6. 65.100
    
  libavresample   3.  1.  0 /  3.  1.  0
    
  libswscale      4.  2.100 /  4.  2.100
    
  libswresample   2.  3.100 /  2.  3.100
    
  libpostproc    54.  1.100 / 54.  1.100
    
[oma @ 0x7f8792000000] Unsupported codec 5!
    
audio2.OMA: Function not implemented

    Both audios works fine when using the MP3 Player.
    The first audio which works is just a random song from my MP3 player to test.
    The second file was recorded in a music studio playing live with multiple channels.

    Anything I’m missing here ?

  • tcp : set socket buffer sizes before listen/connect/accept

    9 janvier 2017, par Joel Cunningham
    tcp : set socket buffer sizes before listen/connect/accept

    From e24d95c0e06a878d401ee34fd6742fcaddeeb95f Mon Sep 17 00:00:00 2001
    
From : Joel Cunningham <joel.cunningham@me.com>
    
Date : Mon, 9 Jan 2017 13:37:51 -0600
    
Subject : [PATCH] tcp : set socket buffer sizes before listen/connect/accept
    

    Attempting to set SO_RCVBUF and SO_SNDBUF on TCP sockets after connection
    
establishment is incorrect and some stacks ignore the set call on the socket at
    
this point.  This has been observed on MacOS/iOS.  Windows 7 has some peculiar
    
behavior where setting SO_RCVBUF after applies only if the buffer is increasing
    
from the default while decreases are ignored.  This is possibly how the incorrect
    
usage has gone unnoticed
    

    Unix Network Programming Vol. 1 : The Sockets Networking API (3rd edition, seciton 7.5) :
    

    "When setting the size of the TCP socket receive buffer, the ordering of the
    
function calls is important.  This is because of TCP’s window scale option,
    
which is exchanged with the peer on SYN segments when the connection is
    
established. For a client, this means the SO_RCVBUF socket option must be
    
set before calling connect.  For a server, this means the socket option must
    
be set for the listening socket before calling listen.  Setting this option
    
for the connected socket will have no effect whatsoever on the possible window
    
scale option because accept does not return with the connected socket until
    
TCP’s three-way handshake is complete.  This is why the option must be set on
    
the listening socket. (The sizes of the socket buffers are always inherited from
    
the listening socket by the newly created connected socket)"
    

    Signed-off-by : Joel Cunningham <joel.cunningham@me.com>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavformat/tcp.c

Navigation