Posted by Frank on 11/27/06 16:39

On 27 Nov 2006 00:24:56 -0800, in 'rec.video.production',
in article <Re: Exported AVi is of poor quality>,
pwilleke@gmail.com wrote:

>Frank,
>
>I was checking the settings in Premiere last night and I found that the
>project I created was indeed PAL. As I live in Europe, this is what I
>want.

That's what I figured.

>But I also discovered that the output was set to Microsoft AVI.
>I opened the list and saw there was a setting Microsoft DV. When I
>choose that one, I can select NTSC DV or PAL DV.

The Microsoft AVI setting was what was limiting your choices at output
time. Selecting PAL DV should solve your problem.

>I Choose PAL DV and recreated the movie. It took about 20 minutes to
>create the AVI.
>This was very surprisingto me, as with the previous setting, it took
>about 12 hours !!!!!

That was expected. If Premiere was functioning correctly, the only
re-encoding that it should have had to perform would have been on
footage where you made actual changes to the original frames, such as
during transitions, chroma adjustments, effects, titles, etc. The
remaining untouched, unmodified frames would merely need to be copied
unchanged from the input to the output with no rendering required.

One of the characteristics of the Cinepak codec, and this was by
design, is that it takes much more processor power to encode than to
decode. This was a conscious design decision on the part of the folks
who developed it. At the point in time when it was developed many
years ago, most end users had quite underpowered computers, so it was
decided to design the codec in such a way that it would require a lot
of processing power to encode video but very little on the decoding
side to play it back. It's a highly asymmetric codec in that regard.

>However, the files created was about 8 Gb where the previous was -only-
>6 Gb. This would be a better quality I'm guessing.

Not so much due to the size, per se, but just because of the codec
used. Remember, different codes have varying degrees of efficiency.
That is, codec A might produce output files with approximately the
same visual quality level as codec B, but the files produced by codec
A might be 25 percent larger than those produced by codec B, thus
making codec B the more efficient codec in terms of file size. In
other words, file size alone is not a determinate of quality.

There are other measures of codec efficiency as well, including
encoding/decoding time, as you've already seen with the Cinepak codec.
Decoding time, and the related processor speed requirement, is a major
consideration these days due to the widespread use of battery-powered
handheld devices, from cell phones to music players. Tradeoffs are
constantly being made in this area, and extended battery life is a
major consideration in a handheld device since faster processors tend
to consume more power and generate more heat.

I don't think that many people would be happy with a cell phone that
could make and receive telephone calls, take high quality still
photos, shoot fabulous looking video, play games, record voice memos,
play audio and video files in 20 different formats, function as a
calculator and a calendar/schedular, surf the Web, and do your laundry
(and whatever else the designers could think of), but requires three
high-speed fans to keep it cool and has an eight-pound battery
attached. :)

>I opened TMPGenc late last night and went to bed. I will check this
>evening when I get home from work if the quality is better now.

I fully expect that it will be much better.

>I will
>also write another DVD to check the quality on a tv screen. Hope it's
>better this time so I can show my colleagues a descent video friday.

Ditto.

>Thanx a lot for your advises, you sure were a great help!

You're quite welcome. Happy to help.

>P

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/

[Back to original message]