Poorer quality on M-PEG2 than on original DV tape.

[Henrik Sundell]

Hello from a real novice,

I have a Sony DCR-TRV27E and I have used Ulead VideoStudio6 for capturing, editing and DVD burning.

My problem is that my converted MPEG-2 files shown on a TV have a
poorer quality played from the burned DVD than played directly
from the DCR.

Can there be some conversion problem as my DCR has a resolution of 690000 pixels which is more than MPEG-2 has (about 400000 pixels) ?

[greymalkin]

what is the bitrate you are encoding your mpeg2 files at? You should set it high (8500Mbps).

You are always going to lose some quality due to the transfer from dv to mpeg..mpeg is just a more lossy format.

[junkmalle]

Regardless of how many pixels your camcorder's CCD has, it produces the same 720x480 resolution as DVD.

[wwjd]

Also, the mpeg encoder in Pinnacle 6 is not very good even with higher bitrates. Not all mpeg encoders are created equal. Two popular encoders on this site are Main Concept and CCE Basic.

[Webster]

Hello from a real novice,

I have a Sony DCR-TRV27E and I have used Ulead VideoStudio6 for capturing, editing and DVD burning.

My problem is that my converted MPEG-2 files shown on a TV have a
poorer quality played from the burned DVD than played directly
from the DCR.

try to capture with DVIO
Encode to DVD MPEG-2 with TMPGEnc

You will definitely get better result.

[edDV]

Ulead VideoStudio 6 is a pretty old version. You are a couple of revs back on the internal Mainconcept MPeg2 encoder. You should consider upgrade to v9 next time there is a sale. Huge improvements over v6.

That said, VS defaults to 7Mb/s vbr for DVD MPeg2. Change that to 8.5Mb/s CBR for full quality.

I'll assume you are using IEEE-1394 for DV transfer.

[MpegEncoder]

Regardless of how many pixels your camcorder's CCD has, it produces the same 720x480 resolution as DVD.

Yes, but the bitrate of the camcorder is about 8x that of the DVD.


25 Mbps vs. ~8 Mbps

[junkmalle]

Regardless of how many pixels your camcorder's CCD has, it produces the same 720x480 resolution as DVD.

Yes, but the bitrate of the camcorder is about 8x that of the DVD.


25 Mbps vs. ~8 Mbps

25/8 is not 8x, it's ~3x. Someone had already brought up bitrates. I was responding specifically to this:

Can there be some conversion problem as my DCR has a resolution of 690000 pixels which is more than MPEG-2 has (about 400000 pixels) ?

[MpegEncoder]

Regardless of how many pixels your camcorder's CCD has, it produces the same 720x480 resolution as DVD.

Yes, but the bitrate of the camcorder is about 8x that of the DVD.


25 Mbps vs. ~8 Mbps

25/8 is not 8x, it's ~3x. Someone had already brought up bitrates. I was responding specifically to this:

Can there be some conversion problem as my DCR has a resolution of 690000 pixels which is more than MPEG-2 has (about 400000 pixels) ?

Opps, that is correct 3x

[Nelson37]

Not certain about the pixel numbers you are citing, as mpeg2 has a max resolution of something like 4800 x 4800.

Since 720x480, mpeg2 is what is required for DVD, that particular issue is simply not relevant and you should waste no time on it.

There are several steps to assuring quality. After testing your original DV capture, and very carefully assuring that there is no loss due to your DV codec and capture software, then you look at the encoding. Also check such things as using a tripod, as the massive movement caused by handheld camera panning is very difficult to encode.

IMO, VS6 absolutely sucks as an encoder. Of the half-dozen or more I have tried, it was the worst. Try TMPGenc on a two-pass, VBR encode with a bitrate max of 8500 to 9000, do a short one first to check field order and other settings.

When you say the quality is poor, what precisely do you mean? Washed out or incorrect color, blacks displayed as grey, motion jerky, interlacing lines? These are all correctable with filters or program settings. Loss of sharpness or pixelation correctable with more bitrate and/or better encoder.

[MpegEncoder]

There are several steps to assuring quality. After testing your original DV capture, and very carefully assuring that there is no loss due to your DV codec and capture software, then you look at the encoding. Also check such things as using a tripod, as the massive movement caused by handheld camera panning is very difficult to encode.

DV "capture" does not require a codec.

It is a direct transfer from camcorder (etc) to harddrive.

[lordsmurf]

There are several steps to assuring quality. After testing your original DV capture, and very carefully assuring that there is no loss due to your DV codec and capture software, then you look at the encoding. Also check such things as using a tripod, as the massive movement caused by handheld camera panning is very difficult to encode.

DV "capture" does not require a codec.

It is a direct transfer from camcorder (etc) to harddrive.

DV requires a codec to encode in the hardware, as well as on the computer to be decoded to be read.

If you decode with the "wrong" codec, it will undoubtedly look like crap.

[vhelp]

Actually, the DV codec is hardware built-in to the device(s) that
produce DV through firewire.

For instance, the advc-100 has its own DV codec (encoder) on it's chip.
And, every DV CAM has their's built-in as well.

I believe that these devices are DV encoder-only chips.

As in the cases for DV CAM's, they have their own DV encoder chip, and
encode the video to DV during shooting of video.

When you transfer video *live* through firewire while watching on your
pc monitor inside a window (during FW transfer) the *live* video is
being DV encoded, and THEN transfered through your firewire.
.
Also, as with the advc-100 device (and other external DV capture devices)
the same applies.. that when you capture *live* video w/ these external
devices, the video feed (ie, tv; vcr; laserdisc; etc) are being DV
encoded on-the-fly, and then passed through firewire for transfer to
your hdd.

Then..

It is up to the software side (per given DV codec) to utilize/opimize
the final decoded results to an video editor or encoder for processing.

-vhelp 3527

[MpegEncoder]

There are several steps to assuring quality. After testing your original DV capture, and very carefully assuring that there is no loss due to your DV codec and capture software, then you look at the encoding. Also check such things as using a tripod, as the massive movement caused by handheld camera panning is very difficult to encode.

DV "capture" does not require a codec.

It is a direct transfer from camcorder (etc) to harddrive.

DV requires a codec to encode in the hardware, as well as on the computer to be decoded to be read.

If you decode with the "wrong" codec, it will undoubtedly look like crap.

Quite true, but the "capture" it really a transfer.

[Nelson37]

It is a transfer of video from one source to another. Many people use the term "capture" for this action. Transfer is not really correct, as there could be encode-recode cycles involved, both on the PC end and the camera end. Transfer implies that it is absolutely guaranteed to be the same file recieved as was originally present on the camera.

You bet your sweet ass there is a codec involved, I have seen too many examples of people who have changed their codec and suddenly gotten dramatically different results. Many people are not aware of the possibility of significant degradation from using the wrong, or just different, DV codec. Obviously, as some don't even think that one is needed!

[edDV]

It is a transfer of video from one source to another. Many people use the term "capture" for this action. Transfer is not really correct, as there could be encode-recode cycles involved, both on the PC end and the camera end. Transfer implies that it is absolutely guaranteed to be the same file recieved as was originally present on the camera.

You bet your sweet ass there is a codec involved, I have seen too many examples of people who have changed their codec and suddenly gotten dramatically different results. Many people are not aware of the possibility of significant degradation from using the wrong, or just different, DV codec. Obviously, as some don't even think that one is needed!

A DV camcorder has a bidirectional hardware DV codec. The encoded video/audio can be recorded locally to tape or "transferred" as a data stream to the PC over IEEE-1394. At the PC end, the DV stream can be saved to a DV-AVI or DV-Quicktime file or passed (similar to frameserving) to a program (e.g. MPeg2 encoder, display driver, filter or other process). Playback from the camcorder's tape system also results in a simialr DV stream over IEEE-1394.

There is no "file" until the DV stream is (umm ... should we say captured? or transferred?) to a file. I say let the user decide. Almost all commercial programs use the term "capture".

As for a DV codec, there is no codec required to transfer-capture a DV stream into a file on the HDD. The stream was encoded in the camcorder's hardware DV codec. The DV stream is just data being read to a file.

If you want to view the stream while it is being transferred-captured, (e.g. WinDV) then the DV stream must be locally decoded in the computer and passed to the display system. This is usually handled under DirectX (Directshow) and the XP default "MS DV codec". This codec is designed to be fast for realtime DV decoding.

If you want to edit or filter DV encoded data in an aplication, a software DV codec is required. Some applications use the built in MS DV codec, others work better or give a choice of using a 3rd party software DV codec (e.g. Panasonic, Mainconcept, Canopus, etc.).

Another case is external monitoring of a DV stream such as preview monitoring a NLE such as Vegas or Premiere. In these cases the DV stream is passed backwards on the IEEE-1394 port to the camcorder where the camcorder's hardware codec is used to D/A to analog for monitoring on the camcorder LCD or external monitor. This results in fast precise monitoring and minimal CPU load.

I'll let others describe the pros and cons of the various DV software codecs. I'm just trying to set the stage.

[MpegEncoder]

It is a transfer of video from one source to another. Many people use the term "capture" for this action. Transfer is not really correct, as there could be encode-recode cycles involved, both on the PC end and the camera end. Transfer implies that it is absolutely guaranteed to be the same file recieved as was originally present on the camera.

You bet your sweet ass there is a codec involved, I have seen too many examples of people who have changed their codec and suddenly gotten dramatically different results. Many people are not aware of the possibility of significant degradation from using the wrong, or just different, DV codec. Obviously, as some don't even think that one is needed!

What a lot of bad (no, false) information.

We don't think, we know that there is NO CODEC involved in getting DV data from camcorder to PC.

If you want to do something with it, then you need a good DV codec.

[lordsmurf]

It is a transfer of video from one source to another. Many people use the term "capture" for this action. Transfer is not really correct, as there could be encode-recode cycles involved, both on the PC end and the camera end. Transfer implies that it is absolutely guaranteed to be the same file recieved as was originally present on the camera.

You bet your sweet ass there is a codec involved, I have seen too many examples of people who have changed their codec and suddenly gotten dramatically different results. Many people are not aware of the possibility of significant degradation from using the wrong, or just different, DV codec. Obviously, as some don't even think that one is needed!

I have to chime in here myself, make this a trio.
In one word: "wrong"

DV data on the camera is saved in a linear data style that does not rely on "codecs" or even "filetypes" or such limited non-sense. It is indeed encoded with a hardware codec prior to being written on the data tape.

When you transfer this file, it must be adapted to a more organized data storage method, the nifty digital storage that involved filenames. And since it cannot exist on it's own (it's just RAW DATA after all), it must be wrapped in a wrapper (AVI on PC or Quicktime on Mac). This is a lossless transfer process from A to B, no different than a floppy drive (assuming your media isn't full of physical errors, but that has NOTHING to do with the data).

The next time the word "codec" is used is when the computer software needs to decode the raw data for playing. This is probably where you're confused. If you pick the wrong one, it'll look bad (or worse than normal). You can do the same thing with MPEG* or any number of video formats; bad codec, bad video.

That's how DV works.

(*MPEG codec, you ask? Yes. Ligos, Cyberlink, Sony, and many more. Compare Ligos to some of the free junk sometime, watch how wildly it can change. Same goes for DVD players, various hardware decoders. Compare a good Toshiba to something cheap like Apex, watch how different it looks.)

[Nelson37]

There is a codec on the camera.

When the data is moved from the camera to the PC, it is changed from its original format. It is possible to drop frames during this process, therefore it is not guaranteed to be lossless. In many instances, the dropping of frames has been eliminated by changing the firewire card in the PC. This is no simple transfer as that term is commonly used in the PC world.

The requirement for a codec on the PC is only if you intend to actually do something with the file after it appears on the PC. Since in every case I am aware of, the file is intended to be played, viewed, edited, or re-encoded, and not simply exist on the drive. Therefore a codec is required on the PC under virtually all circumstances.

My reference to file degradation should have been clarified, the codec present on the PC would not degrade the file during the actual capture, but could certainly affect it during subsequent operations, such operations being the obvious next step in virtually all cases.

My points were these -
1. there is significant possibility of loss of data during the capture.

2. the codecs present on the PC can cause degradation after the capture, unless you do absolutely nothing else with the file. I did not think this last possibility needed to be stated.

[edDV]

...

When the data is moved from the camera to the PC, it is changed from its original format. It is possible to drop frames during this process, therefore it is not guaranteed to be lossless. In many instances, the dropping of frames has been eliminated by changing the firewire card in the PC. This is no simple transfer as that term is commonly used in the PC world.

The transfer from the camcorder is a data stream whether it originates in the camera CCD, the tape drive or the analog input. It is not a OS file transfer or a network file transfer. The data must be collected and wrapped as a file at the PC before it comes under the control of the OS.

The amount of data transferred is substantial at a continuous 36Mb/s (more than 10x the fastest residential internet connection rate). Since the stream is continuous and not under the protection of the OS it is fragile and subject to pixel, line or frame drops. Drops usually occur when the OS takes control of the capture drive for background or user directed processes. This is minimized by capturing-transferring the DV stream to a separate drive from the OS and controlling background processes.

[MpegEncoder]

My points were these -
1. there is significant possibility of loss of data during the capture.

This "loss of data' has nothing to do with codecs.

[Nelson37]

Holy crap. Did I say somewhere I missed that the codec is responsible for issues with capture?

Obviously there is possibility of loss during capture. Too many dropped frame issues with DV capture to even question that.

I pointed to the codec as a possible cause of loss of Quality, AFTER the capture, because as soon as you do ANY manipulation of the file, including even looking at it, your PC codec then comes into play.

Many users would capture a file, then while looking at it (and what other way would they check quality?), IF their PC has a bad, incorrect, or corrupted codec (I have read of all of these), they would assume a poor quality file when that is not really the case.

OK, you can capture without a codec on the PC. This is a distinction without a difference as the capture would be totally pointless unless you do, in fact, have such a codec on the PC.

You could capture on one machine with the intent of editing on another, since some are being nitpicky. BUT, capturing a file on a PC without having a PC which has a DV codec on it, what possible use would this be and for what purpose?

One more time - there is possibility of loss during capture. There is possibility of degradation of quality, during operations subsequent to the capture, due to the codec(s) installed.

These are facts. If anyone would care to dispute them, I would be interested in hearing about it.

[lordsmurf]

You're misusing the words "capture" and "codec" and that's where the trouble lies.

Using the right codec is easy, install the disc that comes with the device. This seems to be the source of your entire rant, and it's really a non-issue.

[Nelson37]

Please point out the specific misuse.

I believe people are incorrectly reading what I have written. My original second paragraph had nothng to do with the capture, per se. ASSumptions are being made that both statements were only concerning the capture, or transfer.

If it is so easy, why have there been a number of people with problems in this area? I guess you have never seen a PC that has been connected to more than one DV device, with incompatible codecs installed?

Smurf, you personally refer to the transfer as a lossless process. This is simply not true. What are dropped frames, then? In fact, in another thread, you just pointed out the "dropped frames in DV" sticky. WHy the hell is this a sticky if the capture is lossless?

Keep calling DV file transfer a "lossless" process, and I'll keep ranting.

[vhelp]

During the capturing or transfer process ...

When there are dropped frames, I do not consider this a
lossy process. This is clearly a system stability issue.
But, nothing to do with quality of the capture or transfer.

When you transfer (people refer to as capture) from your dv cam
to your pc, this is the lossless process. There is no loss of
quality. You can drop frames during this dv transfer,
on account of system in-stability, but that does not tern it into
a lossy outcome.. just less frames

But, the moment you open the dv avi file, you run the risk of
the loosing some quality from this, depending on the dv
codec being used during the editors choice of dv codec.

Some examples of loosing some quality ...

..could be the color space used in the dv internal algorithem; or
other methods to sample or upsample; or black level handling; etc.

All this inside the dv codec's algorithem.

As far as the dv avi file is concirned, it's just a plain YUV 411
stream, empty of a dv codec. Its just a bunch of YUV numbers,
lossless 'ly, but in a structure that is ready and waiting for
a dv codec to desipher.

An example ...

When your given Editor or Encoder opens one of these dv avi files,
it makes a call to a routine that determines which DV CODEC to use
in the conversion (YUV to RGB) process so that you can see the
final bitmap images (video) inside that given Editor/Encoder's
window.

If you had several dv codecs on your system, then whatever the
hierachy of your dv codec setup "load" is, and your Editor/Encoder
way of calling a given DV codec, you could be using any one of them
for all your dv avi file viewing. In some cases, you could be
using a poorly designed dv codec.

If you want to experiment with various dv codecs for a determination
of quality or other, you could go to the tools section and download
the tool, "vcswap.exe" (codec swaper) and try each dv codec to see
what you like from each codec.

-vhelp 3543

[MpegEncoder]

Smurf, you personally refer to the transfer as a lossless process. This is simply not true. What are dropped frames, then? In fact, in another thread, you just pointed out the "dropped frames in DV" sticky. WHy the hell is this a sticky if the capture is lossless?

Keep calling DV file transfer a "lossless" process, and I'll keep ranting.

Dude, get a grip. Dropped frames are a transfer FAILURE.

With any decent computer, there is no reason to have dropped frames. If you are dropping frames, you need to solve that problem.

It has nothing to do with the fact that DV transfer from camcorder (etc.) to PC is a process which does NOT modify the video information in any way. Yes, it does repackage the DV into a file so that a computer program on the PC can access it. But that does not change the fact that the DIGITAL VIDEO data is "copied" from one place to another.