View Bug Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001246||DCP-o-matic||Bugs||public||2018-03-20 23:51||2020-12-16 00:28|
|Summary||0001246: Burnt-in bitmapped subs always wrong with DOM (please bring back the 1920x1080 container!)|
DOM seems to scale bit-mapped subtitles wrt the DCP-container instead of
I create quite a lot of DCPs from Blu-rays (and sometimes DVDs) for screening in our cinema.
A typical situation is that you put a 1920x1080 (hd) Blu-ray in a 1998x1080 (flat) DCI-container.
So it would seem a solution to use a DOM "X Scale" factor of 96% (1920/1998 = 0.961)
Now one could try to use a a DOM "X Offset" to compensate for the shifting.
We could think of a complex solution where one can specify wrt to what container or resolution
But there is one easy thing that could be done to eliminate many of the problems above:
As I understand it a 1920x1080 container is perfectly legal within DCI (because it is
Sometime ago the 1920x1080 container was removed from DOM with only Full/Flat/Scope remaining.
I've added some screenshot to illustrate the problem:
|Tags||No tags attached.|
|Estimated weeks required|
|Estimated work required||Unknown|
subs_correct.jpg (341,789 bytes)
subs_dom.jpg (388,964 bytes)
subs_dom_corrected.jpg (388,712 bytes)
SMPTE 429-2-2009 forbids the 1920x1080 container, so I'm not so keen to bring it back, unless that standard has been superceded. It sounds like we should scale based on the source resolution.
Some discussion here http://www.film-tech.com/ubb/f16/t003081.html
It is probably an old discussion and I certainly don't want to start a resolution war .. :-)
and this is not changed by all the errata (up to January 2018) listed on:
But I believe you when you say that SMPTE 429-2-2009 forbids 1920x1080.
Anyway, back to the subject of this bug report: of course having bit-mapped subs
In the (common) case of 1 video source with a (resolution-wise corresponding)
But with mixed, cropped, scaled content or content with non-square pixels that needs
We were able to read the SMPTE spec, and it is true that only flat, scope and full container is allowed, both in 2k and 4k. Actually we were glad to find this, since for many users, the proper application of scaling and DCP container was too confusing, as both the scaling and DCP container choices used the same names. When doing workshops for DCP-o-matic users, and also following the forum and mailing list, it turned out that scaling vs. container choice was most confusing problem for DCP-o-matic users.
And, as a matter of fact, there are indeed some servers that have trouble to display non-standard containers - at least they need to be setup in a special way to prevent image artifacts.
As a tester and tech-savy user, I would love to have any imaginable option in a DCP tool. But, it doesn't make usage of DCP-o-matic easier, so, even if I cut may own finger, I think we should stay on that road.
Another issue that turned up a few times recently for Carl is that of validation tools rejecting DCPs created with DCP-o-matic because of 'minor' formal standard violations. For years, DCPs created with DCP-o-matic haven't caused playback issues, but since some time, DCP entries for festivals or distribution get rejected by qc or validation tools because of these 'inaccuracies'. It is very bad for the reputation of a free software, and Carl can not just sit back and say 'as long as it plays okay on all servers, I don't care'. Festival entries are actually rejected because of these complaints. So, there is no other way for DCP-o-matic than to stick to the standards, especially now that SMPTE DCPs come into widespread use. I could imagine that at some point, non-standard containers would be rejected as well. Another similar issue is DCPs without any sound reel. I think all servers support this kind of silent DCP, but to my knowledge, it is not compliant. So, in DCP-o-matic, a minimum of 2 channels is used.
We have seen (a) few complaints about the 'missing' container types, so far I guess we manage to resist. The biggest issue for myself was that it forces letterboxing/pillarboxing to be applied for exports of non-DCI aspect ratio footage. But this may be dealt with by other means at some time.
Let's see what happens when 2.12 stable is released. In theory, we could have an advanced pref setting 'allow non-standard containers', as we have it for non-standard frame rates or j2k bandwidths >250Mbit/s. But I hope we don't need to.
I am sure that Carl finds a better way to deal with bitmap subs. I do quite a few subtitled BD conversion, but never came across your problem. Maybe I don't care enough about subtitle appearance in this application, as long as they are readable and complete.
I'm sure this isn't the whole story, but if you scale subs DoM is supposed to move them to keep them centered; however there's a bug in this code that e7d33e4 (2.13.6) fixes.
From a few quick tests it looks like maybe DVD subs are prepared for the pixel size of the source (i.e. 720x576) without taking into account any non-square pixel aspect ratios that are in effect.
Hi Carl - you mention some test versions up to 2.13.6 - have any of these been online yet? I can't see them on the test download page.
2.13.7 is trickling up there now.
As far as I know, this is resolved - let me know if not!
|2018-03-20 23:51||robn||New Bug|
|2018-03-20 23:51||robn||File Added: subs_correct.jpg|
|2018-03-20 23:51||robn||File Added: subs_dom.jpg|
|2018-03-20 23:51||robn||File Added: subs_dom_corrected.jpg|
|2018-03-21 00:07||carl||Note Added: 0002313|
|2018-03-21 00:09||carl||Target Version||=> 2.12.x|
|2018-03-21 00:10||carl||Note Added: 0002314|
|2018-03-21 03:18||robn||Note Added: 0002315|
|2018-03-21 22:10||Carsten||Note Added: 0002320|
|2018-03-21 22:36||Carsten||Note Edited: 0002320|
|2018-03-21 22:46||Carsten||Note Edited: 0002320|
|2018-03-21 23:32||Carsten||Note Edited: 0002320|
|2018-03-27 00:58||carl||Note Added: 0002332|
|2018-03-27 00:59||carl||Note Added: 0002333|
|2018-03-27 01:07||carl||Note Added: 0002334|
|2018-03-27 12:32||Carsten||Note Added: 0002335|
|2018-03-28 01:11||carl||Note Added: 0002339|
|2020-08-18 23:23||carl||Assigned To||=> carl|
|2020-08-18 23:23||carl||Status||new => resolved|
|2020-08-18 23:23||carl||Resolution||open => fixed|
|2020-08-18 23:23||carl||Note Added: 0003902|
|2020-12-16 00:28||carl||Status||resolved => closed|