I have known that cef3's older version like 2623 can enable H264 support through modify chromium\src\cef\cef.gypi file.
But in recent versions like 3071 or 3029, cef3 has removed cef.gypi file.
I have googled this, but what I found is still through modify the cef.gypi file.
Since this methold is only valid for older versions. Is there another way that I can make newer version enable H264 support ?
Thanks very much!
Indeed the compile option to support proprietary codecs was moved.
the magic now happens here:
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
there is 2 batch files that you should update/create (as found here):
c:\code\chromium_git\update.bat:
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=C:\code\chromium_git --depot-tools-dir=C:\code\depot_tools --no-distrib --no-build
c:\code\chromium_git\chromium\src\cef\create.bat:
set CEF_USE_GN=1
set GN_DEFINES=is_win_fastlink=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
call cef_create_projects.bat
There is 2 wiki articles that explain how to build CEF/Chromium:
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart.md
and BranchesAndBuilding in the same wiki
Update:
Here are more links with infos on Chromium build flags:
https://www.chromium.org/developers/gn-build-configuration
https://www.chromium.org/audio-video
https://chromium.googlesource.com/chromium/src/+/lkcr/docs/windows_build_instructions.md
... GYP/GN flags which can alter behaviour of Chromium's HTML5 audio/video implementation.
ffmpeg_branding
Overrides which version of FFmpeg to use
Default: $(branding)
Values:
Chrome - includes additional proprietary codecs (MP3, etc..) for use with Google Chrome
Chromium - builds default set of codecs
proprietary_codecs
Alters the list of codecs Chromium claims to support, which affects <source> and canPlayType() behaviour
Default: 0(gyp)/false(gn)
Values:
0/false - <source> and canPlayType() assume the default set of codecs
1/true - <source> and canPlayType() assume they support additional proprietary codecs
Related
I've been using the commercial Google Chrome to do some window.MediaRecorder stuff with h.264 (aka avc1).
To see whether that works I use
const ok = window.MediaRecorder.isTypeSupported('video/webm; codecs="avc1.42E01E"')
On the commercial browser this returns true, but on CEF it returns false. Is there a way around this?
I guess the h.264 / avc1 support is something Google adds when they do their commercial build of the browser. But, there are other command-line arguments that enable features for launching CEF. I wonder if there's one for this.
Yes, it can support H.264, but you need to build it with the proprietary codes feature enabled.
Follow these directions and use this value for GN_DEFINES.
set GN_DEFINES=proprietary_codecs=true ffmpeg_branding=Chrome
More to come.
The gpsd program lets linux users cleanly organize their GPS peripheral data, such that a command line program like cgps or a graphical one like xgps can read the data, and write to a socket, like /var/run/gpsd.sock.
There's a nice tutorial on the net for rigging a raspberry pi to use this data. This is all well and good, but how can I integrate this data in firefox or chromium, as the geolocation API? Is there a specific build process I might need? For instance, setting a ./configure flag or something? Is there a way to integrate this data in a prebuilt version of either browser?
Firefox on Linux supports gpsd - it was added in Firefox 4, removed in Firefox 23 and added back in Firefox 50.
However, it still needs to be enabled during build, with --enable-gpsd (which seems not to be the case yet in Ubuntu) and in the configuration, by following these steps:
Navigate to about:config
Create a new string preference, name geo.location.use_gpsd value true
Prior to Firefox 23, you had to:
Create a new string preference, name geo.gpsd.host.ipaddr value localhost
Create a new boolean value, name geo.gpsd.logging.enabled value true
Google Chrome had gpds support added in November 2011 and removed in October 2013. It looks like hardware GPS support is not a priority. If this was handled in Chrome OS, it might be possible to use the same mechanism, but I don't see support there either.
Someone built an extension which attempts to provide support in recent versions, requiring to install a script system-side.
Firefox on linux used to support gpsd.
Navigate to about:config
Create a new string preference, name geo.gpsd.host.ipaddr value localhost
Create a new boolean value, name geo.gpsd.logging.enabled value true
However, it seems that the gpsd support has been removed
Chromium seems to have had gpsd support in the past, but I can't find anything about it now. It looks like hardware gps support is not a priority. If this was handled in ChromeOS, it might be possible to use the same mechanism, but I don't see support there either.
In both cases, it should be possible to write an extension to fake the GPS coordinates, which could read from your real GPS.
Two issues with mp4 videos hosted on Microsoft Azure in Google Chrome only:
Background video don't loops (implemented by vide.js)
Video don't seeks by vjs player.
I know, server should send video files with http status 206. But my file sends with 200 at the first time, and if it doesn't made full download, problem still remains. How to setup right sending video files on Azure?
The reason why you cannot seek within the video is caused by the storage version.
By default, the version is set to 2009-09-19. Unfortunately, this version does not support the Range Header which is required to seek within a video (see https://msdn.microsoft.com/en-us/library/azure/ee691967.aspx). Therefore, you have to change the default version to at least 2011-08-18.
There are several way to change the default version.
From .NET you can use CloudBlobClient.SetServiceProperties Method.
Another option is using the utility from https://github.com/Plasma/AzureBlobUtility to change the default service version.
Also you can use the Azure REST API to set the version as documented on https://msdn.microsoft.com/en-us/library/azure/hh452235.aspx.
However the Authentication part is a bit tricky.
First the video files was mp4 then i converted them to avi files.
Now that they are avi files when i try to open a video file in virtualdub i'm getting this error:
Couldn't locat decompressor for format h264 (unknown) virtualdub requires video for windows vfw compaitable decompress ...etc
What i did so far ?
Install ffdshow in configuration i changed not to disable h264 and all others in decoder.
I installed divx
I have virtualdub 1.10.4
Now i'm using ffdshow 32bit i tried 64bit before
I have windows 8.1 pro 64bit
Tried almost or anything i found in google nothing worked so far.
I wanted to open the original mp4 video files in virtualdub but nothing worked so i converted it to avi but also not working.
What else can i do ?
Maybe there is another program like virtualdub that it will work ?
You need to install the h.264 VFW codec here: https://sourceforge.net/projects/x264vfw/
Just close VirtualDub beforehand, and pick the default options in the installer. Worked like a charm for me.
AFAIK the file being MP4 or AVI is unimportant, it's just a change of "container", ie. what's inside both files is a h.264 encoded video channel.
Caveat: as mentioned by Ivo Kostić in another answer, it doesn't work well with interlaced x264 (I have no experience with that, I just thought this important fact should also appear in the "top" answer).
I used the VirtualDub FFmpeg Input Driver Plugin, Direct sourcforge page
Download
Copy files to the plugins folders in the virtualdub directory
Restarted virtualdub
and no matter what you do currently x264vfw (either as standalone as mentioned by ghis, or via ffdshow's vfw config (decoder options)) doesn't work well with interlaced h264, it doubles the framerate and then it's not really usable esp. if you just wanna cut video in 'direct stream copy mode'.
a bug that probably won't be fixed.
I'm trying to debug some JavaScript for a Rails project and its incredibly frustrating to go line by line when the source code is compressed in the Sources developer tab.
I know this compression is done by Chrome through the body variable. What I want to know is if there is any way to stop Chrome from compressing files in source view, i.e:
\application.js?body=1 --> \application.js
Thank you for your time.
Compression is being done by Rails. Disable it in your configuration:
# config/production.rb (or whatever environment you're in)
config.assets.compress = false
You might want to investigate a new feature in Chrome called Source Maps.
Source Maps allows Chrome to map the compressed source code it receives to the uncompressed original, which in turn means that you can debug the code, even though it's been compressed.
This feature should help you get around this kind of problem without having to change the compression settings on your server.
You can read more about it here: http://blog.mascaraengine.com/news/2012/4/16/sourcemap-support-in-chrome-greatly-improves-debugging.html
I believe this feature is still in test and not yet in the final release version of Chrome. I'm sure it will arrive in due course, but for the time being you may need to install the "Canary" version of Chrome, ie the pre-release version that includes all the forthcoming features that they're still working on.