HDV Black Frames hardware dependent?

Comments

riredale wrote on 6/17/2007, 10:50 AM
Serena, try the HDV RenderTest. I found that with ram preview set to 0, only one core would run, but with any other value for ram preview then both cores would operate, essentially halving the render time. Since someone else has recently pointed this out, I'd be very interested in whether your system exhibits a different behavior.
riredale wrote on 6/17/2007, 10:54 AM
Peter:

If you're in the market for yet another html builder, I'd recommend SiteSpinner. It's not free, but it's cheap and there is a free trial. Working with it is like working with Powerpoint from the standpoint of building a page with text and graphics.
Serena wrote on 6/17/2007, 8:02 PM
>>>I'd be very interested in whether your system exhibits a different behavior.<<<

Riredale, OK. Ran the render test with RAM preview=0 and both cores shared the work about equally.
riredale wrote on 6/17/2007, 11:03 PM
Yes, but were they both working at 100%, as shown on the Performance tab of Windows Task Manager? With 0 ram on my system, both were working at 50%, I recall.
Serena wrote on 6/17/2007, 11:12 PM
Ah, I misunderstood your report as saying only one was working. Agree, both cores work at 100% if set RAM preview to 1, and at about 60% if set to 0. Does make quite a difference to the render time. I checked using the AMD power manager rather than the task manager.
Serena wrote on 6/18/2007, 5:29 PM
Just was rendering to a new track (HDV 1080 50i intermediate) and RAM setting (0/1) made no difference to CPU usage. Rendering to mpeg-2 it does make the difference observed by riredale.
Laurence wrote on 6/19/2007, 9:14 PM
Just to answer two questions about the 2 black frame bug.

1/ Yes I get it with my single core system.

2/ No I never see the 2 black frame bug with Cineform. Only m2t.
John_Cline wrote on 6/19/2007, 9:30 PM
Just moments ago, I saw the infamous 2 black frame bug on some footage that I had transcoded from M2T to Cineform. I'm with the rest of you, this bug needs to be squashed as soon as possible. It's getting tiresome.

John
Serena wrote on 6/19/2007, 10:14 PM
A difficulty is in the apparently intermittent nature of the black frames. My observations are restricted to working with cineform intermediates, although a few months back I cut a 90 minute project in m2t without encountering the "black frame". No question it needs to be fixed, but this is looking like a "dry solder joint". I guess many specific examples need to be sent to Sony Support.
Laurence wrote on 6/19/2007, 10:27 PM
John, did you transcode from Vegas? My guess is that it was at the "Vegas reading m2t" part of the process that you got your two black frames. That's one of the advantages to using HDLink.

Having said that, I am currently working on my laptop. Because my Neo HDV license only covers one computer, I am using Gearshift to generate the Cineform clips. Doing it this way is fine except that you have to go through all the converted clips looking for black frames. I have about two hours worth of footage so that is a real pain. Yeah this bug needs to be fixed!
Serena wrote on 6/19/2007, 11:40 PM
In view of Laurence's comment, perhaps I should add that the project I cut in m2t was captured with HDLink (not Vegas).
farss wrote on 6/19/2007, 11:57 PM
I don't think this is anywhere near as intermittent as the old random black frame problem. Peter Wright's clip that several of us downloaded produced the problem quite reliably.
It would be nice to get some feedback from Sony, even an admission of the issue would be a start. I don't think a sticky of known issues would be too much to ask. Other software vendors can manage this and it's one of the first things many look for when evaluating a product.

Bob.
John_Cline wrote on 6/20/2007, 12:30 AM
Laurence,

Yes, I captured from tape in Vegas and transcoded to a Cineform intermediate from Vegas.

You know, as much as I like HDV, its long-GOP MPEG2 compression is amazingly "delicate." Regardless of the black frame issue, one render pass and it just visually falls apart to an unaccptable degree. HDV straight off tape looks quite decent, but the final render out of Vegas takes a noticable quality hit. Even if Vegas had MPEG2 smart-rendering, anything that has been modified from its original form will be recompressed and, quite simply, it just doesn't look good enough.

Most of what I do is either shot in the studio or at a fixed position indoors on location. I'm moments away from buying a Blackmagic Intensity Pro card and building a small form factor PC to record the live HDMI output from my V1u and bypass HDV compression altogether. From what I've gathered from Blackmagic, I'll have to capture outside of Vegas, but I should be able to use Vegas to edit the files. I asked about plans to integrate the Intensity Pro into Vegas so I can use the HDMI or HD component analog outputs for preview from within Vegas and they said that the ball was pretty much in Sony's court on that one. They implied that Sony hasn't been cooperating to the extent that they need. I suppose I could capture with Cineform's NEO HDV, it supports the Intensity Pro. I guess I could also use Premiere as it's fully supported by the Intensity drivers, but I'd rather insert a sharp stick in my eye. Anyway, I need a better solution to maintain the V1u's basically decent image quality throughout the edit process. Maybe 35mbps XDCAM EX will be more robust.

John
farss wrote on 6/20/2007, 1:27 AM
Interesting,
from what I've seen really good footage footage from the V1 seems to hold up very well even after a couple of re-encodes. I tried this with locked off shots of fast moving vehicles and couldn't see any loss at full res.
Conversely some other far from optimal footage seemed to go downhill very fast when re-encoded. The V1 does seem to want a LOT of light to perform well and I think the trap is (as with any HDV camera) that less than pristine footage will suffer from re-encoding.
I have to admit though, this is different to DV.
Also good to keep in mind that no matter how you capture mpeg-2 compression at some stage is almost inevitable.

Bob.
John_Cline wrote on 6/20/2007, 2:39 AM
Bob,

Generally, HDV looks good and most stuff will re-encode reasonably well. However, the other night, I had a chance to do some "non-commercial" recording by taping my niece's dance recital. It was held at a theater here in Albuquerque and was lit very well. I ended up at zero gain at f4 on my V1u. The backdrop was white cloth with a wash of moderately bright, not-too-saturated magenta light. It had a lot of subtle shading differences and when viewing the tape output of the V1u on my CRT HD monitor, the color gradients looked quite smooth, the dancers were well exposed and there was no visible noise in the image. No color correction was necessary, so I edited her six dances out of the show with simple fades and rendered it out of Vegas. When viewing the resulting M2T file, the subtle background gradients were suddenly full of false contouring and blocky false contouring at that. I also wrote the file back out to tape so I could use the same V1u hardware decoder and component connection that I had used to view the original footage. The detail and textures survived the encoding, but the background took a major hit. My brother, who also does a lot of high-end broadcast HD work and had previously been impressed with the little V1u, walked into my edit suite, looked at the rendered product and remarked, "man, that looks like crap!" HDV MPEG2 just doesn't handle re-encoding large areas of solid color with subtle gradients.

It could be that the Main Concept MPEG2 encoder in Vegas is at fault, so I'm going to render this out uncompressed and encode it to .M2T using a few other MPEG2 encoders to see if they do any better. Since it may also be a Vegas/Main Concept decoding issue, I'm going to do a complete decode/re-encode pass outside of Vegas using some other MPEG2 encoders as well.

I've had always thought of MPEG2 as an end-user delivery format, not an acquisition format, but I thought that 25mbps MPEG2 might not be too bad, so I got the V1u. I wasn't expecting pristine HD video from a $4,000 camcorder but, up until this particular shoot, I had been basically satisfied. Perhaps I still haven't totally changed my mind about MPEG2 being an exclusively end-user delivery format.

Just so I won't have totally hijacked this thread with my problem, it was also this shoot that I finally had a consistent problem with the two-black-frame issue.

John
Xander wrote on 6/20/2007, 3:23 AM
I have seen this once. Looked like more than two frames to me. Closed project and reopened. Black frames gone. Pentium 840 D, 2GB RAM, Win XP Pro SP2, ATI X850, latest updates on everything. Dynamic RAM 512. I haven't spent hours editing, so can't say how often it happens. Next project is all HDV, HDR-FX1. Have captured through Vegas and use Sony HD tapes. Will update with anything I notice.
Serena wrote on 6/20/2007, 4:45 AM
John,

It would be interesting to repeat using NEO HDV. One of the benefits is reducing that blockiness of colour rendition and the render out should be better. You can use a free trial, so no cost involved.
farss wrote on 6/20/2007, 5:02 AM
Don't want to hijack this thread too much but I have a suspicion what you're seeing is not due entirely to the HDV re-encoding. Try looking closely at the original footage at Best / Full on the Vegas T/L in the areas where you saw the problems after encoding.

Bob.

FuTz wrote on 6/20/2007, 5:25 AM
I don't know but maybe a massive notice to the bugs department , apart from -numerous- complaints on this forum ? Just in case they didn't have a look here since v.6 ?
John_Cline wrote on 6/20/2007, 12:29 PM
Just tried rendering my project uncompressed out of Vegas and using Procoder to encode the HDV M2T. It looks massively better than the Vegas MPEG2 encode. No blockiness and just a hint of banding. I've always thought that Procoder produces the best looking MPEG2 renders and this further confirms it.

Next, I'm going to take the Vegas Main Concept MPEG2 encoder out of the equation altogether. I'll use Procoder to convert the raw .M2T captures to uncompressed .AVI and use this .AVI to edit in Vegas, then render uncompressed and use Procoder to do the final .M2T encode. From a time and disk space standpoint, this is an impractical solution for everyday use, but will probably produce the highest quality results.

I did download the NEO HDV trial and I'll experiment with it later.

John
Laurence wrote on 6/20/2007, 12:51 PM
How fast is an Procoder HD mpeg2 encode compared to a Vegas encode?

Will Procoder accept a Cineform codec AVI as it's input?
John_Cline wrote on 6/20/2007, 2:16 PM
Procoder has four levels of quality, each of which affects render speed vs. quality. In Procoder's "Highest Quality" mode, which is actually one level below ultimate "Mastering Quality", Procoder and Vegas render at virtually the same speed. I always use "Mastering Quality", which performs all encoding optimizations to produce the absolute best quality without regard to encoding speed. This setting increases Procoder's render times by an average of about 20% over the "Highest Quality" setting.

Yes, it will accept a Cineform .AVI.

John
john-beale wrote on 6/21/2007, 9:31 PM
I just saw the 2-black-frames in a HDV timeline again. I went to Options/Preferences/Video tab/Dynamic RAM Preview max and set it to 0 (had been 511, out of max available 1024 MB. The black frames were immediately gone, without even restarting Vegas. I set it back to 511 MB and the black frames were still gone. Mysterious. I'm using Vegas 7.0e on a Pentium 4. I have 2 GB DRAM.
PeterWright wrote on 6/21/2007, 10:17 PM
Yes, that's been my experience too since Bob discovered this. If, however you put the RAM back up to 511 then close and reopen the project, you may find the rogue frames have returned.