My source AAC frame contains the ADTS header. I need to initialize the esds box in the fmp4 file according to the ADTS, cut out the ADTS header and fill in the rest data, but I have tried many times without success (the player can't parse out the audio).
The following is my ADTS data. Which parameters of the esds box I configured need to be modified?
ADTS
FF 1111 1111 0-7 bit
F9 1111 1001 8-15 bit MPEG-2 no CRC
60 0110 0000 16-23 bit AAC Main
40 0100 0000 24-27 bit
You need to parse the adts to get the audio object type, frequency index, and channel count. Then write an audio specific config. https://wiki.multimedia.cx/index.php/MPEG-4_Audio#Audio_Specific_Config
Related
i want so send Data from Raspberry Pi with UART. If i send an character 'A' which is 01000001 in binary the scope shows 0100 0001 0101 0110 0001 0010 1000. What do the last 20 Bit mean in this case? These Bits are set at every transmission.
Im watching the Packages with a scope and i cant tell what these bits mean.
We learned about data compression in my class last week and I'm confused about a certain strategy.
My teacher showed us an example where he truncated 8-bit characters by cutting off the first 5 bits, which were all zeros.
A is 0000 0100 which is truncated to 100
B is 0000 0010 which is truncated to 010
The last one is 0000 0011 which is truncated to 011
What type of data compression is this?
I've been having trouble getting answers to any questions related to data structures. I used to get plenty of responses with language-specific questions when I was studying C++. . .
Anyway, I found the answer on this page:
https://wiki.nesdev.com/w/index.php/Fixed_Bit_Length_Encoding
It's called fixed bit-length encoding.
I am making a simple png image from scratch. I have had the scanlines data for it. Now I want to make it into zlib stream without being compressed. How can I do that? I have read the "ZLIB Compressed Data Format Specification version 3.3" at "https://www.ietf.org/rfc/rfc1950.txt" but still not understanding. Could someone give me a hint about setting the bytes in zlib stream?
Thanks in advance!
As mentioned in RFC1950, the details of the compression algorithm are described in another castle RFC: DEFLATE Compressed Data Format Specification version 1.3 (RFC1951).
There we find
3.2.3. Details of block format
Each block of compressed data begins with 3 header bits
containing the following data:
first bit BFINAL
next 2 bits BTYPE
Note that the header bits do not necessarily begin on a byte
boundary, since a block does not necessarily occupy an integral
number of bytes.
BFINAL is set if and only if this is the last block of the data
set.
BTYPE specifies how the data are compressed, as follows:
00 - no compression
[... a few other types]
which is the one you wanted. These 2 bits BTYPE, in combination with the last-block marker BFINAL, is all you need to write "uncompressed" zlib-compatible data:
3.2.4. Non-compressed blocks (BTYPE=00)
Any bits of input up to the next byte boundary are ignored.
The rest of the block consists of the following information:
0 1 2 3 4...
+---+---+---+---+================================+
| LEN | NLEN |... LEN bytes of literal data...|
+---+---+---+---+================================+
LEN is the number of data bytes in the block. NLEN is the
one's complement of LEN.
So, the pseudo-algorithm is:
set the initial 2 bytes to 78 9c ("default compression").
for every block of 32768 or less bytesᵃ
if it's the last block, write 01, else write 00
... write [block length] [COMP(block length)]ᵇ
... write the immediate data
repeat until all data is written.
Don't forget to add the Adler-32 checksum at the end of the compressed data, in big-endian order, after 'compressing' it this way. The Adler-32 checksum is to verify the uncompressed, original data. In the case of PNG images, that data has already been processed by its PNG filters and has row filter bytes appended – and that is "the" data that gets compressed by this FLATE-compatible algorithm.
ᵃ This is a value that happened to be convenient for me at the time; it ought to be safe to write blocks as large as 65535 bytes (just don't try to cross that line).
ᵇ Both as words with the low byte first, then high byte. It is briefly mentioned in the introduction.
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.
I have a GEZE door reader for RFID tags. The web app shows for one RFID tag the number "0552717541244". When I read the same tag with a USB reader connected to my computer, it shows "0219281982".
The values in hex are d11fa3e and 80b0885f7c. So it does not seem to be the difference in byte order discussed in other similar questions.
Is there a way of finding out the longer number when only the shorter one is known?
How come one single tag can have two different identifiers?
Looking at only a single value pair makes it impossible to verify if there actually is some systematic translation scheme between the two values. However, looking at the binary representation of the two values gives the following:
decimal binary
0552717541244 -> 1000 0000 1011 0000 1000 1000 0101 1111 0111 1100
0219281982 -> 0000 1101 0001 0001 1111 1010 0011 1110
So it looks as if the web app reverses the bit order of each byte when compared to the reading of the USB reader and adds an additional byte 0x80 as the MSB:
decimal binary
0552717541244 -> 1000 0000 1011 0000 1000 1000 0101 1111 0111 1100
(added) --------> --------> --------> -------->
<-------- <-------- <-------- <--------
0219281982 -> 0000 1101 0001 0001 1111 1010 0011 1110