View Issue Details

IDProjectCategoryView StatusLast Update
0001652DCP-o-matic[All Projects] Featurespublic2019-11-27 23:35
Reportercarl Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version 
Target Version2.16.0Fixed in Version 
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
Estimated weeks required
Estimated work required

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.

Issue History

Date Modified Username Field Change
2019-11-03 22:42 carl New Issue
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