I'm trying to extract NAL units from raw .h264 files generated by Raspivid. I'm piping the output of Raspivid to netcat as so:
Raspivid | nc -u IPaddress Port
I can receive and save the stream on a client. The .h264 file that results actually DOES play in VLC.
However, my ultimate goal is to parse the NAL units out of the file and feed them into Media Codec on Android. To do this, I need the SPS and PPS data.
The problem is that I'm not finding the corresponding NAL units when examining the Hex output of the generated file. I'm looking for "00 00 00 01 67" for SPS.
All I'm seeing are a ton of "00 00 00 01 21",
"00 00 00 01 27",
"00 00 00 01 28"
etc.
Any idea what I'm doing wrong here?
Edit: I AM using the -ih option on Raspivid so it should be inserting those values regularly.
Guys on the Pi forums helped me out. I was basing my 67 number on a blog post describing NAL units, but I didn't consider that the hex could change regardless of the last five bits still being 7. Total noob.
Related
Currently trying to essentially reverse engineer a file format that is produced by a CNC machine when backing up programs on the machine so that i can read the programs on a standard PC. Have opened a few of the backup files created and can clearly see patterns of data such as the program name etc. which can be clearly seen in plaintext form. One thing i am struggling with is how numbers are represented in this.
for Example: the number '20' is represented in this file in hex form as '40 0D 03 00'.
More examples:
"-213.6287": "21 67 DF FF"
"-500.3366": "9A A7 B3 FF"
Any help with trying to figure out how these hex values make up those numbers?
Thanks
These numbers are stored as little-endian signed integers, as a count of ten-thousandths.
for Example: the number '20' is represented in this file in hex form as '40 0D 03 00'.
0x00030d40 = 200000.
"-213.6287": "21 67 DF FF"
0xffdf6721 = -2136287.
"-500.3366": "9A A7 B3 FF"
0xffb3a79a = -5003366.
I have two questions.
How many DES-keys will produce the same first 32 bit ciphertext from the same plaintext?
Example:
Plaintext = 00 00 00 00 00 00 00 00 (hex)
Ciphertext = 01 02 03 04 ?? ?? ?? ?? (hex)
How many keys can produce this?
If I get another plaintext-ciphertext pair, where I know the entire plaintext, but only the first half of the ciphertext. How many keys can produce the same first half of a ciphertext?
How many DES-keys will produce the same first 32 bit ciphertext from the same plaintext?
Since a block cipher is modeled as a pseudo-random permutation, the answer is 232.
If I get another plaintext-ciphertext pair, where I know the entire plaintext, but only the first half of the ciphertext. How many keys can produce the same first half of a ciphertext?
If the plaintext is longer than a block, then this depends on the mode of operation you're using and the specific length.
If the plaintext is exactly one block and no padding is used, then it is the same answer as to your first question, because half a block are 32 bits for DES.
I was submitting a job application, after research and a well thought out reply that was made on multiple questions, I clicked submit. Then the page asked me to re-input my login data, I pray it would 1. remember my form data or 2. Allow the back button to work, but no. Fun times! God damn whoever developed that page.
I have spent some time reading about how to resurrect the form data from Chrome from here and here.
I was able to do my regex to pull out the hex from the cached file, but it says that it is corrupted when I go to decompress it.
So my questions is how should the hex be?
Here is the first line, should it have two whitespaces at the end?
1f 8b 08 00 00 00 00 00 04 00 ed bd 07 60 1c 49 <--- here?
And what about the end?
13 fe <-- what amount of whitespace should be here?
I found a post on here that stated what the file should end in and it was not the same. So I not sure where else I can go with this.
Any ideas?
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 am attempting to write a small utility to produce a binary file that will mimic the one produced by another closed application. I've used hex editors to decrypt the format by I'm stuck trying to understand what the format/encoding is so that I can produce it using C++ or C#.
The file starts with the first four bytes: 01 00 followed by FF FE. My understanding is that the file begins with SOH followed by the byte order mark for little endian. After these four bytes, the program appears to write BSTR's for each of the string fields from the app's GUI.
Using C#, I have produced a unicode file that starts with FF FE, but I'm not sure how to insert the SOH character first.
I would be forever grateful if someone could offer insight to the file format or encoding and why the file starts with the SOH character.
Thank you in advance.
Reverse engineering a binary file format can be a challenging task. On the surface, I don't recognize this as an obvious, well-known file format ... but there are thousands out there, so who knows.
Legal issues aside, I would suggest you look at some of the following resources that talk about approaches to such an endeavor:
How To Crack a Binary File Format
Tools to Reverse Engineer Binary Files
Basics of Reverse Engineering File Formats
File Format Reverse Engineering
If you are just having trouble writing out the first four bytes this will do it for you.
using (var stream = new FileStream("myfile.bin", FileMode.Create))
{
using (var binaryWriter = new BinaryWriter(stream))
{
binaryWriter.Write((byte)1);
binaryWriter.Write((byte)0);
binaryWriter.Write((byte)0xFF);
binaryWriter.Write((byte)0xFE);
binaryWriter.Write(Encoding.Unicode.GetBytes("string"));
}
}
This will output the following file
01 00 FF FE 73 00 74 00 72 00 69 00 6e 00 67 00 ....s.t.r.i.n.g.
Edit: Added Mark H's suggestion for writing out a string.