Although I grumble that my NLE of choice Vegas is now Sony-owned and clearly favors Sony products (e.g. lack of native DVCPro/HD support and lots of silly support for PSP), in this case it's good for V1 buyers as the update is out as soon as the camera ships:
http://download.sonymediasoftware.com/releasenotes/vegas70c_readme.htm

Also includes support for HVR-DR60 recorder though I would like to see details as exactly how workflow works with it.

I wish all NLE and camera support came this quickly. But hopefully FCP, Avid, Premiere etc. support will follow quickly as it seems like as easily as Vegas added it, it must be a simple fix. If anyone has some raw 1080 24p footage, test it out and let us know if true 24p workflow awaits.

Just to make it PERFECTLY CLEAR:
The reason DVCPro is not supported by Vegas has absolutely ZERO to do with the fact that DVCPro is Panasonic-owned and Sony camcorders and Sony NLE are the same company. Nothing related whatsoever.
Excuse my angst, but this is an old myth constantly propagated.
Sonic Foundry Vegas didn't support DVCPro for the same exact reason that Sony Vegas doesn't support DVCPro HD. Cost. nothing more, nothing less.
If Panasonic wants it supported by everyone, they'd give the SDK away for free to everyone. But they don't.

To further comment, the "fix" or updated features are not simple to implement. Having been on the Beta for Vegas for years, and having been on the Beta for the V1, and DR60 (to my knowledge, I'm the only non-Sony employee to have beta access to both camcorder and software) it was not at all a fast, nor easy process.

I'm happy to answer questions about workflow; Vegas has some very clever methods of getting around issues the DR60 had to bring along in order to offer max compatibility with both Apple and PC workflows.

Cost. nothing more, nothing less.
If Panasonic wants it supported by everyone, they'd give the SDK away for free to everyone. But they don't.

I'm happy to answer questions about workflow; Vegas has some very clever methods of getting around issues the DR60 had to bring along in order to offer max compatibility with both Apple and PC workflows.

Cost was the same reason CineForm hasn't supported DVCPRO HD.

Could you outline the capture, edit, and the addition of pulldown during export.

Specifically, are you dropping frames during capture or skipping frames during editing. If the former, is the MPEG-2 being decoded? If so, is it re-encoded to MPEG-2 or recompressed to an intermediate codec?

I don't want to get this thread off-topic and into a back and forth, but facts of NLE, Raylight etc. DVCPro/HD support widely available here and other reputable sources (e.g. Barry Green) make it more than a myth. Cineform does convert DVCProHD BTW.

But since I don't own and only occassionaly edit DVCPro, the real issue I'm interested in is how good the Vegas V1 support is. I would like to hear some detailed DR60 workflow:

(1) How are the files saved?
(2) What are the stream details?
(3) What shooting modes are supported?
(4) File naming, folders?
(5) Transfer speeds?

Cost was the same reason CineForm hasn't supported DVCPRO HD.
And yet, CineForm *does* support DVCPRO-HD. And they didn't pay anybody a penny to do it.

And neither did Serious Magic, and neither did Raylight, and neither did MainConcept, and I don't think Matrox did either, as far as I can tell. And I don't know if Canopus had to, but they developed their own DVCPRO-HD support years ago, and I don't believe they licensed anything because they don't even call their codec DVCPRO-HD, they call it "Canopus HD" (even though it is 100% DVCPRO-HD compatible). Maybe Apple paid, maybe Avid did, I don't know, but the simple fact is that support could be integrated right now without paying anybody a single penny in licensing fees.

I wish all NLE and camera support came this quickly. But hopefully FCP, Avid, Premiere etc. support will follow quickly as it seems like as easily as Vegas added it, it must be a simple fix.

Does this mean FCP does not support V1 at all?

Does this mean FCP does not support V1 at all?

Any of the current NLE solutions should support the V1 right now. The output is on tape as 1080i (60 or 50 fields/sec depending on region).

What most WON'T do right now is remove the extra fields placed in the 1080i stream when shooting 24p.

The camera is still perfectly usable unless you are needing to do native 24p editing. From other reports here its starting to show up in sofware updates.

I think there is even a workflow that will get you to true 24p using some extra steps to remove the pulldown outside of your NLE.

Chris

Okay guys, lets look at this from a business perspective.

Vegas was one of the first to allow 24p editing with the DVX100. Now, from a business perspective it is a dumb idea not to support a widely used format. In fact, Vegas does support DVCpro as long as you use Quicktime to do it. You can also install DVCpro codecs and Vegas reads the files. The only real issue is HVX200 etc MXF files. I'm sure they have their reasons as DSE etc have pointed out.

Being on the beta team for Vegas myself, I will also add my 2c worth that the programmers work their butts off to make things as good as they can, and that what might seem like a simple issue to an outsider is in fact far more complex than it looks on the surface.

but the simple fact is that support could be integrated right now without paying anybody a single penny in licensing fees.

Unless more than one NLE developer has lied to me about this (and I highly doubt it) then this statement is abjectly false.
I also know beyond certainty that the Vegas team wanted to support DVCProHD, but given the costs both internal and external, it wouldn't recoup itself.
Given that DVCProHD is effectively developmentally dead, it probably was a good move anyway.

Unless more than one NLE developer has lied to me about this (and I highly doubt it) then this statement is abjectly false.
I also know beyond certainty that the Vegas team wanted to support DVCProHD, but given the costs both internal and external, it wouldn't recoup itself.
Given that DVCProHD is effectively developmentally dead, it probably was a good move anyway.

It would be relatively simple and cheap for Sony to provide a developer like me the source to their Sony MXF file interface to be adapted to reading Panasonic MXF files using the Raylight decoder. I'm doing something similar for Cineform so they can drop the Panasonic drivers from their install requirements. This would allow you to have HVX200 MXF files in the Vegas timeline. Dave Hill and Dennis Adams have my number if ya'll want to encourage them to do that.

But I agree that the mass market appeal of this is nil. You can already drop a CONTENTS folder into RayMaker and with one click it generates mirror AVI's ready for editing, so having MXF in the timeline seems a slim sliver of simpler.

Unless more than one NLE developer has lied to me about this (and I highly doubt it) then this statement is abjectly false.
Or you just don't have the full story.

Having been a software developer, and having been in communication with various developers, and having researched the process of coming up with my own DVCPRO-HD decoder back when the HVX was first announced, and having experienced the licensing issue you're concerned about, and having seen how so many others have solved the problem WITHOUT PAYING A PENNY IN LICENSING FEES, and having even been in the loop to suggest to certain software developers ways that they could also support it with NO licensing fees, I can assure you that my statement is abjectly true.

The codec issue is solved. A decoder (the key necessary component) can be gotten for free. It can also be licensed from another developer, such as SM or DVFILM. It is no problem to support DVCPRO-HD, Panasonic distributes the decoder freely (as does Avid, for that matter, and theirs is a full codec but for Quicktime). File transport is already implemented in Windows XP SP2, so capture is using a standard OHCI interface. Vegas or Premiere would need to implement Op-Atom MXF support, and they're basically done.

Will they? Remains to be seen. But the reluctance to implement support certainly isn't restricted to a "licensing fee" issue. Any assertions that it is are, at best, inadequately informed, and at worst, abjectly false.


I also know beyond certainty that the Vegas team wanted to support DVCProHD, but given the costs both internal and external, it wouldn't recoup itself.
And I also know beyond certainty that what you're saying is based on old information. There is another way.

Given that DVCProHD is effectively developmentally dead, it probably was a good move anyway.
"developmentally dead?" What is that supposed to mean? "developmentally dead"? Is HDCAM "developmentally dead"? Is Digital Betacam "developmentally dead"? Considering Panasonic is releasing three new DVCPRO-HD camcorders over the next four months, you certainly can't be implying that the format is dead, that would be a ridiculous assertion.

Or is "developmentally dead" some sort of inflammatory language that really means it's tried, true, finished and working (and thus doesn't need more development)? Because they've just launched the HDX900, HPX2000, HPX2100, announced the new HPX500, and Jan's even hinted that there's another 2/3" model that'll be introduced at NAB. All of them using DVCPRO-HD. Add that to the existing HVX, VariCam, HDX400, recently released new AJ1400 deck, and however many other products that there are out there... Heck, Panavision just announced a deal to buy $2 million worth of DVCPRO-HD products. I don't know about you, but "thriving" would seem to be a more appropriate term.

DVCpro is developmentally dead. Panasonic want to move away from tape gradually, and DVCpro limits them. Hence AVCHD etc.

Its a popular format, but you can bet that it will be phased out over the coming years.

DVCpro is developmentally dead. Panasonic want to move away from tape gradually, and DVCpro limits them. Hence AVCHD etc.

Its a popular format, but you can bet that it will be phased out over the coming years.

You could make that argument for any current format HDV, miniDV, HD CAM but for those Vegas users who need to edit a variety of formats, today, next year and in years to come, supporting all major formats natively is important feature.

But despite all the fun in Sony vs. Panny, I'm still interested in Spot's report on DR60 workflow...

DVCpro is developmentally dead. Panasonic want to move away from tape gradually, and DVCpro limits them. Hence AVCHD etc.

Its a popular format, but you can bet that it will be phased out over the coming years.

to be honest with you, i dont think the issue itself is the DVCProHD format, hell, as mentioned, its been used and milked by a variety of developers, so if they can do it, there is no reason SOny cant.. cost or not, sony are isolating themselves from a professional format used by many studios throughout the world.
In all honesty, it seems that its the MXF used to transport the format..
Sony have their system with their XDCam support, and i really dont see why it cant be tweaked for the Pana equivalent to be used within Vegas
Same concept, VERY similar workflow, same file managment system.. differnt manufacturer..

I also dont think that any format which utlises 4:2:2 colour space could ever be redundant, and P2 being the ONLY real portable format for it ensures its longevity... especialy if you couple P2 with AVCHD

Direct to disc units have proven to be a risk, sure some work, but the firestores and quickstreams ive sold have had more problems than not...

You're right, it's the MXF packaging which costs money, and isn't supported. However, that's what comes with the HVX flavor of DVCPro, and given that it's very expensive to purchase the SDK, and given the fact that the *majority* of the MXF format cams are from Sony, and that Vegas supports their flavor of MXF... all that totals up to "why support it?" If the tools were given to Sony at no cost/low cost, they'd support it. I've heard that commented from Madison to Japan.
either way, you're not going to see it supported in Vegas any time soon, so if you're wanting to work with the HVX and upcoming cams using Panasonic's version of MXF, you'll need to either not work with Vegas, or find a workaround.

You're right, it's the MXF packaging which costs money, and isn't supported. However, that's what comes with the HVX flavor of DVCPro, and given that it's very expensive to purchase the SDK, and given the fact that the *majority* of the MXF format cams are from Sony, and that Vegas supports their flavor of MXF... all that totals up to "why support it?" If the tools were given to Sony at no cost/low cost, they'd support it. I've heard that commented from Madison to Japan.
either way, you're not going to see it supported in Vegas any time soon, so if you're wanting to work with the HVX and upcoming cams using Panasonic's version of MXF, you'll need to either not work with Vegas, or find a workaround.

Here's your workaround

1. Drop CONTENTS folder into Raylight RayMaker.
2. Start editing

;)

You're right, it's the MXF packaging which costs money
http://freemxf.org/
An open-source library, free source code.

if you're wanting to work with the HVX and upcoming cams using Panasonic's version of MXF, you'll need to either not work with Vegas, or find a workaround.
That's what we've all been doing. A shame that we have to though.

http://freemxf.org/
An open-source library, free source code.


That's what we've all been doing. A shame that we have to though.

I agree - support more cameras and more codecs, happier users, more sales, the worlds a better place. I don't own a HVX or other DVCPro cam - just love Vegas and want to use it for all freelance editing work without having to buy extra solutions for each supported item.

But at least they added speedy support for V1. I can always be an optimist and decide they will change their mind and strategy and support DVCPro natively, though glad Cineform and Raylight have offered workarounds.

http://freemxf.org/
An open-source library, free source code.

That's what we've all been doing. A shame that we have to though.

No, that's not what we've "all" been doing. "We're" doing just fine using the Serious Magic and Raylight tools for those few times when we *need* to use our HVX. If we had a Varicam, it would probably be different. but I don't see the need for the extra cost that supporting DVCProHD coming out of my pocket or the pocket of the majority of users that don't use the DVCProHD format. That's where I have to turn south of supporting DVCProHD. If it costs more, but can't support itself in the number of users it engenders, then it's not a high-value add, and makes no business sense to add it if it doesn't generate additional revenue.
At the end of the day, that's all it adds up to. We both know if the Madison team could add DVCProHD to Vegas without significant cost to them (which is then in turn passed on one way or another to users), they would do so. It's not a Sony vs Panasonic conspiracy. It's a cost issue, nothing more, nothing less.

Understood, however, like canopus with the HD codec upgrades, im sure those that wish to use it within the NLE would be more than happy to pay for the priviledge...

*that* idea, I can get behind. Paying extra for a codec package makes for good business sense. For that model to work however, there has to be a belief that XX% of the users of a particular product requiring the codec would either purchase the codec package, or move from XYZ NLE to Sony Vegas. Adobe has done it, Canopus has done it, and it's a proven model.
If there were enough "guaranteed" revenue, it makes total sense to build a package that isn't third-party dependent.

http://freemxf.org/
An open-source library, free source code.


I remember looking at that when I started the raylight project. The wrapper does weird thing like puts each frame in its own essence container. It follows a more generic scheme for MXF files than SMPTE 377. For example, there's no function call that returns the frame size. You still have to wade through the spec to figure out how to get that.

Anyway it's not the file format decoding that I need, but an SDK for the Vegas file interface which only Sony can provide. I did send an email to Dennis Adams to see if they would provide that.

No, that's not what we've "all" been doing. "We're" doing just fine using the Serious Magic and Raylight tools for those few times when we *need* to use our HVX.
I seriously don't get this. I quote your exact words, which say we have to either not use Vegas, or use a workaround -- which are the only two choices available to us (and CineForm, Raylight, and SM DVCPRO-HD Decoder are all workarounds). We all have to do that because there is no native support.

Then you try to come in here and mock my words and say that's not what
"we're" doing. Why? Why play word games? I was agreeing with you and quoting your exact words.

It gets worse though. We've already shown that there is no additional licensing cost at all to support it, MXF support is a SMPTE-codified standard (390M) which is used by Panasonic, Ikegami, and Thomson to name a few so Vegas will likely have to support Op-Atom anyway... so even though the cost argument has been disproven you come up with a different "cost" argument, saying you don't want that cost coming out of your pocket.

Well, that argument slices both ways. I don't want the cost of supporting the PSP coming out of my pocket either. And I really don't use the Ogg Vorbis format, so why should I have to pay for that? And I'm not too jazzed on using XDCAM HD, yet they spent time and money to support that, which I, as a Vegas user, would presume that part of the price I pay for the software is now higher because of that development, right?

Supporting any format is going to involve some work on somebody's part. Should they just decide to not support new formats? I don't get this logic. At all.

As for an extra-cost add-on pack, I'd be fine with an add-on pack. I did that with DV Rack, I'd do it for Vegas too. In fact, I have done it for Vegas, I bought Raylight. But while I love that Raylight allows me to use the HVX with Vegas, the non-native implementation can't hold a candlestick to how it could be -- try EDIUS Broadcast with it, where my laptop can handle six streams of HD in realtime off the card. Or try it on FCP, with three streams of HD from the internal hard disk. Raylight or SM can't do that, can't come close to that. Native support could (because I can see it happening in the other programs).

Like it or not there are a massive amount of HVXs out there. If editor integration was decided solely on the number of potential users, factor that there are probably more DVCPRO-HD systems (if not multiple times as many) as there are XDCAM HD systems out there. Yet Sony felt there were enough users to implement XDCAM HD support, obviously. And I'd wager that there are probably thousands and thousands more DVCPRO-HD users than there are people trying to author PSP titles.

Seems to me that an editor should support editing footage, regardless of who makes the camera. And with tiny startup companies and one-man operations like MVB able to solve the problem, I think it's not unreasonable to wish (and that's all we're doing anymore, is wishing) that Vegas would support it too.

I really don't see what's so wrong with that.

try EDIUS Broadcast with it, where my laptop can handle six streams of HD in realtime off the card. Or try it on FCP, with three streams of HD from the internal hard disk. Raylight or SM can't do that, can't come close to that. Native support could (because I can see it happening in the other programs).



The reason for that is not the non-native format but becasue FCP and Edius embrace hardware acceleration, which limits the platforms (ie graphics cards) that can run it. Vegas has never used hardware acceleration I presume so it can run on any PC

Perhaps a more intersteing approach / question is how many NLEs have implemented full MXF support in the same way as Vegas does with XDCAM. It seems to me this is where the power of MXF lies, all the talk about codecs is a side issue.
Having to suck the footage out of the wrapper into another wrapper like I believe FCP does kind of bypasses the whole concept.

The reason for that is not the non-native format but becasue FCP and Edius embrace hardware acceleration, which limits the platforms (ie graphics cards) that can run it. Vegas has never used hardware acceleration I presume so it can run on any PC
I beg to differ...
its teh management of the codec which is the issue. not HW acceleration. To date, i am yet to se a "hardware accelerated" version of FCP5, however i have seen a juiced out MacG5 dual core with 4gb ram pumpin many MANY video tracks without a problem.. of course these are all QT shelled, but to get the gravy, u need to cook the meat.. in tehend however, were still lookin at abotu 4 streams of 100mbps material... vegas with raylight cant even manage 1 stream without puking.. hell it pukes when u do too much with HDV...

I am yet to see a PC based NLE with equivalent grunt (im talkin XP with Dual core cpu and 4gb ram vs MAc OS10 with dual core and 4gb ram) have the ability to do what FCP5 can do with this same footage..edius comes close, i have seen it running HD material without skipping a beat and this is SW only.. run on my Edius SP training system (HW based), and the bugger screams, but thats not the point. the point is that the codecs are much more efficient within Canopus and Apple systems as opposed to any other NLE i have seen.. even Avid pukes unless u have cash to burn.. and the godfather would be the Axio, but then your looking at 20k system

Fair enough we get what we pay for, and if we want to use professional Broadcast formats using higher bitrates for our acquisition and delivery, then sure enough we pay for it, however, one should never forget the fact that 90% of event editors working on projects day by day shot on the HVX (as an example) , do NOT use AVID, Edius or FCP... they use PP, Liquid and Vegas.. why??
Cost...
Thing is those same Editors are now forced to to rethink their NLEs as many of these NLEs DONT suppport the Pana MXF format..

irrespective of what else is availabel out there, the issue here is the fact that specific camera users are isolated from using a specific NLE.
This will hurt the camera manufacturer AND the NLE developer equally as the producer will have to decide whether to stick with the NLE theyre comfy with, or stick with the camera which gets the footage they need.
Consider that its this same tossup which bought many people across to Vegas in the first place with its implementation of progressive scan.
Of those DVX100 and XL2 users, many have now upgraded to newer machinary, however those DVX100's users who jumped teh HVX wagon are now isoalted with this NLE and a camera which cannot be used as it could be.. (ie immediate P2 MXF edit) and its these users who have no option but to chop and change to an intermediate workflow simply becuase teh NLE which they supported back when it was virtually unknown does nto support the format to which they use now

its really not much to ask for... hell Vegas supports QT, which not only is an opposeing OS, but usually created on an opposing NLE

go figure...

Barry,
I can't really argue most of your points with you, as on the surface, they appear to be sensible. But there are a few points that should be mentioned:

PSP support didn't cost you a dime. Even if it did, what do you suppose the ratio of PSP owners vs HVX owners might be? 500,000 to 1? Ogg is another example of a no-cost development, but a massive user-base existing. If DivX support ever happens, it won't be of any real cost to you either. DivX has people *begging* the NLE companies to allow them in the box, and will do the dev themselves.

Like it or not there are a massive amount of HVXs out there.
This would run contrary to what Panasonic's own representatives had to say in a public forum at the Academy of Recording Arts and Sciences just last month.
Which is why I don't think it's sound business sense to develop for a tool that isn't as popular as hype might have one believe.
As Bob mentioned, it's really about the MXF, and Sony has taken steps thus far, to support it beginning with their own flavor. No application in the industry at any price point can do what Vegas does with XDCAM. However, you didn't/aren't paying for that either. And even if you were, there are indeed "massive" numbers of XDCAMs out there the world over.

Maybe you know a secret with FCP, as I can't get it to stay stable with footage from my HVX. And working with it has been nothing but a PITA. Edius does a great job. But they too, are not future-developing for DVCProHD/MXF for a while, as stated at NAB. They've got their own codec and MXF flavor to work with/on.

And I'd wager that there are probably thousands and thousands more DVCPRO-HD users than there are people trying to author PSP titles.

Maybe you don't understand the PSP encoding role in Vegas, as you'd not have said this? Vegas isn't a PSP authoring tool, it's merely an encoder for the PSP, and for iPod. And Vegas is an exceptionally popular tool for encoding to the PSP. But the UMD authoring tools are not included in Vegas. And sell for $20k.

So the point still is; develop for and embrace a featureset that sells more product to fund future development, particularly when it costs virtually nothing to develop while looking at a massive existing user base (such as PSP or HDV), or develop for a format that:

a-is exceptionally costly to develop due to costs from the manufacturer (particularly when that manufacturer provides no-cost development and support for your competitors)

b-not a significant number of camcorders in the same cost/user class exist in the world as a whole, to support the costly development.

Putting my bias regarding the marketing ethic of the HVX aside, I agree with you in that I'd like to see every codec/format/interchange ever devised inside of Vegas. But if the checks and balances don't work out, then priorities have to be made. That's basic business sense. During the dev of Vegas 5/6, we didn't have good HDV support in the app either. CineForm to the rescue. Third party support that made it work, and given the number of HDV cams out at the times of release of Vegas 5/6m, it made perfect business sense. Sony even put the basic wrapper package in the box. Bear in mind as well, that some of the development for the HVX tools would be best done using DirectShow, and Vegas doesn't support Directshow at this time (although I wish it did/think it should).

Comparing the number of XDCAMs out there to the HVX #'s, well...

"No application in the industry at any price point can do what Vegas does with XDCAM."

and the funny thing is, even Avid cant do half the things vegas can with XD... now, if the Pana MXF could be implemented it would be the perfect system for the HVX user considering the price point of the NLE and the camera...

all i can say to this is that amazing potential is lost.. political, economical.. who cares.. fact remains a perfect system is dead before its given a chance to thrive...

The reason for that is not the non-native format but becasue FCP and Edius embrace hardware acceleration, which limits the platforms (ie graphics cards) that can run it. Vegas has never used hardware acceleration I presume so it can run on any PC

EDIUS does not use hardware acceleration for any codec.

-----------

Frankly, I don't care if any P2 codec is supported because I'll never use a P2 anything. Which includes AVC-Intra. IMHO P2's a dead format walking.

But, DVCPRO HD is a different animal having proven itself. The new 900 DVCPRO HD camcorder looks great. These will sell for years to come. So supporting DVCPRO HD in an NLE seems to be an obvious thing to do -- since the $100K SDK cost issue seems to be untrue.

That does seem to leave the issue being a political one. But, that really is Sony's call to make. It's not like Vegas is Avid or FCP -- or even Premiere in market importance. Do those shooting DVCPRO HD really miss anything by not having Vegas support? Especially considering the huge market share of HD editing held by FCP which has great DVCPRO HD support. I don't think so. Why the big fuss then.


But this thread has gone WAY off topic. DSE has yet to describe the V1 support details which are what is important to V1 owners.

"No application in the industry at any price point can do what Vegas does with XDCAM."

and the funny thing is, even Avid cant do half the things vegas can with XD... now, if the Pana MXF could be implemented it would be the perfect system for the HVX user considering the price point of the NLE and the camera...

all i can say to this is that amazing potential is lost.. political, economical.. who cares.. fact remains a perfect system is dead before its given a chance to thrive...

No argument from me, Peter. As mentioned before, it would be great if Vegas could be treated equally by the various manufacturers at all levels. Then it would easily have far more support than anything out there. In the meantime, I for one, am grateful for Raylight. Serious Magic had a good thing cookin' too, but Adobe immediately killed the product when they bought Serious Magic. Who knows...? As mxf becomes the buzzworkflow of the industry, maybe we'll see some meeting of the minds on the subject.

[edit] Of course Edius has had hardware support available, Steve. So has FCP. Not required, but certainly available.
I agree, P2 is a dead format before it hit the ground. "Slightly ahead of it'self" IMO. But that's beside the point.
I guess I don't understand what workflow question you're asking about.
As I've described in several threads, Vegas sees the DR60 and brings in the files that are in a tree format, and appends appendable files. In other words, it doesn't worry about the drive format limitations, it has smart tools to know what files go with what. I think the Vegas team learned a valuable lesson after the nasty errors the DSRDU 1 brought to the table, with identical file names in different folders, which caused a lot of NLE's and users to accidentally delete files. That won't happen with the DR60 and Vegas.
Vegas 7c also allows users to remove the pulldown, or leave it. Your choice.

No argument from me, Peter. As mentioned before, it would be great if Vegas could be treated equally by the various manufacturers at all levels. Then it would easily have far more support than anything out there. In the meantime, I for one, am grateful for Raylight. Serious Magic had a good thing cookin' too, but Adobe immediately killed the product when they bought Serious Magic. Who knows...? As mxf becomes the buzzworkflow of the industry, maybe we'll see some meeting of the minds on the subject.

Put it this way.. lack of NLE support stopped me from buying 2 HVX's plus a myriad of cards.. my edit workflow is a higher priority in my studio than the camera i use, and now with newer HDV models offering very similar shooting modes (overcranking, gamma, progressive scan etc) the lean towards an "inferior" codec'd camera is forced because of this issue..

but still, im in no rush... we'll see how wit pans out when all these new formats come to the fore...

EDIUS does not use hardware acceleration for any codec.


Hmmm. When I drag the clip window in Edius around, the video image lags behind the frame by 10-25 pixels then catches up. What's your explanation for that?

Also from the Edius system requirements page: "A graphics card with hardware-based DirectDraw Overlay" etc . ?

Hmmm. When I drag the clip window in Edius around, the video image lags behind the frame by 10-25 pixels then catches up. What's your explanation for that?

Also from the Edius system requirements page: "A graphics card with hardware-based DirectDraw Overlay" etc . ?

DirectDraw is simply Microsoft's graphics support function. The whole point of Canopus products from Day 1 is use the CPU.

FCP doesn't use any acceleration either.

DirectDraw is simply Microsoft's graphics support function.
Yes indeed. Here is the spec on the YUV overlay mixer and the other functions, including hardware DCT decoding
http://www.microsoft.com/whdc/device/stream/DirectX_VA/default.mspx

FCP doesn't use any acceleration either.
Core Image, Core Video and Quartz Extreme are part of the Mac's hardware accelerated graphics architecture, also used by FCP, see for example
http://www.apple.com/macosx/features/coreimage/

Canopus used to be *only* about hardware acceleration, so not sure about what you mean by "since day 1." Hiro started Canopus as a hardware support company for Ulead Media Studio and Adobe Premiere. And until Matrox entered the picture, Canopus actually had staff in the Adobe building part time. Edius more or less required hardware at first release.

And as Marcus pointed out, the Microsoft implementation uses hardware acceleration. Again, not required, but for optimum performance, hardware is beneficial. FCP isn't all that different, calling on the vid card for decoding and other tasks. Again, not required, but very useful and significantly more efficient.

You might recognize this studio; (http://www.canopus.com/support/tutorials/EDIUS.php) we produced the Canopus training DVDs for them. We've been Canopus users in one form or another quite literally since day 1. I think I've got at least 5 Raptor cards, a few Rex cards laying around still. Canopus had RexEdit later on, but that was an extremely poor editing tool outside of great keying ability that eventually, everyone caught up with. Edius is significantly mo' betta.

Yes indeed. Here is the spec on the YUV overlay mixer and the other functions, including hardware DCT decoding
http://www.microsoft.com/whdc/device/stream/DirectX_VA/default.mspx


Core Image, Core Video and Quartz Extreme are part of the Mac's hardware accelerated graphics architecture, also used by FCP, see for example
http://www.apple.com/macosx/features/coreimage/

Well if your definition of "hardware acceleration" is the normal functions of your PC's graphic's cards, then every NLE uses hardware acceleration! So does every DVD player, game, etc.

Obviously when one talks about "NLE hardware acceleration" one is talking about when you add a PCI card with a specialized LSI that does certain tasks such as wipes, dissolves, proc amp, color correction, etc. in order to support RT editing. Matrox, Media 100, Avid, have made a business of such boards.

Canopus did have one PCI board to RT encode MPEG. I reviewed it years ago. Within about 18 months -- dual processors could encode at RT speeds and the product was dropped.

Hiro started Canopus as a hardware support company for Ulead Media Studio and Adobe Premiere.

Actually, he started making ordinary PC graphics cards just like many companies. They were not sold in large quantatities in the USA because Taiwan cards were so cheap. He THEN went toward video editing.

ONCE AGAIN we are OT.

It would be very helpful if you would provide a detailed explanation of the V1's SCNA mode and the Vegas support of the V1. I have to wonder why, given the topic of this thread you have yet to respond to this very simple request. One that has also been made at the Vegas site.

It would be great if we got this information before the V1's arrive and folks puzzle through the V1 errata sheet on SCNA!

Well if your definition of "hardware acceleration" is the normal functions of your PC's graphic's cards, then every NLE uses hardware acceleration! So does every DVD player, game, etc.

Obviously when one talks about "NLE hardware acceleration" one is talking about when you add a PCI card with a specialized LSI that does certain tasks such as wipes, dissolves, proc amp, color correction, etc.


I would want to expand that definition to include hardware acceleration for VLC decoding, inverse DCT, and YUV to RGB conversion. Fair enough?

I would want to expand that definition to include hardware acceleration for VLC decoding, inverse DCT, and YUV to RGB conversion. Fair enough?

By nature of the industry definition of hardware acceleration going back nearly 12 years; any application or process that uses any hardware other than the CPU falls into the category of "Hardware acceleration" by most standard forms of conversation, so IMO, the clarity Marcus asks for is already apparent and redundant.
The Canopus Raptor, for example, had no acceleration for wipes, dissolves, color correction, proc amp, but was absolutely a hardware decoder and accelerator. Without it, nothing could use the Canopus codec and display/process. It wasn't until later that Canopus offered cards that managed to accelerate the processing of wipes, dissolves, color correction, proc amp, etc.

This thread has meandered enough that there is little point in allowing it to continue.