I am trying to add additional codec support to Chromium for HTML5 media play back. I've installed the package chromium-codecs-ffmpeg-extras to include a few more than what is included in original download.
I am curious if anyone knows the amount of work/ if its possible to fork the chromium code and add additional codec supports (.ts, .avi, etcc). Is it as simple as forcing chromium to use a different ffmpeg library or possibly use VLC to decode all of its videos?
Related
We compiled WebRTC based on souce code ,using code of milesone m91,and with sctp not built.
1.Our code is based at WebRTC m91
2.usrsctp is disalbed and not built by setting these values to false in WebRTC.gni,so that usrsctp won't be built.
1) rtc_enable_sctp=false
2) rtc_build_usrsctp=false
3.build libjingle_peerconnection_so.so by command
autoninja -C out/arm libjingle_peerconnection_so
4.integrate the compilied libjingle_peerconnection_so.so to App and submit it to google play store
Though usrsctp is not built,however,the google play store detects that I'm using a vulnerable versions of WebRTC use usrsctp.
Here is the FAQ from google play store.
How to fix apps with bad WebRTC versions
Here is my questions
Question1：
How does google store dectect that I'm using a vulnerable versions of WebRTC use usrsctp ?The rules are not clear to me .
by scanning the symbols in .so ?
by scanning the meta infos ?
Question2:
Is there a way to know the version of WebRTC that libjingle_peerconnection_so.so is built from ?
In other words,given a specific so file libjingle_peerconnection_so.so ,How can I know that it's built from M91 or M102 ?Is there any meta informations about the version of WebRTC we are used in the compiled products ?
WebRTC M012 or higher is required to pass this check on Play, even if usrsctp is removed. While usrsctp is our most pressing concern, many other security issues have been fixed in other components. It is highly recommended that you update to a more recent version, and be prepared to update on an on-going basis in the future if more serious vulnerabilities.
Please don't attempt to circumvent this check in Play, as you will miss important notifications about future security issues, and there is no guarantee that detection will remain the same
I've filed an issue to WebRTC Issue 14664: usrsctp is not built but detected by goolge play store
I'm trying to study webRTC and want to learn about how it encodes and transport the media stream.
Are codes of this part of webRTC already included in the chromium source codes?
http://code.google.com/p/chromium/wiki/LinuxBuildInstructions
Thanks~!
yes and no.
The core of webrtc (including all the transport) is in the third party libwertc code, you can find information at webrtc.org.
The codec and other libraries are shared with Chrome, and libwebrtc import a copy of chromium when building from source. THe exact list of libs that are shared are in this file
The "capturer" is in the chrome code, more info there.
I've got a simple application using WebKitGTK 1.6.0 that simply displays a webpage in a window.
When I browse a page using it that contains an Ogg/Theora video and HTML5 video element it appears this simple application is using some mozilla plugins and even xulrunner. Can somebody tell me why this is?
Here is a list of files open by the program using lsof.
I built WebKitGTK 1.6.0 and most of it's dependencies from source including gstreamer-0.10 and the gstreamer plugins. No where do I recall configuring WebKitGTK to using any mozilla plugins or xulrunner.
What might be causing the mozilla plugins, libtotem and xulrunner to be loaded? I provided the link to the files the application is using in hopes that it might provide a clue.
Lol, found the reason. I have FireFox, totem and totem-mozplugin installed on my system. Once I removed totem and totem-mozplugin, WebKitGTK used the appropriate Gstreamer plugins to render the video and audio.
I'm building an AIR application using Flex where I use the NativeProcess API to resize images through ImageMagick using the convert program. Does anyone know how I can package "convert" with my application without needing to install ImageMagick on the user's system?
I'm looking for a solution on Mac and PC. (especially on Mac).
I don't have that much experience with building/installing something like ImageMagick so I'm wondering if it can be done in one file (convert only) so that I can directly call it in my app without the user needing to install anything prior on his/her system.
You have to package your AIR application as native installer or with a captive runtime. Both methods allow you to add additional files to your package. Adding the convert executable won't be enough, though, because it depends on a number of ImageMagick shared libraries, loadable modules for different image formats, and possibly other files. To get started, you can add the whole ImageMagick directory to your package. You can find the path to the packaged convert executable using File.applicationDirectory.
I'm not an expert on Flex, but there is a documented method for packaging native extensions at Adobe. Won't this work?
I know this question is very old, but I have the same issue so I stumbled on it !
I actually found a Mac only workaround solution, that is to use sips instead of ImageMagick. Advantage being that sips is included in all Mac's (Well as far as I know, from 10.4 to 10.8).
In my case, all functionalities that I used ImageMagick for are also available in sips, so maybe it could fit you too !
I found someone who created static libs of convert and identify programs for Mac. For Windows these are available already on the ImageMagick website but for Mac you need to build these from source. Important on Mac is to not call Convert directly but use a bash script which sets the export paths first and then runs convert in order for it to work!
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).