[FFmpeg-devel] mjpegenc: wrong chrominance sampling values written to SOF header for YUVJ422P?

Michael Niedermayer michaelni at gmx.at
Sat Dec 14 19:17:45 CET 2013

On Sat, Dec 14, 2013 at 04:03:55AM +0200, Andrey Utkin wrote:
> In RFC 2435 (JPEG RTP) section 4.1 there is a table which defines
> "types" 0 and 1 for pixel formats. (You can look at it at
> http://www.ietf.org/rfc/rfc2435.txt)
> rtpenc_jpeg.c sets type=0 if pixel format is yuvj422p, and 1 if yuvj420p.
> Actually the issue is not related to RTP, just JPEG RTP RFC is one of
> my info sources on this issue, because the issue has raised while i
> have been working on JPEG RTP payloader for VLC.
> The issue is probably mjpegenc.c.
> For yuvj420p everything is ok - in mjpegenc.c output in SOF section
> the components Y, Cb, Cr have such sampling factor values: 0x22, 0x11,
> 0x11 (first half-byte is for horizontal, second is for vertical).
> But for yuvj422p mjpegenc.c outputs sampling factors 0x22, 0x12, 0x12.
> By the table from RFC, there should be values 0x21, 0x11, 0x11. Also
> looking at GStreamer JPEG RTP payloader, it expects the same values -
> 0x21, 0x11, 0x11 in such case.

> Looking at gstreamer jpeg encoder, i see some division operations under comment
> "maximum is invariant, as one of the components should have samp 1".
> As far as i understand, there we need to divide all vertival sampling
> factors so that we have at least one of them equal to 1. Is that
> correct?

I dont know, what does the jpeg spec say about that ?


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131214/b01f1b1e/attachment.asc>

More information about the ffmpeg-devel mailing list