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 .. :-)
but it seems that 1920x1080 is explicitly allowed by sections 8.4.3.2. and 8.4.3.3. in:

http://dcimovies.com/specification/DCI_DCSS_v12_with_errata_2012-1010.pdf

and this is not changed by all the errata (up to January 2018) listed on:

http://www.dcimovies.com/specification/

But I believe you when you say that SMPTE 429-2-2009 forbids 1920x1080.
Unfortunately this spec does not seem not to be publicly (freely) available?
(can't find it) Would love to have access to it ..

Anyway, back to the subject of this bug report: of course having bit-mapped subs
scaled to the source resolution would be fine too!

In the (common) case of 1 video source with a (resolution-wise corresponding)
bit-mapped subs-track this "source resolution" is obvious.

But with mixed, cropped, scaled content or content with non-square pixels that needs
to be stretched, determining the proper source resolution might require some extra thinking.

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.

• Carsten

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.

Subtitle path:

• FFmpegDecoder::decode_bitmap_subtitle; emits (ContentTime, Image, Rect<double>); rect is scaled to 0--1 depending on source size.
• Player::image_subtitle_start; content's translation/scale applied to 0--1 rectangle; put into _active_subtitles as a PlayerSubtitles [list of ImageSubtitle]
• Player::transform_image_subtitles; 0--1 scaled to _video_container_size and image scaled accordingly.
• put into PlayerVideo to go onward.

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.

• Carsten

2.13.7 is trickling up there now.

As far as I know, this is resolved - let me know if not!