When execute ps -ef on my machine, I found a very strange/special command line parameter of chrome:
501 536 493 0 二11上午 ?? 13:11.48 /Applications/Google Chrome.app/Contents/Versions/69.0.3497.100/Google Chrome Helper.app/Contents/MacOS/Google Chrome Helper --type=gpu-process --field-trial-handle=3535656472344341962,3817030915272013891,131072 --gpu-preferences=KAAAAAAAAACAAAAAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAADgBAAAmAAAAMAEAAAAAAAA4AQAAAAAAAEABAAAAAAAASAEAAAAAAABQAQAAAAAAAFgBAAAAAAAAYAEAAAAAAABoAQAAAAAAAHABAAAAAAAAeAEAAAAAAACAAQAAAAAAAIgBAAAAAAAAkAEAAAAAAACYAQAAAAAAAKABAAAAAAAAqAEAAAAAAACwAQAAAAAAALgBAAAAAAAAwAEAAAAAAADIAQAAAAAAANABAAAAAAAA2AEAAAAAAADgAQAAAAAAAOgBAAAAAAAA8AEAAAAAAAD4AQAAAAAAAAACAAAAAAAACAIAAAAAAAAQAgAAAAAAABgCAAAAAAAAIAIAAAAAAAAoAgAAAAAAADACAAAAAAAAOAIAAAAAAABAAgAAAAAAAEgCAAAAAAAAUAIAAAAAAABYAgAAAAAAABAAAAAAAAAAAAAAAAUAAAAQAAAAAAAAAAAAAAALAAAAEAAAAAAAAAAAAAAADAAAABAAAAAAAAAAAAAAAA0AAAAQAAAAAAAAAAAAAAAPAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAAAAABIAAAAQAAAAAAAAAAAAAAATAAAAEAAAAAAAAAABAAAABQAAABAAAAAAAAAAAQAAAAsAAAAQAAAAAAAAAAEAAAAMAAAAEAAAAAAAAAABAAAADQAAABAAAAAAAAAAAQAAAA8AAAAQAAAAAAAAAAEAAAAQAAAAEAAAAAAAAAABAAAAEgAAABAAAAAAAAAAAQAAABMAAAAQAAAAAAAAAAQAAAAFAAAAEAAAAAAAAAAEAAAACwAAABAAAAAAAAAABAAAAAwAAAAQAAAAAAAAAAQAAAANAAAAEAAAAAAAAAAEAAAADwAAABAAAAAAAAAABAAAABAAAAAQAAAAAAAAAAQAAAASAAAAEAAAAAAAAAAEAAAAEwAAABAAAAAAAAAABgAAAAUAAAAQAAAAAAAAAAYAAAALAAAAEAAAAAAAAAAGAAAADQAAABAAAAAAAAAABgAAAA8AAAAQAAAAAAAAAAYAAAAQAAAAEAAAAAAAAAAGAAAAEgAAABAAAAAAAAAABgAAABMAAAAQAAAAAAAAAAcAAAAFAAAAEAAAAAAAAAAHAAAACwAAABAAAAAAAAAABwAAAA0AAAAQAAAAAAAAAAcAAAAPAAAAEAAAAAAAAAAHAAAAEAAAABAAAAAAAAAABwAAABIAAAAQAAAAAAAAAAcAAAATAAAA --service-request-channel-token=17030867567105907743
For curiosity, I find the source of chromium, which seems very normal:
namespace gl {
// On dual-GPU systems, expresses a preference for using the integrated
// or discrete GPU. On systems that have dual-GPU support (see
// GpuDataManagerImpl), resource sharing only works between
// contexts that are created with the same GPU preference.
//
// This API will likely need to be adjusted as the functionality is
// implemented on more operating systems.
enum GpuPreference {
GpuPreferenceNone,
PreferIntegratedGpu,
PreferDiscreteGpu,
GpuPreferenceLast = PreferDiscreteGpu
};
} // namespace gl
So, is this parameter (KAAAA....) is obscured or some encoding of GPU name? Why such a strange encoding?
Any time you see an encoding with lots of AAAA in it, you can bet that it's a Base64 encoding of a binary with lots of nulls in it.
>>> a=b'KAAAAAAAAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAADgBAAAmAAAAM=='
>>> base64.b64decode(a).hex()
'2800000000000004000000000000000001800000000000000000002000000000000000e004000098000000'
(And speaking more generally, any encoding that uses both upper- and lowercase letters is quite likely Base64. For example, a SHA256 is often given in Base64 compared to hexadecimal for SHA1.)
This corresponds to this interface: https://cs.chromium.org/chromium/src/gpu/ipc/common/gpu_preferences.mojom
The wire format does not seem to be very heavily documented, so if you want to interpret this value you might be best off checking out the chromium tree and building the bindings generator. https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md
Related
My goal is to convert a C++ program in to a .pexe file in order to execute it later on a remote computer. The .pexe file will contain some mathematical formulas or functions to be calculated on a remote computer, so I’ll be basically using the computational power of the remote computer. For all this I’ll be using the nacl_sdk with the Pepper library and I will be grateful if someone could clarify some things for me:
Is it possible to save the outputs of the executed .pexe file on the remote computer in to a file, if it’s possible then how? Which file formats are supported?
Is it possible to send the outputs of the executed .pexe file on the remote computer automatically to the host computer, if it’s possible then how?
Do I have to install anything for that to work on the remote computer?
Any suggestion will be appreciated.
From what I've tried it seems like you can't capture the stuff that your pexe writes to stdout - it just goes to the stdout of the browser (it took me hours to realize that it does go somewhere - I followed a bad tutorial that had me believe the pexes stdout was going to be posted to the javascript side and was wondering why it "did nothing").
I currently work on porting my stuff to .pexe also, and it turned out to be quite simple, but that has to do with the way I write my programs:
I write my (C++) programs such that all code-parts read inputs only from an std::istream object and write their outputs to some std::ostream object. Then I just pass std::cin and std::cout to the top-level call and can use the program interactively in the shell. But then I can easily swap out the top-level call to use an std::ifstream and std::ofstream to use the program for batch-processing (without pipes from cat and redirecting to files, which can be troublesome under some circumstances).
Since I write my programs like that, I can just implement the message handler like
class foo : public pp::Instance {
... ctor, dtor,...
virtual void HandleMessage(const pp::Var& msg) override {
std::stringstream i, o;
i << msg.AsString();
toplevelCall(i,o);
PostMessage(o.str());
}
};
so the data I get from the browser is put into a stringstream, which the rest of the code can use for inputs. It gets another stringstream where the rest of the code can write its outputs to. And then I just send that output back to the browser. (Downside is you have to wait for the program to finish before you get to see the result - you could derive a class from ostream and have the << operator post to the browser directly... nacl should come with a class that does that - I don't know if it actually does...)
On the html/js side, you can then have a textarea and a pre (which I like to call stdin and stdout ;-) ) and a button which posts the content of the textarea to the pexe - And have an eventhandler that writes the messages from the pexe to the pre like this
<embed id='pnacl' type='application/x-pnacl' src='manifest.nmf' width='0' height='0'/>
<textarea id="stdin">Type your input here...</textarea>
<pre id='stdout' width='80' height='25'></pre>
<script>
var pnacl = document.getElementById('pnacl');
var stdout = document.getElementById('stdout');
var stdin = document.getElementById('stdin');
pnacl.addEventListener('message', function(ev){stdout.textContent += ev.data;});
</script>
<button onclick="pnacl.postMessage(stdin.value);">Submit</button>
Congratulations! Your program now runs in the browser!
I am not through with porting my compilers, but it seems like this would even work for stuff that uses flex & bison (you only have to copy FlexLexer.h to the include directory of the pnacl sdk and ignore the warnings about the "register" storage location specifier :-)
Are you using the .pexe in a browser? That's the usual case.
I recommend using nacl_io to emulate POSIX in the browser (also look at file_io. This will allow you to save files locally, retrieve them, in any format you fancy.
To send the output use the browser's usual capabilities such as XMLHttpRequest. You need PNaCl to talk to JavaScript for this, you may want to look at some of the examples.
A regular web server will do, it really depends on what you're doing.
I have been trying to understand how DASH works, mainly the MPD and how a remote client boots-up to play a stream. Of many parameters in the MPD, the Initialization range and SegmentBase indexRange seems to be of much interest. If I understand it right, these values give the base URL and the mappings to key-frames that must be retrieved if the client seeks/rewinds a video.
My question is if these values can be seen before I actually play a video. For example, can I use a tool like youtube-dl to download these byte-ranges and decode them in a way that is human readable?
Much appreciated.
-Jamie
I'm also starting to look into DASH so take my answer with a grain of salt.
The SegmentBase is used when you have a single segment in a representation. For multiple segments there's SegmentList and SegmentTemplate. You can find more in this MPEG-DASH overview.
For MPEG-DASH the SegmentBase indexRange attribute points to the location of the sidx box (Segment Index Box). The box contains information about the sub-segments and random access points for seeking etc. There's more info in this Quick Tutorial on MPEG-DASH.
In the case of WebM-DASH the segment index corresponds to the Cues element.
The Initialization range attribute points to the initialization segment.
If the server supports it you could issue HTTP Range requests to get the data but you'll need to parse it.
There's a Node.js ISO BMFF parser here: iso-bmff-parser-stream and the DASH-IF reference client implementation in JavaScript can be found at: dash.js.
For WebM the Cues can be read using mkvinfo, as reported by #jamie.
I tried to passed a JSON via websocket to a html GUI. When size is upper than 32768 bytes, chrome raises this exception:
WebSocket connection to 'ws://localhost:8089/events/' failed: Received a frame that sets compressed bit while another decompression is ongoing
on the line where WebSocket is instantiated :
this._websocket = new WebSocket(url);
However it work fine on firefox. I used jetty 9.1.3 on server side and I tried with chrome 33 and 34 beta.
I forget to precise that if I send length message superior than 32768 bytes, on chrome's network debugging tools, it show 32768 bytes length instead of real message length.
Any ideas ?
When using Jetty 9.1.2.v20140210 I don't have any problems with the connection, but with the later 9.1.3.v20140225 version it fails and I get the error using Opera or Chrome. Firefox works fine on all versions.
I submitted a bug report to Jetty about this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=431459
This might be a bug in Jetty.
permessage-deflate requires the compression bit be set on the first frame of a fragmented message - and only on that.
It might be that Jetty fragments outgoing message to 32k fragments, and sets the compression bit on all frames. If so, that's a bug.
I have just tested current Chrome 33 using Autobahn|Testsuite: everything works as expected .. including messages with 128k.
You can test Jetty using above testsuite. It'll catch the bug if there is one.
i am using python3.1 ,so i found a html5 websocket snippet here:
http://www.nublue.co.uk/blog/threaded-python-websocket-server-and-javascript-client/
I test with chrome.
After send handshake packet,web client has no response as expect(websocket.onopen is not fired).I do receive client's request.
.i tried many times.It just not work.
Here is a .NET code:
http://nugget.codeplex.com/
I test it,it works fine.so my chrome is ok.
I wanna know is there any python3.x demo code can give me a help.
And my machine:
WIN7 pro X86
thanks.
The noVNC project (a HTML5 VNC client) contains a python 2.X (but should be easy to convert to 3.X) utility named wsproxy which is a WebSockets to generic TCP proxy. It transparently supports v75 and v76 (which has new handshake) of the WebSockets protocol.
If you're still working on it, that might be a helpful reference at least.
Disclaimer: I made noVNC and wsproxy.
oh.i got it .
that article is obsolete.
and see:
http://en.wikipedia.org/wiki/Web_Sockets
sum of the concatenated string.[1]
sum of the concatenated string.[1]> The Sec-WebSocket-Key1 and
Sec-WebSocket-Key2 fields and the 8
bytes after the fields are random
tokens which the server uses to
construct a 16-byte token at the end
of its handshake to prove that it has
read the client's handshake. The
handshake is constructed by
concatenating the numbers from the
first key, and dividing by the number
of spaces. This is then repeated for
the second key. The two resulting
numbers are concatenated with each
other, and with the last 8 bytes after
the fields. The final result is an MD5
sum of the concatenated string.[1]sum of the concatenated string.[1]
sum of the concatenated string.[1]
Is there some cheap and reliable way to detect if an image file has EXIF data? Something like "read the first 100 bytes and search for EXIF substring" is highly preferable. I don't need to read and parse it - only to know if it is there.
The key is that it must be very fast. C++ is preferable.
You might look at the implementation of file (1).
You could just call it, of course, but you presumably don't need the rest of files functionality so...
You only need to check first 4 bytes of the stream:
bool IsExifStream(const char* pJpegBuffer)
{
static const char stream_prefix1[] = "\xff\xd8\xff\xe1";
return memcmp(pJpegBuffer, stream_prefix1, 4) == 0;
}
You could read the source of the PHP EXIF extension - by looking at how the exif_read_data is implemented, you might pick up some clues.
If you do not require massive performance, I would use some Exif library and let it try to get the Exif data (if present) for you. (pyexif, perl Image::exif, c# MetaDataExtractor etc)
Otherwise,
take a look at http://en.wikipedia.org/wiki/JPEG#Syntax_and_structure
You need to create a simple binary parser do dig out the "segment codes", and to find the segment called APP1 (if I understand it correctly). The data should contain the letters "Exif"
e.g. in a random JPEG file on my PC, the bytes 7-10 said "Exif". I do not know if the location is the same in all JPEG files. The segments may be of variable length.