Would this cure the AVCHD blues?

farss wrote on 5/11/2010, 7:02 AM
Upfront I have to say I've had little experience with the AVCHD horror, just enough to understand why so many complain. On machines that I can reasonably well edit XDCAM EX, AVCHD is impossible, admitedly some variants seem worse than others.

Reading a Knowledgebase article the suggestion is to transcode to Cineform. I know there's scripts to do this and there's other ways as well. But it's another step and the competition does this on the fly.

Now we have Device Explorer and I guess one can use that to copy files from the camera or from cards. Seems kind of obvious to me that an option should be in Device Explorer to do the transcode while it's copying. USB speeds are pretty slow and the cards are even slower to read. Lots of CPU cycles going to waste here, they could be doing the transcode. This shouldn't take that much coding.

Bob.

Comments

dlion wrote on 5/11/2010, 7:08 AM
i agree, bob, vegas should have that capability.

before they add it, i'd prefer to see them address the stability issues, but in this case that feature may be the solution.

for now, consider using handbrake to do a batch transcode.
kkolbo wrote on 5/11/2010, 7:41 AM

I am not sure why you would use Handbrake. Cineform copies the files from the card and transcodes them during that process. It sounds redundant to me either with Handbrake or with Device Explorer. Since you have to buy the Cineform CODEC to begin with, why not use its capabilities rather than add them to Vegas.

You may say that Device Explorer should do the work and Vegas should include the intermediate format CODEC, but the reality is, Sony is going to be hard pressed to develop a better CODEC for that purpose. Bundling Cineform is not really a good option. Most of the cost of licensing Cineform when you buy Neo is, as I understand it, paid out by Cineform to patent and licensing fees. Bundling it with Vegas is not going to cut the cost significantly. That is why I am not opposed to buying Cineform's Neo directly from Cineform and let SCS work on other things.

Dave from Cineform may correct me, but I think the Cineform route is the way to go for the best quality and we get Cineform's constant development efforts on top of that. ProRes and such just don't stand up to my tests against Cineform.
ritsmer wrote on 5/11/2010, 8:38 AM
AVCHD is not just about squeezing the video in size on the media.

MPEG-2, H.264, and other codecs treat portions of the video image in blocks.
While MPEG-2 has a fixed block size of 16x16 pixels, H.264 permits the simultaneous mixing of different block sizes (down to 4x4 pixels).
This permits the codec to accurately define fine detail (with more, smaller blocks) while not having to ‘waste’ small blocks on coarse detail.
In this way, for example, the blue sky in a video image can use large blocks, while the finer details of the foreground in the frame could be encoded with smaller blocks.

So - if you just transcode H264 to MPEG-2 when you transfer the video from your camera, then you lose the better definition and sharpness that is possible with AVCHD (.264).

Using proxies makes editing faster and allows to use the original AVCHD media for the final render... but again if your final render is to mpeg-2 then it doesn't matter :- ) since this format discards the better possibilities of your source AVCHD.

Dunno - but obviously my Mac Pro with 2 x Quad Xeons is just over the required CPU-power limit where I can edit AVCHD H.264 directly and even have full speed preview (on a simple timeline, that is)
rmack350 wrote on 5/11/2010, 9:02 AM
Transcoding doesn't mean you're going to lose detail. Take an extreme example. If I transcode an H.264 clip to uncompressed AVI do I lose any detail? The answer is No. I get every bit of detail that was contained in the H.264 original.

Yes, having an adaptive block size allows H.264 to have higher compression overall while still preserving detail. You get a good image in a low data rate at the cost of high processing.

One of the big advantages of something like H.264 is that cameras can use lower performing solid state media like SDHC cards. Without this high compression you'd need faster media and more of it too. It's not a very marketable proposition.

Ideally, transcoding shouldn't be throwing away quality. What you should be getting for the transcode is the same image quality you had but with a higher data rate and less CPU load. Basically, you get something that is easier to edit.

Of course, in practice you're not really going to transcode to an uncompressed file, but still there are codecs available that are totally lossless as well as codecs that are visually lossless. If you transcode to a good codec there's no reason you should need to go back to your original AVCHD media for a final render.

It's a completely valid practice to treat H.264 as a recording format and transcode to something else for editing. The only problem with doing that is the time it takes to do the transcode.

Rob Mack

Sebaz wrote on 5/11/2010, 12:44 PM
I think that Sony should buy a license to use the technology that Grass Valley has come up with for Edius 5.5 and Edius Neo Booster. Having used Booster I can assure you that the AVCHD stutter and sometimes horrible performance in Vegas is not ONLY a matter of hardware power, it's also a matter of how well the AVCHD reader module is programmed. If it was only a matter of enough CPU power and amount of RAM, then Neo Booster would do a mediocre job at reading AVCHD footage in my computer as Vegas does, and it doesn't. I can even play the timeline at 1x and 2x the speed without rendering and it plays smoothly. I can play the timeline in reverse and it plays perfectly smooth. If I want to play the timeline in reverse at 2x then I get a bit of stutter, but it still plays. And I can play the timeline with color correction and many other filters, through fades and transitions, and it still plays in real time, all this with the raw AVCHD footage from my cameras. And my computer is a 2.66 Ghz quad core with 8 GB of RAM.

This doesn't mean that I prefer Edius 100% over Vegas because it seriously lacks in other areas, but since Vegas handles AVCHD playback so bad, then why don't they license that module from Grass Valley? Don't they license the blu-ray authoring and burning modules from Sonic, or am I wrong?

However, for when I have to use Vegas in a project that is more than straight cuts, I made a MPEG2 preset that is 960x540 at 15 Mbps, and I convert all the files to that to use as proxies, which allows me to use Vegas as comfortably as I can use Neo Booster with the raw footage, and then I have to remember to switch back to the original files before I do a test or the final render. The Proxy Stream script works pretty good for this, although it has some problems in Vegas 64 and you have to run Vegas as administrator to use it. But converting the source files to half the size in MPEG2 at least makes the conversion pretty fast, about real time or so, and it makes editing in Vegas much less frustrating.
ritsmer wrote on 5/11/2010, 12:49 PM
Rob: perfectly right - that goes without saying.

But I did read farss' post as a thought to transcode to something easily editable and storeable - like Cineform or MPEG2.
Imagine transferring a days recording from your AVCHD camera (say 20-40 GB) to uncompressed AVI... would take quite a few HDD's.

Sebaz: Agree that the AVCHD preview in Edius is smmoooootthhh.
Also agree that I would not change to Edius.
And finally agree that a Vegas combined with that preview would be non plus ultra.
rmack350 wrote on 5/11/2010, 2:04 PM
I was using an obvious example to illustrate that transcoding from AVCHD to something else doesn't automatically imply a loss.

To take that a bit further, transcoding to cineform or DNxHD is probably a net gain if you ignore the transcoding time. Quality-wise, there's no reason to keep the media as AVCHD. The reasons to leave it that way are storage size, set-up time (transcode time), and maybe time spent figuring out what would be the best codec to transcode to. The reason to transcode is for editing efficiency later on.

This isn't an all-or-nothing proposition. Working directly with AVCHD files gets you going quickly. Transcoding should make life easier in the long run. Quality loss due to transcoding just doesn't seem like an issue.

Rob

farss wrote on 5/11/2010, 3:07 PM
It appears that one of the reasons AVCHD is such a problem to edit is not just the variable block size but also because the GOP is variable. From what I've also seen the variable block size can be an issue if the vision is transcoded to mpeg-2. I cannot picture the technical reasons as to why this happens but it's been fairly obvious to me that quality can go downhill quite badly in the process.

Sure more compression can mean more video can fit into a given size cheaper storage media. On the other hand I can record XDCAM EX at 35Mbps to SDHC cards. Sure I fill them up pretty quick and I do need to buy the better quality, more expensive ones. On the other hand someone I know with a very cheap AHCHD palmcorder bought some really cheap SDHC cards. Not good, not good at all, files going south, camera doing wierd stuff. Really not the way to make consummers happy. I digress.

What prompted my idea was some actual experience with an uniformed but far from silly client with a CX550. 64GB of internal flash memory, filled to the brim.

It took this person 9 hours to get the footage into iMovie on a not top shelf Macbook. It took over 1 hour to simply copy the files onto a PC. On the latest desktop Mac, transcode to Prores seems included in the time to copy the files. Editing on a 3GHz Pentium D with Vegas 9.0c was a joke, had my local Macolite rolling on the floor. Editing AVCHD on my Q96xx is almost possible, same PC edits EX footage quite nicely.

I have no doubt that one of the SCS recommended firebreathers will edit native AVCHD quite nicely. When / if I have the money yes I'll buy such a box. It makes sense for me as much of MY income comes from doing doing post for others. From a consummer point of view this is insane. Buy a $2K AVCHD camera because its cheap but then need a $8K PC to edit it. I'm stating the obvious when I say a $8K camera and a $2K PC makes a lot more sense for a consummer or a prosummer indie producer.

Yes, if Cineform is the answer it should be in the box. If putting NeoHD "in" Vegas Pro adds $300 or $400 to the ticket, so what. Vegas is marketed as a Pro NLE. My main reason for saying it should be in the box, integrated more tightly into Vegas, is to change what has been a torrid affair between Vegas and Cineform into a stable marriage.

Bob.
rmack350 wrote on 5/11/2010, 6:04 PM
Gotta run to catch a bus but on the size/cheap media topic just keep in mind the state of things when tapeless products were still in development. Yeah, SD cards have improved and a lot more is possible now than initially.

Honestly, if you could really edit AVCHD natively in Vegas you'd chose that path in a heartbeat over transcoding. In some cases you can do it but I think I'd be inclined to transcode just to take a more conservative path.

Sure, it'd be nice if Vegas could come with Cineform for an extra fee, but the two have been pretty on-again/off-again. We want them to get along. We really do.

Rob
Sebaz wrote on 5/11/2010, 6:18 PM
I really don't think bundling Cineform is the answer. AVCHD footage can be edited in a moderately powerful PC that nowadays many people have, not to mention videographers. That is proven by the way Edius 5.5 handles AVCHD. The solution for Vegas is to provide that kind of playback, not to force editors to transcode to something else to begin editing.
Rob Franks wrote on 5/11/2010, 10:56 PM
Well, well. What has happened? I find myself actually agreeing with Sebaz.

Vegas is one of those apps that prides itself on native editing. The idea of bundling a conversion app along with Vegas not only serves as a band-aid solution. It also flies in the face of what Vegas is supposed to be.

Of course on the other hand Vegas has always been known as a pure software driven system... and that idea must change too. And I don't see SCS as having much choice in the matter. Just about everybody has gone with some form of gpu acceleration now and it's SCS's turn to do so. I would expect to see something of this nature either in version 10.... or 11 at the absolute latest.... but I don't think this is something that they can avoid either way for much longer.
Grazie wrote on 5/11/2010, 11:10 PM
Rob, there has always been a convergence of bitrate and codec lurking in the shadows for SonicF and now SCS. It's just, as you now are saying, coming into sharp focus. In the cool light of day having said that, I'm sure Vegas will become more and more "intelligent" about the mixed formats still to "Darwin-like" evolve as more and more clever ways to capture and pass on to editing stumble over the finish line.

It's this core philosophy of Vegas that I don't see changing - an ability to want/wish to embrace the newest of ways to capture moving images - whatever that may mean.

Survival of the fittest? I think we have ONLY just started to get an idea of what is going to emerge in the future. Who'd have thought solid state capture would have been commercially/prosumer attainable at this time? Well it is . . . . Vegas to use the processing power of the graphics in my PC? Bring it on! Me no wanna be a DoDo! How about a graphics card in a camera? Eh . . ? wink . .

Grazie

farss wrote on 5/12/2010, 5:57 AM
"not to force editors to transcode to something else to begin editing. "

Strange I don't recall the word "force' being in the suggestion. I fail to see the issue with having an "option". Many users are transcoding or using proxies and probably will continue to do so regardless. Giving them an option to speedup their workflow seems like a plus for them.

Bob.
farss wrote on 5/12/2010, 6:01 AM
"Vegas is one of those apps that prides itself on native editing. The idea of bundling a conversion app along with Vegas not only serves as a band-aid solution. It also flies in the face of what Vegas is supposed to be."

Huh,
no one's talking about bundling a :conversion app" along with Vegas. Vegas has been creating audio proxies since V4 and vision proxies since around V6. SCS themselves have been recommending using DIs for years, why do you think they bundle a cut down version of Cineform with Vegas.


Bob.
kkolbo wrote on 5/12/2010, 7:07 AM
It is not just about speed. There are many good reasons for using DI's.

I have an HP Compaq dc7900 computer with an E8400 Core(tm)2 Duo CPU @3.0GHz and 4GB of RAM. I have a system drive and a media drive. 1080p MPEG4 plays back at best full at 29.97fps. During a crossfade it goes to 22fps. I can edit AVCHD just fine. For speed I do it that way when speed is desired over quality.

I use Cineform or any other DI because in the end you can get better quality. AVCHD does not hold up well to being processed over and over. If there is a lot of work being done on the footage, a GOOD DI will hold up much better. Cineform is one of those options. It holds up to being processed and twisted.

This will draw a lot of fire, but I will say it any way. Everyone says they want Vegas to be a professional NLE, yet they are constantly complaining about its support for consumer formats. Regardless of what folks say other NLE's do, Vegas is solid for formats like XDCAM and RED. Especially when run on current professional level hardware. My performance on a mid level box with a consumer format is fine. The performance on a workstation is great. The performance on a low level box with a processor heavy format sucks. hmmm. Yes Edius Neo Booster plays the stuff better, but what about other functions? Vegas will not now or ever be what EVERYONE screams about. It will continue to be a solid tool for well matched workflows in a creative environment. If you want to use Vegas on a box that will not handle the format, buck up and use a goo DI. Take the hit or use a better acquisition format. I may want a pickup truck with duals in the back, but since I can't afford that truck, I have a smaller pick up and I make more trips. I can still be happy and get the job done.
Sebaz wrote on 5/12/2010, 8:26 AM
Strange I don't recall the word "force' being in the suggestion. I fail to see the issue with having an "option".

What I meant by "force" is that unless you have a Mac Pro or similar configured computer, editing AVCHD in Vegas is very frustrating, so editors are kind of forced to use proxies or if they prefer intermediate files and render from them directly. I prefer proxies because I want the highest possible quality so I want my final render to be from the original footage.

Adding Cineform to Vegas would probably make it more expensive, and I think if it's going to be more expensive I would much rather prefer them to license the AVCHD playback technology from Grass Valley than an intermediate codec from Cineform.
farss wrote on 5/12/2010, 9:03 AM
"Adding Cineform to Vegas would probably make it more expensive,"
Its already added, haven't you noticed? I'll say it again. There's a knowledgebase article that recommends transcoding to Cineform as a cure to problems with AVCHD.
I'm not arguing against the need for Vegas to also, at some time, provide GPU acceleration. Regardless of its true worth the reality is everyone else is doing it, it is a big selling point and it'll be suicide to ignore it.
Sure if proxies are your thing, then OK, lets have an option to create them on the fly, much the same way Vegas has been doing it for ages.

Bob.

kkolbo wrote on 5/12/2010, 9:39 AM
Bob,

Cineform is no longer included in Vegas.
rmack350 wrote on 5/12/2010, 9:53 AM
Rob Franks said regarding hardware acceleration "I would expect to see something of this nature either in version 10.... or 11 at the absolute latest.... but I don't think this is something that they can avoid either way for much longer"

This has been said about every upcoming version of Vegas that I can remember. It's never happened. That doesn't mean it won't, just that the trend has never gone that way.

IMO, a generalized GPU coprocessing feature would be more fitting for Vegas. The feature would probably have to be something that works at a system level so that it doesn't matter who's GPU is installed.

Rob
rmack350 wrote on 5/12/2010, 10:21 AM
Farss said: Vegas has been creating audio proxies since...

Have you looked at the DVFilm Epic I product? It's really limited in scope but it does this with AVCHD MOV files in Vegas. Unfortunately my GH1 produces MTS files rather than MOV so it seems that the tool doesn't see them.

--------------------------------

For Vegas to do this more directly would require some new project-level preference settings:

-Use proxy files? (Yes/No)
---Proxy file location? (Directory path)
------Storage limit? (Vegas guesses a number, you can change it. You don't want Vegas filling disks on it's own)
---CPU priority for background proxy creation (Low, Medium, High)
---Proxy file quality? (Draft, Preview, Good, Best (although it'd be nice if Vegas could just drop the good/best distinction))
---Proxy file bit depth? (8-bit, 10 bit)

You'd need a lot of storage space because Vegas would be filling it up in the background.

----------------------------

One other idea I've dropped in their suggestion box is to come up with a file format that they could dump RAM cached frames into. The idea would be to use these files for the entire duration of the project. They'd need to have an alpha state for each frame, or at least have a state where frames can be totally transparent, and they'd need to be able to drop frames into the middle of files. and they'd need a routine to immediately validate frames against the underlying tracks. The basic idea is to be able to save the RAM cache into preview files automatically so that you extend what the Preview RAM can do. It's another approach, and I'm not sure if I'm being clear here. It'd be easier to describe with pictures but it'd probably look like a Premiere timeline with a thin red/green track at the top edge.
TeetimeNC wrote on 5/12/2010, 10:45 AM
>IMO, a generalized GPU coprocessing feature would be more fitting for Vegas. The feature would probably have to be something that works at a system level so that it doesn't matter who's GPU is installed.

I think that is the approach taken by Edius. They only requre a GPU that supports Direct3d 9c or later. I hope SCS will take this same approach.

/jerry
Rob Franks wrote on 5/12/2010, 1:41 PM
"This has been said about every upcoming version of Vegas that I can remember. It's never happened"

I think the times have changed.
It used to be that hardware was expensive... not so anymore.
It also used to be that some form of hardware assist (what ever you may coin it as) was only found on the more expensive and posh NLE's. Today however you can find forms of hardware assist on even the cheap consumer level apps like cyberlink Power Director.

I really see SCS as not having too much of a choice at all now. At some point they will HAVE to go forward with hardware assist. 60i avchd is hard enough to run... but now they're coming out with 60p which is even tougher. With other apps being able to chew this stuff up and spit it out, SCS stands a terrific chance of being left behind if they don't follow through.

Yester-year hardware assist was considered very much a luxury but with today's formats pushing the boundaries with each passing day, hardware assist is fast becoming a standard necessity.
Sebaz wrote on 5/12/2010, 7:50 PM
I think that the GPU may play a part in this, but also it seems to me that Vegas has some kind of memory or buffer problems that need to be solved. I spent a while this afternoon editing a simple cuts family video and I realized that many times Vegas just chokes, but not because the footage is CPU intensive (which it is). I was editing footage from my Canon HF100, which is 16 Mbps, on preview full quality, and the timeline was playing at full frame rate for several minutes, but if I started pressing JKL back and forth, or if I trimmed a clip, then it would start choking and go down to even 7 fps. Even with the secondary color corrector applied to the whole track it would play at 29.97 for several minutes, as long as I didn't press JKL too much or trim or slice, it would still keep playing at full fps.

And the interesting part is, I noticed that if it's choking with a rather long clip, maybe playing at 15 fps, when the cursor gets to the beginning of the next clip, it will go back to full fps.

All this tells me that it's not only the lack of GPU assistance (which probably would help), but also something that is not working right in the module that reads AVCHD files. If it was simple lack of hardware power, it would choke right away when I try to play a file in this format, but it doesn't. It doesn't choke even if I play a timeline several minutes long, as long as I let it play and don't play around with the cursor too much.

Perhaps Vegas would do a much better job with GPU assistance, but until they fix their AVCHD reader, I doubt it will work as good as Edius in this particular area.
TeetimeNC wrote on 5/13/2010, 5:35 AM
Sebaz, I tend to agree with you. I think Vegas has had memory management issues even before AVCHD. AVCHD has just really aggravated the underlying problem. When 8.1 came out I was hoping 64bit would solve the memory issues but as we all know, it didn't.

/jerry