CompuServe Messages

Vincent: Thanks for the response. I do have a couple of questions though.. >>MPEG go even further by recording the delta to the delta and/or also considering all the frames/deltas. << I'm a little confused by this. I do understand the I,B,P frames (key-frames, delta-frames, predictive frames) of a typical MPEG stream. How are you using "delta?" Do you also mean "delta" as "change?" >>Its speed is also not balance, normally its compression will take around 100 times more than the decompression.<< Be careful here, this is ceraitnly not true by definition. The speed is completely dependent on the codec in use. In the current issue of New Media we review six different_real-time_MPEG encoders (there are two more that have become available since the end of the review cycle). These are "balanced" in terms of equal time for encoding and decoding: real-time video. That is not to say that the encoding quality is as good as if it were done over time. We did see a quality difference between the real time encoders and the work of MPEG service bureaus, who take as long as they need using software encoding. >> its decompression is time and data dependent. If you move a frame forward or remove/loss a frame, all will be affected/distorted. << I have not noticed this to be the case. Yes, frames are repeated if the next frame data does get through in time. Are you suggesting that a 4:00 minute clip might take less or more than 4:00 minutes to play out, with or without skipping frames? >>Therefore, it is possible to do I-Frame only MPEG clip editing but we need to do/define the rule to do interpolation of those delta frames without much performance penalty for practical usage.<< Isn't MPEG is enough of a standard that the rules are defined. This is my question. Recognizing that MPEG & M-JPEG share this common root (JPEG), and recognizing that MPEG offers greater potential for delivery at low data rates and recognizing that one does need every frame to do editing: what is the barrier to I-frame editable MPEG? I know it's not here yet, why not? Is it that the standard is too narrow to allow for the agreesive compression work done with M-JPEG. Since M-JPEG is not a standard, has this given manufacturers greater flexibility to tighten the algorithms? Is it incorrect to see the advantage of I-MPEG over M-JPEG as the ability to avoid artifacts on artifacts if you have to re-compress for delivery? IOW, wouldn't an MPEG I-frame recompress artifacts as they were before rather than making new artifacts on top of old artifacts? Wouldn't a stream of MPEG I-frames be ripe for conversion to a stream of I, B, and P-frames without changes to the retained I-frames? One other thing, I saw you write in another thread that Double-buffer should be turned on for video capture. When we were studying capture cards for New Media we were told by a couple different manufacturers, Intel included, that it should be turned OFF for video capture. I don't know that I remember why though I'm looking into it. Any thoughts on the disagreement? Jeff