>> I found the problem. It is concerned with lavtools. I was >> recording the fooprint using lavrec. Apparaently, it produced many >> pixels (at least 10% per image) with YUV out of the spec >> (16<=Y<=235, 16<= u,v <= 240). Since matteblend.flt is programmed >> using the exact spec, a lot of overflow/underflow conditions >> appeared giving rise to the above mentioned effects. I added some >> code to matteblend.flt.c in an attempt to force the standard. This >> worked well, although the process became much slower. ... >That pixles are a slight problem, because they are nor allowed, but >appear, because of the transmiton. There should be one or two mail from >Andrew about that problem.
Such pixels are not really "out of spec"... all values in the range [1,254] are legal --- even though they do not map back to R'G'B' values. (For example, Y' < 16 is "blacker than black".) The specification was created this way on purpose, to give some room for ringing and over/under-shoot in both the signal acquisition and the digital operations that follow. The pixels should only need to be clipped to the [16,235]/[16/240] range when converted to R'G'B'... ...AND, here, the value of the alpha frame pixels in matteblend.flt should also be clipped (because they are being implicitly converted into a [0,1] scale). But, the output pixels (and the other inputs) should not. (The output should be restricted to a [1,254] range, but given the math involved and legal input pixels, clipping is probably not necessary.) -matt m. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
