MXF proxies quality

[Christoffer Glans]

So Avid is changing the codec naming from the usual DNxHD 36, 120, 185 and 185x (25p) to DNxHD LB, SQ, HQ and HQx.
The problem is that the new naming isn't on par with the quality of the old version of the codec.

DNxHD 36 is supposed to be the go to codec for editorial that looks good enough for reviewing edits and client approvals. The corresponding codec should be DNxHD LB but it's no where close to the quality of DNxHD 36. I'm very surprised that something that's supposed to look the same looks this awful. There's blocky compression all over the image and it's just bad in all ways possible. The only way is to step up to DNxHD SQ, but that codec is way heavier to work from on a laptop with a regular USB3.0 drive (which most client works are done from) while taking up unnecessary space on both the Red Minimag cards and drives for editiorial.

Seriously, how can Avid fuck this up this badly? Aren't the quality of LB supposed to match the old DNxHD 36 quality?

Or is this something Red need to fix with a firmware? Just transcode a R3D clip to DNxHD 36 in redcine-x and then compare that to the MXF proxy recorded in-camera.

 

[MichaelP]

There "should" be no difference between the two, but I only have a few test files of in-camera DNx generated media, but will go back and compare. As far as data rate, DNxHD 36/DNxHD LB or DNxHR@ 1920@1080 all have the same data rate - which is also the same as UHD @ DNxHR LB 1/4 proxy. There was a version of Media Composer (8.3?) that had messed up play back when selecting green/green. versus green/yellow, or yellow/yellow that was horrible.

Michael

 

[Marc Wielage]

The rates are definitely different:

I would just buy a bigger, faster external drive, like a RAID 0 or a RAID 5 that can be backed up on a regular basis. I think 444 is overkill just for offline, but HQ should be fine, assuming you can live with 8-bit and it's just for a temp version.

 

[MichaelP]

10 seconds of the same clip transcoded as DNxHD 36 and DNxHR LB 1920 x 1080.

 

[Christoffer Glans]

There was a version of Media Composer (8.3?) that had messed up play back when selecting green/green. versus green/yellow, or yellow/yellow that was horrible.

I had that version, upgraded and now the LB coded media files in the MXF folder are recognized as unsupported, prompting an ignore or quarantine-message. So there seems to be some lack of collaboration between the folks doing the codec work and the folks coding the software itself, maybe they should talk and test together before releasing. So far I've only had problems with the "new" version of the codecs, the DNxHD 36 and up works just as good as before, there's definetely a difference.

I would just buy a bigger, faster external drive, like a RAID 0 or a RAID 5 that can be backed up on a regular basis. I think 444 is overkill just for offline, but HQ should be fine, assuming you can live with 8-bit and it's just for a temp version.

It's not about the storage speed. The files take up space on the recorded cards when filming so the less space for proxies the better, but you want that sweetspot of good enough quality with as less disk space required. Right now, even if DNxHD 36 and LB is around the same file size, they look quite different qualitywise.

10 seconds of the same clip transcoded as DNxHD 36 and DNxHR LB 1920 x 1080.

Record a clip on the weapon with LB quality on the proxies. Compare that LB to the quality of DNxHD 36 coded from the same R3D. It doesn't matter that they are the same file size, a x265 clip is far better in quality in half the file size of a x264 clip. There's something not right with the "new" codec versions. LB looks quite honestly like pure shit. The compression blocks are all over the clips, they are close to unworkable and for client approval not at all. DNxHD36 looks vastly different. I've been editing two feature films with DNxHD36 and we've even made screening copies from an edit with those files. I would never use LB for anything like that.

So how come they are the same size if they look so different? Is it the Weapon not being able to code the LB correctly or is it just that Avid's R&D messed this up when changing the codecs?

 

[MichaelP]

My comparison was for Marc to show that given the same resolution and frame rate, there is no difference between DNxHD 36 and DNxHR LB. DNxHR is the resolution independent version of DNxHD.

As far as what is happening in camera, it seems to be an issue with what is being used in camera to create the DNxHD 36 as I don't see the same artifacts at other DNx resolutions. The same RED file transcoded via RCX or MC via AMA transcode do not show the same artifacts. It almost looks like 1920x1080 is at 1/16 proxy. I'll have to try encoding with proxy on to see if the images look close.

Seeing as other data rates look fine, it is probably just a programming error in the encode parameters. I have sent reference to this link and image comparisons directly to RED.


Michael

 

[MichaelP]

It's not a 1/16th proxy issue as the artifacts look completely different than the ones from created in-camera.

Michael

 

[Marc Wielage]

It's not about the storage speed. The files take up space on the recorded cards when filming so the less space for proxies the better, but you want that sweetspot of good enough quality with as less disk space required. Right now, even if DNxHD 36 and LB is around the same file size, they look quite different qualitywise.

Buy a lot more cards. There are companies out there that will rent you X number of cards for shoots. I'd consider them the modern-day equivalent of going to Kodak and buying raw stock, only it's data. You only need them long enough to get the data off and check everything, then you can wipe them a day or two later and reuse them. I bet there are also users in your area that would make you a deal on a few 500GB or 1TB mini-mags.

My comparison was for Marc to show that given the same resolution and frame rate, there is no difference between DNxHD 36 and DNxHR LB. DNxHR is the resolution independent version of DNxHD.

They did go to a modified compression scheme, so I would bet there are some minor differences. I don't doubt that Christoffer is seeing compression artifacts. To me, the only answer is to go up a notch and go to the next-higher mode for less compression and use that.

I know of editors who thought that some of the lower Avid or QuickTime resolutions were fine until they had to screen them on a 50" or 60" display, then everybody was horrified by how bad it looked. The other problem is that with compression that bad, it becomes more of an issue to see focus problems. Dozens of times, I've sat in a room with editors while we looked at a much larger screen with the uncompressed camera files, and they're dismayed and say, "oh, my god -- I never would've used that shot if I knew that problem was there!"

So it does help to a) use a big monitor, and b) use the least amount of compression your system can handle. Both problems can be solved by spending more money -- I don't know of a solution beyond that.

 

[Christoffer Glans]

Buy a lot more cards. There are companies out there that will rent you X number of cards for shoots. I'd consider them the modern-day equivalent of going to Kodak and buying raw stock, only it's data. You only need them long enough to get the data off and check everything, then you can wipe them a day or two later and reuse them. I bet there are also users in your area that would make you a deal on a few 500GB or 1TB mini-mags.


They did go to a modified compression scheme, so I would bet there are some minor differences. I don't doubt that Christoffer is seeing compression artifacts. To me, the only answer is to go up a notch and go to the next-higher mode for less compression and use that.

I know of editors who thought that some of the lower Avid or QuickTime resolutions were fine until they had to screen them on a 50" or 60" display, then everybody was horrified by how bad it looked. The other problem is that with compression that bad, it becomes more of an issue to see focus problems. Dozens of times, I've sat in a room with editors while we looked at a much larger screen with the uncompressed camera files, and they're dismayed and say, "oh, my god -- I never would've used that shot if I knew that problem was there!"

So it does help to a) use a big monitor, and b) use the least amount of compression your system can handle. Both problems can be solved by spending more money -- I don't know of a solution beyond that.

No. DNxHD 36 is a perfect balance of disk space and image quality together with enough decoding speed to edit fluidly on any system. It's easy to edit on a big ass computer with a lot of horse power, a big RAID etc. but as a full time editor I can say that this is not the case for day to day work. Some jobs you will use the desktop but plenty of times you need to be able to edit on the go from a small 2,5 inch drive with USB3 and a laptop but still be able to output a 1080p signal for client approval at their office, not yours.

I don't know why you put the responsibility on the user to "do it some other way" in order for it to work. I'm saying that we had a perfect editorial proxy codec with DNxHD 36 and the new naming is just supposed to be that, a new naming, not vastly reducing the image quality beyond worthless. If this has something to do with how the Weapon encode the file, then it needs to be fixed right away. Buying more cards is also not a solution. The media cards are also expensive and if you think the solution to the problem of a screwed up encoding system is to just buy more cards then I'm happy if you send me both more cards and more hard drives to cover it. However, I don't think a solution to this problem involves investing thousands just to be able to do editorial as it's supposed to work. Not when the DNxHD36 workflow has been a perfect proxy-standard for a long time.

Here's two images that clearly show what I mean. The same clip, one LB from the Weapon directly and one decoded from the R3D in Redcine-X. On top of that, LB coded proxies doesn't work in the latest Avid, they can only be AMA linked and consolidated which erases the entire purpose of using MXFs in the first place (just opening the database files links to native media structures directly).

Red needs to do a checkup of this fast. The quality of LB proxies are far more important than high quality MXFs. The LB proxies is the entire foundation for smooth editorial workflow.

From the camera proxies

From redcine transcode (half-debayer)

 

[MichaelP]

There is also a performance issue to deal with, and not only storage. Many users working with DNxHD LB at UHD or higher also work in 1/4 proxy playback in Media Composer. 1/4 UHD LB is exactly DNxHD 36 so any gains are minimal unless rendering and going back to full proxy and green/green mode. So increasing storage by a factor of 4 for reducing it for performance can be a bit of a wash but if the user is aware of it can be managed. I did some full screen playback tests of 1/4 and 1/16h combined with green/yellow settings in the timeline and you reach a point of not seeing anything of value in the image.

My rule of thumb is that if 2K or greater is 16:9, then 36 and 115 are still very valid proxy workflows. I do like working at target aspect ratio and native source aspect ratios when not 16:9 so that conforms are pixel accurate when conforming in third party products. FrameFlex on content with backed in letterboxing is a no-no for pixel accuracy that Avid has yet to address (despite much of my beta feedback).


Michael

 

[Christoffer Glans]

I always work in "green/green" with DNxHD36 for offline. When it comes to speed and editorial flow, nothing comes close to that quality at that speed.

But it still doesn't help solving why Weapon is recording LB in such tremendous low quality which ends up unsuable.

One of my strong sale-points why people want to work with me is that I can deliver Avid ready workflow while shooting and this is seriously something that lowers my reputation as a quality provider. It needs to be fixed asap.

 

[MichaelP]

Red is looking into why the artifacts only exist with DNxHD 36 and not 115, 175, etc. Stay tuned.

Michael

 

[Eirik Nicolai Heim]

Is this fixed? Seems like I will be changing to a windows workflow, and then also dnxhr.

 

[MichaelP]

Not yet, but the issue seems to be with DNxHD and not DNxHR. The only time DNxHD LB (36) is selectable is when aspect ratio is 16:9 and 2K is selected for proxy. I need to do more testing on this when I get back off the road. There are other issues still pending with the Avid AMA plug-in and spanned MXF files that is also still being looked into from the Avid side, but have not heard back.

Michael

 

[alexjentz]

Just recorded MXF DNXHR SQ 2048x1080 from monstro 8k with a 320 Iso signal that was clean as it could be ( 3200 color balance and lights)

i was surprised to see way more artefacts than with the same prores of comparable file size out of the weapon ( or a pores from resolve/RCX) ( -> not really many artifacts but they are there if you watch anything bigger than on a 11" monitor full hd. )

to my knowledge ProRes 422 should be about the same data rate than DNXHR SQ when both are at 1920x1080

is there still something wrong in how the Weapon encodes DNXHR?

we had FW 7.0.0

i did not try LQ yet, but i can believe that this would look not very good if SQ looks with artefacts like this.

also i don't know if HQ will kill all artefacts, but since data rate is only slightly hither than SQ i would guess there is still artefacts.

it would be great if that could be looked into and fixed, because until then ProRes would be the only real world work solution, until then dnxHR is not real world ready yet i in my opinion

merry xmas from germany

 

[alexjentz]

solved?

solved?

anybody knows if this has been solved?

 

[martinnoweck]

yesterday i was testing the in camera MXF the first time and before reading this thread the editor and i came to conclusion that the HR HQ and HR SQ look fine and the HR LB is quite blocky.
way more blocky than the DNxHD 36 used to be.

best wishes and kind regards,
martin

 

[Burk Finley]

DNxHD/HR still blocky

DNxHD/HR still blocky

My 2 cents:

It's October 2018, and I was just handed DNxHD/HR HQX, 1920x1080 MXF files. Camera was Epic-W 8K Helium on latest 7.1 firmware. Issues still remain.


Pulled them into Resolve:
Showed up with 16 channels of audio - ?

Pulled them into Premiere:
Audio not recognized, video OK

Linked in Avid MC 8.8.5:
Linked fine, consolidated fine 2 out of 3 tries. The one time the audio wasn't recognized and the consolidated video would not play.
Also, audio TC started at 00:00:36:00
Video TC (appropriately) started at 10:46:18:00. Odd.


On the blocky subject = unusable. HD files were shot in log, and blockiness in the bokeh was visible everywhere before adding color/contrast in Resolve. Added contrast and color only made it more so. Images with blockiness were viewed in Resolve 14.3 on $30,000 Canon OLED (and Apple Cinema, and MacBook Pro Retina).

These files were viewed on both Windows and Mac systems (not that it matters).

I can only assume RED is having trouble with its DNxHD/HR compression.

 

[Jeremy Torrie]

Has anyone had any luck with good Avid proxies? With picture and sound? And by this I mean generated from within the DSMC2 cameras.