Recherche avancée

Médias (0)

Mot : - Tags -/serveur

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

Autres articles (102)

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

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

  • Contribute to translation

    13 avril 2011

    You can help us to improve the language used in the software interface to make MediaSPIP more accessible and user-friendly. You can also translate the interface into any language that allows it to spread to new linguistic communities.
    To do this, we use the translation interface of SPIP where the all the language modules of MediaSPIP are available. Just subscribe to the mailing list and request further informantion on translation.
    MediaSPIP is currently available in French and English (...)

Sur d’autres sites (7639)

  • ffmpeg progress is freezing frames when scene change

    19 août 2017, par Karol

    I’m capturing data from IP camera with RTSP protocol with ffmpeg with command :

    ffmpeg -rtsp_transport tcp -progress /media/kamip/stats.txt -i rtsp://192.168.1.220:554/live/h264/ch0
    -c:v copy -c:a copy -strict 1 -map 0 -f segment -strftime 1
    -segment_time 1800 /media/kamip/cam_%d_%m_%Y_%H_%M_%S.mkv

    I’m using this for 5 cameras. One is different type and it is in different location.
    Because ffmpeg does not support reconnect I’m writing status to /media/kamip/stats.txt file. In another script I’m parsing this output and every 30 seconds I’m checking if frame number changed, if yes - it is ok, if not, I’m restarting above command.

    The problem is only in the night. When is quite dark and suddenly lights on, for example when car is parking, the /media/kamip/stats.txt is showing the same frame number, so my script is recognizing this as a lost connection (video freeze)

    I tried "-strict 1" option and I think it is better (one false alarm per day instead of 10 per day), so I think this may be related to ffmpeg, not camera/video source, especially because the video is fine even frame number reported by ffmpeg is still the same. Also VLC does not have this kind of problem (but I cannot use it currently for this camera)

    I found that ffmpeg has build-in scene change detector, but it should works only when encoding video (I’m using "copy" option for audio and video) ?

    I’m thinking about different way of analyzing the video capturing, but this "-progress" in ffmpeg should works fine - and it is working fine for other cameras for few years).

    I also do not see any errors,
    when I encoded one cutted file with "-loglevel debug" I saw only information like below :

    [libx264 @ 0x25d77a0] scene cut at 174 Icost:2049115 Pcost:2006553
    ratio:0.0208 bias:0.1387 gop:54 (imb:3186 pmb:168)

    ffmpeg in latest version

    ffmpeg version 3.3.3-1ubuntu1~16.04.york0 Copyright (c) 2000-2017 the FFmpeg developers
    built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609

    any help will be appreciated

  • ffmpeg : playing media files does not release processor after media ends ?

    2 septembre 2017, par Blake Senftner

    I have a commercial C++ application which uses FFMPEG’s libav series of dlls to play media in a Windows application. I basically started with the dranger tutorial about two years ago, and created a library that can playback USB cameras, IP camera / online streams, and media files on disk. (http://dranger.com/ffmpeg/)

    My question is directed at anyone who has created their own similar library :

    I recently noticed after playing a video file from disk (as opposed to a live stream from USB or IP source), my 8 core i7 workstation will show 28-29% CPU usage after a media file has ended. My application can play an unlimited number of videos, and each "virtual video panel" (not a window, just a "virtual tab" created using wxWidgets that holds an OpenGL context that I use to glDrawPixels() to the visible app panel) will play any of the three media types fine (USB, IP stream or media file) and when I stop a USB or IP stream my application’s CPU usage drops to zero. But when I "stop" a media file playing or the media file ends on its own the CPU usage does not drop - until the application quits.

    Three media files playing will take my application to 80-83% CPU, and it never drops. UNLESS I reuse that same "virtual video panel" to play a USB or IP stream. If I stop those streams, CPU usage is released.

    MP4 (h264) video files exhibit this "holding a processor" problem.

    MP4 (mpeg2) files do not.

    MP4 (h265) files do not.

    MPG (mpeg1) files do not.

    ASF (MS MPEG-4 Video v3) files do not.

    MKV (vp8) files do not.

    MOV files using h265 do not, as well as MOV (h264) files do not.

    FLV (sorensen) files do not, as well as FLV (h264) files do not.

    So it is not just the h264 codec.

    Anyone know what is going on, and how I tell libav to release CPU usage when a media file is no longer playing ?

  • Remove support for building for mingw32ce (Windows CE)

    30 août 2017, par Martin Storsjö
    Remove support for building for mingw32ce (Windows CE)
    

    The toolchain for this target is unmaintained since many years.

    While it has been continuously build tested on fate, it hasn’t
    actually been tested at runtime since many, many years (and back
    then, only a few codecs in libavcodec were tested).

    So far, keeping support for it has been mostly effortless, but
    the compiler does seem to have issues with dllimported data symbols,
    ending up as internal compiler errors in some cases. Instead of
    jumping through further hoops to work around that, just remove the
    target.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DBH] configure
    • [DBH] libavformat/os_support.h
    • [DBH] libavutil/file_open.c
    • [DBH] libavutil/wchar_filename.h
    • [DBH] tools/qt-faststart.c