MAJOR PROBLEM

bruceo wrote on 9/12/2007, 10:08 AM
We have rendered 3 different projects on 4 different machines (p4, Pd, Q6600, Dual Dual) Vista & XP and all HDV projects rendered with smart render have occasional gitches similar to footage that is captured with bad firewire cable. If you put a filter on the track and force render then all of the footage is pristine.

So it looks like enable no recompression on long GOP needs to be unchecked in preferences until this much needed/desired feature is FIXED.

Comments

DJPadre wrote on 9/12/2007, 10:31 AM
could be a IBP frame stitch issue...??? dunno.. mine was too slow during the rendered parts to let it run a 4 minute clip on a dial core 1.8 lappy (this usually renders faster than realtime in V7... ) so i killed the render.. it wasnt worth my time
bruceo wrote on 9/12/2007, 10:38 AM
Q6600 I am getting about 4 minutes render time for a 5 minute straight cut no filter occaisonal dissolve edit with smart render off.

Stich issue? Possibly it seems that most glitches (pixelation blocks) occur on cuts but there are some quick jitters that occur middle frame.
DJPadre wrote on 9/12/2007, 10:49 AM
wow.. not much faster than me.. and this is rendering from a 5400rpm USB bus powered portable drive to the system drive..

as for the glitch, like i said, i didnt hang around long enough to really notice.. v8 renders were too slow for me
MarkFoley wrote on 9/12/2007, 10:50 AM
Hmmm...this indeed sounds like a major problem if it is truly the software...seems puzzling that this wasn't caught during beta testing....
bruceo wrote on 9/12/2007, 11:03 AM
Just reconfirmed this error on another machine with a counterpart in the local market who smart rendered a 7 minute section and counted at least 7 judders or pixellated blocking. Reproduced every time on numerous hardware and software configurations. Does not occur on recompressed footage.
DJPadre wrote on 9/12/2007, 11:07 AM
have you scrubbed through the newly rendered clip frame by frame and taken a screen grab of the problem? in comparson to the original (preview window snapshor or simple cookie cutter will suffice..

DO THIS then email SMS support direct.. its your best option mate
blink3times wrote on 9/12/2007, 11:40 AM
"Just reconfirmed this error on another machine with a counterpart in the local market who smart rendered a 7 minute section and counted at least 7 judders or pixellated blocking. Reproduced every time on numerous hardware and software configurations. Does not occur on recompressed footage."
================================================
I have the same problem. I initially thought it had something to do with 32bit color. But after switching to 8 bit with smart render on... I get the same thing... juttering, blocky pixelation... etc. If I turn smart render off, the problem goes away.

The render time has taken a drastic tumble too. The smart rendered section go well. It's the re compressing sections that are moving slllllloooooowwww

(Q6600,4gig ram, ati 1950 video card)
P.S. wrote on 9/12/2007, 11:42 AM
I also have some problems with option recompression on long GOP, there is some glitches which looks like drop out on tape.
Anyhow it will speed up rendering to my project about 45min, so hope Sony can fix this...
bruceo wrote on 9/12/2007, 12:02 PM
I am working with SMS on this right now. I will let you know the resolution.
Nobody wrote on 9/12/2007, 12:31 PM
Thank you for keeping us posted.
Wolfgang S. wrote on 9/12/2007, 2:54 PM
I have been able to generate a repro, and have forewarded the details to the development department of Sony.

What I see here, is a kind of blocking - in parts of the video, where no errors are.

Is that the kind of error, that you see?

http://wolfgang.sb-web.de/misc/error/Error%20in%20Picture.jpg

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti * Blackmagic Extreme 4K 12G * Atomos Sumo * QNAP Max8 10 Gb Lan * Blackmagic Pocket 6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED (H7600, 12th Gen Intel) with internal HDR preview on the laptop monitor

bruceo wrote on 9/12/2007, 3:14 PM
Yep the 1 miute render I sent was randomly picked off a raw timeline and in 1 minute had 3 of these types of errors. I am also starting to find more anomalies in regular renders (not Smart rendered) as well as black frames that I will not comment on until I do some more testing..... But as far as the smart rendering of HDV with as many repros among different configurations I have already seen i would be shocked to hear of someone doing a clean HDV render and if this other issue I'm working on now doesn't resolve then V8 will be currently worthless for HDV.....
Wolfgang S. wrote on 9/12/2007, 3:23 PM
No, I do not think that it is worthless, even if I do not know what else you see there. At least for that error shown in my picture in the link above there is a working repro now, what is the base to fix that.

Deactivate at the moment the smart rendering capabilities in the project setting, as written above. Then the rendering results seems to be clean, as far as I see up to now (but as said, I do now know what else your refer to).

But be aware that you cannot go back from a Vegas 8 project file to a Vegas 7 project file. So, for time critical work I would take that into account at the moment.

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti * Blackmagic Extreme 4K 12G * Atomos Sumo * QNAP Max8 10 Gb Lan * Blackmagic Pocket 6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED (H7600, 12th Gen Intel) with internal HDR preview on the laptop monitor

MarkFoley wrote on 9/12/2007, 3:24 PM
What happened with beta testing I wonder....
winrockpost wrote on 9/12/2007, 3:57 PM
... public beta is the way to go , dont blame the testers, just not enough of them., all software has bugs and a public beta will catch a lot more than a private one.
bruceo wrote on 9/12/2007, 4:09 PM
"No, I do not think that it is worthless, even if I do not know what else you see there. At least for that error there seems to be a repro now, that should Sony allow to fix that.

Deactivate at the moment the smart rendering capabilities in the project setting, as written above. Then the rendering results seems to be clean, as far as I see up to now (but as said, I do now know what else your refer to).
"

V7e was worthless because it would crash on certain "error" frames and a significant number of peak building erros occured. I just tested a known section with the freezing on "error" frame and peak building and both seem resolved, so everyting was looking good, smart render is definitely fubar and I am still testing long form render to verify is my probllem is an anomale or a V8 reproduceable error. I will know in about 2 more hours or so...
DJPadre wrote on 9/12/2007, 4:31 PM
it wouldnt surprise me if this was also seen in beta..

one other thing to note is that the issues your seeing (as they look like DV dropouts, not HDV dropouts.. HDV dropouts are black, not glitchy like DV <or whats described here> ) is drive fragmentation...
Wolfgang S. wrote on 9/12/2007, 4:59 PM
"V7e was worthless because it would crash on certain "error" frames and a significant number of peak building erros occured."

Well, I have performed a lot of HDV projects based on V7e, and that worked fine for me. We should not forget that m2t files are not the perfect format for editing - there was a time where we have seen even mpeg2-PS as a deliverable format, but not as a editing format. And HDV is a consumer format, but not a professional acquisition format. If somebody needs professional features, maybe he should rethink the use of a consumer format.

The question, how the NLE works with corrupted m2t files, is a releant one - for sure. Some errors like the peak building error was resolved long time ago, as far as I remember, other errors still exist. The issue is also, that you always need the material to be able to generate a repro.

And in terms of beta testing - people who do that, do that on a voluntary base, and it is a lot of work. It is not my job to assess and to judge that system, or to defend it. But I think that the price of the software would be higher, if you imply the quality criteria as used in other industries - like the pharma industry, where you have significant processes in terms of quality management, and organisations like the FDA that must be funded too. Maybe not the best comparison, but economy matters - and if that does not work out, we would not see a further development of the software at all.

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti * Blackmagic Extreme 4K 12G * Atomos Sumo * QNAP Max8 10 Gb Lan * Blackmagic Pocket 6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED (H7600, 12th Gen Intel) with internal HDR preview on the laptop monitor

Cheesehole wrote on 9/13/2007, 2:56 PM
I rendered a 4 minute HDV clip using Smart Render. Didn't see any glitches.

Then I cut up the clip randomly and mixed up the segments - just cuts, no transitions, and rendered it out. At one of the transition points blocks appear all over the image for a few frames.

I have to agree it seems like a major problem. It happened on my second render and it isn't hard to see. I'm using Vegas Pro 8 Trial with HDV video and preset templates. Q6600 / XP 64 / 4GB
bruceo wrote on 9/13/2007, 5:12 PM
"HDV is a consumer format, but not a professional acquisition format. If somebody needs professional features, maybe he should rethink the use of a consumer format."

Then maybe sony needs to stop advertising all of their "professional HDV" cameras?

So far th anomalie that ocurd on the first recompress render did not reappear so apparently a 2 hour project that V7e would not render and would freeze up on certain frames V8 was able to easily edit and render it as long as smart render was off.
wwaag wrote on 9/13/2007, 8:52 PM
"Then I cut up the clip randomly and mixed up the segments - just cuts, no transitions, and rendered it out. At one of the transition points blocks appear all over the image for a few frames."

I've experienced the very same problem with Premiere Elements using the Mainconcept "smart-render" plug-in. After repeated complaints to Mainconcept, they acknowledged the problem, but to date, no "fix" has appeared. I finally gave up.

If Sony simply "licensed" their smart-rendering from MC, this may explain the problem. Anyone know??? In any case, it's a real "show-stopper".

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia 1050ti graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

4eyes wrote on 9/13/2007, 10:53 PM
The setting to smart render long GOP footage is on by default. I think it should be off by default.
Smart-render will usually cause a problem if performing other then simple cuts, splice & joins.

Smart rendering mpeg is famous for also causing audio sync issues.

Wolfgang S. wrote on 9/14/2007, 1:37 AM
> Then maybe sony needs to stop advertising all of their "professional
> HDV" cameras?

Well, that is up to Sony - and also JVC runs it professional serie for the JVC HD100/200. But the format HDV was designed as a consumer HD format, the data rate is lower, and there is no protection against droped frames during recording to the mini-DV-tape. Understand me right: if HDV is fine for you, great. But for sure, professional acquisition formats use other ways for compression and recording.

> a 2 hour project that V7e would not render and would freeze up on
> certain frames V8 was able to easily edit and render it as long as
> smart render was off.

Yes, I have also seen that Vegas 8 has be become more robust, in handling and rendering also some defect m2t material. And for the smart rendering option - I am sure that we will see an update, where this bug will be corrected.

> Smart-render will usually cause a problem if performing other then
> simple cuts, splice & joins.
> Smart rendering mpeg is famous for also causing audio sync issues.

Have you seen that in Vegas 8? Or are that comments from your experience with other tools? Because then it must not be true for Vegas 8!

And if you do not like smart-rendering at all - fine. It is up to every use to deactivate that optionin. Frankly spoken, I intend to use that in a way, where I utilize smart rendering for first drafts - and deactivate that for the final product. Even if I do not see a difference when reviewing smartrendered material, versus the original HDV footage (beside the actual error as discussed here).

Desktop: PC AMD 3960X, 24x3,8 Mhz * GTX 3080 Ti * Blackmagic Extreme 4K 12G * Atomos Sumo * QNAP Max8 10 Gb Lan * Blackmagic Pocket 6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED (H7600, 12th Gen Intel) with internal HDR preview on the laptop monitor

bsuratt wrote on 9/14/2007, 4:31 AM
This problem has been thprtoughly discussed in the forums of other products which suffer the same bug. It appears that when cuts are made on other than I-Frames in HDV video the SmartRender will often produce a glitch. In my tests with Vegas 8 most of my crossfade transistions are flawless. But some suffer from a "blip" which may precede or come after the transistion. There is one product that gets it right by allowing you to set the trimmer window to display only I-Frames and thus you can readily cut only on those frames. This works flawlessly in that product.

If you cut your events on I-Frames in an editor which permits that and then bring into Vegas, it will probably work fine. (Too much additional work though.)

Vegas mentions frame-accurate editing but I do not understand exactly what they are referring to in the trimmer window since they are not displaying any frame type data.

I had waited all summer for this upgrade hoping that Vegas would get it right. Well, not quite yet!