I'm trying to locate h264 frames in the mp4 container of a segmented file(styp). For the segmentation I'm currently using MP4Box dash. I used MP4Box parser and I noticed that in each keyframe(IDR) the size of the sample is different than the size of the same frame in the original file. I calculated the difference and it's always 37 bytes for the same file in other segments.
What do these bytes represent? They only appear in the segmented mp4 file types before each keyframe. I tested with other files and the number of these bytes vary slightly(other file was 39 bytes) and are not the same data(they share some byte patterns though). Is this something from the mp4 standard or H264 or even MP4Box? I don't have a clue.
00 00 00 19 67 ... - H.264 SPS NAL 0x19 (25) + 4 = 29 bytes size
00 00 00 04 68 ... - H.264 PPS NAL 0x04 (4) + 4 = 8 bytes size
In sum this gives 29 + 8 = 37 bytes of SPS/PPS. Usually for mp4 (avc1 samples) SPS/PPS are not present inband (mdat box) and stored out-of-band in avcC box. But that is not strict rule afaik and SPS/PPS can be both inband and out-of-band or out-of-band only as for avc3 samples.
Related
For my assembler, I want to encode the operation mov eax, [addr]. In 64 bits this would only possible using a SIB byte, as the mod r/m combination 00 101 was changed to indicate rip-relative addressing. The problem I find is that, in 32 bits, encoding this instruction using a SIB byte doesn't work. For example I have:
8B 84 25 1C FE 43 00
(mov) (10 000 100) (00 100 101) (address)
but disassemblers don't seem to accept it, I get:
mov eax,DWORD PTR [ebp+eiz*1+0x43fe1c] (defuse.ca)
mov eax, ss:off_43FE1C[ebp] (ida)
and when the instruction is executed it generates an exception. I know that there is the shorter encoding in 32 bits, but don't understand what's wrong with the longer one.
I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.
I am having a problem with the I2C driver for a Freescale p1022tw board. There is a command on U-Boot's console to read from an I2C device:
i2c md chip address[.0, .1, .2] [# of objects]
When I read 4 bytes from a device with id 0x60, at address 0x0, I get:
tw=>i2c md 60 0 4
0000: 45 45 45 45 EEEE
These values that it returned are wrong. I can get the right values if I read one byte at the time:
tw=>i2c md 60 0 1
0000: 45 E
tw=>i2c md 60 1 1
0001: 45 E
tw=>i2c md 60 2 1
0002: 46 F
tw=>i2c md 60 3 1
0003: 00 .
I should have gotten 45 45 46 00 or EEF0 in the first command. In multiple readings for this device, it is returning always just the first byte value. If I try to get 6 bytes starting at address 0x2, this is the output:
tw=>i2c md 60 2 6
0002: 46 46 46 46 46 46 FFFFFF
This problem does not happen on other devices on the bus. For instance, in the device with id 0x4F, the right values are printed:
tw=>i2c md 4F 0.2 6
0000: 18 00 f6 48 00 00 ...H..
The address in the previous command has a ".2" because the chip uses 2 bytes for addresses. The first device only uses 1, so there's no need to put a ".1" (I already tested that).
I went through the implementation of the Freescale driver for the I2C communication, but I didn't change anything on it and it works for other devices. My coworker also says that the very same code works on his board. Have anybody had a similar issue or has any theory about why this is happening?
Thanks in advance.
I met such a situation. I had driver, read and write functions, and it worked not for all i2c devices. I found that was caused the not working device had different operating format for a number of operation. Unfortunately this happens, there a kind of not standard protocols. When you open the doc for the problem device and compare it to working and/or to the driver implementation you most likely will see a difference.
I have to say that I don't really understand the mechanics of CRC-32; but I was hoping to be able to at least calculate a CRC based on a chunk.
I have a PNG with the following information: 2px by 5px, RGBa, no interlace
The image header chunk results in:
00 00 00 0d = data is 13 bytes long
49 48 44 52 = ascii for IHDR (image header)
00 00 00 02 00 00 00 05 08 06 00 00 00 = data; dimensions, bit-depth, etc.
6f b3 3d 9c = CRC
I wanted to see if CRC could be easily calculated so I tried using:
http://depa.usst.edu.cn/chenjq/www2/wl/software/crc/CRC_Javascript/CRCcalculation.htm
The calculator's default polynomial for CRC-32 is 04C11DB7.
When I plug in "0000000d4948445200000002000000050806000000" I get 35F0A255.
I looked it up on Wikipedia and tried the other various representations used by PNG (EDB88320 & 82608EDB) and I tried leaving off the length and chunk type with the various polynomials I used before; I also tried including the information before the chunk which defines the PNG signature. I never got 6fb33d9c.
Any ideas on why I can't get the right CRC via calculator?
What is the difference between Big Endian and Little Endian Byte order ?
Both of these seem to be related to Unicode and UTF16. Where exactly do we use this?
Big-Endian (BE) / Little-Endian (LE) are two ways to organize multi-byte words. For example, when using two bytes to represent a character in UTF-16, there are two ways to represent the character 0x1234 as a string of bytes (0x00-0xFF):
Byte Index: 0 1
---------------------
Big-Endian: 12 34
Little-Endian: 34 12
In order to decide if a text uses UTF-16BE or UTF-16LE, the specification recommends to prepend a Byte Order Mark (BOM) to the string, representing the character U+FEFF. So, if the first two bytes of a UTF-16 encoded text file are FE, FF, the encoding is UTF-16BE. For FF, FE, it is UTF-16LE.
A visual example: The word "Example" in different encodings (UTF-16 with BOM):
Byte Index: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
------------------------------------------------------------
ASCII: 45 78 61 6d 70 6c 65
UTF-16BE: FE FF 00 45 00 78 00 61 00 6d 00 70 00 6c 00 65
UTF-16LE: FF FE 45 00 78 00 61 00 6d 00 70 00 6c 00 65 00
For further information, please read the Wikipedia page of Endianness and/or UTF-16.
Ferdinand's answer (and others) are correct, but incomplete.
Big Endian (BE) / Little Endian (LE) have nothing to do with UTF-16 or UTF-32.
They existed way before Unicode, and affect how the bytes of numbers get stored in the computer's memory. They depend on the processor.
If you have a number with the value 0x12345678 then in memory it will be represented as 12 34 56 78 (BE) or 78 56 34 12 (LE).
UTF-16 and UTF-32 happen to be represented on 2 respectively 4 bytes, so the order of the bytes respects the ordering that any number follows on that platform.
UTF-16 encodes Unicode into 16-bit values. Most modern filesystems operate on 8-bit bytes. So, to save a UTF-16 encoded file to disk, for example, you have to decide which part of the 16-bit value goes in the first byte, and which goes into the second byte.
Wikipedia has a more complete explanation.
little-endian: adj.
Describes a computer architecture in which, within a given 16- or 32-bit word, bytes at lower addresses have lower significance (the word is stored ‘little-end-first’). The PDP-11 and VAX families of computers and Intel microprocessors and a lot of communications and networking hardware are little-endian. The term is sometimes used to describe the ordering of units other than bytes; most often, bits within a byte.
big-endian: adj.
[common; From Swift's Gulliver's Travels via the famous paper On Holy Wars and a Plea for Peace by Danny Cohen, USC/ISI IEN 137, dated April 1, 1980]
Describes a computer architecture in which, within a given multi-byte numeric representation, the most significant byte has the lowest address (the word is stored ‘big-end-first’). Most processors, including the IBM 370 family, the PDP-10, the Motorola microprocessor families, and most of the various RISC designs are big-endian. Big-endian byte order is also sometimes called network order.
---from the Jargon File: http://catb.org/~esr/jargon/html/index.html
Byte endianness (big or little) needs to be specified for Unicode/UTF-16 encoding because for character codes that use more than a single byte, there is a choice of whether to read/write the most significant byte first or last. Unicode/UTF-16, since they are variable-length encodings (i.e. each char can be represented by one or several bytes) require this to be specified. (Note however that UTF-8 "words" are always 8-bits/one byte in length [though characters can be multiple points], therefore there is no problem with endianness.) If the encoder of a stream of bytes representing Unicode text and the decoder aren't agreed on which convention is being used, the wrong character code can be interpreted. For this reason, either the convention of endianness is known beforehand or more commonly a byte order mark is usually specified at the beginning of any Unicode text file/stream to indicate whethere big or little endian order is being used.