#Boards and Basics
5 messages in this thread
Jeff,
Your description of MPEG is almost right but not accurate enough, we should
also mention that it also considers the previous frames and all the frames are
considered all together, not just the delta to the key frames. Because of this
nature, MPEG is not suitable for the video editing purpose. Please find MPEG
FAQ on Internet for details. Motion-JPEG (M-JPEG) just stored each frame as a
JPEG compressed frame. They are both lossy compression format. Nothing come
cheap, more compression ratio you gain, more loss of data. Find JPEG FAQ on
Internet for details.
As to the PC-based M-JPEG capture board, nothing come close to the TrueVision
Targa 2000 that I use yet. Its listed price is around US$5000. For lower
priced products (less than US$1000), miro DC1 TV, Fast Movie Machine Pro (with
M-JPEG option board), and Intel Smart Video Recorder are the ones being
recommended by New Media. I have used all of them, they are all good boards in
price/performance. Intel SVR Pro being the easiest to install (most of people
can't understand this is really a great achievement of Intel until you tried to
install all the other boards on the market place and failed with headache) and
give good output. Miro board has the build-in S-Video encoder and gives the
best quality output to video tape, but its performance to computer's monitor is
not so good. Fast is good in all but lacks the encorder (you have the option
to buy) to output video to tape.
–Vince, Ulead Systems.
Vincent:
Thanks for the correction on the P-frames. I was trying to keep it too simply.
I have a question for you or anyone else. MPEG and M-JPEG are both based on
the JPEG spec. I know it is simplistic to say the M-JPEG captures 30 JPEG
frames per second and MPEG captures JPEG frames on I-frames. But can anyone
tell me in more technical terms what the difference is between a M-JPEG stream
and an I-frame only MPEG stream? and why, if they are both based on JPEG,
can't any of the professional editing systems (AVID, DT, etc.) compress to
I-frame only MPEG rather than M-JPEG for recompression later to an MPEG file?
That does mean writing a new compression algorithm, which is the business
reason why no one has done it. But is there a technical reason? It would seem
to me someone would do well to create such an "I-MPEG" stream, edit with that,
than recompress to lower the data rate by adding the B- & P-frames. Wouldn't
such a stream have the advantage of not making MPEG artifacts on top of M-JPEG
artifacts?
Vincent, BTW, I did much of the testing for the New Media article you
mentioned.
Jeff Sauer
Desktop Video Group
Jeff,
Sorry for replying you late, I was so busy. Put it into the simplest way of
speaking: M-JPEG is just a sequence of JPEG compressed frames. JPEG compression
is also balance, that means its compression and decompression take equal time.
You can extract and locate each frame percisely, therefore, you can use this
format (among other formats) to do video frame editing. MPEG and other
compression scheme (for example, CinaPak and Indeo) use key frames concept and
do further compression by only recording the delta to the key frame. MPEG go
even further by recording the delta to the delta and/or also considering all
the frames/deltas. Its speed is also not balance, normally its compression
will take around 100 times more than the decompression. And, its decompression
is time and data dependent. If you move a frame forward or remove/loss a
frame, all will be affected/distorted. Therefore, to locate a precise frame to
do editing or move a frame will become not practical/possible without hardware
assistance.
However, as you said, if each frame of MPEG is set to be a key frame (I-Frame),
MPEG/M-JPEG will be the same. But, you loss the extra compression gain in
MPEG. 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. This kind of editable MPEG
format is only in a early draft poposal stage.
Right now, you should treat MPEG as an delivery format for your final result.
And treat M-JPEG as the editable format for your source clips.
Hope this will help.
And, thanks for the testing you did in the New Media article. It's a very good
review and reference of the exiting boards.
–Vince
Ulead Systems, Inc.
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
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.