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
Related
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
as the title says I'm curious to know how the checksum value is calculated, from what I've read it calculated using 2s complement. Below is a 2 lines from the hex file which was loaded onto my Microcontroller, I've added spaces to make it easier to read, S315 appears on every line, the address on line 1 is 080C0000 followed by 16 hex values which represent the bytes, the values AA on line 1 and AB on line 2 are I assume the checksum values.
For line 1 I've tried adding the following 15+08+0C+00+00+4D+53+53+70+6F+74+31+00+66+10+AE+19+7E+63+1F+78 which gives me 555 Hex or 010101010101 in binary. I've entered the binary value into an online 2s complement calculator but it always says "invalid binary"??
S3 15 080C0000 4D 53 53 70 6F 74 31 00 66 10 AE 19 7E 63 1F 78 AA
S3 15 080C0010 00 00 00 00 45 85 63 EB FF FF FF FF 04 00 03 00 AB
You add the byte values, like you've done. From that sum you take only the least significant byte.
Then for Motorola HEX (SREC):
Then you take the one's complement of that byte by inverting its bits (i.e. 1s turns to 0s and vice versa).
Then for Intel HEX:
Then you take the two's complement of that byte by inverting its bits (i.e. 1s turns to 0s and vice versa) and then you add 1.
Going by your example you have the sum 0x555. Then take the least significant byte, which is 0x55.
For Motorola HEX (SREC): Calculate the one's complement of that. You get 0xAA as the checksum.
For Intel HEX: Calculate the two's complement of that. You get 0xAB as the checksum.
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
Looking at the PNG specification, it appears that the PNG pixel data chunk starts with IDAT and ends with IEND (slightly clearer explanation here). In the middle are values that don't make sense to make sense to me.
How can I get usable RGB values from this, without using any libraries (ie from the raw binary file)?
As an example, I made a 2x2px image with 4 black rgb(0,0,0) pixels in Photoshop:
Here's the resulting data (in the raw binary input, the hex values, and the human-readable ASCII):
BINARY HEX ASCII
01001001 49 'I'
01000100 44 'D'
01000001 41 'A'
01010100 54 'T'
01111000 78 'x'
11011010 DA '\xda'
01100010 62 'b'
01100000 60 '`'
01000000 40 '#'
00000110 06 '\x06'
00000000 00 '\x00'
00000000 00 '\x00'
00000000 00 '\x00'
00000000 00 '\x00'
11111111 FF '\xff'
11111111 FF '\xff'
00000011 03 '\x03'
00000000 00 '\x00'
00000000 00 '\x00'
00001110 0E '\x0e'
00000000 00 '\x00'
00000001 01 '\x01'
10000011 83 '\x83'
11010100 D4 '\xd4'
11101100 EC '\xec'
10001110 8E '\x8e'
00000000 00 '\x00'
00000000 00 '\x00'
00000000 00 '\x00'
00000000 00 '\x00'
01001001 49 'I'
01000101 45 'E'
01001110 4E 'N'
01000100 44 'D'
You missed a rather crucial detail in both the specifications:
The official one:
.. The IDAT chunk contains the actual image data which is the output stream of the compression algorithm.
[...]
Deflate-compressed datastreams within PNG are stored in the "zlib" format.
Wikipedia:
IDAT contains the image, which may be split among multiple IDAT chunks. Such splitting increases filesize slightly, but makes it possible to generate a PNG in a streaming manner. The IDAT chunk contains the actual image data, which is the output stream of the compression algorithm.
Both state the raw image data is compressed. Looking at your data, the first 2 bytes
78 DA
contain the compression flags as specified in RFC1950. The rest of the data is compressed.
Decompressing this with a general zlib compatible routine show 14 bytes of output:
00 00 00 00 00 00 00
00 00 00 00 00 00 00
where each first byte is the PNG row filter (0 for both rows), followed by 2 RGB triplets (0,0,0), for the 2 lines of your image.
"Without using any libraries" you need 3 separate routines to:
read and parse the PNG superstructure; this provides the IDAT compressed data, as well as essential information such as width, height, and color depth;
decompress the zlib part(s) into raw binary data;
parse the decompressed data, handling Adam-7 interlacing if required, and applying row filters.
Only after performing these three steps you will have access to the raw image data. Of these, you seem to have a good grasp of step (1). Step (2) is way harder to "do" yourself; personally, I cheated and used miniz in my own PNG handling programs. Step 3, again, is merely a question of determination. All the necessary bits of information can be found on the web, but it takes a while to put everything in the right order. (Just recently I found an error in my execution of the rarely used Paeth row filter--it went unnoticed because it is fairly rarely used in 'real world' images.)
See Building a fast PNG encoder issues for a similar discussion and Trying to understand zlib/deflate in PNG files for an in-depth look into the Deflate scheme.
I'm using the crypto module to create salts and hashes for storage in my database. I'm using SHA-512, if that's relevant.
What I have is a 64 byte salt, presently in the form of a "SlowBuffer", created by crypto.randomBytes(64, . . .). Example:
<SlowBuffer 91 0d e9 23 c0 8e 8c 32 5c d6 0b 1e 2c f0 30 0c 17 95 5c c3 95 41 fd 1e e7 6f 6e f0 19 b6 34 1a d0 51 d3 b2 8d 32 2d b8 cd be c8 92 e3 e5 48 93 f6 a7 81 ...>
I also have a 64-byte hash that is currently a string. Example:
'de4c2ff99fb34242646a324885db79ca9ef82a5f4b36c657b83ecf6931c008de87b6daf99a1c46336f36687d0ab1fc9b91f5bc07e7c3913bec3844993fd2fbad'
In my database, I have two fields, called passhash and passsalt, which are binary(64)s.
I'm using the mysql module (require('mysql')) to add the row. How can I include the binaries for insertion?
First of all, I'm no longer using the mysql module, but the mysql2 module (because it supports prepared statements). This changes roughly nothing about the question, but I'd like to mention that those reading this who are using 'mysql' should probably use 'mysql2'.
Second, both of these modules can take Buffers as parameters for these fields. This works perfectly. To do what I was originally attempting to do, I have it like this:
var hash; //Pretend initialized as a 64-bit buffer
var salt; //" "
connection.query('insert into users set?', {..., passhash: hash, passsalt: salt,..., callback});
Additionally, I didn't realize that the crypto "digest" function had a default behavior with no parameter, which is to return as a Buffer.
This is not the best worded answer, but that's because no one seems to be paying much attention to this question, and it was my question. :) If you would like more clarification, feel free to comment.