Hi all.
Does anyone have any pointers on converting a 3D bluray to DCP? The
bluray which is the source in this case has the 3D encoded as MVC. From
my reading, this means the right eye picture is encoded as a separate
stream (which is a delta from the left eye).
Have ripped the bluray with MakeMKV which recognises that it's an MVC-3D
stream. And the file it outputs appears to be the right size so I think
MakeMKV is not dropping the extra stream or something like that.
But I haven't found any software that can display both eyes at present.
DCP-o-matic doesn't see it, and nor does Bino 3D player or VLC.
I'm on Mac but can get hold of a Windows box if I need to.
Anyone encountered this before?
Many thanks,
Jim
Hi all,
I recently updated the mailing list software (mailman) from version 2 to
3. This is quite a big change, but hopefully nothing too serious has
broken. If you see any strange behaviour, do let me know.
The mailing list web interface is now here:
https://lists.dcpomatic.com/
To post to the list, use
users(a)lists.dcpomatic.com
Thanks!
Carl
Good evening from Berlin!
I am pleased to say that the release of DCP-o-matic 2.16.0 is soon
approaching.
2.16.0 brings some useful new features and improvements over the 2.14.x
series:
- Linux-formatted DCP drives can be written from macOS or Windows using
the Disk Writer.
- Player performance is improved.
- DCPs can be combined using the Combiner.
- The DCP verifier built into the player is much improved.
- A number of new SMPTE DCP features are supported (CPL metadata,
markers etc.)
- Full support for Apple Silicon (M1) processors.
- Subtitle export.
...and lots of other good stuff:
https://dcpomatic.com/release-notes.php?v=2.15.175
We are now in the final testing phase with version 2.15.175 (also
known as beta 8). If no show-stopping bugs are found, I will release
2.16.0 within the next week or two.
If you have any time to help with the release, that would be great!
The important
work now is:
* TESTING - making DCPs, playing them back, writing DCP drives
using the disk writer - whatever you can, on whatever machines
(Windows, macOS, Linux) you have available. Report any bugs,
errors or confusions you find in whichever way is most
convenient for you:
- by email to carl(a)dcpomatic.com
- on the bug tracker https://dcpomatic.com/mantis
- on the forum https://dcpomatic.com/forum
- twitter @dcpomatic
* TRANSLATION --- here https://dcpomatic.com/i18n you can see the
current state of the translations of DCP-o-matic from English to a variety of
other languages. Are you a fluent speaker of a language that is coloured
yellow or red on that list? If so, it would be great if you could help by
translating some or all of DCP-o-matic's untranslated strings. If you need help
with that, or don't know where to start, do get in touch via carl(a)dcpomatic.com !
As always you can download the current test version from
https://dcpomatic.com/test-download
A huge thanks to everyone for your continued support.
All the best,
Carl
We had a very strange problem with a short DCP this week at a multiplex
cinema with Sony projectors.
The DCP was made with DOM 2.14.54. It was 2K Flat, SMPTE, unencrypted,
25fps. It was 2 mins long.
The DCP was due to play in 3 different screens. In one screen, it played
fine. In the other 2 screens, the same DCP ingested fine but then failed
at the "validation" stage.
In one of these screens, after repeated attempts, the DCP did finally
validate, but then wouldn't play (as in when you pressed the "play"
button, nothing happened).
The same cinema has in the past week successfully played other SMPTE
DCPs made with exact same version of DOM and same specs (2K Flat, SMPTE,
25fps, unencrypted).
All three screens have Sony projectors. As usual with these kinds of
things, I have of course tried to find out the model number of
projectors, firmware version etc but am unable to extract this
information from the cinema staff, who are rushed off their feet.
A couple of questions:
1. I had understood that this issue was resolved a couple of years ago.
https://dcpomatic.com/forum/viewtopic.php?f=2&t=1214
Has anyone else seen validation fails on Sony projectors since DOM 2.14.x?
2. What even is "SMPTE validation" anyway?
My understanding of "validation" is that it's a content integrity check
(hash check etc). However, I thought that happened at time of ingest and
ingest would fail if hash check fails. This problematic DCP is ingesting
OK, but then fails later at "validation".
"Validation", I am told, takes a long time (1 hour or so for a feature)
and can only be run when the projector is not playing anything. That
suggests it is reading a lot of data from disk. Again, that sounds like
a hash-check.
However, the cinema said their projectors only perform this extra
validation for SMPTE DCPs, not Interop.
So, if validation means what I think it does, why are Interop DCPs not
being hash-checked? Or if "validation" means something else entirely,
what on earth is it?
I hope someone else may be able to shed some light on these mysterious
events!
Jim
