[FFmpeg-user] Getting mono image after scale to convert YUV to RGB24; the YUV image is still color, the RGB isnt

[Connie L. O'Dell]

Hi All,
   We have an application which we have compiled for a proprietary
processor using a customized gcc targeting that processor, and the compiler
supplies integer-based floating point emulation via a library.
The application decodes an H264-encoded image into a YUV 320x240 image, and
then we need to convert said image to 320x240 RGB24 for display on our
target hardware.  The ffmpeg version is likely downrev, such as ~1 year
old.  Our issue is that the image as decoded into YUV appears correct (in
desperation we even tried decoding a solid red image so we could check the
resulting YUV exactly), but the additional step of converting it to RGB24
seems to have the effect of producing a monochrome image, consistently from
various sources.
Our most common input is originally static jpeg or MP4 images/movies, which
we can check with various natively-compiled tools on our server to ensure
are valid input images and streams.  We are satisfied at the correctness of
the overall decoding into YUV and a monochrome-looking version of RGB, but
this one aspect mystifies us.  We know that the same image is produced if
just the Y component gets through as R, G, and B, without any U and V, but
it does appear that U and V are present, in our one-color diagnostic
examples.
We have studied the tutorials mentioned on this reflector and other
reflectors/websites, and model our use of sws_scale extremely closely on
these.  Certainly we are frustrated like many others by the moving target
aspect, but I do not doubt that it creates job security for specialists in
this area.
We have also seen other mention on other websites of people who
mysteriously obtain monochrome when expecting color, but we either see
these questions unanswered, or the answer is something we have tried and
hasn't helped, or didn't have wrong in the first place.

Can anyone suggest any of the following that is most likely to make a
difference?  We have considered all:
1) Use a more up-rev ffmpeg version (this is not without pain for us, as
it's probable that at least the makefiles/mkconfig/whatever have been
hacked by our compiler folks.  More info in Appendix A below).  It would be
nice if we knew a specific reason, or subset of the files that are
affected, but we would try it regardless if it was indicated.
2) The YUV to RGB conversion is very heavily dependent on the accuracy of
the floating point comptation, and this lack is only evident at this phase.
3) Someone has yet another example or tutorial we could peruse,or one that
is more helpful in this specific application.  Please?   :-)
4) We need to somehow specify a narrower target RGB colorspace than 0-255,
such as maybe 16-235, in order to do the conversion without
clipping/overflow errors.  We tried the method one website suggested for
this with no luck so far.
5) This is a bug still in ffmpeg?
6) Other bugs in our targeted compiler.  Obviously, this is always a
possibility.
7) We are using the correct YUV and RGB keywords.  We have been over this
pretty heavily already.
7) Other?

Finally, we are looking for a resident compiler expert, but a resident
ffmpeg expert who could cover both would work also.  Email me if you want a
link to the employment website involved (I am just a contractor and have my
own company).

Thank you for taking the time to listen to our problem, and I welcome your
thoughts...  :-)

Appendix A: (clues to what version we have that I have found is
ffmpeg_src/Changelog, where the latest version specifically mentioned that
is not <next> is 0.6, also, if I cd to ffmpeg_src and do "version.sh .", I
get back: SVN_r487, but I do not know if either of these are meaningful
since I do not know if the Changelog is still maintained in the same form,
and the use of version.sh is something I just reverse engineered.  I do
realize that if we had a compiled version of ffmpeg based on this source, I
could inquire as to its version, as previosuly discussed on this reflector,
but so far we do not have such).

Cheers,
Connie L. O'Dell
Sr. Verification Specialist
c.odell at co-consulting.net
303-641-5191
_____________________________________________
CO Consulting - Boulder, CO - http://co-consulting.net