What is the difference between base64 and buffer in NodeJs?
Input passed within the POST body. Supported input methods: raw image binary. What does raw image binary mean - base64 or buffer?
buffer: <Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 01 77 00 00 01 b6 08 06 00 00 00 84 74 c6 ef 00 00 18 34 69 43 43 50 49 43 43 20 50 72 6f 66 69 ... 275877 more bytes>,
Would this work, for the input format if I passed it to the API?
base64 is a style of storing information(where 6 bits encode your information). It's usually used for image to binary conversion (and encoding decoding).
Buffer is a storage type that uses dynamic heap and is used for ensuring conversion standards ( IPCs can be encoded in utf-8, however if you start utilizing Sockets or network packets then they will have their own encoding types).
Raw image binary means raw values. You may save them either as base64 or in the Buffer as per your convenience
Related
Test Case
I have a live test case available here: https://lonelearner.github.io/charset-issue/index.html
Since the HTML has non-ASCII characters, if you want to reliably reproduce this test case on your system, here is how you can reproduce it. You can use any one of these methods to reproduce it:
Fetch the page from above URL.
curl https://lonelearner.github.io/charset-issue/index.html -O
Run this command:
echo "
3c21444f43545950452068746d6c3e0a3c68746d6c3e0a20203c68656164
3e0a202020203c7469746c653e636861727365742069737375653c2f7469
746c653e0a202020203c6d65746120687474702d65717569763d22436f6e
74656e742d547970652220636f6e74656e743d22746578742f68746d6c3b
20636861727365743d69736f2d383835392d31223e0a20203c2f68656164
3e0a20203c626f64793e0a202020203c703ea93c2f703e0a20203c2f626f
64793e0a3c2f68746d6c3e0a
" | xxd -p -r > index.html
Interesting Byte
Let us look at the ISO-8859-1 encoded character that we are concerned about in this question.
$ curl -s https://lonelearner.github.io/charset-issue/index.html | xxd -g1
00000000: 3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 3e 0a <!DOCTYPE html>.
00000010: 3c 68 74 6d 6c 3e 0a 20 20 3c 68 65 61 64 3e 0a <html>. <head>.
00000020: 20 20 20 20 3c 74 69 74 6c 65 3e 63 68 61 72 73 <title>chars
00000030: 65 74 20 69 73 73 75 65 3c 2f 74 69 74 6c 65 3e et issue</title>
00000040: 0a 20 20 20 20 3c 6d 65 74 61 20 68 74 74 70 2d . <meta http-
00000050: 65 71 75 69 76 3d 22 43 6f 6e 74 65 6e 74 2d 54 equiv="Content-T
00000060: 79 70 65 22 20 63 6f 6e 74 65 6e 74 3d 22 74 65 ype" content="te
00000070: 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 65 74 xt/html; charset
00000080: 3d 69 73 6f 2d 38 38 35 39 2d 31 22 3e 0a 20 20 =iso-8859-1">.
00000090: 3c 2f 68 65 61 64 3e 0a 20 20 3c 62 6f 64 79 3e </head>. <body>
000000a0: 0a 20 20 20 20 3c 70 3e a9 3c 2f 70 3e 0a 20 20 . <p>.</p>.
000000b0: 3c 2f 62 6f 64 79 3e 0a 3c 2f 68 74 6d 6c 3e 0a </body>.</html>.
In the row before the last one (line at offset 000000a0), the 9th byte is a9. That is our interesting byte. That is an ISO-8859-1 representation of the copyright sign. Note that this is ISO-8859-1 encoded symbol, not UTF-8. If it had been UTF-8 encoded, the bytes would be c2 a9.
META Tag
To ensure that the content of this HTML file is interpreted as ISO-8859-1 encoded data, there is this <meta> tag in the HTML code:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Local Behavior
If you open this file on your system locally with a browser, you would most likely see an output like this:
This is expected because when opening the file locally, there is no HTTP server sending HTTP headers. So the iso-8859-1 encoding specified in the <meta> tag is honored.
GitHub Behaviour
If you access the URL https://lonelearner.github.io/charset-issue/index.html with a browser, you would most likely see an output like this:
This is also expected. If you notice the page is served with GitHub Pages and GitHub Pages server always returns HTTP header that specifies ISO-8859-1 encoding.
$ curl -sI https://lonelearner.github.io/charset-issue/index.html | grep -i content-type
content-type: text/html; charset=utf-8
Since HTTP header specifies the character encoding, the character encoding in <meta> tag is no longer honored.
Question
Is there anyway I can override the character encoding specified in the HTTP header using HTML, JavaScript or CSS to tell the browser that this content should be interpreted as ISO-8859-1 encoding even if the HTTP header says otherwise?
I know I can always write the copyright symbol as © or encode the symbol in UTF-8 in the file, but let us consider such solutions to be outside the scope of this question because here are the constraints I am dealing with:
The content of the <body> is made available to me as ISO-8859-1 encoded text.
I cannot modify the content of the <body>. I must use the ISO-8859-1 encoded text in my HTML.
I can modify anything within the <head> tag. So I can add JavaScript, CSS or any other tricks that can solve this problem.
Is there anyway I can override the character encoding specified in the HTTP header using HTML, JavaScript or CSS to tell the browser that this content should be interpreted as ISO-8859-1 encoding even if the HTTP header says otherwise?
No. The HTTP header is authoritative w3:
"...The HTTP header has a higher precedence than the in-document meta
declarations, content authors should always take into account whether
the character encoding is already declared in the HTTP header. If it
is, the meta element must be set to declare the same encoding."
Should a raw h.264 video track contain at the start SPS and PPS data in order for a player (at least VLC Player) to be able to play it properly?
In this Android question, I see that in this specific context - MediaCodec decoder on Android API - it is said that the two buffers need to be provided. Is this generalized. Do I provide it as 0,0,0,1,[sps],0,0,0,1,[pps]?
[EDIT]
I've added SPS and PPS as is, and now VLC Player wants to play the video. It seems to decode the proper amount of frames at the good framerate, though the frames are pink and green noise, with movements that seem to follow original movie movements. I feel like there are missing informations regarding the format of my video track data. When I demux an MP4 with FFmpeg, the provided sps at the beginning of the raw h.264 stream is richer than mine.
FFMPEG h.264 raw video track stream:
SPS
00 00 00 01 67 42 c0 0d 9a 74 03 c0 11 3f 2e 02 20 00 00 03 00 20 00 00 06 51 e2 85 54
PPS
00 00 00 01 68 ce 3c 80
The rest...
00 00 00 01 65 etc....
which library are you using to get stream ? for example if you use live555 to get stream you need to put sps and pps information before frames because ffmpeg wants these information for decoding.
00 00 00 01 for h264 format
00 00 00 01 sps 00 00 00 01 pps 00 00 00 01 data frame
I have a video with an unknown frame rate. I need to calculate the frame rate it was encoded for. I am trying to calculate it using the data in SPS but I cannot decode it.
The bitstream for the NAL is :
67 64 00 1e ac d9 40 a0 2f f9 61 00 00 03 00 7d 00 00 17 6a 0f 16 2d 96
From an online guide (http://www.cardinalpeak.com/blog/the-h-264-sequence-parameter-set/), I could figure out its profile and level fields, but to figure out everything after the "seq_parameter_set_id" field in the table, I need to know the ue(v). Here is where I get confused. According to this page the "ue(v)" should be called with the value v=32? (why?) What exactly should I feed into the exponential-golomb function? Do I read 32 digits from the beginning of the bitstream, or from after the previously read bytes, to regard it as the "seq_parameter_set_id"?
( My ultimate goal is to decode the VUI parameters so that I can recalculate the framerate.)
Thanks!
ue = Unsigned Exponential golomb coding.
(v) = variable number of bits.
http://en.wikipedia.org/wiki/Exponential-Golomb_coding
I'm just starting out with Node streams.
My library's demo code uses:
stream.pipe(process.stdout, {end: true});
Which works fine, printing chunks of JSON to standard output.
I'd like to use:
stream.on('data', function(chunk) {
console.log(chunk)
}
But I get a binary buffer instead:
chunk! <Buffer 7b 22 73 74 72 65 61 6d 22 3a 22 20 2d 2d 2d 5c 75 30 30 33 65 20 35 35 32 38 38 36 39 62 30 30 33 37 5c 6e 22 7d>
Is there a way I can use on('data') and see the JSON?
I believe you should run stream.setEncoding('utf8') on your stream, so node.js core will decode utf8 automatically.
You should probably not use chunk.toString('utf8') like suggested earlier because it can garble unicode characters on the boundaries, unless you're sure that the data will be in one block.
Use chunck.toString ('utf8'). Also, the Buffer class has other encodings too!
I am stuck on HEX(intel hex) format which I see in Hex Editor (Hex Editor Neo).
Ok,I know hex,decimal,binary,their addition,multiplication,their conversion.
Ex. sample.jpg
(this is a jpg file I open with Hex Editor Neo in hex format with 4 columns)
ff d8 ff e0
00 10 4a 46
49 46 00 01
01 01 00 48
00 48 00 00
ff db 00 43
00 05 03 04
04 04 03 05
04 04 04 05
05 05 06 07
0c 08 07 07
07 07 0f 0b
0b 09 0c 11
I see this(these are just some of the rows from the whole file) type of hex code.
I am interested in what they mean?
I know ff d8 ff e0 tells you jpg.
I know jpg ends with ff d9.
I want to know about other codes..I mean why they are their?.They must be having some meaning or how the conversion takes place from picture to hex.
What do you mean by "4a 46 49 46 00" and many others present there?
Some of it will be standard header information and a lot of it will be picture data. Don't forget that this is a binary file and as part of the compression algorithm the picture file will be converted into a different type of binary encoding to what it originally was. I doubt if you would be able to tell what the picture looks like by reading the binary data that relates to it :)
You can read all about the jpeg standard here.
BTW. hex is just a means of representing the binary data in a more easily understood form than binary. The data is the same - its binary data. If you opened the file in an editor supporting octal it would look different again.