Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Avid DNxHD codec garbage

Chris Swinbanks

Well-known member
Joined
Aug 16, 2007
Messages
282
Reaction score
0
Points
0
Location
Sydney
Website
www.animallogic.com
Playing with v3.08 Redcine (PC version), I seem to get garbage (ie totally screwed up pixelated mashed unrecognisable image) when rendering a QT with Avid DNxHD codec (from a Cam Bld 15 clip)?
All other codecs supplied as standard in this build seem to be OK, apart from the usual "washed out" look of H.264. I have no problem playing back DNxHD codecs generated from other sources.
Anyone else seen this?
 
What resolution are you rendering to? DNxHD is an HD only codec. Try rendering to a standard HD format.
 
That would seem a sensible thing to do... :biggrin: ...


Ok, tried changing a few variables, such as project format (back to 4k) and output to either 1080P and 720P, same problem...

any other bright ideas before I start posting more info about systems etc?
 
DNxHD error also on a Macbook

DNxHD error also on a Macbook

...same results doing it on a macbook pro, Redcine 3.08, on a build 15 clip (different clip, same garbled result).
Corrupted image ONLY with QT DNxHD render, the other codecs seem to be OK.

Anyone else see a similar thing?
 
I finally got it t work with RedCine build 108. 1080P. Downloaded the clip and don't recall which build made it. It did play OK in QT, then Avid imported it pretty quickly. Once in Avid, color correction uncovered a lot of artifacts probably introduced by the import compression.

Bob
 
I'm running Redcine 3.08 and having the same result - mac os. Had no problem before, I have tried rolling back to the qt codec 1.5 but no luck, have you found a solution?
 
nope, but I was just tinkering and thought its a problem....
found an interesting issue with DNxHD codec on other systems though (not involving RED), but involving Intel Macs... some .mov's being corrupted with large blocks of "interlaced" type lines (as in interlaced from other frames, not video interlacing)... which seems to be attributed to minute variations in byte size of clips... weird thing is my PC can read the same .mov files as non-corrupt, Intel-Mac and they are garbage....anway, I digress...
 
I’ve been having this exact problem as well. On a recent project, the first day’s shooting had the exact same results as CWS. I hadn’t maintained the top level folder structure as I’d re-organised footage into 4K and 2K. So I re-copied the footage from the Red drive, maintaining the structure and the problem went away.

However, with the 2nd days filming the problem returned and I couldn’t fix it. In the end I exported Avid DV100.

After seeing this thread I went back to that first project and I can still export DNxHD with no problems.

If I create a new project and ‘import all’ of the 2nd days shooting, again I can export as DNxHD with no problems. I’ve just spent the morning trying to ‘break’ the DNxHD export, but I can’t. Just as I can’t ‘unbreak’ the project that’s being a pain. I’ll have to save out all the curves etc and reload them into the working project. Redcine just seems to be a bit temperamental with DNxHD.

David Litchfield
 
I am having the same problem. Garbled output with the DNXHD codec from Redcine.

Tried both Build15 and Build16 footage, both 720p and 1080p with the same results.

No luck so far..
 
Yes... I am seeing this as well. We are working the issue with RED to see where the issue might lie.

Michael
 
Thanks Michael,

Fyi, my workaround for now has been to export MJPEGA QT's from redcine and then use the ALE transform to get the metadata into MC with those QT's instead. Apart from the longer ingest time for the transcode into MC it seems to work fine? (The transform doesn't seem to care which codec the offline QT is in.. and I don't see why it should).

Just as a temp workaround.. it all gets transcoded into DNxHD in the end anyway inside of MC.
 
As long as the format can be decoded from QuickTime, in theory it can be imported. Of course there are exceptions, but it explains why it works using MJPEGA. As an exmaple, you could create the ALE from the original QT and export sequential TIF and it would still merge and work.

I am going to get an update this morning on the QT issue. I will let everyone kow.


Michael
 
I'm curious as to why you need to encode DNxHD.

Sure, it's a great codec but when you import those QuickTime clips to Avid my understanding is that they will be re-encoded to whatever native media your platform uses. Therefore you'd be adding an extra encoding step.
 
There is no re-encoding step if you encode to a QT wrapped DNxHD codec in the first place - that is why the codec exists. During import, it will unwrap the QT and move the essence over as MXF. No re-encoding. If you chose a different data rate or codec during import that the one in which was encoded, then like any system, there will be a decode and encode to that format.

On the topic of the garbage frames, we were able to identify and fix the codec on the PC to create proper images. It is getting wrapped up and a new installer will be available shortly on the Avid website. I will post a message when it does.

Michael
 
Michael, that's great new's, thank you!

Do you know if the update will fix the issue with Scratch as well? I am having the same issue exporting DNxHD from Scratch (this will be our preferred workflow over using Redcine for dailies)

Thanks again,
S
 
I suspect the issue is the same on both applications.

Michael
 
Thanks Michael,

It seems as though I had made a mistake and had 16-bit selected in the Scratch QT export options.. so that may have been causing the unpredictable output. I'm just testing now..
 
Back
Top