Recherche avancée

Médias (1)

Mot : - Tags -/ticket

Autres articles (48)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

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

Sur d’autres sites (9004)

  • Revision 7247 : Résolution du ticket ...

    12 décembre 2012, par kent1 — Log

    Résolution du ticket ​http://www.mediaspip.net/ticket/configuration-du-telechargement
    On ajoute une option dans les champs ajoutés des diogènes emballe_medias permettant d’ajouter dans le formulaire de l’article la gestion du téléchargement des fichiers.
    On ajoute pour cela deux champs dans la table spip_articles
    On passe par une autorisation autoriser_document_mstelecharger pour gérer cela

  • Getting incorrect output resolution ffmpeg

    29 octobre 2011, par Adam

    I am capturing an RTSP stream from a security camera, and transcoding it for (live streaming) to iphone, using OSX as the encoding platform.
    I have it working correctly, and Im tuning it.
    However, it seems that it is not outputting the requested resolution. This is my script

    /Applications/SecurityCamera/openRTSP -v -c -t rtsp://10.0.1.118/ch1-s1 | \
    
    /Applications/SecurityCamera/ffmpeg \
    
    -r 10 -i - \
    
    -y -an -ab 64000 -f mpegts -vcodec copy -s 960x640 \
    
    -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 \
    
    -subq 5 -trellis 1 -refs 1 -coder 0 -me_range 16  -keyint_min 25 -sc_threshold 40 \
    
    -i_qfactor 0.71 -bt 400k -maxrate 524288 -bufsize 524288 \
    
    -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 \
    
    -aspect 960:640 -r 10 -g 10 -async 2 -\
    
    | /Applications/SecurityCamera/mediastreamsegmenter -b http://hydracam.dyndns.org:8080/ -f /Library/WebServer/Documents/ -i stream.m3u8 -t 10 -s 4 -D

    This is the status report :

    Input #0, h264, from 'pipe:':
    

    
  Duration: N/A, bitrate: N/A
    
  Stream #0.0: Video: h264, yuv420p, 1600x1200, 10 fps, 10 tbr, 1200k tbn, 20 tbc
    
  [mpegts @ 0x10100c200] muxrate VBR, pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts
    
  Output #0, mpegts, to 'pipe:':
    
  Metadata:
    
    encoder         : Lavf52.93.0
    
    Stream #0.0: Video: libx264, yuv420p, 1600x1200 [PAR 1:1 DAR 4:3], q=2-31, 90k tbn, 10 tbc
    
Stream mapping:
    
  Stream #0.0 -> #0.0

    You can see that its working, but it is outputting 1600x1200 for some reason.

    If I change the -vcodec copy to -vcodec libx264 then I get the correct status report (stating 960x640, correct), but the streaming halts after 54 frames (see output below)

    Seems stream 0 codec frame rate differs from container frame rate: 20.00 (20/1) -> 10.00 (20/2)
    
Input #0, h264, from 'pipe:':
    
  Duration: N/A, bitrate: N/A
    
    Stream #0.0: Video: h264, yuv420p, 1600x1200, 10 fps, 10 tbr, 1200k tbn, 20 tbc
    
[buffer @ 0x100d02420] w:1600 h:1200 pixfmt:yuv420p
    
[scale @ 0x100d026f0] w:1600 h:1200 fmt:yuv420p -> w:960 h:640 fmt:yuv420p flags:0x4
    
[libx264 @ 0x10100d400] using SAR=1/1
    
[libx264 @ 0x10100d400] frame MB size (60x40) > level limit (1620)
    
[libx264 @ 0x10100d400] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
    
[libx264 @ 0x10100d400] profile Constrained Baseline, level 3.0
    
[mpegts @ 0x10100c200] muxrate VBR, pcr every 1 pkts, sdt every 200, pat/pmt every 40 pkts
    
Output #0, mpegts, to 'pipe:':
    
  Metadata:
    
    encoder         : Lavf52.93.0
    
    Stream #0.0: Video: libx264, yuv420p, 960x640 [PAR 1:1 DAR 3:2], q=10-51, 200 kb/s, 90k tbn, 10 tbc
    
Stream mapping:
    
  Stream #0.0 -> #0.0
    
read pmap fffps=  3 q=37.0 size=      37kB time=0.10 bitrate=3008.0kbits/s    bits/s    
    
video pid set at 100
    
found sequence start
    
  next segment value 1026000
    
written bytes 376 skipped 0
    
frame=   54 fps=  2 q=-1.0 Lsize=     160kB time=5.40 bitrate= 242.0kbits/s    
    
video:141kB audio:0kB global headers:0kB muxing overhead 12.872737%
    
frame I:6     Avg QP:34.68  size: 23524
    
[libx264 @ 0x10100d400] frame P:48    Avg QP:41.53  size:    75
    
[libx264 @ 0x10100d400] mb I  I16..4: 63.9%  0.0% 36.1%
    
[libx264 @ 0x10100d400] mb P  I16..4:  0.1%  0.0%  0.0%  P16..4:  0.8%  0.1%  0.0%  0.0%  0.0%    skip:99.0%
    
[libx264 @ 0x10100d400] final ratefactor: 38.54
    
[libx264 @ 0x10100d400] coded y,uvDC,uvAC intra: 57.7% 22.3% 2.0% inter: 0.0% 0.1% 0.0%
    
[libx264 @ 0x10100d400] i16 v,h,dc,p: 23% 35% 27% 15%
    
[libx264 @ 0x10100d400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 32% 16%  4%  3%  3%  7%  4%  8%
    
[libx264 @ 0x10100d400] i8c dc,h,v,p: 83% 11%  5%  0%
    
[libx264 @ 0x10100d400] kb/s:214.43

  • ffplay : fix handling of resolution changes with h264-mt

    20 décembre 2012, par Michael Niedermayer

    ffplay : fix handling of resolution changes with h264-mt

Navigation