Activity › Forums › Apple OS X › QuickTime MPEG2 Component
-
Brent Altomare
April 16, 2006 at 5:11 amThanks for the suggestion Simon.
We did quite a bit of playign around with compression markers and even tried to futz with the GOP structure to see if that gave us any improvement.
I’m also a little concerned that the problem may be related to our work in DV. I’m going to see if I can take one of our uncompressed projects (we have one right now that originated in HDCAM) and try to reproduce the problem.
—
Brent Altomare
Groovy Like a Movie
(877) 3-GROOVY -
Brent Altomare
April 16, 2006 at 5:14 amSounds like that’s what happened. Makes sense.
I didn’t think to try a single pass VBR… I would have thought that would make the problem worse, not better…
But hey… I’ll give anything a go at this point! I’ll switch to a single pass VBR and run an output on Monday to see what happens.
Actually, now that I think about it, if that really does solve the issue, that would explain why the output from QuickTime player would look better than the Compressor output. I’m sure that the output from QuickTime player would be a simple single pass… which would also explain why QuickTime player is faster at compressing the MPEG2 than Compressor…
OK… now you’ve gone and gotten my hopes up. I’ll let you know if they get dashed.
Thanks!
—
Brent Altomare
Groovy Like a Movie
(877) 3-GROOVY -
Gunleik Groven
April 16, 2006 at 1:04 pmYour issues are not unique!
They’ve been discussed a lot on the FCP forum. (Do a search over there)
my solution has been to buy BitVice from http://www.innobits.se.
This solves most mpeg2 issues for me, still on some (very old and shaky 16 mm dubbed to digi) footage, I’m still playing around with different options and settings in both Compressor and BitVice.
You can dl a free, full working demo to check if it solves your issues. It leaves a watermark but otherwise it’s the real deal.
Gunleik
-
Brent Altomare
April 16, 2006 at 6:10 pmI’ll check BitVice out. Thanks for the suggestion!
—
Brent Altomare
Groovy Like a Movie
(877) 3-GROOVY -
Alexander Kallas
April 17, 2006 at 1:02 pmHi Brent,
The problem with Compressor is the VBR, one pass or two, no-matter. With VBR choosing a data-rate higher than a modest 6-7mbs actually allows SPIKING to above the 10.2mbs limit, with all those subsequent problems.
Stay with one-pass!
Compressor actually has really good features (the filters, the avoidance of the DV codec when used straight out of FCP, etc) that Bitvice cannot do.
Use One Pass for material under 60 mins and you can go up to the max. (9mbs). You’ll be amazed at the results.Cheers
Alexander -
Brent Altomare
April 17, 2006 at 2:59 pmThanks Alexander –
I’m giving this suggestion a try now.
—
Brent Altomare
Groovy Like a Movie
(877) 3-GROOVY -
Don Greening
April 17, 2006 at 4:51 pm[Alexander] “Compressor actually has really good features (the filters, the avoidance of the DV codec when used straight out of FCP, etc) that Bitvice cannot do.”
Hi Alexander,
A little while ago some kind soul did a little comparison test with Compressor: he exported a self-contained .mov from FCP and then used Compressor stand-alone for the encode. Then the same .mov exported to Compressor from within FCP. The result was that the encoded .mov file using Compressor within FCP was considerably darker than the version encoded with Compressor as a stand-alone app. He posted screen grabs as proof. He said he’d never use Compressor within FCP again but only as a stand-alone program.
Interesting, don’t you think?
– Don
“Please take a moment to fill out your profile, including your computer system and relevant software. Help us help you.”
-
Alexander Kallas
April 18, 2006 at 12:05 am[Don Greening] “Interesting, don’t you think?”
Yes, very.
No link to that post?
I suspect this has to do with how/what the recorded material is, so this could/ could not be a problem.
However Compressor has a gamma control filter, although there is not much info in the Compressor manual.Cheers
Alexander -
Don Greening
April 18, 2006 at 1:26 amHi Alexander,
I found it! Here’s the link to the original thread from the FCP forum back in Feb/06:
…..and here’s the link to the test images. I didn’t think the test images would still be available online but they are:
https://www.visiontracks.com/compressortests/
Let me know what you think.
– Don
-
Alexander Kallas
April 18, 2006 at 8:23 amThanks Don,
Hmmm,
Requires some thought.
The difference cannot be due to hardware used, as that was the same for both images.
What I can conclude is that unlike some, who say that both methods are identical, FCP DEFINATELY does it different.
It may render in 4:4:4 or 4:2:2 colorspace, which is different to the DV codec’s handling (4:1:1) and there-in lies the gamma difference.
This may be more or less noticable, depending on the codec and/or camera used.
I’ll try a test in the DV codec between the two methods and post.
However, for DV, encoding in Compressor via FCP, produces a cleaner sharper picture as one transcoding (to QuickTime’s codec) is avoided, and the gamma
factor, if problematic, can be adjusted with the gamma filter, after all, why is this filter there, if not for these situations.
My 2 cents……Cheers
Alexander
Reply to this Discussion! Login or Sign Up