Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (42)

  • MediaSPIP : Modification des droits de création d’objets et de publication définitive

    11 novembre 2010, par

    Par défaut, MediaSPIP permet de créer 5 types d’objets.
    Toujours par défaut les droits de création et de publication définitive de ces objets sont réservés aux administrateurs, mais ils sont bien entendu configurables par les webmestres.
    Ces droits sont ainsi bloqués pour plusieurs raisons : parce que le fait d’autoriser à publier doit être la volonté du webmestre pas de l’ensemble de la plateforme et donc ne pas être un choix par défaut ; parce qu’avoir un compte peut servir à autre choses également, (...)

  • Personnaliser les catégories

    21 juin 2013, par

    Formulaire de création d’une catégorie
    Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
    Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
    On peut modifier ce formulaire dans la partie :
    Administration > Configuration des masques de formulaire.
    Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
    Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

Sur d’autres sites (8482)

  • Damaged h264 stream not working with ffmpeg but working with vlc or mplayer

    15 avril 2013, par gregoiregentil

    I have a h264 file, coming from an rtsp stream, that is slightly damaged. Some frames are altered.

    ffmpeg reports :

    ffmpeg -i stream.mpg 
    
ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
    
  built on Apr  2 2013 17:00:59 with gcc 4.6.3
    
*** THIS PROGRAM IS DEPRECATED ***
    
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
    

    
Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 90000.00 (180000/2)
    
Input #0, mpegts, from 'a.mpg':
    
  Duration: 00:03:18.84, start: 93370.745522, bitrate: 2121 kb/s
    
  Program 1 
    
    Stream #0.0[0x44](): Video: h264 (Baseline), yuv420p, 640x480, 90k tbr, 90k tbn, 180k tbc
    
At least one output file must be specified

    I can play the file with VLC or mplayer. Obviously, the damaged frames are "kind of blurred" but it's working. mplayer reports :

    mplayer stream.mpg
    
MPlayer2 UNKNOWN (C) 2000-2011 MPlayer Team
    
mplayer: could not connect to socket
    
mplayer: No such file or directory
    
Failed to open LIRC support. You will not be able to use your remote control.
    

    
Playing stream.mpg.
    
Detected file format: MPEG-2 transport stream format (libavformat)
    
[lavf] stream 0: video (h264), -vid 0
    
LAVF: Program 1 
    
VIDEO:  [H264]  640x480  0bpp  90000.000 fps    0.0 kbps ( 0.0 kbyte/s)
    
Load subtitles in .
    
[ass] auto-open
    
==========================================================================
    
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
    
Asking decoder to use 2 threads if supported.
    
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
    
==========================================================================
    
Audio: no sound
    
Starting playback...
    
V:   0.0   0/  0 ??% ??% ??,?% 0 0 
    
Movie-Aspect is undefined - no prescaling applied.
    
VO: [xv] 640x480 => 640x480 Planar YV12 
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!
    
Video pts after filters MISSING
    
V:93370.7   0/  0 ??% ??% ??,?% 0 0 
    
No pts value from demuxer to use for frame!

    When I try to re-encode the file with :

    ffmpeg -i stream.mpg -fflags +genpts -an -vcodec mpeg4 -r 65535/2733 stream.mp4

    ffmpeg seems to jump over the altered frames. The length of stream.mp4 << length of stream.mpg

    How could I fix this problem, i.e. having ffmpeg to output something similar to what mplayer and vlc output ?

  • 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 &#39;video.avi&#39;:
    
  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 &#39;gray.bmp&#39;:
    
  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 &#39;video.avi&#39;:
    
  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 &#39;rgb.bmp&#39;:
    
  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.

  • Revision 8357292a5a : Fix test on maximum downscaling limits There is a normative scaling range of (x

    18 juin 2014, par Adrian Grange

    Changed Paths :
     Modify /vp9/common/vp9_convolve.c


     Modify /vp9/encoder/vp9_encoder.c



    Fix test on maximum downscaling limits

    There is a normative scaling range of (x1/2, x16)
    for VP9. This patch fixes the maximum downscaling
    tests that are applied in the convolve function.

    The code used a maximum downscaling limit of x1/5
    for historic reasons related to the scalable
    coding work. Since the downsampling in this
    application is non-normative it will revert to
    using a separate non-normative scaler.

    Change-Id : Ide80ed712cee82fe5cb3c55076ac428295a6019f

Navigation