2 problems

David Laine wrote on 7/11/2009, 9:54 AM
Hi All

I hope someone can help me with 2 issues.

For some reason, every time I import an MTS file from my camcorder into Pro 9 Timeline, the file splits up into equal lengths, (I'm sure it's a setting I've changed by mistake) - can anyone tell me what it is ?

My other problem is with rendering. If I take say 3 MTS files, and butt them next to each other, and select the right output, I get the 'no re-compression' required' and everything's done very quickly, which tells me that the file settings are all correct - since if they weren't they'd have to re-code, if I overlay one track over another, to create a one second cross fade, and render again, I get the same caption and speed as above, then the preview comes back on, just before the cross fade, then the caption comes back and everything speeds up, but after a few seconds, the caption goes and it all slows down again

Has anyone any idea what it is I'm doing wrong, or have I found a fault with the programme ?

Thanks in advance for any help offered

Dave

Comments

musicvid10 wrote on 7/11/2009, 10:09 AM
David,
As to your second question, in order for Vegas to produce a file with the edits, transitions, effects, titles, pan/crops, track motion, envelopes, automation, compositing, or whatever else you have added to the timeline, it must Render those sections.

It cannot smart-render media that isn't already there or any changes that you've made. It's that simple.

If it's rendering sections where you don't think you've made any changes, then there's something hiding in there that you haven't remembered. As an example, lowering the track level or event opacity to 99% will cause it to render, because you have changed the output from the original media. Turn off everything mentioned above and try again. Hope this explains it.
David Laine wrote on 7/11/2009, 10:38 AM
Hi musicvid

I see what you are saying but I have now put the same file in the timeline twice butted up in runs without recom but if there is just a 1s x fade joining the 2 then all is well till the x fade vegas then slows for the fade then speeds up for a few seconds then slows right down

I have been carefull not to do any thing to the second file

One point though Vegas always slows down the second time at the same point in the 2 nd file


As ever thanks to anyone who can help

David
musicvid10 wrote on 7/11/2009, 10:47 AM
That may suggest there is something slightly different in the second file, or that there are errors (possibly unseen) with the imported file that Vegas is compensating for.

If the case is the former, looking at the files with MediaInfo will reveal it.
Once you have ruled out everything in my first post, by importing the second media into a fresh project, and setting the project and render properties exactly the same as the media:
The things that must be perfectly the same for smart-rendering to take place are pixel dimensions, aspect ratio, frame rate, field order, maximum bitrate, and average bitrate.

If it's error correction that is taking place (determined by ruling out all of the above, then simply let it happen. Except for train-wreck errors, Vegas does a pretty good job of fixing missing / incorrect header and GOP information, but it must render in order to do so. As an example, even one dropped frame or missing header may cause the entire file to be re-rendered from that point on, because Vegas may have to recalculate the GOP structure from that frame to the end of the file. As shown by deep analysis, errors are very common, and occur in some form in every file, but most often are never seen or noticed in viewing.

HTH
David Laine wrote on 7/11/2009, 10:56 AM
The second file is just the first file repeted on the timeline and they work if butted togeather


The 2 files are 12,200 frames in total length the 1s fade is at 6,100 frames in

at 19% progress the time remain is at 1m

When the render starts it is fast until frame 6,106 the progress bar is at 50% at this point time remain is at 35s

It then speeds up again to 11,200 then the frame count goes back down to 6,100 and then runs real slow till the end of the render at frame 12,200

I think I will try to find a copy of Vegas 8 to see what that does

Dave
David Laine wrote on 7/11/2009, 11:20 AM
Right

Vegas 8.1 does not smart render even 1 instance of the file in the timeline

Do I need to change a setting in V8.1
David Laine wrote on 7/11/2009, 11:47 AM
I cant get platium 9 demo to smart remder at all so it looks like I will have to stick with vegas 9

It would not be so bad if 9 was not so slow rendering

David
David Laine wrote on 7/13/2009, 8:50 AM
I've just tried something else. With the 2 clips butted together, I put a video fade at the end of the first instance. No re-compress was shown up to the fade point and then it went back to fast re-encode throughout the second clip

Now, I put a fade at the start of the first clip, it ran slowly through the fade, then no re-compress appeared briefly and it ran really slowly with no re-compress caption showing until it got to the fade out, then the second clip coded with no re-compress

The interesting thing is, the point at which the software slows down when it gets to the second clip is the same point where it starts to slow when it's a fade at the beginning of the clip

This is telling me that for some reason, these clips don't like having anything done to the front of them
musicvid10 wrote on 7/13/2009, 9:29 AM
So far I have been unable to duplicate the behavior you describe.
Your best solution may be to contact Tech Support through the links at the top of the page.
David Laine wrote on 7/13/2009, 11:19 AM
Hi

Yes I have sent a message to support

I have just done 2 vids with the HG10 that show the rendering problem in vegas the are in a zip file and can be downloaded here

http://rapidshare.com/files/255439775/laptopview.zip


This is the file I used in the laptop videos

http://rapidshare.com/files/255373293/test.M2TS.html

I must stress I get this problem on 2 pc's and using vegas pro 9 full 32 or 64 bit using vista home premium 32 or 64

I also had a go with W7 RC 64 and 32 same problem

Maybe someone can look at the test file and see what might be wrong is somthing wrong with the HG10 files themselves

Thanks in advance for any ideas or help

Dave
David Laine wrote on 7/13/2009, 1:19 PM
Hi All

I think i have got to the bottom of this problem here's what I did

i took the test file that I put on rapidshare and renderd it out as a .avc file

Then took it back into Vegas and renderd it out as a m2ts file

I then put it back into vegas twice with a 1s overlap and renderd out as a m2ts file again this time it went out as no re-encode so it looks like the problem is the HG10 files

It would be great if someone could download the test file and conferm that it does for them what it did for me

The next question how do I make the HG10 files work as they should in vegas if that is not possable the HG10 can go back to argos as it is not compatable but what to replace it with any sugestions will be welcome
David Laine wrote on 7/14/2009, 12:42 AM
it looks like it might not be a fault with the Canon alone, I've just found some sample footage shot on a Panasonic, it was 1440 x 1080, 29.970 fps. One instance in the timeline rendered out with no re-compression, 2 instances of the clip butted together - no re-compression required, but as soon as I put an overlap between the first and second instance, same as before - no re-compression until the overlap and then after a brief appearance of no re-compress, back to really slow rendering

Has anyone any idea what this is ? I'm getting it on 2 pcs, a range of OS's and in several versions of Vegas

Please help !!
blink3times wrote on 7/14/2009, 3:16 AM
I see from the other thread David that you have put a problem ticket in on this... good thing. HULK is having the same issue as well as I. If the clips are simply butted together then a "no re-compress" render works fine. But if you enter a transition (or any other small interruption) then "no re-compress" has trouble coming back on line after that transition.

For me the "no re-compress" works fine UNTIL the first transition. It will only go back to "no re-compress" anywhere from 200 to 800 frames after the transition, so if I happen to have my transitions within about 800 frames of each other...... well.... the "no re-compress" doesn't show up again.

I am presently speaking with Eric D at Sony and he is aware of the situation. Mention his name on your problem ticket and we'll see if we (he) can't tie all this together.
David Laine wrote on 7/14/2009, 3:22 AM
Hi

Yes will do

back in May HULK said

"First I have noticed that the manual does not specify m2ts as a SmartRender format.

Now that would explain things if it would not work but it sort of does

Have you had a go with my dirty fix for norecompress m2ts with overlap

As that works it does look like a file problem


I got a message back from Eric saying they had never heard of the problem before asking for a copy of the test file

I wonder if Eric D is a real person or some sort of auto responder

David
blink3times wrote on 7/14/2009, 4:14 AM
No, Eric is a real person of which I have actively been corresponding with on this problem.

I have no doubt that it is a file problem as some are experiencing this and some not. I had to send a file sample into Eric because the samples he had on site were working fine. In his samples he could get "no re-compress" to come back on line within 10 frames after a transition.

On the other hand this is now happening with 3 different cams... My SR11, Mark's HF100, and your HG10 and if the clips are simply butted together the "no re-compress" works fine. So although this may be a "file problem", it has to be that the encoder is somehow 'looking' at the file(s) wrong.

M2TS "smart render" is not mentioned in the manual but then if you look at the template, it has a "=" sign beside which indicates a potential "smart render" template.

The M2TS 'smart render" is another side issue that I'm having which is somewhat related. My cam has 5.1 surround sound but the M2TS smart render template only includes the "Studio" surround encoder.... which re-compresses in DVDa and since I can't "smart render" my original MTS files over to .AVC, I have to alter the template a bit not to include audio (I will render a M2TS without audio and then a separate AC3 file with the "pro" Dolby encoder which does not re-compress in DVDa) This minor adjustment in the render template seems to make the whole "no re-compress" issue even worse. Again... fine until the first transition, but then it even takes longer for "no re-compress" to kick in again after that transition.
blink3times wrote on 7/14/2009, 4:30 AM
One additional side note.... When you put in a problem ticket, your first response back will be automated. You have to indicate to this auto response that your problem has not yet been resolved. THEN you will get the assistance of a real person. They clearly (and understandably) do this simply to weed out the more serious issues from the rubbish.
David Laine wrote on 7/14/2009, 5:30 AM
Hi

This was the reply I got from Eric D on 13/7

"I have seen where no recompress rendering will begin a few frames after the overlap, however, I have not seen an issue where after one transition the project will not return to no recompress rendering."

Maybe he was downplaying the problem by not telling me others had it also
blink3times wrote on 7/14/2009, 8:53 AM
"Maybe he was downplaying the problem by not telling me others had it also "

No... he's not downplaying.

AS stated, he couldn't repro with his samples so I sent him mine, I also believe he is not (or at least WAS not) aware that there is a connection and others with this problem. I have informed him of such, told him there are others, and gave him links to these threads.

The last I heard (again on 13/7) he was going to send this over to the Engineering dep for a closer look. They're pretty good about this stuff. Every time I have sent in a problem ticket with a reproducible problem it has been corrected in the following patch. We'll sit back and see.
David Laine wrote on 7/14/2009, 9:36 AM
Hi

Did he tell you yseterday that he had seen the problem on a pc at his end I ask 'cos I talked with him to day on the 'phone and he said he could not get his PC to do it (he is running XP32)

Dave
blink3times wrote on 7/14/2009, 10:09 AM
I'm at work now so I haven't got his email directly in front of me, but from memory.... he never told me either way whether he repro'ed it or not. He simply stated that this is not a "common" issue and he will need additional info from me in order to forward my sample and problem on to Engineering. I gave him the info he requested and am assuming he will follow through with what he has stated.
blink3times wrote on 7/15/2009, 9:50 AM
Just a quick update. I've heard from Eric and he has in fact escalated the issue to Engineering for a closer look into what's going on.

Keep the fingers crossed for a quick repair on the next patch.
David Laine wrote on 7/15/2009, 10:10 AM
Hi

Yes he has been in touch with me also

He says the testing they were doing was using m2ts files made in vegas itself and they work well they would i guess but with files from my camara files they get the same problem

I have said that if I do not get a working version within 30 days I will expect a refund

Thankfully I paid by CC so I can take against them for supplying goods "not fit for the perpose" more folk should do the same maybe then Sony would not sell software with so meny faults in it

Dave
musicvid10 wrote on 7/15/2009, 10:18 AM



That accurately reflects my workflow and results when I said I was unable to duplicate your issue . . .
David Laine wrote on 7/15/2009, 10:24 AM
well that is one problem solved !!

I really would have thought that before putting a £600 piece of software on sale someone someware would have thought to test it;s flagship freature that is AVCHD support would work on a range of camara files and not just raced to sell it

thank god we have consumer law in the UK to help us

Dave
musicvid10 wrote on 7/15/2009, 10:35 AM
David,
I wouldn't be too critical of software developers here -- full AVCHD support in consumer NLEs is a relatively young technology, and will be a work in progress for hardware developers as well, for some time to come.

Going back a few years, early support for MPEG-2 for home DVD creation was terribly expensive, you were lucky if it worked at all.

Going back even further, my first VCR cost $900 and the recordings were caca.

GM's first computer controlled emissions systems were a total nightmare -- they didn't work more than 5,000 feet above sea level.

I could go on and on, but these problems will iron themselves out over time, and anecdotal evidence suggests other software manufacturers are having their own problems with AVCHD, despite different approaches.

The other thing, and one that no one has any control over, is that various manufacturers / implementers of the technology are going to need some time for every variant to adapt and settle into a "consensus" range where it always works for most users. Truly a work in progress in 2009.

Now knowing some of the issues faced trying to implement editing of Long-GOP, highly compressed temporal data, I marvel that we are able to work with it at all. Getting Vegas to smart render edited material from Canon's cameras under reasonable circumstances is certainly one of many issues that needs to be be dealt with, by Canon or Sony or both, but it is hardly a deal-killer.