
Recherche avancée
Autres articles (100)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (14110)
-
FFMPEG library Integration unsuccess
1er septembre 2017, par Alok Kumar VermaI’m stuck with the integration of the FFMPEG file. I’m using Android Studio 2.3.3
I’ve followed this link and hence got to know how to do this but all I’m getting is a failure.
Links
Now I"ve my ndk installed in this path : /Users/alok/Library/Android/sdk/ndk-bundle
And I’ve downloaded the newest version of the FFMPEG i.e., 3.3.3 unzipped it in the sources folder of ndk-bundle
Now I’ve followed this and implemented everything as said.
- Editing the Configure File using TEXTVIEW in my mac
-
Creating a file name build_android.sh and copy pasting the given code. However I’ve changed the NDK path in my case in the code the code is here
NDK=/Users/alok/Library/Android/sdk/ndk-bundle
SYSROOT=$NDK/platforms/android-23/arch-arm/
TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -
Now opening the folder through terminal and then typing this command sudo chmod +x build_android.sh followed by this sudo ./build_android.sh
The result is : No android name folder created inside under the folder FFMPEG 3.3.3 in this root i.e., /ndk-bundle/sources/ffmpeg 3.3.3/
and the terminal shows this output :
./configure: line 3341: syntax error near unexpected token `2'
./configure: line 3341:
DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>/dev/null | sed -e "/^\#.*/d" -e "s,^[[:space:]]*$(@F),$(@D)/$(@F)," > $(@:.o=.d)''
Makefile:2: config.mak: No such file or directory
Makefile:67: /common.mak: No such file or directory
Makefile:114: /libavutil/Makefile: No such file or directory
Makefile:114: /library.mak: No such file or directory
Makefile:116: /doc/Makefile: No such file or directory
Makefile:206: /tests/Makefile: No such file or directory
make: *** No rule to make target /tests/Makefile'. Stop.Hence I’m not been able to move next due to this which creating a JNI folder and stuff. I’m a beginner with FFMPEG and want to integrate it.
NOTE : I’ve already used this library in my gradle
compile ‘com.writingminds:FFmpegAndroid:0.3.2’
For easy approach and things are working fine too but due to the older version I’m getting wrong outputs, so need to update it and there is one way and this is the way to do it.
-
Progress with rtc.io
12 août 2014, par silviaAt the end of July, I gave a presentation about WebRTC and rtc.io at the WDCNZ Web Dev Conference in beautiful Wellington, NZ.
Putting that talk together reminded me about how far we have come in the last year both with the progress of WebRTC, its standards and browser implementations, as well as with our own small team at NICTA and our rtc.io WebRTC toolbox.
One of the most exciting opportunities is still under-exploited : the data channel. When I talked about the above slide and pointed out Bananabread, PeerCDN, Copay, PubNub and also later WebTorrent, that’s where I really started to get Web Developers excited about WebRTC. They can totally see the shift in paradigm to peer-to-peer applications away from the Server-based architecture of the current Web.
Many were also excited to learn more about rtc.io, our own npm nodules based approach to a JavaScript API for WebRTC.
We believe that the World of JavaScript has reached a critical stage where we can no longer code by copy-and-paste of JavaScript snippets from all over the Web universe. We need a more structured module reuse approach to JavaScript. Node with JavaScript on the back end really only motivated this development. However, we’ve needed it for a long time on the front end, too. One big library (jquery anyone ?) that does everything that anyone could ever need on the front-end isn’t going to work any longer with the amount of functionality that we now expect Web applications to support. Just look at the insane growth of npm compared to other module collections :
Packages per day across popular platforms (Shamelessly copied from : http://blog.nodejitsu.com/npm-innovation-through-modularity/) For those that – like myself – found it difficult to understand how to tap into the sheer power of npm modules as a font end developer, simply use browserify. npm modules are prepared following the CommonJS module definition spec. Browserify works natively with that and “compiles” all the dependencies of a npm modules into a single bundle.js file that you can use on the front end through a script tag as you would in plain HTML. You can learn more about browserify and module definitions and how to use browserify.
For those of you not quite ready to dive in with browserify we have prepared prepared the rtc module, which exposes the most commonly used packages of rtc.io through an “RTC” object from a browserified JavaScript file. You can also directly download the JavaScript file from GitHub.
Using rtc.io rtc JS library So, I hope you enjoy rtc.io and I hope you enjoy my slides and large collection of interesting links inside the deck, and of course : enjoy WebRTC ! Thanks to Damon, JEeff, Cathy, Pete and Nathan – you’re an awesome team !
On a side note, I was really excited to meet the author of browserify, James Halliday (@substack) at WDCNZ, whose talk on “building your own tools” seemed to take me back to the times where everything was done on the command-line. I think James is using Node and the Web in a way that would appeal to a Linux Kernel developer. Fascinating !!
-
7 Reasons to Migrate from Google Analytics to Matomo Now
15 mai 2022, par Erin