There is a JPEG2000 Bandwidth configuration on the DCP ----> Video Tab. It defaults to 100 MBit/s
I have the following questions related to this configuration.
1. What is the ideal value to select here and what is the best way to find out this value for the source input file?
2. Should the value selected be same as or more than the value for the input file?
3. Will the value entered have a implication on the time take to generate the DCP?
4. How will a value of 100MBits/s vs 200MBits per second show up different when it comes to onscreen image or the sound that the user will experience?
Thanks for your guidance.
JPEG2000 Bandwidth
-
Carsten
- Posts: 2668
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: JPEG2000 Bandwidth
In my opinion, Carl should update that default to something higher, but, in general, it's no big deal.
There is no straight relation between input file datarate and j2k datarate. Some input file codecs are closely related to J2K, and setting similar (or higher) values in DCP-o-matic may have some rational background. But for most input files, that relation doesn't exist.
In general, I'd say, if you do slides/animation with low complexity content (e.g. no grain), then 100MBit/s is usually sufficient. However, I have seen some high contrast/saturation animations with visible artifacts even at higher bitrates.
For live footage, I'd set it at 200 or 235MBit/s and forget about it. The only reason to really think about this is if for some reason you may want to achieve a specific target DCP size, either because your transport media is of limited size (disc, USB stick), or you are distributing by up/download. But then it's still a hit and miss, because the effective bandwidth/size will not compute straight from the set encoding bandwith. It is always depending on source file complexity. You may perform one encoding run and see that the DCP comes out at e.g. 138Gbytes, while your transport media is limited to 126GBytes. Then you may try another run with a lower rate and see if you get it below that. But that is cumbersome and you may even need multiple runs to hit that target.
In general, I don't care, on a new installation, I set the default value to 235MBit/s, then forget about it. You should not choose 250MBit/s, because, with some footage and on some servers, this may cause playback errors. You may as well go with 230 or 240, 235 is just my personal choice.
This only affects image (if at all), not sound.
- Carsten
There is no straight relation between input file datarate and j2k datarate. Some input file codecs are closely related to J2K, and setting similar (or higher) values in DCP-o-matic may have some rational background. But for most input files, that relation doesn't exist.
In general, I'd say, if you do slides/animation with low complexity content (e.g. no grain), then 100MBit/s is usually sufficient. However, I have seen some high contrast/saturation animations with visible artifacts even at higher bitrates.
For live footage, I'd set it at 200 or 235MBit/s and forget about it. The only reason to really think about this is if for some reason you may want to achieve a specific target DCP size, either because your transport media is of limited size (disc, USB stick), or you are distributing by up/download. But then it's still a hit and miss, because the effective bandwidth/size will not compute straight from the set encoding bandwith. It is always depending on source file complexity. You may perform one encoding run and see that the DCP comes out at e.g. 138Gbytes, while your transport media is limited to 126GBytes. Then you may try another run with a lower rate and see if you get it below that. But that is cumbersome and you may even need multiple runs to hit that target.
In general, I don't care, on a new installation, I set the default value to 235MBit/s, then forget about it. You should not choose 250MBit/s, because, with some footage and on some servers, this may cause playback errors. You may as well go with 230 or 240, 235 is just my personal choice.
This only affects image (if at all), not sound.
- Carsten