Recherche avancée

Médias (0)

Mot : - Tags -/protocoles

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (25)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

  • 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

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

Sur d’autres sites (5284)

  • Anomalie #3371 : faille sécurité ? balise meta+refresh dans un champ d’article

    5 janvier 2015, par Fabien Abbadie

    Fil Up a écrit :

    Pour moi le problème de sécu vient du piratage qui a eu lieu, pas de ce que le pirate a fait une fois dans la place... Essentiellement il est passé admin, et les admins gardent le droit de faire des choses intéressantes dans leur site.

    Oui mais non : j’ai testé sur une 3.0.17 à jour, pas piraté, et a priori, n’importe quel rédacteur peut faire ça.
    J’ai même testé sur forum.spip.net et ça a l’air de le faire aussi fait : mettez en titre, et voyons si les utilisateurs sont contents quand ils sont renvoyés vers une page piégé à chaque fois que l’article est listé.

    Si vous pouvez, essayez de voir cet article, proof of concept : http://forum.spip.net/ecrire/?exec=article&id_article=3140

  • Anomalie #3615 (Fermé) : Evitons les redirections

    8 décembre 2015, par Franck Dalot

    Bonjour
    spip 3.1 [22634]

    Il reste encore dans le core des url de type .org au lieu de .net
    Je croyais que cela avait été fait, mais il semble que non :-(
    Exemple :
    Faudrait faire une transformation des url du type :
    http://core.spip.org/
    en :
    https://core.spip.net/

    http://forum.spip.org/
    en :
    http://forum.spip.net/

    http://demo.spip.org/
    en :
    http://demo.spip.net/

    Pendant que j’y suis, il s’agit de sites de la galaxie ou pas ?
    http://math.spip.org/tex.php
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc_version.php#L234

    http://example.org/squelettes/bg.png
    http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/compresseur/tests/css/expected_url_abs.css
    Car ils ne sont pas en .net

    Franck

  • ffmpeg decoding yuv420p to rgb shifts luminance/brightness down

    6 avril 2013, par glopes

    I'm recording video from a grayscale camera into an MPEG4 video file using FFMPEG. Recently I noticed a weird effect : if I playback the file using FFMPEG or windows media player, the output frames are noticeably darker (by about 10 brightness values) than the original source.

    I thought the encoding step was doing this until I opened the same file in VLC and it gave me back the correct result. I played around with FFMPEG command lines to decode a single frame and realized that if I decode a frame into GRAY8 pixel format, the brightness/luminance values are preserved. Here's the command and ffmpeg output :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt gray gray.bmp
    

    
ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
    
  built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
    
  configuration: --enable-w32threads
    
  libavutil      52. 18.100 / 52. 18.100
    
  libavcodec     54. 92.100 / 54. 92.100
    
  libavformat    54. 63.104 / 54. 63.104
    
  libavdevice    54.  3.103 / 54.  3.103
    
  libavfilter     3. 42.103 /  3. 42.103
    
  libswscale      2.  2.100 /  2.  2.100
    
  libswresample   0. 17.102 /  0. 17.102
    
Input #0, avi, from 'video.avi':
    
  Metadata:
    
    encoder         : Lavf53.32.100
    
  Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
    
    Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    
0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    
Output #0, image2, to 'gray.bmp':
    
  Metadata:
    
    encoder         : Lavf54.63.104
    
    Stream #0:0: Video: bmp, gray, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 kb
    
/s, 90k tbn, 30 tbc
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    
Press [q] to stop, [?] for help
    
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    
video:851kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.002524%

    However, if I decode the same frame into an rgb color pixel format, I end up again with the darker frames :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt bgr24 rgb.bmp
    

    
ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
    
  built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
    
  configuration: --enable-w32threads
    
  libavutil      52. 18.100 / 52. 18.100
    
  libavcodec     54. 92.100 / 54. 92.100
    
  libavformat    54. 63.104 / 54. 63.104
    
  libavdevice    54.  3.103 / 54.  3.103
    
  libavfilter     3. 42.103 /  3. 42.103
    
  libswscale      2.  2.100 /  2.  2.100
    
  libswresample   0. 17.102 /  0. 17.102
    
Input #0, avi, from 'video.avi':
    
  Metadata:
    
    encoder         : Lavf53.32.100
    
  Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
    
    Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    
0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    
Output #0, image2, to 'rgb.bmp':
    
  Metadata:
    
    encoder         : Lavf54.63.104
    
    Stream #0:0: Video: bmp, bgr24, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 k
    
b/s, 90k tbn, 30 tbc
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    
Press [q] to stop, [?] for help
    
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    
video:2550kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000843%

    This happens with every single grayscale video that I encode to MPEG4 with FFMPEG. My best guess so far is it has to do with how the container pixel format gets converted to/from. Since I'm using MPEG4, the file pixel format is YUV420P. I have no idea how ffmpeg encodes from GRAY8 to YUV420P, but maybe it stores just the luminance values in Y... if this happens, then decoding from this to RGB could produce darker pixels by the scaling factor that is applied to the luminance matrix ?

    To sum it up :

    1) How can encoding a grayscale video to YUV420P with FFMPEG and decoding back produce wrong (darker) brightness values when decoding to RGB versus GRAY8 ? Presumably once the frames are in YUV420P format it shouldn't matter whether the source is actually grayscale or not so the result should be equivalent, no ?

    2) How does VLC avoid this situation ? I was under the impression that VLC used FFMPEG as well for video decoding, but somehow they managed to figure out how to produce the correct values without requiring me to indicate explicitly that the video was grayscale.

Navigation