View Full Version : Editing raw footage
Michael Chen May 1st, 2003, 07:38 PM Hi all,
I know adding effects to a clip such as transitions, colour correction and so on will cause minor degrades to the footages.
But what if I am only cutting and pasting the footages?
I would just like to do some cutting and pasting in my computer and output it to another computer for colour correction.
Will there be any quality losses?
Edward Troxel May 1st, 2003, 07:48 PM Cuts only should result in ZERO loss of quality. Rendering will result in the file being COPIED - not recompressed.
Michael Chen May 1st, 2003, 07:53 PM Well, I guess thats what I needed.
Thanks Edward!
Alex Knappenberger May 1st, 2003, 08:02 PM Yup.
Also, Sonic Foundry's DV codec (used in vegas) is found to be much better then Microsoft's (used in premiere and the others). In a test, SF's Codec could re-render (not sure of what word to use, possibly recompress) the footage upto a infinite amount of times without seeing any degrading video quality, in the test they redid it 50 times. However, after about only 15 recompressions, you could see significant degration in the Microsoft encoded footage.
Jeff Donald May 1st, 2003, 08:39 PM Do you have a link to that test?
The moral of the story is do not render your scene 15 times. Be aware that rendering your scene causes a slight lose of quality each time. The quality lose is cumulative. You may not notice the first few times you render, but the artifacts are sneaking in. Keep your changes to a minimum and render as few a s times as possible.
Alex Knappenberger May 1st, 2003, 08:41 PM Here it is:
http://www.digitalvideoediting.com/2001/12_dec/reviews/cw_vegasvid3.htm#
Directly to the sample picture with comparisons:
http://images.digitalmedianet.com/2001/12_dec/reviews/cw_vegasvid3/codec.jpg
Michael Chen May 2nd, 2003, 01:35 AM ok how bout adding sound effects / voice overs?
It doesnt add any effect on the video itself, just on the sound part.
Will the quality be worse off compared to if i just do cuts and trims?
Ed Fiebke May 2nd, 2003, 02:43 AM Up until now, I was operating under the assumption that there wasn't degradation when scenes are rendered and re-rendered again after more effects, etc. However, after viewing the sample pictures offered by Alex and reading the comments to this thread, I've now learned otherwise.
Slightly confused, I seek clarification:
1) Does the degradation process also include copying the video signal from a DV (miniDV) tape to the computer via IEEE 1394?
2) Are editing cuts and splicing made during the editing process considered some form of rendering and therefore subject to degradation too? (To be honest, I don't fully understand how the process works whenever I "shorten" or cut out parts of a scene on a particular video footage. I just take for granted that it does works and marrily splice and edit away.)
Now that I understand that degradation of the video occurs with each repeated rendering, I ask the following questions:
1) What type of editing/effect processes causes the most severe degradation during repeated rendering?
2) What DV editing techniques to you used to help keep the degradation process to a minimum during repeated rendering of edited scenes?
Great topic, and I appreciate the knowledge shared here!
Ted
Alex Gingell May 2nd, 2003, 04:30 AM Capturing to computer via firewire causes no quality degradation...it is merely copying the already compressed (by the camera - dv is 5:1 compressed) files across.
AFAIK editing by purely slicing and dicing your .avi's is not going to change a thing because when it renders out it should just be copying portions from all the .avi's to your final .avi.
Where you will get quality losses is if you re-render your video in an effects package like after effects or 3dsmax for purposes of compositing or adding vfx (as I learned harshly myself).
My question is, if you do all the effects work with uncompressed files (i.e. you import your starting dv .avi's and then all renders are to uncompressed .avi's) can you get away with no loss in quality UNTIL you have to render out in the final step back to compressed dv?
Assuming you use a good codec like mainconcept dv or sonic foundry that last compression step should be your only loss in quality, and hopefully not by much!
After viewing this:
http://images.digitalmedianet.com/2001/12_dec/reviews/cw_vegasvid3/codec.jpg
I can safely say that $50 for mainconcept's dv codec is looking mighty tempting. Does mainconcept's compare to sonic foundry's ? Is sonic foundry's available outside vegas ?
Alex
Rob Lohman May 2nd, 2003, 05:34 AM I'm not really keen on this comparison between codecs, why?
Because of the following reasons:
1. it was done 1,5 years ago
2. it is known that certain Microsoft DV codecs were bad and others were a lot better, they don't specifiy which MS DV codec they used
3. they don't talk AT ALL about how they run the tests with what applications and with which source material.
4. there are no fullscreen samples available to check out yourself in an UNCOMPRESSED or LOSSLESS compression format. Who says their resizing routines and jpeg saving is good?
Now I'm not saying that the Vegas codec isn't better than the
Microsoft one or Mainconcept... But what I like to see is the
following:
1. a test that has been done NOW (not a couple of years ago)
2. a test that clearly explains how everything was tested and with which source material and such (ideally with multiple images)
3. a test with more than one codec and different versions (Microsoft DV codecs on Windows 98, 2000 and XP for example. Vegas codec 3 and 4 etc.)
4. output images that are not compressed and full resolution
5. unbiased (I am not saying that the tests above are biased, sponsered or whatever)
I am thinking of perhaps doing such a test myself for the Watchdog,
but currently time and a not clean PC with multiple OS-es is
prohibiting me.
Jeff Donald May 2nd, 2003, 05:43 AM I agree with Rob. I'm not a big MS fan, being a Mac user, but a lot changes in a year and a half. I would think the gap has narrowed quite a bit from what I've seen of the the MS codec. The VV codec is acknowledged as one of the better Codecs in the industry. Most people would never render a scene 50 times and with careful media management, should be able to limit the number of renders to well under 10.
Robert Bobson May 2nd, 2003, 06:35 AM Just to clarify, if you're editing uncompressed DV and exporting back to tape, does this degradation apply?
BB
Jeff Donald May 2nd, 2003, 07:06 AM DV is not uncompressed. It is compressed 5:1 per the DV specification. When you watch the image, the codec decompresses it for viewing. This applies to either analog viewing via S-Video or RCA. There are very few FireWire display devices at this time.
If you capture your DV footage via analog, the capture card could capture at more or less compression depending on the codec used for capture and various settings. It could be captured as uncompressed files also (about 30mb per second or 108 gigs per hour for SD video).
DV could be captured (transferred might be a more accurate term) then rendered in an uncompressed format. Once uncompressed it could be edited uncompressed and all effects, graphics etc. rendered uncompressed. This would yield high quality files with no compression artifacts.
Is this feasible? For most people no. Standard IDE or FireWire drives are not fast enough. SCSI RAID 0 drives are the standard for this type of work. Uncompressed capture cards are expensive.
Once you have your finished project what are you going to do with it? If you go back to DV you're compressing it again (5:1 per the spec). You need a high end VTR (D-1, D-5, Digi Beta) to record your signal and again big bucks.
Don Donatello May 2nd, 2003, 12:24 PM nobody renders 50x ... i do a ONE render test
if you want to see the difference in how codec's handle color
load in NTSC smpte color bars
take a digital readout of all the bars ( for this post just RGB)
these are what they should read for SMPTE
RED r180 g16 b16
GREEN r16 G 180 b16
BLUE r16 g16 b180
render out the bars
if bars are media generated ( digital - like in Vegas) ) you just render them out
if bars were from a camera you'll need to force a re-render ..
results of ONE render
MS= microsoft DV codec
SOFO = vegas codec
RED 180 16 16
MS 173 29 28
sofo 180 16 16
Green 16 180 16
MS 27 171 27
sofo 16 180 15
Blue 16 16 180
MS 29 30 174
sofo 16 16 180
now look at all 3 bars on vectorscope and waveform
compare MS, SOFO to the digital generated bars
NOTICE that on the waveform every MS color has loss luminance.
on the vectorscope every MS color loss satuation. SOFO on waveform hits all bars on the mark , vectroscope all the color's hit their mark ...
MS also made a mess of your blacks
the 3 pluge bars ( 3.5 , 7.5 , 11.5 ire )
digital RGB readouts
RGB for 11.5 is 41 41 41
MS 51 51 51 , SOFO 41 41 41
RGB for 7.5 is 16 16 16
MS 30 30 30 , sofo 16 16 16
RGB for 3.5 is 7 7 7
MS 22 22 22 , sofo 7 7 7
100% white RGB 235 235 235
MS 218 218 218 , SOFO 235 235 235
also the MS has artifacts from the cyan bar running into the small magenta below it ..and the magenta bar has artifacts running into the small cyan below it
i see no problems with SOFO ..
running V4 , microsoft directX 9 ... using V generated smpte NTSC color bars
for V users - use the cookie cutter FX ..it has a eye dropper to sample colors for RGB read out
Simon Orange May 2nd, 2003, 02:13 PM Don,
Very interesting. The MS codec seems terribly lacking !!
Although I do not in any way doubt your results, I would like a little more detail before drawing any conclusions....Rob has outlined these earlier. You have not mention which version of the codecs you were using...what OS..what you were rendering in for example. I think it would be worth doing the tests with the Mainconcept codec also (anyone interested in trying) or even the canupus one - or is that a variation on the MC one ?
With regard to the 50x render tests mentioned above, I am suprised that the images using the VV codec looked so good after 50 recompresses. I would have imagined that the picture would have degraded appreciably even with a great codec (we are talking 5:1 compression here). This leads me to suspect that there 'might' be something else going on in vegas (?).
Just to add my 2pence to the whole discussion. Premiere, by default uses the MS codec. This means that capturing in premiere uses the MS codec, but this isn't really an issue as in this instance it is just acting a a wrapper to get the data from the camera to the .avi file. There is theoretically no quality loss on this initial transfer. If you then go on to edit only applying cuts...not dissolves or anything that needs rendering....then lay it back out to tape there is NO quality loss.
The issue is with FX and transitions that need rendering. It is more than feasable to do bits of FX work uncompressed using either uncompressed TIFs or AVI, then you will get the best quality possible. It will be near to impossible to play uncompressed video media on your average PC, but you can either preview to RAM or make a lo-quality proxy. If you can possibly manage it keep all your data at the highest 'practicable' quality for as long as possible and only compress once - at the end.
Unfortunately at some stage 'if' you want to lay back out to DV tape you will need to render down using a DV codec. This is where the of course where the codec quality issue comes in.
If you are using something other than Premiere and are not happy with the MS codec (test results pending) then buy the mainconcept codec (ditto). In premiere, however, the MS codec is quite deeply embedded. There are tweaks you can do to premiere to force it to use the mainconcept codec - this is something that some of you might want to (do a search on the internet...and the adobe site and abcdv.com..look for qcap.dll)
PS all of the above applies to PCs only...macs are a whole different ball game !
simon
Jeff Donald May 2nd, 2003, 02:45 PM Don,
Was the source of the color bars the same for both tests?
Simon Orange May 2nd, 2003, 03:00 PM Just done some peliminary tests on my laptop
1 - SMPTE bars generated internally in premiere 6.5 (using an uncompressed project). Saved as uncompressed 24 bit .bmp
2 -imported this .bmp into one frame project in AFX 5.5.
each movie re-imported into AFX project and exported as uncompressed 24 bit .bmp
Exported as AVI using each DV codec.
using mainconcept 2.1 demo - poor
microsoft DV v6.5.1.900 - poor
canapus v3.0 demo - best but not perfect
notes:
1.don't know where the canapus codec came from
2.main concept codec was ran with fastest mode de-selected (assume this is highest quality ?)
I know I am giving subjective analysis at this stage. Will do the test tommorow on a winXP machine all service packed up and present proper results and post all relevant before/after/project files. I will also try to get hold of SF codec (does anyone have it ?)
si
Don Donatello May 2nd, 2003, 04:28 PM the SMPTE color bars i used are generated in Vegas .. they are digital generated media .. i only used 5 sec color bars ..and rendered out using standard NTSC DV template ..i did both good/best quality and the results were same.
again i used Vegas 4 for both SOFO and microsoft codec .. i have direct X 9 (updated 2 weeks ago from microsofts win2K site) ) .. operating system doesn't matter it is NOT going to affect results ( but it was win2K ) but you are correct that versions of directX will be different. direct X 9 is current ..
my point for the TEST was you don't need to do 10 X re-rendering
.. 1 render will show you results ... it is easier to see results if you
have a vectorscope/waveform .. but RGB #'s will also tell you something especiall with BIG #'s difference like MS codec.
.. i rank SOFO , canopus , Avid , QT6, mainconcepts dv codec ALL excellent and would not avoid any of em ... but i do find i can say that one should aviod the microsoft dv codec which is the default on ALL PC 's. it is not going to show you the correct colors when you color correct on a NTSC/computer monitor ..
have not tried any matrox or pinnacle products
Simon Orange May 2nd, 2003, 04:29 PM Ok......it seems that the DV codec in Vegas is coded into the application and doesn't make itself available to other apps.
....mmm
will sleep on it
Don Donatello May 2nd, 2003, 04:36 PM "The issue is with FX and transitions that need rendering. It is more than feasable to do bits of FX work uncompressed using either uncompressed TIFs or AVI, then you will get the best quality possible"
remember if you have a DV clip .. now you want to make it a tga/tiff/png/jpeg or uncompressed avi/QT, mpeg or what ever .. you need a DV codec to uncompress the clip - so if your version of premiere defaults to microsoft DV codec then that is what it is going to use to uncompress the DV clip so it be changed into a PNG/tiff/tga, uncompresseed avi/qt
Simon Orange May 2nd, 2003, 06:11 PM Don,
Totally agree about the uncompressing (although I haven't seen any tests results for this) and Premiere would of course use MS codec for this by default - although my gut feeling is that the decompress between codecs would be quite similar (famous last words !). Might even test that later.
I am more concerned about the quality of the MS codec. I have just compared my initial test results with yours and I notice that your MS results are way off compared to mine (using aftereffects). My MS results are about half-percent off perfect..not a great deal different than the MC ones. Yours are miles away ! Does this mean that Vegas handles the codec in a different way ?
In addition - just because Vegas can read and write its own codec perfectly it doesn't mean that it can read other codecs well...it seems to make a more of a mess with the MS codec than AFX...In fact referring back to your original point about the decompress - who is to say SF is decoding the original Canon (sony ?) hardware codec correctly in capture mode ? Doesn't matter if you are copying back to the camera but it might if you were working uncompressed......In fact I assume you pulled the video back into Vegas to test RGB values - the error might have crept in here - not at the MS compress - this would have ramifications on footage imported from other applications.
This isn't a 'my codec is better than yours' debate - we all know the MS codec is sh*t - I just trying to evaluate how sh*t. And why is the SF one so much better ? Is it time to give MC a try ?
I hasten to add that these thoughts are just that....thoughts ! And I am assuming that a codecs ability to compress colour bars is the sole indicator of its quality(which it obviously aint) - but I have spent years working with D1 and digibeta and never seen a 50x dub look anything like the original (even with D1 - which you would at first assume was just a digital clone)
Have tested mainconcept/canopus/MS and might have a look at vegas. Will post results tommorow.
simon
Garret Ambrosio May 2nd, 2003, 07:34 PM Have any of you use AlamDv? I don't have scientific data regarding this, but it refuses to use the MS DV codec. According to their website (ww.csbdigital.com or alamdv.com) the MS codec is a low quality codec and therefore they recommend using the Matrox, Mainconcept or Canopus DV codecs when running their software. Just a quick tidbit.
Don Donatello May 3rd, 2003, 12:55 AM " My MS results are about half-percent off perfect..not a great deal different than the MC ones. Yours are miles away "
you might have something on perhaps a software tunes their render engine to the default codec ! could be ?
your results are Vaild for your computer /sofware and that is what counts ... how did the the pluges read out using MS with AE .... were you able to view them on vectorscope/waveform ?
now on my computer the MS DV codec shows more into shadows and midrange , seems to holds highlights and that is explained in my test of seeing it LIFT the blacks ( 3 pluges) and it brings down the 235 whites to 218 ...
how does your Premiere handles the MS codec in rendering ?.. put your digital generated BARS in Premiere's TL .. can you get a RGB' read out on em in Premiere ? .. then render them out in Premiere and put them back in premiere or AE and read them against the GENERATED bars #'s ... your results could/will be different then mine and that is what you should go by ... let us know how Premiere MS dv codec did on rendering - did the #'s match AE?
i'll try out rendering with Combustion and Commotion using the MS dv codec this weekend - just to see if each handles the same codec different ... i know Commotion is QT native..
Rob Lohman May 3rd, 2003, 04:07 AM I've done some research on the Microsoft DV Codec in the past
and the quality/version can be a tricky thing. It has happened
a couple of times that a NEWER version of the DV Codec actually
made things worse. So it might be that the DV Codec in DX9
that Don is using might be newer but in more worse in quality
than an older codec that Simon might be using... If you want
to know what version you are you using do the following:
1. go to your <winroot>\system32 directory (make sure you can see system files)
2. find the file QDV.DLL and right-click on it and choose properties.
3. Go to the version tab and you'll see the version on top
I seem to be running version 6.3.1.881 on my Windows 2000
Professional Service Pack 3 system. According to DXDIAG I am
running DirectX 8.1.
Simon Orange May 3rd, 2003, 09:13 AM ok....
test results at:
http://www.hyperstar.demon.co.uk/codec_test.zip
Don,
started to repeat tests just using premiere but results looked the same as AFX (check the zip file). If you could post the files that you generated in vegas (or anything you make in combustion/commotion) I would be interested to see them. Seems like there is something a bit weird going on using the ms codec.
Rob,
As far as I can tell I am running the same version of the MS codec as Don.
Garret,
I assume that AlamDV can't use the MSDV codec because it needs a VFW codec and the MSDV is directshow only. The MC codec is VFW also. Check out:
http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp
to All,
one last thing: this is from the mainconcept FAQ
Does the MainConcept DV Codec do lossless compression? My understanding is there are two parts to DV encoding. Can it do the entropy encoding only (lossless) and skip the DCT compression (lossless)? In other words, I could edit/compress an infinite number of times without lossing any data, or I could record DV and then recompress it in a different format and won’t get any additional loss from the DV Codec.
There is a loss of Quality when you create new frames. New frames are created when you use effects (FX) or transitions on a clip. These new frames must be calculated and produced. In this case you have a loss of quality. The visible loss is shown by the cycle ratio. For example, a ratio of 5 means, that you can recompress a DV clip 5 times without a visible loss. Our cycle ratio is higher than the one of the Microsoft DV codec. A pure copy from a DV clip, e.g. from one DV camcorder to your hard disk and back to another DV camcorder will cause no loss.
simon
Don Donatello May 3rd, 2003, 11:46 AM down loaded your samples
the premiere BAR export avi was BLACK , canopus avi had errors on my system ...
i found all STills color bars to be pretty much right on and they all had very close the same RGB's numbers ..
however all the avi 's do not come close to your stills ??
all the avi's have about the same readings to each other (AVI).. very small difference on waveform/vectorscope ..however again they do not come close to the STILLS ??
using the uncompressed still (color bars are correct)
the 100% white on the stills are 235 ..on the avi's around 218 ?
still RED 180 16 16 the avi's 173 29 29
still GREEN 16 180 16 the avi's 28 171 27
still BLUE 16 16 180 the avi's 29 30 174
now what i notice is that all your avi's are pretty much matching my rendered MSdv bars .....
are you getting RGB's readout that are showing the AVI 's have the same #'s as the original COLOR bars ? they should match up with the STILLS if the source was the same bars ..
try taking the uncompressed color bar.tiff and render that out as a AVI - now do a RGB read out comparing the 2 ... they should match
i find the readings on the STills to be correct for SMPTE color bars.
all the readings on the AVI's i find not to be correct ..
i assume the source of color bars was the same for stills and avi?
my version of the QDV 6.5.1.900
directX 9a 4.09.0000.901
win2K 5.0.2195 service 3 build 2195
msdv.sys 5.3.0.900
Simon Orange May 3rd, 2003, 12:02 PM how odd...
the stills were taken from the AVIs........not the other way round...
basically:
1. started with 1 frame of uncompressed colour bars
2. loaded in AFX
3. exported 3 movies (3 different compression codecs)
4. loaded the 3 'new DV compressed movies' and exported a still from each.
Just to spell it out again....
the stills are taken from the movies - not the other way round. If you are saying that the AVIs are of a lower quality than the stills that come from it then there is something else going on. In premiere and AFX the AVIs measure (RGB values) the same as the stills that are exported from them.
The canopus DV codec is obviously some kind of proprietry codec...it was on my system (don't know why) .best just ignore it !..
to comment further I need to know in detail your method for measuring/creating/viewing etc.....
simon
Don Donatello May 3rd, 2003, 01:36 PM we are getting the same readings on the STILLS ..
not sure why why are you converting the avi's into stills ??
seems if final output is AVI's then the readings should be from AVI's ?...
are you getting the same RGB's readings on your stills and AVI's ?
i was using Vegas for RGB readings on the AVI's and the stills ..Last night i read the RGB's in Combustion. i just did it again this AM using Commotion and they all have same read out's .. i'm reading the AVI's not converting to them to stills ..
looking at your steps
1) i find your uncompressed still to be CORRECT
2) ...
3) i find all your avi's do NOT match the uncompressed still
4) i find all the stills do match the uncompressed still
in your PDF you are listing my AVI's RGB #'s and your Stills RGB #'s .. again it is your avi's that i find to be off.. maybe others don't ??
?? you are on XP ..i'm on win2K ..perhaps there's something different ?? perhaps others could RGB read the AVI's and stills to see if the difference is in the OS ??
--------------
i load the AVI clips & stills into vegas/commotion/combusting
i then sample RED,GREEN,BLUE bars with eye dropper for the read out ... for waveform/vectorscope i use Vegas which matches external waveform/vectorscope.
on the AVI's i sent you .. Vegas produces digital generated bars, they do not exist as a still or avi ... i then rendered out 5 frame avi using SOFO codec ..then rendered out a 5 frame avi using the MSdv codec ... you should see that if you RGB read both AVI's the SOFO ( Vegas) avi will match your uncompressed still and the msDV codec will pretty much match your AVI's ( not the stills from your avi's) ....
Simon Orange May 3rd, 2003, 06:31 PM PART 1 OF 2 POSTS (phew...!)
Don, thanks for your patience.....
As I mentioned to you earlier, I have put your files at:
http://www.hyperstar.demon.co.uk/don.zip
but to answer your questions first:
> we are getting the same readings on the STILLS ..
yes
> not sure why why are you converting the avi's into stills ??
> seems if final output is AVI's then the readings should be
> from AVI's ?...
yes and no ...trying to eliminate the application (vegas/premiere/afx) from the equation..it is the application doing a decompress on the file when it opens, which I think is the root of the problems. I have enclosed the AVIs also for comparison.
>are you getting the same RGB's readings on your stills and AVI's ?
YES...absolutely...for both AFX and Premiere. Additionally rendering bars in AFX 'OR' Premiere gives exactly the same quality of image as the final stills (otherwise the framegrab export would be increasing quality) I am willing to guess I would get the same results from combustion, shake or whatever else but not if VEGAS was installed (a clue here ?).
>i was using Vegas for RGB readings on the AVI's and the
>stills ..Last night i read the RGB's in Combustion. i just did it
>again this AM using Commotion and they all have same read
>out's .. i'm reading the AVI's not converting to them to stills ..
>
>looking at your steps
>1) i find your uncompressed still to be CORRECT
>2) ...
>3) i find all your avi's do NOT match the uncompressed still
>4) i find all the stills do match the uncompressed still
3 and 4 gives the clue to the issue i think.
>in your PDF you are listing my AVI's RGB #'s and your Stills RGB
>#'s .. again it is your avi's that i find to be off.. maybe others
>don't ??
Because on my machines they are EXACTLY the same.
>?? you are on XP ..i'm on win2K ..perhaps there's something
>different ?? perhaps others could RGB read the AVI's and stills
>to see if the difference is in the OS ??
One of my machines is XP one machine Win2k
>--------------
>i load the AVI clips & stills into vegas/commotion/combusting
>i then sample RED,GREEN,BLUE bars with eye dropper for
>the read out ... for waveform/vectorscope i use Vegas which
>matches external waveform/vectorscope.
>
>on the AVI's i sent you .. Vegas produces digital generated bars
>they do not exist as a still or avi ... i then rendered out 5 frame
>avi using SOFO codec ..then rendered out a 5 frame avi using
>the MSdv codec ... you should see that if you RGB read both
>AVI's the SOFO ( Vegas) avi will match your uncompressed still
>and the msDV codec will pretty much match your AVI's ( not the
>stills from your avi's) ....
Makes perfect sense..thanks, with one proviso. This assumes that original bars match mine...(no reason not to but it would be nice to be sure..your 11.5 looks off to me - and the ones the premiere creates aren't correct)
STAND BY FOR PART ...the conclusion
Simon Orange May 3rd, 2003, 08:18 PM PART 2 OF 2........THE CONCLUSION (nearly)
Playing Don's avi (x2) this is what I see on my machines....
Don's MS codec file isn't great - lots of bleed between colours..poor colour accuracy etc etc but Don's Vegas codec file is worse !! the pluge at the bottom right...almost all are black (certainly on my system - check out: http://www.greatdv.com/video/smptebars3.htm and compare).
Similarly, my mainconcept and MS codec AVIs don't look right on Don's machine.
If someone else can open Don's avis (http://www.hyperstar.demon.co.uk/don.zip) and double check my findings. Playing the files in media player will be best. Probably best if you are using DX9 DV codec or mainconcept one.
Actually I was gonna finish this post with more conclusions about SOFO codec, how it decodes the MS/MC codec incorrectly..and visa versa......how it takes over the system and forces other apps to use it........how it might upset your ability to use premiere correctly if you had vegas installed - but as I was writing this I thought I best not be lazy and double test my conclusions in Vegas (the app, not the city). I booted up a third (win2k machine), installed vegas 4.0b demo...and attempted to play Don's clips in media player confident that the vegas codec would look fine......it didn't. Opened vegas (not used it before) and imported both don's clips....still looked wrong....mmmmmmm. Reboot (you never know! )...still no good.
After this last minute double check on my theory I am now thinking that there is an issue with either Don's machine or mine. I suggest that somebody else tries to play Don's avi's, check that the various shades of grey (pluge - bottom right) show correctly - or at least near.
If the vegas codec avi doesn't look right on other peoples machine then I think the problem is with Don's machine...if they do the problem is with my machines - OR - the issue is with the compatiblity between codecs and it didn't just didn't catch me out when I installed vegas (!?!).
Incidentially, I have no doubt that the SOFO codec is the better of the codecs tested, but checking through the SF site forums suggest that the canopus one might have advantages also. I know all of this seems a little pedantic but the quality loss seen by Don using the MS codec and me viewing the Vegas codec is huge.....and would mean all rendered footage would be greatly degraded and files made on one machine could not be used safely on another.
si
Don Donatello May 4th, 2003, 01:01 PM UPDATE --- i found the WHY !!!!
seems each software has a NATIVE codec ..it works BEST with that codec ...
I was doing ALL RGB's readings in Vegas with SOFO codec ...
when i rendered the MSDV codec clip - after when i was comparing the clips i was using Vegas with SOFO codec to read the RGB #'s ... when i was reading Simons avi's i was also using SOFO codec to read em -.... when i switched applications to read RGB's , i was reading with the software's native codec i was not reading using MSDv codec...
if i use the MSDV codec to read the clips, ALL posted AVI's read correct except sofo V Bars
NOW putting the rendered Vegas dv bars clip into Vegas time line using the msdv codec to read RGB's they are way out of whack !! and they look terrible with artifacts ( Simon, you must have questioned my eye site)....
Uncompressed clips/stills read correct with either codec ...
it appears that Premiere/AE does not read Vegas clips ( rendered using sofo codec) very well ..
Vegas ( using sofo codec) does not read clips rendered in Premiere/AE/Vegas rendered using MSdv codec) very well ..
Vegas (reading with msdv codec ) does not read Vegas clips that were rendered using sofo codec very well ...
ALL mentioned software do read uncompressed clips and Stills excellent...
it looks like whatever codec one used to render - it is best to use that codec to play back the clip !!!
----------------------------------------------------------------------
old post
i down loaded the donzip and looked at the V clips and the #'s are GOOD (on my system + - 1 number) ...
in the end i would say that each should test their own codec's on their systems if they want to see how their codec renders.
IMO you have to go by YOUR test results !!
your EXCEL sheet shows the msDV , mainconcept, canopus dv codec's are ALL approx. 99% match the original .. based on those results anyone of those codec's is a good choice. i stand behind your results becuase you repeated your test and you tested on win2K/XP.. i can only conclude that msdv codec doesn't work well with the software that i use.
so perhaps there is something in software works best with its default codec, and perhaps each software is fine tuned to work BEST with that codec.
bottom line for ALL is how it looks to them viewing the final output.
Michael Chen May 4th, 2003, 09:15 PM Don,
I captured my video files using ulead previously, and then I rendered the final output using Vegas, and the quality was really bad.
Could the different software used be the cause?
Is that what you are referring to?
Don Donatello May 4th, 2003, 10:15 PM for a experiment try rendering the ulead clips in Vegas using the msDV codec .. under preference uncheck ignore 3rd party codec's and then Check the use microsoft dv codec Box ... see if that turns it around
i'm not sure but ulead uses the microdoft dv codec and perhaps ??? when i used V with MSdv codec all of Simons clips and the clips i used rendering with msdv codec look excellent.
|
|