rtpjpegdepay returning jpeg images that do not end in EOI (ff d9)
Hi! I am running gstreamer on a number of rtsp streams each connected a different camera. For two specific cameras the output of gstreamer sometimes includes jpeg frames that are not valid jpegs - they do not end in an EOI marker (ff d9).
This is my command:
gst-launch-1.0 -vv rtspsrc location=rtsp://USER:PASSWORD@IP:554/sub ! rtpjpegdepay ! multifilesink location="/tmp/frame%d.jpg"
Here is an example of a 'bad' file from the first camera. Around 7% of the frames are invalid JPEGs:
$ file /tmp/frame24.jpg
/tmp/frame24.jpg: JPEG image data, baseline, precision 8, 640x360, components 3
$ hexdump -C /tmp/frame24.jpg | head -5
00000000 ff d8 ff db 00 43 00 10 0b 0c 0e 0c 0a 10 0e 0d |.....C..........|
00000010 0e 12 11 10 13 18 28 1a 18 16 16 18 31 23 25 1d |......(.....1#%.|
00000020 28 3a 33 3d 3c 39 33 38 37 40 48 5c 4e 40 44 57 |(:3=<9387@H\N@DW|
00000030 45 37 38 50 6d 51 57 5f 62 67 68 67 3e 4d 71 79 |E78PmQW_bghg>Mqy|
00000040 70 64 78 5c 65 67 63 ff db 00 43 01 11 12 12 18 |pdx\egc...C.....|
$ hexdump -C /tmp/frame24.jpg | tail -5
0000ab70 0f 9a 0e c7 a2 4f ab 4d 1c b7 16 96 16 c1 36 96 |.....O.M......6.|
0000ab80 55 2a 32 46 0e 09 0a 06 07 7a e4 6f 9a db cb 89 |U*2F.....z.o....|
0000ab90 60 20 b0 ce fc 2e 00 e7 8e 7b f1 59 34 51 6d 4d |` .......{.Y4QmM|
0000aba0 25 5a 3c 9c 91 8d bb bd d9 |%Z<......|
0000aba9
And some more:
$ hexdump -C /tmp/frame58.jpg | tail -5
0000ab70 a2 b0 6a ea cc e8 8d 59 41 de 0e c7 a2 4f ab 4b |..j....YA....O.K|
0000ab80 1c b7 16 96 16 c1 36 92 aa 54 67 18 24 12 14 70 |......6..Tg.$..p|
0000ab90 3b d7 23 7c d6 c5 22 10 10 58 67 7e 17 00 73 c7 |;.#|.."..Xg~..s.|
0000aba0 3d f8 ac 9a 28 b6 a6 92 ad 1e 4e 48 c6 dd d9 |=...(.....NH...|
0000abaf
$ hexdump -C /tmp/frame78.jpg | tail -5
0000ab70 8d 59 41 de 0e c7 a2 4f ab 4c 92 cf 69 61 6e 10 |.YA....O.L..ian.|
0000ab80 29 65 52 a3 38 c1 c1 21 47 03 bd 72 37 c6 db cb |)eR.8..!G..r7...|
0000ab90 89 60 20 b0 ce fc 2e 00 e7 8e 7b f1 59 34 51 6d |.` .......{.Y4Qm|
0000aba0 4d 25 5a 3c 9c 91 8d bb bd d9 |M%Z<......|
0000abaa
All of the files end in either bd d9
or dd d9
.
From the second camera things look a little different - I receive bad frames 15% of the time and the files all end in 15 9d 45 3b 12 d9
:
$ hexdump -C /tmp/frame85.jpg | tail -5
000056e0 e7 98 e6 59 15 47 a0 39 c5 61 51 45 82 e7 49 15 |...Y.G.9.aQE..I.|
000056f0 a4 50 8f ba 19 bd 5a a5 69 95 07 50 2b 96 a2 8e |.P....Z.i..P+...|
00005700 52 b9 8e 82 4d 46 24 fb a0 b9 aa 17 17 52 5c 36 |R...MF$......R\6|
00005710 4f 03 b0 15 9d 45 3b 12 d9 |O....E;..|
00005719
Now I assume that the camera is returning some kind of bad data (although I'm not sure why it's only happening for 2 cameras out of 100), but looking at the code of rtpjpegdepay I see that it is supposed to ensure that output jpeg's always end in EOI:
if (end[0] != 0xff && end[1] != 0xd9) {
GST_DEBUG_OBJECT (rtpjpegdepay, "no EOI marker, adding one");
/* no EOI marker, add one */
outbuf = gst_buffer_new_and_alloc (2);
gst_buffer_map (outbuf, &map, GST_MAP_WRITE);
map.data[0] = 0xff;
map.data[1] = 0xd9;
gst_buffer_unmap (outbuf, &map);
gst_adapter_push (rtpjpegdepay->adapter, outbuf);
avail += 2;
}
So I'm pretty sure that this is also a bug of some kind in rtpjpegdepay.