GNOME Bugzilla – Bug 664792
Staircase effect in M-JPEG over RTP with unaligned image dimensions..
Last modified: 2011-12-05 09:49:14 UTC
Created attachment 202117 [details] [review] Proposed fix ceiling image dimensions instead of flooring them. When M-JPEG images are streamed over RTP they may get a staircase effect if their dimensions are not a multiple of 8. E.g. if the width of an image is 450 pixels then it has to be either floored to 448 or ceiled to 456 in order for its width to be expressed properly in an RFC2435 JPEG over RTP header. The current rtpjpegpay element floors the dimensions before writing the image dimensions into the RFC2435 header. Unfortunately if an image of 450 pixels is being transmitted, then it actually contains image data for 456 pixels, but the flooring in the RFC2435 header states that the width is 448 pixels. This is what causes the staircase effect mentioned above. In order to fix this rtpjpegpay should of course round up to the nearest multiple of 8. Doing so should always be safe since JPEG image data is expressed in 8x8 pixel (or larger) MCUs. Unfortunately I can not provide a pipeline testcase that exhibits this behaviour that I am able to share with you, so I need to appeal to your insights about the RTP and JPEG specifications and hope that you can identify the same bug as I do. And hopefully you are also of the opinion that my fix is sane. / Sebastian
This testcase exhibits the staircase effect that I manage to get rid of using the attached patch: hostname$ gst-launch-0.10 -e videotestsrc ! video/x-raw-yuv,width=450,hight=800,framerate=1/1 ! jpegenc ! rtpjpegpay ! rtpjpegdepay ! jpegdec ! autovideosink
commit c090201ca59f4d16df8af7390472b5eebfa86cab Author: Sebastian Rasmussen <sebrn@axis.com> Date: Thu Nov 24 13:58:01 2011 +0100 rtpjpegpay: Ceil jpeg dimensions, instead of floor A JPEG image inside an RTP stream has a preceeding RFC2435 header that conveys width/height. The dimensions in this header are limited to be multiples of 8. Since JPEG uses an MCU of 8x8 pixels any image must already indirectly have image data dimensions that are rounded up in order to contain enough data to render the image. Therefore this fix safely rounds the image dimensions in the RFC2435 header up to the closest multiple of 8.