On Sun, 2007-08-12 at 20:51 -0600, James G. Flewelling, Cobras2 wrote: > Hello there, > I've never done any coding for transcode, or any other video software > for that matter, so I'm a bit new to the whole idea... but what I want > to know is, how do I take a given RGB colour value, and convert it into > the YUV values as used in the transcode vframe_list structure's > video_buf_Y, video_buf_U, and video_buf_V? (Note that I only need to > convert one or a small number of colours, and then use them over and > over; I am not extracting a whole bunch of colours from the frame itself > and then converting them, or anything like that.)
Branko already gived the formula; there are some version (less or more precise) of such formula floating around. I've reconstructed the history of this conversion formulas some time around, but unfortunately I've no longer this stuff avalaible :( Anyway, if you need only a subset of colors, consider the usage of some pre-computed values, and/or a look-up table. It also can be a good idea to use integer arithmetic in computations. > This might be a stupid question. I don't even know if the Y,U,V values > have the same interpretation for every different codec (do they?), but I > won't find out if I don't ask. They always have the same meaning, it's the image data after a lossless[1] transformation :) [1] Except for rounding errors and subsampling, if any. > It would be highly convenient if there is already some kind of RGB to > YUV conversion function in the transcode source I could use (I would > have thought there would be one, but I can't find it if it exists), but > it would be just as useful if someone could give me (or tell me where to > find) some info on how to make my own. First and foremost, I'll HIGHLY recommend to use 1.1.0 (the more recent alpha you can grab) for your development, since 1) it is much more modern and future-proof 2) it is much more confortable than 1.0.x for development Unfortunately, there is not a per-pixel convertion utility function avalaible, we have low-level (aclib) and high-level (libtcvideo) conversion routines that works for the whole image/picture. Maybe per-pixel functions will be added in future release, if there is need for them. > For example, although it's not the way I was planning on doing it, it > would solve my problem if I could simply define some pixels in the > video_buf_RGB member array of the vframe_list structure, and then run a > conversion to place the same info in the video_buf_Y, _U, and _V arrays > (in YUV format). I'm not sure that I've fully understood what you're saying here. What you mean with "define some pixels"? The whole video_buf_RGB data must have valid meaning, otherwise a conversion to YUV will give senseless results. > I have already looked at the wikipedia article about YUV (at > http://en.wikipedia.org/wiki/YUV ), which gives a conversion (when > simplified) simplifying is good but take the rounding errors in account when doing so. > It would also be very useful to know how the values themselves in the > video_buf_Y, _U, and _V arrays are stored (in fact, this may actually be > my only problem, but I'm not sure). They are specified as char values, video data is stored contiguosly, 8 bits for sample. No special meaning for any bit in a given sample. It would be nice to have pixel buffers page-aligned (speed reasons), but this requisite isn't strictly enforced yet. > but what is the particular interpretation of the bits inside the char? > For example, what would the maximum Y value look like? (11111111 which > is 0xFF, or something different?) And what would the minimum look like > (00000000 which is 0x00, or something different ?) Strictly speaking, the correct Y range is 16-240 (not 0-255), but that also isn't always enforced (and not only in transcode core). > Any information (or links to information) that anyone has on the subject > would be much appreciated; mplayer/mencoder have some good docs and pointers (see DOCS/*) wiki.multimedia.cx is another interesting source too. There also are some really good books on signal processing and/or digital audio/video around, but they are expensive :( Bests, -- Francesco Romani // Ikitt [ Out of memory. ~ We wish to hold the whole sky, ~ But we never will. ]
