Recherche avancée

Médias (1)

Mot : - Tags -/3GS

Autres articles (89)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

  • Menus personnalisés

    14 novembre 2010, par

    MediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
    Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
    Menus créés à l’initialisation du site
    Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...)

Sur d’autres sites (15748)

  • Announcing our latest open source project : DeviceDetector

    30 juillet 2014, par Stefan Giehl — Community, Development, Meta, DeviceDetector

    This blog post is an announcement for our latest open source project release : DeviceDetector ! The Universal Device Detection library will parse any User Agent and detect the browser, operating system, device used (desktop, tablet, mobile, tv, cars, console, etc.), brand and model.

    Read on to learn more about this exciting release.

    Why did we create DeviceDetector ?

    Our previous library UserAgentParser only had the possibility to detect operating systems and browsers. But as more and more traffic is coming from mobile devices like smartphones and tablets it is getting more and more important to know which devices are used by the websites visitors.

    To ensure that the device detection within Piwik will gain the required attention, so it will be as accurate as possible, we decided to move that part of Piwik into a separate project, that we will maintain separately. As an own project we hope the DeviceDetector will gain a better visibility as well as a better support by and for the community !

    DeviceDetector is hosted on GitHub at piwik/device-detector. It is also available as composer package through Packagist.

    How DeviceDetector works

    Every client requesting data from a webserver identifies itself by sending a so-called User-Agent within the request to the server. Those User Agents might contain several information such as :

    • client name and version (clients can be browsers or other software like feed readers, media players, apps,…)
    • operating system name and version
    • device identifier, which can be used to detect the brand and model.

    For Example :

    Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.99 Mobile Safari/537.36

    This User Agent contains following information :

    Operating system is Android 4.4.2, client uses the browser Chrome Mobile 32.0.1700.99 and the device is a Google Nexus 5 smartphone.

    What DeviceDetector currently detects

    DeviceDetector is able to detect bots, like search engines, feed fetchers, site monitors and so on, five different client types, including around 100 browsers, 15 feed readers, some media players, personal information managers (like mail clients) and mobile apps using the AFNetworking framework, around 80 operating systems and nine different device types (smartphones, tablets, feature phones, consoles, tvs, car browsers, cameras, smart displays and desktop devices) from over 180 brands.

    Note : Piwik itself currently does not use the full feature set of DeviceDetector. Client detection is currently not implemented in Piwik (only detected browsers are reported, other clients are marked as Unknown). Client detection will be implemented into Piwik in the future, follow #5413 to stay updated.

    Performance of DeviceDetector

    Our detections are currently handled by an enormous number of regexes, that are defined in several .YML Files. As parsing these .YML files is a bit slow, DeviceDetector is able to cache the parsed .YML Files. By default DeviceDetector uses a static cache, which means that everything is cached in static variables. As that only improves speed for many detections within one process, there are also adapters to cache in files or memcache for speeding up detections across requests.

    How can users help contribute to DeviceDetector ?

    Submit your devices that are not detected yet

    If you own a device, that is currently not correctly detected by the DeviceDetector, please create a issue on GitHub
    In order to check if your device is detected correctly by the DeviceDetector go to your Piwik server, click on ‘Settings’ link, then click on ‘Device Detection’ under the Diagnostic menu. If the data does not match, please copy the displayed User Agent and use that and your device data to create a ticket.

    Submit a list of your User Agents

    In order to create new detections or improve the existing ones, it is necessary for us to have lists of User Agents. If you have a website used by mostly non desktop devices it would be useful if you send a list of the User Agents that visited your website. To do so you need access to your access logs. The following command will extract the User Agents :

    zcat ~/path/to/access/logs* | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -n20000 > /home/piwik/top-user-agents.txt

    If you want to help us with those data, please get in touch at devicedetector@piwik.org

    Submit improvements on GitHub

    As DeviceDetector is free/libre library, we invite you to help us improving the detections as well as the code. Please feel free to create tickets and pull requests on Github.

    What’s the next big thing for DeviceDetector ?

    Please check out the list of issues in device-detector issue tracker.

    We hope the community will answer our call for help. Together, we can build DeviceDetector as the most powerful device detection library !

    Happy Device Detection,

  • Unable to 'make' android ndk project - build fails : [build-openh264-x86] Error 2

    18 décembre 2015, par NoobNinja

    I’ve attempted these two fixes I’ve found while researching the issue :

    android update project  --23 --/Users/ajswann/Downloads/android-sdk-macosx

    make OS=android NDKROOT=/Users/ajswann/Downloads/android-sdk-macosx TARGET=android-19 ARCH=x86 clean

    ...however neither seems to resolve the issue.

    Any input/suggestions are appreciated.

    P.S.

    I’m running OSX - could this be an issue with attempting to run an x86 architecture on a 64 bit machine ?

    Error Message :

    chris-mini-mac:linphone-android ajswann$ sudo make
    ls: /opt/local/etc/openssl/certs: No such file or directory
    /Users/ajswann/Downloads/android-sdk-macosx/tools/android update project --path . --target android-23
    Updated project.properties
    Updated local.properties
    build.xml: Found version-tag: custom. File will not be updated.
    Updated file ./proguard-project.txt
    It seems that there are sub-projects. If you want to update them
    please use the --subprojects parameter.
    /Users/ajswann/Downloads/android-sdk-macosx/tools/android update test-project --path tests -m .
    Resolved location of main project to: /groupchat/linphone-android/tests
    Updated project.properties
    Updated local.properties
    Updated file tests/proguard-project.txt
    Updated ant.properties
    /Users/ajswann/Downloads/android-sdk-macosx/tools/android update project --path liblinphone_tester --target android-23
    Updated project.properties
    Updated local.properties
    Updated file liblinphone_tester/proguard-project.txt
    ant -e -S clean
    Buildfile: /groupchat/linphone-android/build.xml
    No sub-builds to iterate on
    mkdir -p /groupchat/linphone-android/submodules/externals/openh264/include/wels
    rsync -rvLpgoc --exclude ".git"  /groupchat/linphone-android/submodules/externals/openh264/codec/api/svc/* /groupchat/linphone-android/submodules/externals/openh264/include/wels/.
    building file list ... done

    sent 156 bytes  received 20 bytes  352.00 bytes/sec
    total size is 56216  speedup is 319.41
    mkdir -p /groupchat/linphone-android/submodules/externals/build/openh264
    mkdir -p /groupchat/linphone-android/submodules/externals/build/openh264/arm
    cd /groupchat/linphone-android/submodules/externals/build/openh264/arm \
       && rsync -rvLpgoc --exclude ".git"  /groupchat/linphone-android/submodules/externals/openh264/* .
    building file list ... done

    sent 18841 bytes  received 20 bytes  37722.00 bytes/sec
    total size is 48272799  speedup is 2559.40
    cd /groupchat/linphone-android/submodules/externals/build/openh264/arm && \
       make libraries -j4 OS=android ARCH=arm NDKROOT=/Users/ajswann/Downloads/android-ndk-r10e TARGET=android-19
    cd ./ && sh ./codec/common/generate_version.sh
    Keeping existing codec/common/inc/version_gen.h
    mkdir -p /groupchat/linphone-android/submodules/externals/build/openh264
    mkdir -p /groupchat/linphone-android/submodules/externals/build/openh264/x86
    cd /groupchat/linphone-android/submodules/externals/build/openh264/x86 \
       && rsync -rvLpgoc --exclude ".git"  /groupchat/linphone-android/submodules/externals/openh264/* .
    building file list ... done

    sent 18841 bytes  received 20 bytes  12574.00 bytes/sec
    total size is 48272799  speedup is 2559.40
    cd /groupchat/linphone-android/submodules/externals/build/openh264/x86 && \
       make libraries -j4 OS=android ARCH=x86 NDKROOT=/Users/ajswann/Downloads/android-ndk-r10e TARGET=android-19
    cd ./ && sh ./codec/common/generate_version.sh
    nasm -DX86_32 -f elf -I./codec/common/x86/   -o codec/decoder/core/x86/dct.o codec/decoder/core/x86/dct.asm
    codec/decoder/core/x86/dct.asm:1: error: label or instruction expected at start of line
    codec/decoder/core/x86/dct.asm:144: error: label or instruction expected at start of line
    codec/decoder/core/x86/dct.asm:234: error: symbol `IdctResAddPred_mmx' redefined
    codec/decoder/core/x86/dct.asm:262: error: symbol `WelsBlockZero16x16_sse2' redefined
    codec/decoder/core/x86/dct.asm:276: error: symbol `WelsBlockZero8x8_sse2' redefined
    codec/decoder/core/x86/dct.asm:287: error: label or instruction expected at start of line
    make[1]: *** [codec/decoder/core/x86/dct.o] Error 1
    make[1]: *** Waiting for unfinished jobs....
    Keeping existing codec/common/inc/version_gen.h
    make[1]: *** wait: No child processes.  Stop.
    make: *** [build-openh264-x86] Error 2

    Source Repository (I simply clone it, add the platform-tools and tools folder from my android-sdk and run ’make’ and I get this error) :

    https://github.com/TheBaobabTeam/linphone-android

  • FFmpeg 32-bit DLLs fail to load on Windows when switching target platform to 32-bit in C# project (Linux cross-compile with MinGW)

    8 novembre 2024, par ryan

    I’m working on a C# project in Windows that integrates FFmpeg DLLs. I need both 32-bit and 64-bit FFmpeg DLLs. The 64-bit DLLs load and work fine, but when I change the target platform in my project settings to 32-bit, some 32-bit DLLs (specifically avfilter-7.dll) fail to load, even though they’re in the correct directory.

    


    Code :

    


    case PlatformID.Win32Windows:
    return WindowsNativeMethods.LoadLibrary(libraryName);


    


    is returning a null pointer for avfilter-7.dll.

    


    Error Received :

    


    System.Runtime.InteropServices.Marshal.GetLastWin32Error() = 0x0000007e 


    


    Which I think translates to ERROR_MOD_NOT_FOUND.

    


    Environment & Context :

    


      

    • Linux VM : Using a Linux virtual machine to cross-compile FFmpeg for Windows.
    • 


    • Tool : ffmpeg-windows-build-helpers script from https://github.com/rdp/ffmpeg-windows-build-helpers.
    • 


    • Cross-Compiler : MinGW (latest version installed on VM).
    • 


    • Target Architectures : Both 32-bit and 64-bit DLLs for Windows.
    • 


    • FFmpeg Version : n4.4.5 (using —ffmpeg-git-checkout-version=n4.4.5).
    • 


    


    Compilation Command :
Using the helper script, I’ve tried the following command to generate the 32 and 64 bit shared libraries :

    


    ./cross_compile_ffmpeg.sh --ffmpeg-git-checkout-version=n4.4.5 --disable-nonfree=y --build-libmxf=n --build-mp4box=n --build-vlc=n --build-svt-hevc=n --build-svt-vp9=n --build-dvbtee=n --build-dependencies=y --build-mplayer=n --build-ffmpeg-static=n --build-ffmpeg-shared=y --prefer-stable=y --build-x264-with-libav=n


    


    I’ve also updated MinGW to the latest version on the VM to ensure compatibility.

    


    Questions :

    


      

    1. What might be causing the 32-bit FFmpeg DLLs (like avfilter-7.dll) to fail to load on a Windows platform, while 64-bit DLLs work fine ?
    2. 


    3. Are there specific flags or steps in the build process needed to ensure compatibility for 32-bit FFmpeg DLLs in a 64-bit Windows environment ?
    4. 


    5. Are there common pitfalls when cross-compiling 32-bit and 64-bit FFmpeg DLLs with MinGW on Linux that could cause these loading issues ?
    6. 


    


    Any insights or additional troubleshooting tips would be greatly appreciated !