Recherche avancée

Médias (1)

Mot : - Tags -/belgique

Autres articles (66)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • 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

  • Changer son thème graphique

    22 février 2011, par

    Le thème graphique ne touche pas à la disposition à proprement dite des éléments dans la page. Il ne fait que modifier l’apparence des éléments.
    Le placement peut être modifié effectivement, mais cette modification n’est que visuelle et non pas au niveau de la représentation sémantique de la page.
    Modifier le thème graphique utilisé
    Pour modifier le thème graphique utilisé, il est nécessaire que le plugin zen-garden soit activé sur le site.
    Il suffit ensuite de se rendre dans l’espace de configuration du (...)

Sur d’autres sites (12488)

  • How can I use FFMpeg with PHP in a Vagrant environment ?

    31 juillet 2015, par curtisblackwell

    I’ve got this working on a DigitalOcean server, but I can’t seem to get it working locally.

    My Vagrant box is ubuntu/trusty64. When I ssh into the machine to check out the permissions of the ffmpeg binary, it’s 664. I tried running chmod 755 ffmpeg (w/ and w/o sudo), but it has no effect and outputs no response. I’m the owner, so chown wouldn’t make any difference (but also doesn’t work, w/ or w/o sudo). Outside of the Vagrant machine, the file permissions are 755 and owned by me, though that doesn’t seem to matter.

    The binaries are static builds from a site linked to on the official FFMpeg site’s download page.

    Running cat /etc/*-release on both the remote DO server and the Vagrant machine returns the same result :

    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=14.04
    DISTRIB_CODENAME=trusty
    DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"
    NAME="Ubuntu"
    VERSION="14.04.2 LTS, Trusty Tahr"
    ID=ubuntu
    ID_LIKE=debian
    PRETTY_NAME="Ubuntu 14.04.2 LTS"
    VERSION_ID="14.04"
    HOME_URL="http://www.ubuntu.com/"
    SUPPORT_URL="http://help.ubuntu.com/"
    BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

    When attempting to execute the binary through PHP on the Vagrant machine (with exec()), I get a 126 exit code.

    What else should I try to get this working ?

  • OpenCV ffmpeg DLL not loaded when running app on Windows 7, works on 8 and 10

    4 avril 2018, par David G.

    I need to maintain a desktop app written in C++, using Qt and OpenCV for some video processing. As far as I understood, the decoding part of OpenCV is delegated to ffmpeg in a separate DLL for licensing reasons.

    The development environment is on Windows 10, using QT Creator and MSVC12 64-bit as compiler. OpenCV version is 3.0, the official distribution. Here, everything runs fine, I am able to decode a video using VideoCapture::open().

    Issues arise when I try to run the application in a standalone fashion with all the required DLLs in the same folder as the .exe file. All cases below are 64-bit OSes.

    On a Windows 10 computer, not the same as the developement machine and no developer libraries present, the video decoding works fine. I have tested on a Windows 8 machine as well, no issues so far.

    On Windows 7, the things get tricky. The same video files that successfully load during the previous tests are not recognized by the app at all i.e. the isOpened call on VideoCapture returns false. For further testing, I stripped the opencv_ffmpeg300_64.dll file to narrow down the issue on Windows 10 and 8 ; as expected, without this DLL the app is no more able to open the same video files.

    It seems that the DLL is simply not recognized on Windows 7.

    Edit : Further investigation using Process Explorer clearly shows that the aforementioned DLL is not loaded when the app runs on Windows 7.

    • Is there something specific about how Windows 7 manages the DLL path resolution and eventual security measures ? Seems normal that the first search location is the same folder as the executable, which is the case here.

    I have tried to trace using WinApiOverride32, with no results.

  • OpenCV ffmpeg DLL not loaded when running app on Windows 7, works on 8 and 10

    2 novembre 2016, par David G.

    I need to maintain a desktop app written in C++, using Qt and OpenCV for some video processing. As far as I understood, the decoding part of OpenCV is delegated to ffmpeg in a separate DLL for licensing reasons.

    The development environment is on Windows 10, using QT Creator and MSVC12 64-bit as compiler. OpenCV version is 3.0, the official distribution. Here, everything runs fine, I am able to decode a video using VideoCapture::open().

    Issues arise when I try to run the application in a standalone fashion with all the required DLLs in the same folder as the .exe file. All cases below are 64-bit OSes.

    On a Windows 10 computer, not the same as the developement machine and no developer libraries present, the video decoding works fine. I have tested on a Windows 8 machine as well, no issues so far.

    On Windows 7, the things get tricky. The same video files that successfully load during the previous tests are not recognized by the app at all i.e. the isOpened call on VideoCapture returns false. For further testing, I stripped the opencv_ffmpeg300_64.dll file to narrow down the issue on Windows 10 and 8 ; as expected, without this DLL the app is no more able to open the same video files.

    It seems that the DLL is simply not recognized on Windows 7.

    Edit : Further investigation using Process Explorer clearly shows that the aforementioned DLL is not loaded when the app runs on Windows 7.

    • Is there something specific about how Windows 7 manages the DLL path resolution and eventual security measures ? Seems normal that the first search location is the same folder as the executable, which is the case here.

    I have tried to trace using WinApiOverride32, with no results.