An idea....

There is a suspicion that this problem is releated to Sony using it's own codec/parser to read MPEG transport stream files (the .m2t, .ts etc files).

Having recently got fed up with VP8's inability to properly handle transport stream files other than direct-from-capture HDV files, I've started converting them to MPEG 'program stream' files using VideoRedo - free trial from [url=http://www.videoredo.com/en/ProductTVS.htm]. The conversion is a fast lossless re-muxing operation, but it also fixes any errors it finds - just open the .m2t file in VideoRedo, select the entire file and save as a new program stream format file.

Vegas opens 'program stream' files using the MainConcept codec rather than the Sony one which may be more robust....(but it is slower when scrubbing around the timeline etc)

I've only just started editing HDV and I haven't seen the red/black frame problem to date, so I don't know if the above suggestion will help but it's probably worth a try...

Tony

"Has ANYBODY gotten an official word from Sony on this problem? "
I believe someone from here did extract an admission that they're aware of the problems. It'd be nice to see that as a sticky.

"Is there anything that can be done short of wasting my time going through the useless Sony problem report channel? "

Using the phone seems to be the most effective means.
If you don't get satisfactory answers escalate the issue. Find out peoples names and write to them. Always be calm, polite and sincere, avoid threats, pointless really, no one cares about loosing one custumer unless you're big enough to play golf with the CEO.
I can vouch that the few times I've ever been told to drop everything and don't sleep until an issue was respolved was when the CEO got a letter from an unhappy customer. Keeping your cool prevents them from dismissing you as another nutter who shouldn't be taken seriously.

Bob.

I did get a request from someone at Sony to email a sample M2t with red frames/audio dropout after I complained about the problem. So - a day later - I booted the same computer and opened the shortest M2t that had given me grief a couple of days before. Lo and behold, all the frames were flawless and rended out with several codecs without a hitch.

When I told Sony, they mentioned that it was the ephemeral nature of the beast that was making it so hard for them to solve the problem. In any case, I now never render to M2t - only to Cineform or - if I really want superb quality for the sake of the high-rez stills that I might be including - to PicVideo's MJPEG Pegasus (but rarely do I see enough improvement to warrant the larger file size and slower rendering speed).

Unfortunately, the filesize of Cineform is larger than the M2t filesize, but with 1 TB disks going for $170, the issue of filesize no longer is all that significant.

Incidentally, someone once claimed that the captures from HDVsplit were more likely to render out with red frames than were captures with the Vegas capture utility. I haven't tested that hypothesis, for my main computer for some reason has never let me capture from Vegas - I can only capture with HDVsplit (ironically, my old P4 would never capture with HDVsplit - only with Vegas! ah, the thrills of modern computing . . .)

I have used both HDVSplit and Vegas extensively for capture. I can't see any difference at all. Honestly, I don't think it matters whatsoever who created the m2t. I think the m2t files are completely clean in all cases. The reason I believe this is that ALL files that have red-framed in Vegas that I've tried to load into another NLE or even Windows Media Player have played flawlessly, even those rendered out by Vegas that red-frame when I bring them back into Vegas will play clean on any other product.

To me it appears the problem is with the engine in Vegas that is reading and interpreting m2t files. And random, non-repeatable problems like this usually end up being a simple coding problem where an internal pointer in the code is getting messed up. And the randomness is due to whatever was or was not loaded prior to the clip or what else had been done in vegas prior to loading the clip.

I'm very amused by your statement that Sony asked you to send them a failing file. It blows my mind that no one inside Sony is using their own product enough to have actually ever seen this problem. I see it 10 times a day, every day. And again, it's not the file that is failing. I suspect I could make any m2t file I have fail sooner or later.

Does anyone else get complete vegas crashes when you play a red frame? It doesn't always crash for me. But it has many times in the past. (and I've lost a lot of work several times as a result). I'll capture the exception info the next time it crashes and post that info for Sony here. Whoever is investigating this problem for Sony should be able to get a good start in figuring out what is going on from the crash info.

Just out of curiosity.... I want to do a poll... for those of you who are seeing this problem, what brand/model video card do you have? And does it have a GPU? And if anyone is reading this thread that has NEVER seen a red frame on HD m2t, post your video card as well. Let's do Sony's job for them and see if there is some correlation thread between video card and GPU with the red frame problem.

I'll start... I have a NVIDIA Quadro FX 1500. It does have a GPU.

Also, an open letter to Sony... I have 31 years as a software architect and software problem debugger for a major computer company. I'm willing to sign an NDA and get a debug copy of Vegas and find this problem. Just contact me.

"Does it have a GPU?"

Are there graphics cards that don't have graphics processors?

Anyway, not running HD with Vegas so I've never seen a red frame related to that. The only time I've seen a red frame was with a still image that was just too large-pixelwise. I was trying to get a red frame.

Black frames used to be there even with DV. I can't prove it but I've long suspected this to be related to the way Vegas caches frame data in RAM, or perhaps how Vegas uses memory in general.

I'm also wondering if some of the problems that seem most common on Intel Quads are really related to how Vegas interacts with memory. Perhaps the Intel Quads expose it more.

Rob

Hi 2G and everyone ...

Man, it would be awesome if you could have a look at the code in Vegas and try and sort it out!

I'm getting all the errors, red frames, black frames, exception errors, not able to render errors with a very polite 'sorry for the inconvenience' message etc.

I've already done my dash with Sony because I broke Bob's rule and wrote a very rude email which used the F word probably about 20 times ... so I've been dismissed as a nutter already. I think Sony are
in big trouble at the moment ... where's 64 bit Vegas due last year? Where's 8.0c - due mid June? Whatever ...

If you can fix it man I'll kick the tin to help you do it.

I'm running the following system.

Cheers and good luck,

Darren Powell
Sydney Australia

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


Motherboard:
CPU Type QuadCore Intel Core 2 Extreme QX6700, 2666 MHz (10 x 267)
Motherboard Name Intel Bad Axe 2 D975XBX2 (2 PCI, 3 PCI-E x16, 4 DDR2 DIMM, Audio, Gigabit LAN)
Motherboard Chipset Intel Glenwood-DG i975X
System Memory 3328 MB (DDR2-667 DDR2 SDRAM)
BIOS Type Intel (12/13/07)
Communication Port Communications Port (COM1)
Communication Port Standard Serial over Bluetooth link (COM2)
Communication Port Standard Serial over Bluetooth link (COM31)
Communication Port ECP Printer Port (LPT1)

Display:
Video Adapter NVIDIA GeForce 7900 GS (256 MB)
3D Accelerator nVIDIA GeForce 7900 GS

Partitions:
C: (NTFS) 238464 MB (178781 MB free)
D: (NTFS) 1430796 MB (1061079 MB free)
F: (NTFS) 715229 MB (239187 MB free)
G: (NTFS) 953867 MB (617780 MB free)
I: (NTFS) 239359 MB (16770 MB free)
K: (NTFS) 476937 MB (122921 MB free)
L: (NTFS) 476937 MB (35877 MB free)
O: (NTFS) 152625 MB (75445 MB free)
Total Size 4574.4 GB (2292.8 GB free)

DMI:
DMI BIOS Vendor Intel Corp.
DMI BIOS Version BX97520J.86A.2809.2007.1213.0017
DMI System Manufacturer
DMI System Product
DMI System Version
DMI System Serial Number
DMI System UUID 5411D338-30B711DC-8FA6000E-A68F75B9
DMI Motherboard Manufacturer Intel Corporation
DMI Motherboard Product D975XBX2
DMI Motherboard Version AAD53350-507
DMI Motherboard Serial Number BQB2728000PZ

I run a quadrofx 1500. I've yet to see a red or black frame but I only use direct capture HDV on the timeline. Seems like that hasn't been a problem for anyone. Or has it?

64-bit due last year? I thought they said they'd release it to beta last fall but that's hardly a promise of a public release.

Anyway, yes it'd be great to get this business fixed.

rob

i've only seen a red frame on a file that I knew was bad. Since I got my HD cam I've done ~10 hours of HD footage & no glitches in playback, edit or render. The *ONLY* time I got a black frame in DV was in a thread where I said "I've never seen one before" & then later that day I had one. That's it though.

but for reference:
AMD Phenon 9600
ATI 3850 512

old systems (never a black frame on those, except that once):

Intel P3 667, 256mb DDR, ATI 8500 LE
AMD XP 1800, 256 DDR, ATI 8500 LE
AMD 64 3000, 512 DDR, ATI 8500 LE, ATI x1950 Pro
AMD X2 4200, 512 DDR, ATI x1950 Pro (had that CPU for ~1 or 2 months, didn't test much)

should be noted that I do *NOT* get the good, epensive RAM. I don't get the good, expensive PSU's (until recently). The memory in the first 3 listed was all the same sticks too. In the Sony Support thread it was mentioned that intel CPU's seem to be in the specs for more people. 2G, your specs are empty. Wanna fill them?

I've eliminated my 'common hardware' theory. I was seriously thinking it might have something to do with the quad core processor as was mentioned. But I'm pretty sure that's not the problem. I also have pretty much proven my "it isn't the m2t file that's bad" theory.

I hit the following situation tonight... I had a m2t media file that was about 30-40 minutes long. It played fine and did not have any red frames that I saw. I needed to extract a 5-second audio clip and paste it into a new project. The audio (and video) from the clip plays fine in the original project. But when I copy 5-sec audio clip to a new project, the first couple of seconds is silent and the audio pops on halfway through. VERY consistently reproduced so far. And it's a 5 sec project (with 30 min m2t media file). The fact that the clip plays fine in one project and a copy/paste of the clip into another project will not play pretty much vindicates the media file. I've seen three symptoms of this problem so far, sometimes individually, sometimes together a) red frames; 2) sound plays but visual audio waveforms flatline 3) audio waveforms are fine and show audio present, but audio drops out and goes silent. My current failing test case is symptom 3.

So I figured while I had a reproducable failing test case, I'd try some things. I temporarily installed Vegas on an old clunker (AMD something... circa 2002). It's painfully slow. But after I installed it, I brought up the 5 sec project, saved on my main machine and got IDENTICAL results. So we are getting the failure on a super old, single core, clunker. I think I'm pretty much at the two ends of the spectrum with my quad core and the clunker, and it fails the same on both. So I doubt it is hardware related.

BTW... regarding whether all graphics card have a GPU... not really. At least they don't have one that is accessible by applications to offload graphics rendering. The higher end cards allow programs to hand off basic commands to the GPU, and the GPU will do the crunching. With cheaper cards, the main CPU has to do the crunching, and the main CPU simply tells the card where to put the pixels and what colors to use. A slight over-simplification. But try rendering Magic Bullet Movie Looks on a cheap graphics card that doesn't support GPU processing by the plugin. A 17 minute video took 24 hours to render for me. On the same computer when I replaced the graphics card with the one I have now and told Magic Bullet to use the GPU, 24 hours dropped to 40 minutes for render.

Back to the main topic... if you can get back in touch with the Sony person that wanted a failing test case, perhaps I can burn the media file and the veg to a DVD and mail it to him/her assuming I can keep it consistently failing.

Hopefully, we can get some attention on this. In the meantime, I've now got to read that m2t into Audition and render it back out as a WAV so I get my stinking 2 seconds of audio. I'm not using the F word yet... But it's tempting...

Thanks for all the discussion on this....

never seen red or black frames, amd, core2duo, mobile intel before core2duo ( whatever they called it ), various nVidia cards over the years.

You may want to look into anti virus software and internet connections running on those pcs with problems. I never run any of those on whatever the main machine or machines happen to be at that particular time, and there is a big overall difference in responsiveness. It is possible that AV screws up something on some machines during capture. After all it is constantly checking everything and meddling where sometimes it should not be.

It would be rather interesting that a virus targeted Vegas Video ONLY and then ONLY HighDef .m2t file playback at random times inside Vegas. And it would be even more interesting that this one obscure virus happened to be on two of my machines, both with completely current anti-virus and anti-spyware software running. And if it is the antivirus software itself that is messing up Vegas, in my opinion that is still Sony's fault and Sony's problem to fix, considering all of the other apps that play the clip just fine on those same computers were smart enough to write code that wouldn't be affected by it.

No one claimed your problem was a virus so there's no need to go off the deep end about that. The suggestion was the antivirus software. As it turns out you say you use the same one on both machines.

There's been some conjecture that antivirus software interferes with captures of HDV in Vegas so I'd think that to test it out you'd want to get rid of the antivirus software on one machine and then make a new test capture.

Sometimes the real common factor seems like it might just boil down to the user. We often set up multiple machines in the same way. For example, I use AVG and ZoneAlarm on all my windows machines so if there was a problem with one of them I'd spread that problem to every machine.

But you're right to assume that Vegas should run just fine in the same environment a competing program can run in. In the end, what you find on the forum is people with similar problems and others without the problem. The fact that some don't have the problem suggests some sort of hardware or software interaction that Vegas is exposing while other applications don't. SCS sells Vegas as not needing a special environment, so they need to fix the problem.

Rob

Spot has stated that he never has had the problems with black frames, etc. He has also stated that he never runs AV software.

Q6600 on Asus P5B, Asus 7600GT (nVidia 7600GT chip; GPU:yes). I do get red frames, usually with audio dropout ONLY WHEN I RENDER TO M2T, not on captures; and did with the Core2Duo that I used before the quad core.

I cut-and-paste from time-to-time, recently with very long sequences w/lots of effects, but never once have had a problem.

I almost never have seen Vegas crash on this MB or my previous Intel MBwP4@3gHz. Years ago I decided that I was getting crashes on an old computer because of the cheap power supply; since then I've been buying power supplies that cost 4 or 5 times as much as the cheapest that would supply the needed power; perhaps their superior regulation and filtering has help prevent crashes.

I'm pretty sure that I got red frames before I started using AV software (AVG w/Zone alarm, but now AVAST w/Comodo - and Threatfire).

I remember the previous thread where AV software was suspected, and I'm fairly sure (but not certain) that I once performed a test to close down all such protection after unplugging my DSL line to see if I still got red frames; I'm pretty sure I did - hence my current strategy of using only Cineform or other codec for rendering.

I was a mainframe coder for 15 years with systems used by thousands of people. Most likely I have written, debugged, tested and designed more programs that just about anyone else on this forum. I can tell you that some bugs never get solved and others might take years to resolve. It isn't a matter of not caring. I can also tell you how insulting it is to start attacking the coders of Vegas..both to them and to me. Vegas has to run in thousands of scenarios of software and hardware mix and does a great job. Good coders take their jobs very seriously.

Why not do a test and shut down connection to the internet and shut down AV and other running software and redo one of your projects (capture to render) and see what happens. That is a controlled test. Perhaps you will see something new and perhaps you won't. If I did HD that is exactly what I would do if I were having problems. Since I only do standard def I never have a problem with Vegas (except for an occasional glitch that I recover from via restart).

Yeah, a message of hope. It's possible to run without blackframes and redframes (two entirely different things IMO)

The problems are that SCS doesn't really say "You must not run AV with Vegas", they market the program as being able to run on a wide variety of consumer level hardware, and competing products fare better in this regard. So either they need to better manage their customer's expectations or they need to make sure the program meets the design requirements they've set.

Rob

I'm skeptical of the AV culprit but I can't write it off.

One problem with forum users trying to figure this out by playing "30 questions" is that we largely just come up with fairly simple procedural ideas. I'm guessing that at least some of these problems are fairly deep in the way Vegas is addressing memory, and probably too esoteric to really be figured out on this forum.

Example: We use a SAN for our media at work and have had long running trouble with it not being present for some systems when they boot. The solution of the day is just too esoteric and in the end it just took a lucky break of getting the right person at the integrator talking to the right person at Rorke and framing the question in just the right way.

Example: I had long running problems with Dreamweaver because our static site was bigger than they had ever imagined a reasonable person would put up with (The project management is an immovable object that has yet to meet a force it couldn't resist). Turned out that our project was big enough to make a few bugs visible. For a regular project Dreamweaver would just do it's job too quickly to ever notice a problem. (essentially it was running a task twice instead of just once). In the end the solution came from my filing a support request just as the project manager and programmers were deciding they needed to work directly with customers to squash bugs.

Is SCS in denial? Based on my experience with the overgrown static site I work on, I can see a lot of ways for denial to work into a project. An application grows over time, gains features, and really needs a bigger team to work on and maintain the parts. And now you've got enough parts that you can easily break one thing as you develop another. Eventually, as years pass, you find that the design assumptions of 8 years ago are getting you into trouble now but no one wants to suggest rebuilding things from scratch.

Adobe was really brave to rebuild PPro and yet I think they're already painting themselves into corners. Imagine how boxed in Vegas must be! I'm really hoping that this 64-bit effort has also been an opportunity for people at SCS to fix and redesign things that just don't work well anymore.

Rob Mack

Just to add to your comments Rob, a coder might want to spend the time working on something but management has other priorities (right or wrong). I have seen lots of that in my life time. It would be nice to see the 64bit version do some redesign. I was thinking that was possible last year when they announced it. Fingers crossed.

Agreed.

But I don't really want to be an SCS apologist. Some people rely on Vegas for a paycheck and SCS needs to make sure they're taken care of.

Rob

Harold, I'll see your 15 years as a mainframe coder and raise you 16 more. I am a Senior Software Engineer and just left a 12-person worldwide support team for a product I helped write for one of the largest computer companies in the world. I am not attacking the coders. Coders are human. Mistakes happen. Bugs happen. But we take bugs seriously where I work. If several of our corporate customers had reported the same problem over the course of two years, and my answer was "it doesn't happen to everyone, and it works on my machine so just get over it", or if the answer was "just disconnect from the internet and turn off all your security protection", our CEO would be getting a call from the customers I deal with and the threats they would be making would not be idle threats. Again, I'm not attacking the coders. But I am attacking Sony management's apparent lack of interest and/or corporate policy in dealing with problems like this.

I agree that forums are just a bunch of users trying to make the best of a situation. But forums 'should' be used for exchanging ideas, not corporately attempting to debug a software problem that has been reported for a couple of years by multiple users.

Whether it's the antivirus program I use or the brand of deodorant that I use that's causing this, Vegas Video is the ONLY program that is having this problem and it's happening to a large enough sampling of Vegas users that Sony management ought to at least show a few ounces of concern and help US figure it out or at LEAST recommending workarounds so we won't be losing money and reputation on missed deadlines.

I have built my video production business around Vegas. I don't have the time to move to anything else right now. But I'm often losing days on promised delivery dates because I can't render my videos without having dropped audio or blackouts. In my company, that's called "customer down" and we take it seriously.

I'm willing to help debug this. How do I get Sony to work with me? I would be happy if a Sony support person would simply respond on this forum and work with those of us who are willing to research and debug this problem and figure out what is happening. And I'm sure there are problems that never get fixed. But those are problems that don't recur often. In 31 years of software development, I've never encountered a regularly recurring problem that I couldn't resolve, given the right resources and information from the developer (and I've fixed thousands of bugs).

Sony -- please respond and help us. We're tired of shooting in the dark on this.

>> a coder might want to spend the time working on something but management has other priorities

In my company we have coders and management. And we also have a separate group of people called CUSTOMER SUPPORT whose sole job is to solve existing customer problems on existing shipped products. Coders can be off working on the next release of whatever and management can have their strategies and directions. But customer support is supposed to support customers. That's what I think is missing with this problem.

I would love to start a dialog with a customer support person on this problem. But as I mentioned earlier, the last two problems I filed a formal report on (I was professional in the problem definition and not at all belligerent), it took 2 weeks to get a note from an autoresponder, and I never could talk to anyone in person about the problem. They simply wouldn't respond. This is what I'm talking about lack of concern by management. I've got a legitmate "non-pilot error" problem with a purchased product. Their problem resolution process is BROKEN, and I currently see no recourse. That's why I'm frustrated.