View Bug Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001652 | DCP-o-matic | Features | public | 2019-11-03 22:42 | 2023-02-21 09:52 |
Reporter | carl | Assigned To | carl | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | confirmed | Resolution | open | ||
Summary | 0001652: J2K data rate reporting / checking | ||||
Description | So you can see the size in bytes of each encoded frame in the DCP. This could also be done when checking DCPs. For extra points, check for too-big files during encode and re-try the encode of that frame with different parameters. That is assuming that it's possible for openjpeg to exceed its requested bandwidth for one frame; I'm not sure if it is possible or not. | ||||
Tags | correctness | ||||
Branch | |||||
Estimated weeks required | |||||
Estimated work required | Undecided | ||||
|
Maybe for now, write size of every frame coming from j2k encoder into log? |
|
Nice idea. |
|
We probably need some more testing to be sure about this. I did some testing into 4k and HFR frame- vs. datarates quite a while ago, but, arrived at something that wasn't clear enough to file a mantis entry (I think I didn't get any data rates higher than 250MBit/s at the time, no matter what I specified). If we can be sure that DCP-o-matic/openjpeg keeps the datarate below configured threshold, it is probably sufficient to only issue a warning together with the other hints before encoding starts. We may need to revise the spec limit of 250MBit/s towards a lower number with these Doremis in mind. Maybe also limit the default max data rate in advanced prefs to 200, or whatever my findings are with the Doremis. We should protect users. You can read up the 250MBit/s limit everywhere nowadays, so, those 'my precious image' users creating 60fps 4k 16Bit sources into 500MBit/s DCPs get enough of a warning. Then we may need to issue a warning based on j2k frame size if it actually peaks over the threshold. This could be caused by weird content, bug, or an openjpeg update. I think it's a good idea to check this right after a frame has been compressed. Average data rate is really only useful for file size consideration, peak is where the trouble starts. |
|
|
Date Modified | Username | Field | Change |
---|---|---|---|
2019-11-03 22:42 | carl | New Bug | |
2019-11-03 22:42 | carl | Assigned To | => carl |
2019-11-03 22:42 | carl | Status | new => confirmed |
2019-11-03 23:03 | Carsten | Note Added: 0003531 | |
2019-11-03 23:39 | carl | Note Added: 0003533 | |
2019-11-04 15:03 | Carsten | Note Added: 0003544 | |
2019-11-27 23:35 | carl | Tag Attached: correctness | |
2021-05-22 23:56 | carl | Target Version | 2.16.0 => |
2021-05-22 23:56 | carl | Estimated work required | => Undecided |
2023-02-21 03:39 | mhm | Note Added: 0005522 | |
2023-02-21 09:52 | carl | Relationship added | related to 0002450 |
2023-02-21 09:52 | carl | Relationship added | related to 0002451 |