Blackmagic Forum

I'm rendering a 69 minute video for broadcast. When I try rendering it on the DNxHR HQX 10 bit (or anything higher) setting, the output plays back all jittery like it's only playing every 5th frame or so.

Doesn't seem to matter whether I do it at 1080 or 4k. HQ and SQ are fine, as is DNxHD and H.264.

Original footage is 4k.

System specs:
Win 10
Intel Core i7
32GB RAM

I appreciate any ideas you have. Thanks!

Can you share a sample? Not YouTube, something we can download and examine.

There are 3 options in play here:
1) Your hardware can't decode DNxHR 10 bit 4K.
2) Your deliver/timeline/project settings are wrong somehow
3) Davinci has a bug.

Jim is asking for a 1) step.
If you render a 3 second clip and import it back into resolve what happens?
If it plays without problems: Your storage can't deliver the data fast enough or it's a "your player" problem.
If it plays frame 1,1,1,1,1,2,2,2,2,2,3,3,3,3,3 etc then it's a retime setting problem.
if it plays 1,1,1,1,1,5,5,5,5,5 then it's a bug.


But yes, send us an unmodified small clip via wetransfer, google drive, dropbox etc so we can see ourselves what's going on.

And could you post the complete system information?

So sorry to take so long on this. Just saw these replies right now.

Here's the link to a 30-sec clip. https://drive.google.com/file/d/1oAywA0 ... sp=sharing

Playing it in VLC is still jittery. However when I import it into DaVinci it plays fine.

Here's what it looks like when I play it in VLC: https://www.loom.com/share/b16a2d8e9131 ... e8604c99c1

If I were trying to recreate an old silent film look this would be great.

So I imagine it's a storage problem? Tried playing it from my internal C drive as well as a Sandisk external 2 GB SSD.

System Specs. Let me know if there's any other information you need.

OS Name Microsoft Windows 10 Home
Version 10.0.19043 Build 19043
System Manufacturer HP
System Model OMEN by HP Laptop 15-dc1xxx
System Type x64-based PC
Processor Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592 Mhz, 6 Core(s), 12 Logical Processor(s)
BIOS Version/Date AMI F.16, 3/23/2020
SMBIOS Version 3.2
Embedded Controller Version 21.15
BIOS Mode UEFI
BaseBoard Manufacturer HP
BaseBoard Product 8574
BaseBoard Version 21.15
Hardware Abstraction Layer Version = "10.0.19041.1151"
Installed Physical Memory (RAM) 32.0 GB
Total Physical Memory 31.9 GB
Available Physical Memory 26.2 GB
Total Virtual Memory 36.6 GB
Available Virtual Memory 29.1 GB

It's fine if it plays well elsewhere. But I need a way to make sure it plays well elsewhere.

First things first:
File plays well in Resolve, plays well in Media Player Classic, does not play well in VLC.
That leads me to think it's more a VLC issue than anything else.

Secondly: You do know that DNxHR isn't a delivery format, right?
For reference youtube has no problem playing it at 29.97 fps. ( Which I will remove soon)
For delivery (assuming you're going to distribute it yourself): Encode h264. (I'm vague here because I don't know enough about the final settings to be helpful)
For delivery (assuming you're uploading to a service like youtube, vimeo etc): DNxHR HQX is fine
For delivery to netflix etc, use their specs.

So all in all: It's VLC that isn't fast enough to decode. Problem solved methinks.

FWIW that 30 second sample clip played perfectly in VLC for me on macOS. It did use a fair bit of CPU - 200% or so (two cores fully loaded).

However I have seen these sort of issue in VLC in the past: rendering intermediate codecs out of Resolve and in VLC it's really slow, but plays fine in Resolve. So there could well be inefficiencies there.

The clip played perfectly fine for me using PotPlayer.

Query: AAC audio? Not PCM? I mean, for 4K DNxHR HQX, you ain't saving any kind of significant space there.

Thanks, Mads. I'll grab Media Player Classic and try it there. I had also tried it in the Windows Media Player as well as VLC and got the same jitter.

And this particular version is for upload to FilmHub. They do the rest of the transcoding to spec for whoever picks it up.

And thanks for checking that, TheBloke. You probably have a much more robust system than I do, so that could be the difference.

I'll check out PotPlayer too, Jim. Thanks. And actually it will be PCM audio. I just forgot to set that for that little clip.

Much appreciated!

Mads Johansen wrote:Secondly: You do know that DNxHR isn't a delivery format, right?

What?

Sorry to detour, but what do you mean? DNxHR is definitely a delivery codec.

mpetech wrote:

Mads Johansen wrote:Secondly: You do know that DNxHR isn't a delivery format, right?

What?

Sorry to detour, but what do you mean? DNxHR is definitely a delivery codec.

I've been thinking for an hour on how to reply to this, I think the best way is to use the definitions from Avid and Amazon:
1) From https://www.avid.com/products/avid-high ... -workflows :

Avid DNxHR and DNxHD enable media professionals to scale high-res and HD media into everything from lightweight yet beautifully detailed mezzanine files, up to visually lossless mastering quality

That requires people to know what "mezzanine files" mean: From https://videodirect.amazon.com/home/hel ... G202019880 :

A mezzanine file is a compressed master video file used to produce additional compressed video streams and downloads

Thus, no: DNxHR is not a delivery codec.

My understanding is derived from Amazon: Someone uses a Mezzanine codec file to create the delivery file for end users. (Edit: I should have written "Delivery format for end users" in the first message. I assumed we were talking about end users, not delivery to a service)

HOWEVER depending on context a person might be required to deliver a DNxHR file for a client and/or service. What I have written above does not exclude in any way DNxHR being a delivery format, it depends on where the file is delivered to.
In fact here's an overview where DNxHR is used as a final delivery format: https://www.trainingconnection.com/prem ... ormats.php

It is true that both DNxHD and DNxHR are mastering codecs - defacto in the case of Avid and often too with Resolve. Delivery these days is in packages such as AS-11, IMF or DCP etc., for broadcast, streaming or cinema, all of which use different formats and compressions, for delivery. It is common for Vimeo/YT etc. to deliver in more compressed H264. Though in the case of AS-11, which is only really used in UK broadcast, as far as I am aware, other countries may deliver these codecs to the broadcasters directly, without further conversion. Perhaps in the States and perhaps that's what Dom means?

AS-11 is gaining acceptance in other countries too.
Of course, in the broadcast world only.

Sssshhhhhh, don't tell HBO, PBS, CBS, ABC, etc. that DnX is not a mastering/delivery codec.

***This post being typed while exporting DnX for a major network.

Mads Johansen wrote:

mpetech wrote:

Mads Johansen wrote:Secondly: You do know that DNxHR isn't a delivery format, right?

What?

Sorry to detour, but what do you mean? DNxHR is definitely a delivery codec.

I've been thinking for an hour on how to reply to this, I think the best way is to use the definitions from Avid and Amazon:
1) From https://www.avid.com/products/avid-high ... -workflows :

Avid DNxHR and DNxHD enable media professionals to scale high-res and HD media into everything from lightweight yet beautifully detailed mezzanine files, up to visually lossless mastering quality

That requires people to know what "mezzanine files" mean: From https://videodirect.amazon.com/home/hel ... G202019880 :

A mezzanine file is a compressed master video file used to produce additional compressed video streams and downloads

Thus, no: DNxHR is not a delivery codec.

My understanding is derived from Amazon: Someone uses a Mezzanine codec file to create the delivery file for end users. (Edit: I should have written "Delivery format for end users" in the first message. I assumed we were talking about end users, not delivery to a service)

HOWEVER depending on context a person might be required to deliver a DNxHR file for a client and/or service. What I have written above does not exclude in any way DNxHR being a delivery format, it depends on where the file is delivered to.
In fact here's an overview where DNxHR is used as a final delivery format: https://www.trainingconnection.com/prem ... ormats.php

While I understand you are using written definitions, the reality of its visual quality and real-world usage says otherwise - at least here in the USA. From every major network and even in some cases, streaming services - DNxHD/HR is definitely a delivery codec. We deliver (for primetime shows) more often in DNx and ProRes than we do with DCP or IMF for broadcast TV. For European clients, AS-11 and DCP is the more common choice. For film festivals throughout the world, DCP is the preferred choice.

Do broadcasters directly transmit their DNxHR/ProRes version? Or is it converted to another format prior to actual broadcast?

I had thought 'delivery' meant 'delivery to the end consumer' - ie the final step before it appears online/broadcast to a TV/shown on a cinema screen? So I had assumed 'delivery codec' excluded DNxHR et al because it wasn't the final codec the end consumer would see - even if it's used earlier in the chain as a codec for editors/colorists to deliver to a client.

But I'm not in the industry so I have no real idea, just guesses.

Looks like you're in pretty good hands from the comments above - I just stopped by to say I watched the clip and laughed. Good standup.

TheBloke wrote:Do broadcasters directly transmit their DNxHR/ProRes version? Or is it converted to another format prior to actual broadcast?

I had thought 'delivery' meant 'delivery to the end consumer' - ie the final step before it appears online/broadcast to a TV/shown on a cinema screen? So I had assumed 'delivery codec' excluded DNxHR et al because it wasn't the final codec the end consumer would see - even if it's used earlier in the chain as a codec for editors/colorists to deliver to a client.

But I'm not in the industry so I have no real idea, just guesses.

Delivery format to us technically and legally (this is what the contract says we need to deliver in order to be paid) is what the "production bible" or any other written document says which is explicitly an extension of the contract with the client. Production bible for ABC, Disney, HBO, NBC, CBS, Viacom, etc will say the codec, resolution, frame rate, and file format. Often this is DNx/ProRes in MXF or MOV container.

TV Broadcast transmission in the USA is MPEG2 for the most part. This is true for OTA and what cable companies use to compress and transmit. For streaming, I think a form of H.264 is the most common. (Fun fact: Nexflix will recompress big titles in several dozen settings to match user display - iPad, iPhone, Samsung phone, Samsung TV, Sony TV, OLED, etc.).

WooBoy wrote:Looks like you're in pretty good hands from the comments above - I just stopped by to say I watched the clip and laughed. Good standup.

Thanks, Tristan! I appreciate that a lot.
The whole special is on my website if you'd like to see more. Or the audio version is on all the music streaming sites.

mpetech wrote:We deliver (for primetime shows) more often in DNx and ProRes than we do with DCP or IMF for broadcast TV. For European clients, AS-11 and DCP is the more common choice. For film festivals throughout the world, DCP is the preferred choice.

There speaks the voice of authority - I suspected as much, though I am only familiar with my small world in the UK. It is interesting to hear AS-11 gaining acceptance in more countries, it caused quite a welcome revolution here and saved on 50 grand Digibeta HD decks overnight!