I am writing something to get at the information contained in an MPO multi-picture file produced by cameras such as the fuji 3D cameras.
I have the proposed spec, which is obviously written to confuse, and is available from here:
CIPA multi picture spec PDF and have navigated the normal exif parts and extracted the MFP information.
Section 5.2.3 which describes the header lists
The header lists:
4 byte endian flag
4 byte offset
-- start of MP Index --
2 byte count
12 byte version
12 byte number of images
12 byte MP entry
12 byte Individual unique ID list
12 byte total number of capture frames
4 byte offset to next IFD.
The diagram shows the MP Entry and Unique ID list pointing to a offset (which would make 12 bytes).
However, in the description that follows it shows that the MP entry should be 16 bytes for every image (which in my sample image with two images, it is), and the individual unique ID being 33 bytes for every image (my sample doesn't have this).
Up to the number of images, everything is as it should be. I have 2 images, the version is correct, and there appear to be 3 blocks (count).
However, the third block (which is the MP Entry) has the right code, the correct number of bytes and the correct type, but contains the following information
32 00 00 00 52 00 00 00 02 00 02 20 40 63 1B 00
00 00 00 00 00 00 00 00 02 00 02 00 EE 6F 1B 00
The text says the contents of this should be
offset length name
0x00 4 Individual Image attribute
0x04 4 individual Image Size
0x08 4 Individual image offset
0x10 2 dependant image 1 entry number
0x12 2 dependant image 2 entry number
Clearly that makes no sense that if there are two images (they are effectively 10MP jpegs) that they have a size of 52 bytes and 0.
Could anyone take a look at this and check I am not going mad in my interpretation of it, or does anyone know what should be here?
Sorry, I know it is a bit complicated but I really cannot see where this is going wrong.
I believe your tag is ok.
Chapter 5.2 (MP Extensions) of the spec states MP index IFD as following:
Count (2 bytes)
MP Index Fields (Overall structure Info)
Offset of Next IFD (4 bytes)
Value (MP Index IFD)
Up to the number of images, everything is fine, as per spec. Starting from the MP Entry tag the bytes should be parsed as following:
(I'll be using data parsed from my MPO file)
02 b0 07 00 20 00 00 00 32 00 00 00 52 00 00 00
02 00 02 20 00 13 18 00 00 00 00 00 00 00 00 00
02-b0 - Tag ID (MP entry), 2 bytes
07-00 - Type (7 = undefined), 2
bytes
20-00-00-00 - 32 (16 x NumberOfImages,
two images in my file, this value was
parsed before), 4 bytes
32-00-00-00 - Offset of First IFD (50
bytes, starting from endianness tag),
4 bytes
That's where MP entry data ends. It's weird that there are no Individual Image Unique ID List (b003) or Total Number of Captured Frames (b004) tags, maybe they aren't necessary. Anyway, the next 4 bytes show offset of the next IFD, i.e.:
52-00-00-00 - Offset of Next IFD (82
bytes, starting from endiannesss
tag), 4 bytes
First IFD (in my case) starts immediately after the offset of Next IFD:
02-00-02-20 - Individual Image attr., 4
bytes
00-13-18-00 - Individual image size
(which states for 1 577 728 bytes of
data in my case), 4 bytes
00-00-00-00 - Individual image data
offset (states for 0 in case of first
image), 4 bytes
00-00 - Dependent image 1 (no
dependent image), 2 bytes
00-00 - Dependent image 2 (no
dependent image), 2 bytes
In your case, the data should be parsed as following:
32 00 00 00 52 00 00 00 02 00 02 20 40 63 1B 00
00 00 00 00 00 00 00 00 02 00 02 00 EE 6F 1B 00
32-00-00-00 - Offset of First IFD (50
bytes, starting from endianness tag),
4 bytes
52-00-00-00 - Offset of Next IFD (82
bytes, starting from endiannesss
tag), 4 bytes
02-00-02-20 - Individual Image attr., 4
bytes
00-13-18-00 - Individual image size
(which states for 1 794 880 bytes of
data), 4 bytes
00-00-00-00 - Individual image data
offset (states for 0 in case of first
image), 4 bytes
00-00 - Dependent image 1 (no
dependent image), 2 bytes
00-00 - Dependent image 2 (no
dependent image), 2 bytes
And starting next image's data:
02-00-02-00 - Individual Image attr., 4
bytes
EE-6F-1B-00 - Individual image size
(which states for 1 798 126 bytes of
data), 4 bytes
etc.
ABOUT IMAGE SIZE AND OFFSETS
Image size and offsets can confuse a bit. Spec says that:
"Image size is the data between SOI
and EOI markers" (ch. 5.2.3.3.2)
and
"Data offset (for the second image) is
specified relative to the address of
the MP Endian field in the MP Header"
(ch. 5.2.3.3.3)
Which I understand to be as following:
SOI---MPF_FIELDS-------------EOI
^
MP endian field
XXXXXXXXXXXXXXXXXXXXXXXXXXSOI--------------------------EOI
(first image, say, 2164288 bytes between SOI and EOI markers, including the markers. Second image, 2221368 bytes between SOI and EOI markers, including the markers. XXXXX states for offset)
Offset of the second image means that SOI marker is starting in lengthOf(XXXXX) bytes after MP endian marker, which is in the first image's MP field.
I suspect that if you subtract offset value from first image size, you should get MP Endian marker position.
I believe the base address is 8 bytes into the APP2 header, just after the "MPF\0" and right before "II*\0", assuming little endian. In the hex dump you've provided there's no MPO tag included but I guess "32 00 00 00" points to the offset of the MPEntries and "52 00 00 00" is the offset to the next IFD. What you want to be looking at is "02 00 02 20" which probably is the attribute of the first image.
Remember if the offset is "00 00 00 00", it's not relative but absolute.
Related
i am trying to find out how the Number of expected bytes is calculated with Function Code 2 in Modbus RTU.
I am querying registers from 0 to 71, but as a response i am getting expected bytes as 9
Below is the Query and response.
query : 33 02 00 00 00 47 3C 2A
resp : 33 02 09 00 08 00 FE FF FF FF FF 03 FA 68
You queried for 71 bits, the response has 9 bytes containing 8 bits per byte, any excess bits are ignored.
TL;DR: I want to read raw h264 streams from AVI/MP4 files, even broken/incomplete.
Almost every document about h264 tells me that it consists of NAL packets. Okay. Almost everywhere told to me that the packet should start with a signature like 00 00 01 or 00 00 00 01. For example, https://stackoverflow.com/a/18638298/8167678, https://stackoverflow.com/a/17625537/8167678
The format of H.264 is that it’s made up of NAL Units, each starting
with a start prefix of three bytes with the values 0x00, 0x00, 0x01
and each unit has a different type depending on the value of the 4th
byte right after these 3 starting bytes. One NAL Unit IS NOT one frame
in the video, each frame is made up of a number of NAL Units.
Okay.
I downloaded random_youtube_video.mp4 and strip out one frame from it:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.avi
And got:
Red part - this is part of AVI container, other - actual data.
As you can see, here I have 00 00 24 A9 instead of 00 00 00 01
This AVI file plays perfectly
I do same for mp4 container:
As you can see, here exact same bytes.
This MP4 file plays perfectly
I try to strip out raw data:
ffmpeg -i pic.avi -c copy pic.h264
This file can't play in VLC or even ffmpeg, which produced this file, can't parse it:
I downloaded mp4 stream analyzer and got:
MP4Box tells me:
Cannot find H264 start code
Error importing pic.h264: BitStream Not Compliant
It very hard to learn internals of h264, when nothing works.
So, I have questions:
What actual data inside mp4?
What I must read to decode that data (I mean different annex-es)
How to read stream and get decoded image (even with ffmpeg) from this "broken" raw stream?
UPDATE:
It seems bug in ffmpeg:
When I do double conversion:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.mp4
ffmpeg pic.mp4 -c copy pic.h264
But when I convert file directly:
ffmpeg -ss 10 -i random_youtube_video.mp4 -frames 1 -c copy pic.h264
I have NALs signatures and one extra NAL unit. Other bytes are same (selected).
This is bug?
UPDATE
Not, this is not bug, U must use option -bsf h264_mp4toannexb to save stream as "Annex B" format (with prefixes)
"I want to read raw h264 streams from AVI files, even broken/incomplete."
"Almost everywhere told to me that the packet should start with a signature like : 00 00 01 or 00 00 00 01"
"...As you can see, here I have 00 00 24 A9 instead of 00 00 00 01"
Your H264 is in AVCC format which means it uses data sizes (instead of data start codes). It is only Annex-B that will have your mentioned signature as start code.
You seek frames, not by looking for start codes, but instead you just do skipping by frame sizes to reach the final correct offset of a (requested) frame...
AVI processing :
Read size (four) bytes (32-bit integer, Little Endian).
Extract the next following bytes up to size amount.
This is your H.264 frame (in AVCC format), decode the bytes to view image.
To convert into Annex-B, try replacing first 4 bytes of H.264 frame bytes with 00 00 00 01.
Consider your shown AVI bytes (see first picture) :
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 4C 49 53 54 BA 24 00 00 6D 6F 76 69 ....LISTº$..movi
30 30 64 63 AD 24 00 00 00 00 24 A9 65 88 84 27 00dc.$....$©eˆ„'
C7 11 FE B3 C7 83 08 00 08 2A 7B 6E 59 B5 71 E1 Ç.þ³Çƒ...*{nYµqá
E3 9C 0E 73 E7 10 50 00 18 E9 25 F7 AA 7D 9C 30 ãœ.sç.P..é%÷ª}œ0
E6 2F 0F 20 00 3A 64 AA CA 5E 4F CA FF AE 20 04 æ/. .:dªÊ^OÊÿ® .
07 81 40 00 48 00 0A 28 71 21 84 48 06 18 90 0C ..#.H..(q!„H....
31 14 57 9E 7A CD 63 A0 E0 9B 96 69 C5 18 AE F2 1.WžzÍc à›–iÅ.®ò
E6 07 02 29 01 20 10 70 A1 0F 8C BC 73 F0 78 FA æ..). .p¡.Œ¼sðxú
9E 1D E1 C2 BF 8C 62 CE CE AC 14 5A A4 E1 45 44 ž.á¿ŒbÎά.Z¤áED
38 38 85 DB 12 57 3E F6 E0 FB AE 03 04 21 62 8D 88…Û.W>öàû®..!b.
F6 F1 1E 37 1C A2 FF 75 1C F1 02 66 0C 92 07 06 öñ.7.¢ÿu.ñ.f.’..
15 7C 90 15 6F 7D FC BD 13 1E 2B 0C 14 3C 0C 00 .|..o}ü½..+..<..
B0 EA 6F 53 B4 98 D7 80 7A 68 3E 34 69 20 D2 FA °êoS´˜×€zh>4i Òú
F0 91 FC 75 C6 00 01 18 C0 00 3B 9A C5 E2 7D BF ð‘üuÆ...À.;šÅâ}¿
Some explanation :
Ignore leading multiple 00 bytes.
4C 49 53 54 D6 3C 00 00 6D 6F 76 69 including 30 30 64 63 = AVI "List" header.
AD 24 00 00 == decimal 9389 is AVI's own size of H264 item (must read in Little Endian).
Notice that the AVI bytes include...
- a note of item's total size (AD 24 00 00... or reverse for Little Endian : 00 00 24 AD)
- followed by item data (00 00 24 A9 65 88 84 27 ... etc ... C5 E2 7D BF).
This size includes both the 4 bytes of the AVI's"size" entry + expected bytes length of the item's own bytes. Can be written simply as:
AVI_Item_Size = ( 4 + item_H264_Frame.length );
H.264 video frame bytes in AVI :
Next follows the item data, which is the H.264 video frame. By sheer coincidence of formats/bytes layout, it too holds a 4-byte entry for data's size (since your H264 is in AVCC format, if it was Annex-B then you would be seeing start code bytes here instead of size bytes).
Unlike AVI bytes, these H264 size bytes are written in Big Endian format.
00 00 24 A9 = size of bytes for this video frame (instead of start code : 00 00 00 01).
65 88 84 27 C7 11 FE B3 C7 = H.264 keyframe (always begins X5, where the X value is based on other settings).
Remember after four size bytes (or even start codes) if followed by...
byte X5 = keyframe (IDR), example byte 65.
byte X1 = P or B frame, example byte 41.
byte X6 = SEI (Supplemental Enhancement Information).
byte X7 = SPS (Sequence Parameter Set).
byte X8 = PPS (Picture Parameter Set).
bytes 00 00 00 X9 = Access unit delimiter.
You can find the H.264 if you search for exact same bytes within AVI file. See third picture, these are your H.264 bytes (they are cut & pasted into the AVI container).
Sometimes a frame is sliced into different NAL units. So if you extract a key frame and it only shows 1/2 or 1/3 instead of full image, just grab next one or two NAL and re-try the decode.
I'm trying to read the content of a Mifare Ultralight card using the NFC Reader Library.
I'm totally new with NFC and I'm using this github repository to start.
The code in this repo allows to detect which type of card is detected (Mifare, Mifare ultralight ...) and read the UID of the card. I added this code in order to read the content of a Mifare ultralight card:
uint8_t bBufferReader[96];
memset(bBufferReader, '\0', 0x60);
PH_CHECK_SUCCESS_FCT(status, phalMful_Read(&alMful, 4, bBufferReader));
int i;
for(i = 0; i < 96; i++){
printf("%02X", bBufferReader[i]);
}
I have a card that contains the text "Hello world" and when I read it, the piece of code above print the following bytes:
0103A010440312D1010E5402667248650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
So I'm reading some stuff out of my card, however there is no traces of a "Hello world"
text.
Probably missing something (might be a big something or, hopefully, a little something). Any help would be great !
Edit
So I made some good progress. Mifare ultralight contains 16 pages of 4 bytes, 0 - 3 are for internal usage (serial number, lock etc ...) and 4 - 15 are for user data. I can now read the content of my cards, however, just a few question remains:
I'm reading a card that contains an URL, www.google.com, here is what I got:
03 0F D1 01 -> Page 1, 4 bytes of non text data, not sure what it is
0B 55 01 67 -> Page 2, 3 bytes of non text data, then 1 bytes for the "g"
6F 6F 67 6C -> Page 3, 4 bytes for "oogl"
65 2E 63 6F -> Page 4, 4 bytes for "e.co"
6D FE 00 00 -> Page 6, 1 byte for "m", 1 byte for I don't know
00 00 00 00 -> Other pages are just empty
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
So I have got 7 bytes of data + my url, "google.com" + 1 byte FE
I can't find what are these 7 prefix bytes + this 1 trailing byte...
Edit again
Ok got it, it's the NDEF message format.
Yes it is NDEF format!
03 NDEF Message
0F length
Record 1
D1 - MB, ME, SR, TNF=”NFC Forum well-known type”
01 Type length
0B Payload length
55 Type - “U”(Abbrivation for URL)
67 6F 6F 67 6C 65 2E 63 6F 6D (google.com)
Record 2
FE Terminator NDEF
I want to find blue areas on 24 bit bmp image. How can i find the blue color channel ? What is the ways of accessing the blue color channel ?
A 24-bits bitmap (.bmp) image has a header of 54 bytes. After that comes the pixeldata. Per pixel, 3 bytes are used: blue, green, red, in that order.
To see this, make a 1x1 pixel image in paint and make the one pixel blue. If you view the .bmp file in a hexeditor you'll see the 55th byte has the value FF (blue), while the 2 after that are 00 (no green, no red). Ofcourse you can also see this if you write a C program that reads all the bytes. If you print the values from the 55th byte till the end, you'll see the same.
The pixeldata needs to be aligned, this is called stride. Stride is calculated as follow:
stride = (width * bpp) / 8;
In a 3x3 bmp, stride will be (3 * 24) / 8 = 9. This value needs to be rounded up to a number divisible by 4 (12 in this case), so you need 3 extra bytes per row to correctly align the bits. So if all bytes are blue, after the 54 byte you will have:
FF 00 00 FF 00 00 FF 00 00 00 00 00
FF 00 00 FF 00 00 FF 00 00 00 00 00
FF 00 00 FF 00 00 FF 00 00 00 00 00
For a 4x4 bmp, stride = (4 * 24) / 8 = 12. 12 is divisible by 4, so there are no extra bytes needed. For a 5x5 bmp, stride = (5 * 24) / 8 = 15, so 1 extra byte is needed per row.
To find out more info about the bmp file format, check out this wikipedia page. Hope this helps!
The 24-bit pixel (24bpp) format supports 16,777,216 distinct colors
and stores 1 pixel value per 3 bytes. Each pixel value defines the
red, green and blue samples of the pixel (8.8.8.0.0 in RGBAX
notation). Specifically in the order (blue, green and red, 8-bits per
each sample).
...from here.
When I am sending a DNS query to the DNS it returns the header with the format bit set.
Indicating there is a problem with the format, but I am failing to see what it is. Its possible I have misinterpreted the RFC, or misread it but right now I cant seem to work it out.
The DNS structure I am sending looks like this in hex.
Header
00 01 - ID = 1
01 00 - RD = 1
00 01 - QD = 1
00 00 - AN
00 00 - NS
00 00 - NR
Question for www.google.com
03 77 - 3 w
77 77 - w w
06 67 - 6 g
6f 6f - o o
67 6c - g l
65 03 - e 3
63 6f - c o
6d 00 - m 0
00 01 - QTYPE
00 01 - QCLASS
I then flip the bytes for any field that is two bytes, to convert to big endian for the network format. So each row of the header, and then QTYPE and QCLASS ...
Here's what a byte-by-byte hexdump of that query packet should look like (tested and working!):
00000000 00 01 01 00 00 01 00 00 00 00 00 00 03 77 77 77 |.............www|
00000010 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01 |.google.com.....|
I think your problem is that the third and fourth bytes of the packet (flags and rcode) are two single-byte fields, not one 2-byte field - it looks like you might be treating it as a 16 bit integer and swapping the bytes?
To get these you can use netcat and dig.
# nc –uip 53 > dnsreqdump
# dig www.example.com #localhost
# nc –u 8.8.8.8 53 <dnsreqdump >dnsrespdump
Now you can inspect them in hexedit or your favorite hex editor.
I tend to think that your problem depends on how are you actually "flipping the bits to convert to network format".
Typical C library implementations provide the htonl() function family to do the conversion from host into network order and viceversa.
Of course, without seeing the code, I cannot be sure that this is the problem.