Intel® Integrated Performance Primitives
Community support and discussions relating to developing high-performance vision, signal, security, and storage applications.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

RTP Jpeg Compression

stevena
Beginner
205 Views
Hello.
I've recently implemented an RTSP client that connects to a Camera and receives JPEG's over RTP. I receive the JPEG's in parts and when i get a full image i create a JPEG header based off information in the packets and the RTP JPEG RFC(using appendix A & B fromhttp://www.ietf.org/rfc/rfc2435.txt). When i send this new full JPEG to the IPP jpeg decoder(from the CJPEGDecodersample) it eventually gives me a "JPEG_BUFF_TOO_SMALL" error in the NextMarker function, i've stepped through the code and it seems to be towards the end.
If i save the full JPEG to file i can view it in windows image viewer. I can use another JPEG decoder(FreeImage) and it will decode it fine. But freeImage is a bit slower and i'd like to get IPP back to working. I've also tried with IJL but i cant dig deep into it and it just tells me there is a IJL_ERR_DATA when trying to read the whole file(reading just the header is fine).
I'm thinking it must be in the way i create the header, but i've been following the RFC specification, Maybe IPP doesnt support RTP JPEG's?
I've done alot of searching for this already and have not found much.
0 Kudos
1 Solution
Vladimir_Dudnik
Employee
205 Views
I've just tested with picnic application from IPP 7.0. It can display these images, although it brings data error message. As I see your images do not have EOI (end of image) marker, it should be two last bytes in valid JPEG data, if you did not miss from JPEG data anything additionally(0xff, 0xd9)

Vladimir

View solution in original post

7 Replies
Vladimir_Dudnik
Employee
205 Views
Hello,

IPPcodec expect all JPEG data are available at decode stage (although it is possible to have only header part available at ReadHeader call). So,when you try to decode not complete JPEG data, codec will expect more data available and indicate that there no enough data provided (in other words, JPEG data not complete).

Note, I do not think that there is a such separate entity as RTP JPEG's. Real Time Protocol (it is what RTP stands for) is justspecification how to deliver JPEG data from sender to receiver.

You should follow RTP spec in order to restore valid JPEG data at receiver end to avoid issues at decode step.

Regards,
Vladimir
stevena
Beginner
205 Views
So is that what the error is telling you, that my data is incomplete when attempting to decode the JPEG?
I am following the steps to put the JPEG back together as per "RTP Payload Format for JPEG-compressed Video" (http://www.ietf.org/rfc/rfc2435.txt). I follow the "Fragment Offset" so that when it is 0 it is the first part of the JPEG and when the end marker is set the JPEG is complete, and i follow the sequence number for the parts in between to set each part of the jpeg in the right order.
So i'm pretty sure my jpeg's are complete because I can save the final full JPEG's to disk and view them and they look fine. If i take these JPEG file's and try to read them with IPP i get the same data errors.
Vladimir_Dudnik
Employee
205 Views
Are you trying to decode with IPP sample or you develop your own application base on IPP to decode JPEG? Is it possible to attach your file here, so we can look at what might be a problem there?

Vladimir
stevena
Beginner
205 Views
I believe i'm using the sample "CJPEGDecoder" class but wrapped in my own class, i call ReadHeader and it works, i then call ReadData and thats when it hits theJPEG_BUFF_TOO_SMALL, i've added the JPEG file im using, as well as a one that i'm testing with a different JPEG header(VLC) then the RTP one(i get the same error for both)
Vladimir_Dudnik
Employee
206 Views
I've just tested with picnic application from IPP 7.0. It can display these images, although it brings data error message. As I see your images do not have EOI (end of image) marker, it should be two last bytes in valid JPEG data, if you did not miss from JPEG data anything additionally(0xff, 0xd9)

Vladimir

View solution in original post

stevena
Beginner
205 Views
Ahhh i think that has fixed my problem, i guess it is expected that the EOI marker is there and my JPEG source must be expecting me to put the marker there.
Thanks alot!
Vladimir_Dudnik
Employee
205 Views
you are welcome :)
Reply