Quality drop when importing video?

[Supergeil 0]

When I import video from my cam (a PC 330) to my Mac it loose a lot of quality. I import it as Big (960 x 540) 16/9.
And I burn my DVD in iDVD.
Is that normal to loose a quality when importing ?

[DSE 5]

Only if you're importing over analog will you lose quality. If you're coming in over Firewire or card Xfer, it's merely bits, and you can't lose quality on ingest. However, you *can* lose quality if your sequence settings aren't correct, and you render to an odd format.

[faulknerwn 38]

I use that same camera and computer setup and import over firewire and have no loss in quality.

[Supergeil 0]

Maybe It's the analog format that I got wrong. I import with a firewire but the av/dv was not on in the cam menu.

[DSE 5]

If you are using Firewire, then you are digital only. I'm not sure what you're looking for with the AV/DV menu. AV output is analog, DV (firewire) is digital.
If you're using FCP, then use the Easy template for PAL DV Widescreen to import/capture. that will be 720 x 576, 50i.

[hackish 8]

I played with some hardware last winter to digitize video and altitude info at the same time. I ran into a few issues - one of which was the encoding processor I chose. Its compression added significant artifacts to the video. I'd copy the data over to my computer but then it would recompress using a different codec which added to the problem.

As an example you can take an image and save it as jpeg, lowest quality you can. Then open that and rotate the image 90 degrees and bump it 1 pixel to the right. Resave with the same settings, the quality degredation is noticeably worse because you're stacking lossy compression.

I'm no video software expert but maybe your problems are similar.

-Michael

[DSE 5]

Quote

I played with some hardware last winter to digitize video and altitude info at the same time. I ran into a few issues - one of which was the encoding processor I chose. Its compression added significant artifacts to the video. I'd copy the data over to my computer but then it would recompress using a different codec which added to the problem.

As an example you can take an image and save it as jpeg, lowest quality you can. Then open that and rotate the image 90 degrees and bump it 1 pixel to the right. Resave with the same settings, the quality degredation is noticeably worse because you're stacking lossy compression.

I'm no video software expert but maybe your problems are similar.

-Michael

A-no need to rotate to see loss due to recompression of a compressed format such as jpg. Shifting one pixel is enough to force recompression. It's one of the testing methods we use to determine difference between source and multi-recompressions.

B-While your direction is a good thought, it's not relevant to this discussion at all. The encoder is DV, in camera. There are no choices. The decoder is DV, in software. No choices.

Most likely, the problem stems from incorrect sequence settings in FCP, since it really likes everything in the timeline to match source, or it's an output setting, such as attempting to upscale 720x576 to 960x540.

[Supergeil 0]

Then I am digital I use Firewire.
I use iMovie, but maybe I should change to FCP.
The lowest setting in iMovie is 960 x 540 for PAL

[PharmerPhil 0]

I don't use iMovie, but I seem to remember reading that it used to capture files in a different format than normal Quicktime movies. i.e. you couldn't just take the imported clips right into iDVD or something. You had to export the video out of iMovie. The fact that you are using what to me seems to be a non-standard size ("960 x 540 16/9") makes me think that it is something in your import settings. edit: I just opened iMovie and there is a preference for importing 1080i footage that gives you a choice between "Full - 1920x1080" and "Large 960x540." But the note under it says "This setting has no effect for DV,..." A PC330 is just DV.

Is it possible that you are just viewing the clips on your computer and seeing interlace artifacts that don't show up on your TV monitors?

Here's a blog that may or may not be of some use in how exporting from FCS to a "Quicktime Movie" versus "using Quicktime conversion" differs. Don't know if it's relevant to iMovie or not:

http://videoediting.digitalmedianet.com/articles/viewarticle.jsp?id=123085

[Supergeil 0]

You are absolutely right you have to export from iMovie to iDVD seems a little odd to me to. Two standard programs that should work together but doesn't.....come on Mac.

I like iMovie a lot for doing tandem movies in it's pretty easy and fast for that but the quality sucks.
I think i will be heading for the FCS despite it's a pretty heavy program to work with.

Sorry but interlace artifacts doesn't say me much maybe my english isn't good enough. But I watch it on a HD TV.

Thanks for the link!

[faulknerwn 38]

I wonder if its a PAL thing? I just open my tandem movies in "DV Widescreen" and go from there. PC 330 and imovie. The video quality is a lot higher than when we were using Premiere on Windows.

And having to choose "share IDVD" to send it to idvd isn't a major event.

I've used both imovie and FCP extensively and for tandems I prefer Imovie. The themes and stuff you can add in as drag and drop really make the videos seem more professional.

[DSE 5]

Quote

I wonder if its a PAL thing? I just open my tandem movies in "DV Widescreen" and go from there. PC 330 and imovie. The video quality is a lot higher than when we were using Premiere on Windows.

.

Hate to argue this one, but if you're importing over Firewire, there is zero quality difference from FCP to Premiere, or Vegas, or Avid, or anything else using DV over 1394 as ingest. Bits are bits.
It's like saying a text document is more prone to accurate spelling in iWork than in Word.
If you use the Easy templates to match source to project/sequence, then quality in/out is exactly the same in FCP/S, iMovie, Premiere for Apple, or Avid for Apple.
That said...different MPEG encoders, bitrates will create different qualities of output, but that's not relevant to the former paragraph.
Compressor looks like sh** compared to Cinemacraft, and oddly enough, iMovie export has some better encoding opportunities than Compressor, IMO.
build a droplet for Compressor with a bitrate of not more than 8Mbps for tandem vids or typical skydive vids, you'll be very happy, I'm sure.

[hackish 8]

Quote

A-no need to rotate to see loss due to recompression of a compressed format such as jpg. Shifting one pixel is enough to force recompression. It's one of the testing methods we use to determine difference between source and multi-recompressions.

The idea wasn't to merely spark recompression, it was to take advantage of the compression artifacts. Now thinking about it I think you'd need to rotate it other than a 90 degree interval.

Quote

B-While your direction is a good thought, it's not relevant to this discussion at all. The encoder is DV, in camera. There are no choices. The decoder is DV, in software. No choices.

What are all those choices I've seen asking which codec to compress with and when I "produce" a video why does it take 1/2h to "encode"? I'm not disputing what you're saying at all, just trying to understand it a bit better.

-Michael

[DSE 5]

Quote

Quote

A-no need to rotate to see loss due to recompression of a compressed format such as jpg. Shifting one pixel is enough to force recompression. It's one of the testing methods we use to determine difference between source and multi-recompressions.

The idea wasn't to merely spark recompression, it was to take advantage of the compression artifacts. Now thinking about it I think you'd need to rotate it other than a 90 degree interval.

Quote

apparently you know something the rest of the industry doesn't? Artifacts are generated at recompression. Always.

Quote

B-While your direction is a good thought, it's not relevant to this discussion at all. The encoder is DV, in camera. There are no choices. The decoder is DV, in software. No choices.

What are all those choices I've seen asking which codec to compress with and when I "produce" a video why does it take 1/2h to "encode"? I'm not disputing what you're saying at all, just trying to understand it a bit better.

-Michael

Those options are seen at output, not ingest, when dealing with most NLE/acquisition systems.
If you modify a file, it's no longer the same data, so must be recompressed no matter what. DV, MPEG, AVCHD, whatever...therefore, it takes longer. Some apps have a no-recompression 'smart render' where untouched files don't require recompression, and they go very fast. It's NLE-dependent, however. ALL files that are modified require recompression, even if it's merely shifting the video by one pixel to the right, left, up, or down, because it's now a different file.