CompuServe Messages

Do you also mean "delta" as "change?" >> Yes, the "difference". >>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. >> Huh? I should say it is by the complexity of the algorithm involved and the measurement is made without hardware assistance. :> The speed is completely dependent on the codec in use. >> Sure, there is implementation difference. 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. >> The advanced DSP chips used compensate the difference in complexity. Comparing to the complex compression process, it is relatively simple for them to do decompress. That is not to say that the encoding quality is as good as if it were done over time. >> The time involved is irrelevant. 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. >> No, they don't normally use software encoding (it takes a long time even on Pentium). The reason that the bureaus take longer time and get better quality result is because they use human eyes to do tuning and find the best result by experiements. Normally, they need to compress a video section more than 10 times to find the best result. 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? >> I'm talking about the editing process (in the simplest form, to insert/remove/change a frame into a compressed video) and why MPEG compressed video (or a video use MPEG as its codec) is not suitable to do editing. For example, to locate a frame and change its content a little bit (for instance, use a filter), you have to find the nearest I-Frame, render it, find all the B- and P- frames in between, then render and superimpose them to get the target frame, make the change (apply the filter), re-do the compression process for all the B- and P- frames involved. >> This is the case that you didn't make too much changes, so that it is not becoming a I- frame. If it is becoming a I- frame, the previous frames can be left untouched but the newly inserted I- frame will need to be the basis for the following frames, and you need to do the recompression to the following B- and P- frames. >> Note: This is an over simplified (and may not be accurate) way to explain what is going on but I've tried my best. Isn't MPEG is enough of a standard that the rules are defined. >> As a delivery format, yes. what is the barrier to I-frame editable MPEG? >> As I said, when MPEG is all I-frames, it is the same as M-JPEG. And, if it is not all I-frames, it is relatively hard to do editing on it. I know it's not here yet, why not? >> See previous sentence. Is it that the standard is too narrow to allow for the agreesive compression work done with M-JPEG. >> The nature of the compression algorithm involved determine their respective usage. M-JPEG, frame-based editing; MPEG, delivery. Since M-JPEG is not a standard, has this given manufacturers greater flexibility to tighten the algorithms? >> M-JPEG is a standard format used for years. All video capture boards ship with their own M-JPEG Codecs (many ship more than one codec for the different flavors). 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? >> It is incorrect. One other thing, I saw you write in another thread that Double-buffer should be turned on for video capture. >> I said it is for the SCSI drives and in the case that when you use software disk cache program like SMARTDRV. Double buffering allow you to prevent read/write lock introduced by the disk cache and also prevent lazy write algorithm implemented in the disk cache program not being able to flush the data into the disk while you're reading. 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. >> You should always turn OFF any disk cache, buffer, or whatever, when you're doing video capture. It does you no good and wasting time as video data stream is so big, no practical disk cache size can be allocated. –Vince Ulead Systems, Inc.