Recherche avancée

Médias (91)

Autres articles (83)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

Sur d’autres sites (8238)

  • OpenCV3.3.1 fails to read a video

    1er janvier 2018, par Kasparov92

    Here is the code I use

    file_name = 'movie.avi'
    cap = cv2.VideoCapture(file_name)

    success, frame = cap.read()

    i = 0

    while success:
       i +=1
       success, frame = cap.read()

    print "Frames successfully read:", i

    And I am getting this error :

    Unable to stop the stream: Inappropriate ioctl for device

    (python:139873): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed
       Frames successfully read: 0

    On this particular video, it fails to read ! I tried the same code on other videos and they work fine. I also tried the same piece of code with another laptop (same operating system : Ubuntu 16.04) and it works.

    Is it a codec issue ? if so why other videos could be loaded and read successfully ?

    EDIT 1 :

    I recompiled opencv using -DWITH_LIBV4L=ON after sudo apt-get install libv4l-dev and Now I am getting this error :

    Failed to query video capabilities: Inappropriate ioctl for device
    libv4l2: error getting capabilities: Inappropriate ioctl for device
    VIDEOIO ERROR: V4L: device /root/datasets/UCF-101/TableTennisShot/v_TableTennisShot_g22_c02.avi: Unable to query number of channels

    (python:173084): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed
  • How can I retain 2x pixel density when encoding Retina screen capture with ffmpeg ?

    26 février 2018, par hfossli

    Whenever I use ffmpeg to encode a HiDPI/Retina screen recording, the video plays at 2x the size, so it looks fuzzy, because the pixel density is not retained.

    How can I retain the original pixel density of HiDPI screen recordings with ffmpeg ?

    How to reproduce :

    1. Use QuickTime Player to create a Screen Recording on a Retina Mac.
    2. Play the video you recorded in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 2:1 on your Retina Display, so the video looks sharp. It’s playing in half the space of the actual recorded pixels.
    3. Use ffmpeg to encode the video using a command like this :

      ffmpeg -i haha.mov -c:v libx264 -crf 23 haha-lg.mov
    4. Play the new ffmpeg-compressed video in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 1:1, so the video looks fuzzy.

    To clarify, the video does not look blurry because it was compressed. Rather, it looks blurry because the video is being played twice as big as it should be, at a 1:1 pixel density, instead of the required 2:1 pixel density, presumably because some metadata is being discarded when encoding.

    For the record, VLC plays both videos too big (blurry). So being able to play HiDPI videos seems to be a feature of QuickTime Player.

    Here is the detailed information ffmpeg shows for the original screen recording :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha.mov':
     Metadata:
       major_brand     : qt  
       minor_version   : 0
       compatible_brands: qt  
       creation_time   : 2018-02-26T16:46:00.000000Z
       com.apple.quicktime.make: Apple
       com.apple.quicktime.model: iMac18,3
       com.apple.quicktime.software: Mac OS X 10.13.3 (17D102)
       com.apple.quicktime.creationdate: 2018-02-26T10:45:50-0600
     Duration: 00:00:04.35, start: 0.000000, bitrate: 10947 kb/s
       Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1396x928 [SAR 1:1 DAR 349:232], 10701 kb/s, 60 fps, 60 tbr, 6k tbn, 12k tbc (default)
       Metadata:
         creation_time   : 2018-02-26T16:46:00.000000Z
         handler_name    : Core Media Data Handler
         encoder         : H.264

    And here is the information for the ffmpeg-compressed version :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha-lg.mov':
     Metadata:
       major_brand     : qt  
       minor_version   : 512
       compatible_brands: qt  
       encoder         : Lavf57.83.100
     Duration: 00:00:04.35, start: 0.000000, bitrate: 1923 kb/s
       Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1396x928 [SAR 1:1 DAR 349:232], 1783 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
       Metadata:
         handler_name    : DataHandler
         encoder         : Lavc57.107.100 libx264
  • How can I retain 2x pixel density when encoding Retina screen capture with ffmpeg ?

    26 février 2018, par hfossli

    Whenever I use ffmpeg to encode a HiDPI/Retina screen recording, the video plays at 2x the size, so it looks fuzzy, because the pixel density is not retained.

    How can I retain the original pixel density of HiDPI screen recordings with ffmpeg ?

    How to reproduce :

    1. Use QuickTime Player to create a Screen Recording on a Retina Mac.
    2. Play the video you recorded in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 2:1 on your Retina Display, so the video looks sharp. It’s playing in half the space of the actual recorded pixels.
    3. Use ffmpeg to encode the video using a command like this :

      ffmpeg -i haha.mov -c:v libx264 -crf 23 haha-lg.mov
    4. Play the new ffmpeg-compressed video in QuickTime Player using the ⌘1 Actual Size view. Notice that it’s playing 1:1, so the video looks fuzzy.

    To clarify, the video does not look blurry because it was compressed. Rather, it looks blurry because the video is being played twice as big as it should be, at a 1:1 pixel density, instead of the required 2:1 pixel density, presumably because some metadata is being discarded when encoding.

    For the record, VLC plays both videos too big (blurry). So being able to play HiDPI videos seems to be a feature of QuickTime Player.

    Here is the detailed information ffmpeg shows for the original screen recording :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha.mov':
     Metadata:
       major_brand     : qt  
       minor_version   : 0
       compatible_brands: qt  
       creation_time   : 2018-02-26T16:46:00.000000Z
       com.apple.quicktime.make: Apple
       com.apple.quicktime.model: iMac18,3
       com.apple.quicktime.software: Mac OS X 10.13.3 (17D102)
       com.apple.quicktime.creationdate: 2018-02-26T10:45:50-0600
     Duration: 00:00:04.35, start: 0.000000, bitrate: 10947 kb/s
       Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1396x928 [SAR 1:1 DAR 349:232], 10701 kb/s, 60 fps, 60 tbr, 6k tbn, 12k tbc (default)
       Metadata:
         creation_time   : 2018-02-26T16:46:00.000000Z
         handler_name    : Core Media Data Handler
         encoder         : H.264

    And here is the information for the ffmpeg-compressed version :

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'haha-lg.mov':
     Metadata:
       major_brand     : qt  
       minor_version   : 512
       compatible_brands: qt  
       encoder         : Lavf57.83.100
     Duration: 00:00:04.35, start: 0.000000, bitrate: 1923 kb/s
       Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1396x928 [SAR 1:1 DAR 349:232], 1783 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
       Metadata:
         handler_name    : DataHandler
         encoder         : Lavc57.107.100 libx264