Created attachment 534898 [details]
What its supposed to look like

Description of problem:
The enclosed patch applies to current HEAD of Gstreamer Base Plugins and adds a small option to prevent colorspace loss / scaling when transcoding from high fidelity JPEG types to other encoders that can accept the those colorspaces (like H.264 encoders).

Please submit this minimal patch to the Gstreamer project on our behalf.


How reproducible:
Always.


Steps to Reproduce:
1. Download attached .mov file and run:

gst-launch filesrc location=pluge.mov ! qtdemux ! jpegdec ! xvimagesink

2.Compare against the patched version and run:

t-launch  filesrc location=pluge.mov ! qtdemux ! jpegdec ! video/x-raw-yuv,color-matrix=\(string\)jpeg ! ffmpegcolorspace ! video/x-raw-yuv,color-matrix=\(string\)hdtv ! xvimagesink

3.
  
Actual results:
Colors are lost

Expected results:
being able to specify color-matrix we get a proper display of the video. Attached is a jpeg of what it should look like.

Additional info:
There are various ways one can interpret data thats in YUV or Y'CbCr format.

There are a few different flavors which assume that RGB (0,0,0) is mapped to Y'CbCr (16,128,128), and RGB (255, 255, 255) is mapped to Y'CbCr (235,128,128). People I talk with frequently call this 'scaled range', 'SMPTE range', 'video range', '0-700 mV', or something to that effect. Common versions of this include "rec709" and "601" (or hd and sd).


There are a few other flavors which assume that RGB (0,0,0) is mapped to Y'CbCr (0,128,128), and RGB (255,255,255) is mapped to Y'CbCr(255,128,128). Most notiable of these is jpeg. Some folks call these spaces broadly "full range".


Most everyone doing "video" assumes that Y'CbCr means the first case. So when we write video formats (theora, webm, h.264, etc), it's safest to format your frames in the correct color space - or at least the correct color range.

However, our default color space for data that we're transcoding is in one of the "full range" spaces (they're photojpeg quicktimes).

Yes, color space intent can be signalled via metadata, but everyone assumes metadata is wrong :)

Anyway, ffmpegcolorspace in gst-plugins-base-0.10.35 includes a transform which gets most of what we want. It's not *entirely* correct, but it does already exist. The existing implementation simply rescales the components, while a more correct implementation would rematrix the source Y'CbCr to the dest Y'CbCr.

This patch exposes the exsting ffmpegcolorspace implementation via the color-matrix caps.