Since it does the locking right, and we basically have a database now anyway.

Before merging this should decide whether to reinstate UTC offset to cinema, and if so, do that on v2.17.x and adapt this branch.

Some discussion about that here: https://dcpomatic.com/forum/viewtopic.php?t=2359&start=10

Started to reinstate UTC on 2473-restore-offset

UTC restored to v2.17.x in 401da185ca664fc8d819fc842ffc08e14d4f6486

Will need to add sqlite to osx-environment and mxe.

dcpomatic2 started dynamically linking to it on 2.16.75, not in 2.16.74.

Can't see an obvious reason in the diff; perhaps the environment was rebuilt.

2.16.76 tagged on 16/02/2024.

2.16.75 on 09/02/2024

Snapshot 4 of catalina was taken 09/02/2024, adding libdcp-test-private.

Must be 604a5f9343eebfa0108a19bb6b8ec60bc81f4819

Sent a build to Dennis.

This branch works on 10.8.

Also works on the 10.10+ builds

ff12ccdde76c54d3b9e69799a63750db9edf0023

https://github.com/cth103/libdcp/issues/12

Also add -DVis in the ISDCF name here as required.

[]

764c35279cf79e96a9d738ad86625bc3137fc8d7

https://dcpomatic.com/forum/viewtopic.php?p=11601#p11601

Right-click on the OV in the content list and choose "Set project markers from this DCP".

When making VFs with subtitles or different sound track the SMPTE markers are usually the same as for the OV.
Therefore it would ease the step of making SMPTE VFs if there were some way of copying them from the OV. (I guess that cases also exist when one would make a new OV and want to copy the markers).
It could be a button added to the DCP->Markers window saying something along "Import all markers from [OV/DCP]" or it could be a button for each marker copying just that specific marker.
It would make sense if the button(s) were grayed out or only visible if the markers are available in the OV/DCP.

I forgot that this was already implemented - right-click on the OV in the content list and choose "Set project markers from this DCP". Let me know if that doesn't do everything you need...

https://dcpomatic.com/forum/viewtopic.php?p=9071#p9071

ba438ecd16207700ffd849820796b6f833beef21

[]

email

libdcp 869462070671b273ac528e075ac1c00a417cc8a0

be2deae96d8839ee9bc8190972a50d8acceb8c98

Add an option and calculate Y-offset depending on it (from top or bottom).

Why this needed.

For instance if subtitle line is multiline and the subtitles are supposed to be located on top of screen the relative offset will be calculated from the baseline which is bottom. This leads to the following situation when you offset subtitles to the top of screen there is a risk some part of subtitles will be overlaped. If baseline would be top this would not happen I guess. To be more clear take a look on a screenshot

[]

email

[]

Then instead of File -> New we could just create a new project in the store, and allow it to be renamed, perhaps. The motivation would be removing the need for File -> New, which some users find awkward.

stop / pause / play / fast-forward / rewind

email, player

[]

player

This is done in a stash on shankly but it shows up bugs in the waveform view, as it uses the scaled image (scaled for playback) rather than the full DCP frame. Fixing this seems to suggest we want to change how sizes are stored in PlayerVideo - see adjust-sizing.

The adjust-sizing branch tried to remove the knowledge of the output frame size from PlayerVideo (and hence, ideally, from Player) but this is not possible because Player needs to know the output size in order to scale subtitles correctly. I think this is difficult to get around without storing subtitles in some output-resolution-independent way.

Branch seems ok, just need to run tests/merge.

Waveform is totally wrong with this branch for things like DCP-o-matic_2K_test.mov from the recent forum post (and Arrietty). Need to clarify what the video waveform should actually show - presumably what would happen if this content were made into a DCP?

Perform DCP verification/hash checks multithreaded, e.g. one reel per thread.

• Carsten

player

I wonder if this operation is CPU bound at the moment.

A while ago I did some tests in DCP-o-matic to see how reel'd DCPs would benefit from multithreaded digest calculation. I don't remember exact numbers, but I think the outcome was small. It probably only makes sense at all if the DCP is sitting on an SSD. Parallel disc access on spinning discs is dead slow.

• Carsten

OK, thanks for the note.

Looks as if the hash checking efficiency is not exactly meeting common expectations... ;-)

This in the player, I have to check it in DCP-o-matic main for the digest computing.

I also wish there would be a little bit more verbosity during the checking - like immediately opening the report window that now only finally opens after the check, and listing the individual steps of the verification (e.g. which file or structure it is currently checking). The progress bar both in windows and OS X can easily be mistaken for a hanging application, as the verification takes long and there is no real progress bar growing.

• Carsten

[]

player

Would be useful to have the video waveform display available in DCP-o-matic player as well as in DCP-o-matic main.

player

I am having A/V sync problems with the DoM player on all DCPs I try. The version I am using is 2.16.59 git d860d9de91 on a Mac mini M1, 2020 running macOS Ventura 13.4.

DoM player was installed from the homebrew repository using:

$ brew install dcp-o-matic-player

The sync problems persists even if lowering the decoded resolution.

When trying playing back with ffmpeg and mpv, the problem is not there, A/V is in sync:

$ ffmpeg -lowres 2 -ss 00:00:00 -r 25 -i <j2c-file>.mxf -ss 00:00:00 -i <pcm-file>.mxf -ac: 2 -c:v h264 -f avi - | mpv -

(this specific DCP is in 25 fps and with entrypoint 0 in the CPL, but the result is the same for other DCPs I've tested)

player

Can you estimate roughly how far out of sync it is? Does picture lead sound or the other way round?

Also, is the sync error constant?

The audio seems to come approx 0,5 seconds before the video, and this is consistent, yes.

The full RDD52 verification added with 2.16.x takes a lot of time - most of which is unnecessary if the content has already been created with DCP-o-matic 2.16+. Sometimes, all you need is a hash check, and if possible, multithreaded for all components of the DCP (SSDs are now fast enough to read multiple reels of video and audio simultaneously).
Whereas, when you want to check just data integrity of an external USB connected DCP transport drive after copying or conversion, the full verification can take ages.

Maybe add two separate verification options, or bring up a small dialog which let's you choose between hash check and full verification?

player

Feature Request: Show the DCP-Markers (FFEC, FFMC etc.) in the DCP-O-Matic Player.
Also it would be great to be able to hide individual markers from the timeline (maybe adjustable from the general settings?), although you have set them. This is because sometimes, when every marker is set, it can be really messy.

Many thanks in advance:)

player

As apparently you can't get EasyDCP to verify OK with the RDD-52. Possibly debateable whether we should indulge EasyDCP here.

https://dcpomatic.com/forum/viewtopic.php?t=2245&amp;start=10

Install ccache, new cdist and

ci@ventura ~ % cat ~/.ccache/ccache.conf 
remote_storage = http://192.168.1.2:6923/ccache
remote_only = true

Or doesn't show up at all?

mac, 2.17.72.

Instead, store previously created video MXF UUIDs and settings in the metadata.xml so that we can find old video files by indirecting through there, rather than just going directly with the video MXF filename.

Advantages would be:

• removal of confusion e.g. "why is my project folder so big"
• removal of a confusing directory in the project folder
• possibly nicer code as it would remove the mangling of settings into hashes into filename
• one big step towards allowing DCPs to be created anywhere

Removing the mangling of settings into filenames seems awkward; I tried to do it with XML by separating out the bits of Film state that are relevant for video; that was OK but then doing the same for the playlist seems more inelegant.

There's still the info files, which are used to check existing video files to see if their hashes are as expected. Not 100% convinced this is necessary - maybe it only really solves the problem of a truncated video file (and maybe there's a nicer way to solve that).

DCP made in Resolve, macOS, 2.16.79.

It takes around five times longer than in 2.14.59 (using the same content)

Typical analysis time in 2.14.59 was around 3-4min for a full length feature, while in 2.16.65 it takes 15-20 minutes.

audio_analysis_test seems to take just over 2s in 2.14.59 non-debug build on laptop (though I think this was without ebur128 due to a mistake when building)

Since when is Leq(m) in it?

I'll check... on main the same test takes 14s...

Removing _leqm->add(interleaved) from main brings it down to 5s.

Using a PeriodTimer around the main pass() loop:

Removed _leqm->add() from main,
main 3.13 2.14.x 1.93 62%

Removed _ebur128->process call() from both,
removed _leqm->add() from main,
main 0.436s 2.14.x 0.378s 86%

Looks like building leqm_nrt with -O2 is about 4 times faster (judging by test.sh in that repo). Probably also worth looking at doing the convolution there with FFT.

Also leqm_nrt seems to loop over channels, so maybe we don't need to interleave the data before passing it in.

See opt branch on leqm_nrt

Merged the -O2 change as e7a04275703b8cd54e1325d42f484ed7d0acab92

Seems to work a lot faster now, at least in 2.17.13 - full length (2hrs) 5.1 audio incl. LUFS/LEQ in about 5 minutes.

[]

This seems to be much easier with Apple's metal-cpp library: https://developer.apple.com/metal/cpp/

This requires C++17, which appears to mean we have to upgrade libxml++ to its v4 API (2.6 uses auto_ptr which was removed in C++17 [though GCC seems to allow it, but clang not]) which requires a newer glibmm, which pulls in cairomm, sigc++ updates.

libxml++ v4 is API breaking, most notably Node::add_child is gone and now must be Element::add_child_element.

The question is whether we can use C++17 for macOS in v2.17.x without breaking everything else. Or use C++17 for everything? After 30/6/2024 Centos 7 Is EOL (that's keeping us on C++11) but it seems unlikely that everything else would be happy to go to libxml++-4/C++17.

• Fix libdcp not to call add_child (no-add-child)
• Fix DoM master to not call add_child (no-add-child)
• Update osx-environment and build DoM with c++17 and the no-add-child branches on macOS - combined branch of DoM is c++17, osx-environment branch is also c++17
• See if it still builds on everything else - I'm guessing not because libxml++-4.0 does not seem to be included with Debian, so we'd have to build half the world.
• If so closely eyeball the libdcp/DoM changes, commit, profit.

macOS dep updates are:

• sigc++ -> 3.6.0
• glibmm -> 2.68.2
• libxml++ -> 4.0.3
• cairomm -> 1.18.0

Ubuntu 18.04 seems tricky because something (I think) needs meson 1.2.0 but that needs Python >= 3.7.0.

Bottom line though is it seems possible, but will need some ifdeffing. The changes are on

• libcxml - c++17 branch (libxml++ 4.0)
• libdcp - c++17 branch (libxml++ 4.0)
• dcpomatic - c++17 branch (libxml++ 4.0, Cairo / Pango namespace changes)
• osx-environment - c++17 branch

Once C++17 branches are merged I guess this can be bumped from 2.18.0.

https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html

Maybe try it on Linux and then think about the whole Windows build tool SNAFU.

Some encoding hacks on the nvidia branch. Only seeing ~ 7fps on NVIDIA GeForce GTX 980 TI (with arrietty); maybe I'm doing something wrong.

Current showstopper is it doesn't seem to support custom precinct sizes; setting enable_custom_precincts to 1 gives a NVJPEG2K_STATUS_JPEG_NOT_SUPPORTED (I think I'm using 0.5.0 of nvjpeg2k).

It seems that there's more optimisation (pipelining) in the decoder than the encoder at the moment. Perhaps the encoder will get better.

Fixed a few things to make it actually work and the FPS is closer to 10.5.

Translating the PSNR to our bitrate still needs doing.

Decoding seems not to work with 4K (nvjpeg2kStreamParse gives NVJPEG2K_STATUS_INTERNAL_ERROR)

2K playback seems OK, about 1 core being used on i7-7700 with GeForce GTX 980 Ti to play back a DCI flat DCP (BTaER).

I put a message on nvidia's foruma about precinct sizes:

https://forums.developer.nvidia.com/t/nvjpeg2k-enable-custom-precincts/215482

https://forums.developer.nvidia.com/t/nvjpeg2kstreamparse-error-on-4k-jpeg2000-stream/202551 says they're already on the 4K problem.
Fixed apparently in 0.6.0.

Got a sponsorship offer to implement this for playback on Linux.

It would be handy when using DOM player for checking DCPs if it offered some way of displaying the SMPTE markers (e.g. FFEC etc.)
Maybe from the top menu:
View->Markers->[List of markers with with time code]
...and on mouse click jump to that time code.

Another thought:
Adding the markers to the timeline of the player, just like in DOM main program, would do the trick for me most of the time as long as they are clickable.

e.g. a line is 54 pixels high in VLC but only 41 pixels high in the DCP. Not burnt in.

email, git-bug

1920x1080 file that is cropped by 128 top and 128 bottom then fitted to DCI scope. Subtitles only go wrong when the crop is applied (see attached svg).

I think this is because we take a subtitle at some (w, h) from a 1920x1080 container so that the intermediate size is w/1920, h/1080.

Then scale these up by the container size so they end up w2048/1920 h858/1080 i.e. 1.067 times wider and 0.794 times taller i.e. same width and 0.744 of height.

Reporter said 54 becomes 41 i.e. 0.759 so that pretty much fits.

The picture hasn't changed aspect but the subtitles did. We need to scale subs the same as the image.

Sent build over email.

Apparently still broken; need to download stuff from FTP site sent by email.

Got SotD - need to run this and see if I can reproduce.

Obviously a problem with the preview and SotD after cropping and fitting to a scope frame (on main - need to check the branch).

SotD looks on on the branch - asked OP to check

OP confirms it's fixed.

6ac468554c7fea0dfaefde85fb6cdd0fceaf5cad

Still wrong if the source ratio is not the same as the DCP (e.g. 2.33:1 in a scope container).

Sent another build

OP replied on 13/3/24 saying there are no subtitles at all with this build, but didn't respond to follow-up questions.

Dropping priority after a month's radio silence.

[]

email, forum, git-bug

94618a724124cbf5fe9f0b47a3fdce601fcd5581

https://dcpomatic.com/forum/viewtopic.php?t=2391

Never got any feedback about whether this works.

[]

2.17.12

Also happens with English (India), Gunashekar is seeing it.

Apparently (https://docs.wxwidgets.org/3.2/classwx_locale.html) we should be using wxUILocale on macOS: https://docs.wxwidgets.org/3.2/classwx_u_i_locale.html

35e479a49b36cb09880d3171795d39c32a498bcc

https://dcpomatic.com/forum/viewtopic.php?t=2359&amp;start=10

472b44bf1bbeb34cf9c130b9cede0eac7a298e82

Comes out squashed horizontally

email, git-bug

Also not even rotated correctly on v2.17.x.

Should be better with bdcaf60ec37ec694f1e221a33b090f670bf974d6 and 00301ddfa6a7f4c79593d8c86a0ff208aa3be68a

[]

i.e. rebase required changes on top of upstream master

waf / pkg-config
bd785a7 waf build system.
424cb7a Naming fixes; add debug option.
232dceb Missing file.
06834d6 Upgrade waf to a version which works on recent Arch.
6c88c6e Make sure that .pc file specifies -DKM_WIN32 on Windows.
22cfc44 Missing edit to libasdcp-cth.pc.in.
cc2f56b Fix build on old GCCs.
8204f14 Don't include micro version number in MXFs we write.
dfb6aa3 Move public headers into src/asdcp and install them in a asdcp subdirectory.
ab0c4cc Make the IMP stuff usable.
867eb56 Install KM_log.h
3b098c4 Update waf.
48cf75a No-commit versioning.
9a56728 Try to provide python3 compatibility.
6c951dd Debug.
bc9484b Re-fix python3 wscript problem.
b8d5991 Build fix.
aa12a6d added readme for cth branch/fork
b9f1b2f Allow waf to be run with python 3.
0890f62 Remove unused file.
d4bf40b Rename .pc template file.
5d432cf Use -carl rather than -cth to match the git branch name.
8256396 Also need the flag in the actual build.
bb09615 Remove gcc 4.1 check and hide some more warnings.
02d8f88 Add -x32/-x64 suffix to boost libraries when building for Windows.
c78ff82 Fix include paths.
e0440b6 Whitespace fixes.
aab544c Build asdcp-{un,}wrap
a276ed1 Fix static build.
825e475 Bump waf for Python 3.10 compatibility.
ae75eb4 Fix writing of versions to .pc files.

Fixes could try to merge
DONE 9b5b13a Set up MXF header value DisplayHeight. Otherwise mediainfo reports 0 height for DCP-o-matic's MXFs. See DoM bug 0001325 for more discussion

Features / fixes difficult to merge
DONE d273907 Add another OpenReadFrame method for JP2K::CodestreamParser.
DONE 17fddfc Remove edit rate checks so that DCP-o-matic can use any edit rate it wants.
DONE 85eba79 Fix UTF-8 filename handling; replace DirScanner code with boost-based implementation.
DONE c6a91f5 Win32 build fixes.
DONE 0aa9691 cAllow overwrite (i.e. continue) when writing JPEG2000 MXFs.
DONE 565f3a6 Probably fix fake-writing with 3D.
DONE 9343b09 Support hashing while writing MXFs.
DONE f2ad6d5 Patches for testing to allow predictable random number and date generation.
DONE ee04871 Use boost random for the test (repeatable) RNG rather than rand_r.
DONE d3dbfda Add cscript file.
DONE 4b03c8f Build statically on Linux.
DONE 06cd028 Build correctly-suffixed libs (with -cth).
DONE 4d1b1c3 Allow > 60 fps 3D.
DONE a7e1d77 Quell some valgrind errors.
DONE 8f23c6c Add another VALGRIND_MAKE_MEM_DEFINED.
DONE 97918d8 Remove MSVC-ism; I think this is safe, and these methods are only used for debug logging anyway as far as I can see.
DONE c5b8b7e Log actual error codes from CreateFileW failures.
DONE 42342ba Add some more logging to RESULT_WRITEFAIL cases.
DONE 3ef6536 Fix mistakes in valgrind-supporting code.
DONE 8a4a2f2 Hackily fix use of undefined variable if !ASDCP_SUCCESS(result) here.

Merged / fixed / no longer necessary
6eff475 Fix missing initializer for the second variable in TagValue.
7861300 Remove unused parameters to methods.
62e2948 Fix enum switch/case statements with unhandled values.
5174e4a Fix unnecessary const qualifiers on return values.
8ec31f1 Add call to parent constructor.
3ac58e7 Remove some unused variables.
cdbaa07 Fix uninitialised variable.
eb10cbf Fix apparent typo in operator==.
0ff1c0b Remove use of stringstream in FileWriter.
04cf448 Remove stack-allocated BIGNUM which is no longer allowed in OpenSSL 1.1.
a985cd9 Remove some bad defines.

Warning fixes (maybe merged, didn't bother to check)
418bff6 Fix constructor initializer order.
d3e793c Fix some comparisons of signed with unsigned.
ea66f5b Fix a type-punning warning.
86cfe37 Add .gitignore.
9c508f6 Fix / hide some warnings on Linux.
3aaea6c Fix a few compiler warnings about misleading indents.
7a2a3c2 Remove pragma unknown by mingw.
4ebbe02 Re-add WIN32_LEAN_AND_MEAN for the asdcplib build.
2574dca DCP-o-matic already defines WIN32_LEAN_AND_MEAN; fix warning about this.
ee2ba36 Remove use of deprecated register keyword.
b9daf31 Remove uses of register.

dcpomatic-2.13.0 branch of asdcplib ready to try.

32b5af27f00f80054ab0f502ebd7b8a3fa0d4061

[]

email

libdcp 03257d7e08986d1333190f447e5d64c609ade981

Maybe this already happens, but there's all this stuff about all EEE fields being the same length, and only as long as is needed to represent TimeCodeRate - 1. Someone sent a DCP from EasyDCP Creator which got this wrong and raised an error in DoM.

When creating a feature DCP in reels, you usually want to align the reel breaks on picture cuts (at least this is how I always see it done in commercial DCPs, so I assume it's good practice).

DCP-o-matic currently offers 2 options for breaking content into reels:

1. Split by video content
2. Custom - which selects reel breaks by max file size e.g. 2 GB

Could DOM provide an option to produce reel breaks at specified timecodes?

I'm imagining an interface similar to the one used to set markers. Timecodes I think should be relative to the output DCP, not the input (like with markers).

I can't imagine the current "Custom" option is much used, because I can see minimal use cases for splitting a film into reels at points which are random as far as their relation to picture/sound/subtitles. So I think if splitting on timecode were an option, it could probably replace the current "Custom" option, rather than being an addition. If someone needs for some reason to ensure no file in the DCP exceeds e.g. 4 GiB, they could achieve that by setting reel breaks every 2 minutes or so.

There is currently a workaround to achieve reel breaks at desired points but it's hacky and error-prone:

e.g. If you want content broken into 3 reels:

• Bring the source content in 3 times as separate inputs.
• Trim each of the 3 so 1st is trimmed to e.g. 00:00:00:00 - 00:20:00:00, 2nd trimmed to 00:20:00:00 - 00:40:00:00, etc
• Tick "Split by video content"

This works as long as you only have only 1 source input. If you want to e.g. add a logo on the start, and have that logo included in 1st reel rather than having a reel of its own, that's not possible to do. You have to make a single-reel DCP first, then bring that DCP back into DCP-o-matic as an input and then chop it up.

@carl here's the whiteboard from the design team summit conference on this feature

Maybe Timeline can become ContentTimeline and there can be a new DCPTimeline which uses TimelineView etc.

@carl

I guess the interactions that you want are:

• add a reel break at the playhead position
• move a reel break to the playhead position
• nudge reel breaks around, while looking at the preview
• snap some reel break to the start of a subtitle
• add reels every x minutes

Very impressed with the design team's Saturday Night Fever brainstorming dancefloor.

A note on "snap some reel break to the start of a subtitle":

My understanding is that it's unwise to put subtitles/captions near the start of a DCP. I have assumed that was due to a possible lag in subtitle data getting transmitted to wherever it needs to be so there may be a delay before they start displaying (I assume this would be more of a danger with CCAP captions where the chain from server to audience display is long).

I have also therefore assumed that it might also be a bad idea to put subs/captions close to start of a reel, in case the server/projector doesn't "look ahead" into the next reel and only starts transmitting captions for a reel when the reel starts.

We did have one report a few years ago that a DCP we made with CCAP captions did exhibit this problem - captions did not appear at start of each reel. However, it did turn out that that venue's closed captioning system had some systemic problems, so it was unclear if their report was valid, or a symptom of the other unrelated problems. However, as a precaution, we've tried to avoid captions near start of reels ever since.

Do you think this is a legitimate concern?

Either way, it's more common to make reel breaks on picture cuts, and they only sometimes correspond to subtitle/captions cuts.

So I wonder if it's a good idea to provide a feature to snap reel breaks to start of subtitles, as this might suggest to the user that this is the "right" way place to place reel breaks, when often it may not be.

One other thing: A nice timeline-based UI would of course be great, but for me at least, a simpler timecode-based interface (like the one for markers) would suffice. A "Place reel break at current playhead" button would give visual feedback, rather than having to do it with timecode alone. Moving/nudging reel breaks can be achieved by deleting the old reel break and adding another.

None of this is to say that your design isn't really nice! I'm just saying that, for me at least, having the ability to add custom reel breaks is more important than having a slick UI to do it. If the UI is going to be a fairly major job then, in my personal view, it'd be preferable to add the feature with a more basic interface at first, and then iterate on the UI later.

Maybe UI is simpler than I think, in which case feel free to ignore me. In fact, feel free to ignore me either way! Just giving my 2 cents opinion.

Do you think this is a legitimate concern?

Good point - SMPTE Bv2.1 "specifies" this and says that the first sub/caption in a reel should be at least 4 seconds in.

One other thing: A nice timeline-based UI would of course be great, but for me at least, a simpler timecode-based interface (like the one for markers) would suffice

Another good point. I'm hopeful that a DCP "reel" timeline can basically be a rehash of the content one (using lots of the same code) but let's see. I agree that making one on the markers timeline might be enough.

A tricky UI point here might be what you do when reel boundaries have been set up but then the content is changed somehow so that those reel boundaries become invalid.

Merged this in 2354c1fd781879d215834ebe54661f125fcb324e. There's probably some stuff missing but let's see what people think.

This stuff found using a DCPDecoder should be found by the examiner and stored in the content.

Needs tests to be run once the 0002783 is sorted out.

394516c351602f58150bdbbb4e61c45163927147

Aaron says it's a lot faster

https://github.com/cth103/openjpeg/pull/1

8e9da24b4fa8a254d87f293072a4bf44da36b8fa

It looks like they may have added a similar threshold fix to the one we have.

arrietty on shankly

• with new openjpeg [3e0b5ed324]: 03:35.
• with sse/avx2: 03:38
• with old openjpeg [a45f6245e8]: 03:58.

Sintel.2010.1080p.mkv on shankly

• with new openjpeg [3e0b5ed324]: 0:22:39
• with old openjpeg [a45f6245e8]: 0:29:49

TRAILER VERSIE 4.mov on M1

• with new openjpeg [3e0b5ed324]: 5:15
• with old openjpeg [a45f6245e8]: 6:22

TRAILER VERSIE 4.mov on Windows

• with new openjpeg [3e0b5ed423]: 4:12
• with sse/avx2: 4:32
• with old openjpeg [a45f6245e8]: 6:10

Test -msse4.1and -mavx2 also.

openjpeg 2.5.2 in use from 8e9da24b4fa8a254d87f293072a4bf44da36b8fa

https://dcpomatic.com/forum/viewtopic.php?t=1958&amp;start=10

Asked for some files on the forum.

OP wants to hide/disable everything except the File menu in the player.

email

82f87c7711fb664b06b04d44792ed3820b3d1e01

On 2.16.78 (not present in the list of product versions above) if I issue KDMs directly from DOM the $CPL_NAME variable in the sent emails produces the content of the DCP->Name input field rather that the ISCDF name (which is checked for use, see picture).
This results in email content:

Dear Projectionist
Please find attached KDMs for KulturskolenMar24tt.
Cinema: Biffen Nordkraft
Screen(s): C, B, A

When using the dedicated KDM creator application (from DOM DKDM), the email content (and subject) is correct:

Dear Projectionist
Please find attached KDMs for KulturskolenMa_SHR-1-30_F-178_DA-XX_20_2K_20240306_BTD_SMPTE_OV.
Cinema: Biffen Nordkraft
Screen(s): A, C, B

It seems that $CPL_NAME return different strings depending on from which application it is used.

Thanks for the note, that should be fixed in 2.16.79.

@carl 9bebb9724c5b7f254e3cea62a5cdb3c5e0e8571e

Does the spec allow this to be configured for non-burnt subs?

See attached screenshot. 'Series 1' projectors have been sold until 2009/2010 - they are SMPTE compatible, but do not support all SMPTE features. 'Series 2' is what most cinemas use now - all current 2k and 4k DLP projectors (so, except Sony). The subtitle display code in series 1 and series 2 is from TI and all projectors using the same software level support the same feature set. There are now a few so called 'series 3' systems out in the market (e.g. Barco ICMP), but while 'series 3' seems to establish a category, they are not made by a single OEM like TI for series 1 and 2, but every projector/server manufacturer creates their own design, so, no common features in series 3. Some servers allow to render subtitles server side (essentially, burning them into the image that is then transferred to the projector). For some of the mentioned series 3 systems, there is no distinction between 'server side' and 'projector side' anymore (same as e.g. for Sony systems).

No one so far published a feature matrix for these devices, but there is a current report:

http://www.isdcf.com/meeting/Theatrical_Subtitle_Presentation_Quality_V5_20181017.pdf

So, Z position it seems can be used safely, but not dynamic Z position. Wether some systems simply ignore it or crash, I have no idea.

• Carsten

[]

~J2KEncoder() calls terminate_threads(), which interrupts encoder threads and joins them.

But one thread is in _full_condition.wait() in Writer::write(), where the caller ::encoder_thread() has disabled interruption. So that thread is waiting but the interrupt didn't have any effect.

e.g. with Ctrl/Shift.

efc6f0d2148441f3a30e2a66349d66461bb986f9

Add an OV with X channels into a project set to Y, refer to OV's audio but make it so that a new empty audio MXF must be created, then the VF one will have a mismatched channel count to the OV.

Probably should disallow audio VF until the channel count is changed.

d8bbc508e959d8d38c54a6db6cfc868bd64697f5

which is confusing. Also it's annoying that the zoom rectangle stops dragging when you go into the labels, but not always at the edge of the content area.

Google has no idea what this means but maybe it's because the font is not in a interop-style subdirectory (this is in a DCP made by the DCP combiner).

email

I think this will also happen with scope VFs.

email

a9b1c1cb65e1902a64430977cf698054e131a6f4

seemingly OK on Linux though, which is strange. Tested on 2.16.76 on mac.

https://dcpomatic.com/forum/viewtopic.php?t=2363

209bbb88cfcb00ca2185583b74066ad7f09ebd81

This is picking up on Carl's suggestion in 0001700 to have some API to determine the length of a DCP before it is encoded.

It feels to me that rather than adding a new command, this could fit quite neatly into the existing dcpomatic2_cli --dump command.

i.e. What I'm suggesting is to add duration of DCP to the first section of dcpomatic2_cli --dump's output:

MyMovie_SHR-1-25_F_EN-XX_20_2K_20191223_SMPTE_OV
DCI Flat at 2K
Duration 00:10:12:05
150Mbit/s
Output 25fps 2D 48kHz
SMPTE unencrypted

Duration could be expressed either as timecode or number of frames.

This would fulfil the use cases outlined in 0001701.

I would be very happy (hell, I'm keen!) to implement this myself. It's a pretty small change, so could be a good opportunity to start getting my hands dirty in the DOM codebase, without trying to solve a complex problem at the same time.

Please let me know if you'd be willing to accept a patch/PR for this, and it'd be helpful if you could point me to the right place in the codebase to start.

Great! It might also be useful to think about why dcpomatic2_create does not do what you need.

To modify dcpomatic2_cli you need to look in src/tools/dcpomatic_cli.cc. Let me know if you need any help, and don't hesistate to submit a PR on github (or whatever other way is easiest).

OK great. I'll delve into this in the new year. Just to warn you, I've never written a line of C/C++ in my life, so it might take me a while to work it out. About time I learned though...

145177aeee61de5a893b3c58beefc9d840674213

There are two places in DCP-o-matic dealing with ISDCF Name details - preferences and DCP tab. There is enough space around this selection boxes, so why not include a clickable link next to it to:

https://registry-page.isdcf.com/

[]

9d843365fb77e00dd31c03d1e8ea49126ab550f2

In dual screen with controls on other screen the video plays in the upper right hand corner, not using the whole screen. Also, when the player opens as "full screen with controls on another screen" only the audio plays. I have to go into 'view' and take it out of dual screen mode and then put it back on for it to work properly.

player

Cannot reproduce on mac mini.

player

Same machine as 0001972.

these are not standard but that should probably still work.

player

[]

player

Same in DCP-o-matic main. I thought it was a Mac specific issue and admit I never felt bothered enough to report.

Btw - note the prefs tab bar still collapses for all but the first and last tab selection.