View Bug Details

IDProjectCategoryView StatusLast Update
0001652DCP-o-maticFeaturespublic2023-02-21 09:52
Reportercarl Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityhave not tried
Status confirmedResolutionopen 
Summary0001652: 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.

Tagscorrectness
Branch
Estimated weeks required
Estimated work requiredUndecided

Relationships

related to 0002450 acknowledgedcarl Check frame size and color component sizes of frames in verifier 
related to 0002451 acknowledgedcarl Please implement checks in the CLI verifier according to jpeg2000 constraints for cinema specified ISO/IEC 15444-1:2019 

Activities

Carsten

2019-11-03 23:03

manager   ~0003531

Maybe for now, write size of every frame coming from j2k encoder into log?

carl

2019-11-03 23:39

administrator   ~0003533

Nice idea.

Carsten

2019-11-04 15:03

manager   ~0003544

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.

mhm

2023-02-21 03:39

reporter   ~0005522

Probably related to 0002450 and 0002451

Bug History

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