The "popping" your seeing is caused by the inability of RGB data to be converted back to Y values > 235.(posted 8532 days ago)I looked into this issue while developing a M-JPEG codec. I believe my conclusion was the Y and the Cr/Cb values absolutly will/should be clamped to the ranges listed in the ITU-R 601 document. The issue is if you do YCbCr <-->RGB conversion in the codec, like many (most?) computer editing systems need, the color conversion matrix gives RGB values of < 0 or > 255, if your YCbCr values are outside the correct range. What your suggesting is the codec color space conversion should NOT map Y=16 to RGB=0 pixel values. The normal maximum Y value maps to RGB=255. If you adjust the color conversion matrix to make say Y=245 map to RGB=255, then NORMAL whites at Y=235 will be some value less than RGB=255 white. Of course a lot of codec's fumble the color conversion matrix and don't expand the Y in the 16-235 range to RGB in the 0-255 range correctly, they just map Y=16 to RGB=16, which is incorrect if you expect compatability with typical RGB images. The basic problem is video signals can go to > 100%, and computers can't. One fix would be for editing software to work fully in the YCbCr color space. You STILL would have the problem of imported RGB graphics (from say Photoshop) not being able to generate Y > 235.
There is also the little detail of gamma correction. A computer RGB image is generally non-gamma corrected, video data is pretty much always gamma corrected. If you make a RGB color bar chart at say 75% IRE, and feed it through most codec's, and then decompress it with video hardware codec's, and look at the waveform on a waveform monitor, the intensity values are wrong, as things were not gamma corrected. Gamma correction is unfortunatly a very processor intensive operation in software, and to correctly do requires 3 table lookups per pixel.
A lot of codec's also fumble the upsample/downsample filters for YCrCr<-->RGB. RGB is pretty much always 4:4:4 and YCbCr video almost never is. To implement a very high quality filter, potentially on XY for 4:2:0 video, requires a fancy multistage FIR filter. Fortunately newer short vector instructions (MMX or AltiVec) help here.
Software developers come down to the ugly tradoff of fast OR correct. It's only recently that correct functioning of codecs has gotten any attention, and I believe correct ones don't look so good performance wise next to fast ones. Image quality is not very easy to put in marketing ads, percent faster than brand Y is.
Actually your original "popping" problem is a performance issue, if you just recompress every frame, your "popping" will be gone, of course so will your performance for building. So are YOU willing to give up a bunch of performance to get a correct image?
Jan Bottorff, President Paradigm Matrix, Inc.