| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
Also default to the home directory rather than where DoM was run from,
or something equally unhelpful.
|
|
|
|
|
|
Otherwise, for example, some content can be moved and before
the pieces have been re-created some video can arrive. Then the
video's position will be calculated using the content's new position,
causing an apparently big gap in the video which is filled in with
black. These extra black frames cause the video buffers to fill up
without any audio.
|
|
|
|
|
|
A user reports that on a Barco system they needed to use a
"DCI Specific" KDM with an Interop DCP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In English, at least, the excessive length of this label really
screws up the layout.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
work with in-tree builds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The comments discuss this in a bit more depth, but basically we see
errors from avcodec_send_packet after seek. ffplay etc. seem basically
to ignore all errors from avcodec_send_packet, and I can't find a
"proper" fix, so here's a half-way house hack: ignore some errors
after seek. Nasty.
|
|
|
|
|
|
Also fixes problems with invisible subtitles from binary STL files
with weird line numbers.
|
|
The test fails if we don't do this; it doesn't really seem 100%
convincing but we are already doing this for audio.
|
|
|
|
c432ef98c4cf3b2bda32734983eec3b42b8c3d1e completely broke the relinking
of libraries using install_name_tool by only doing it for the x86_64
part of the binaries. This commit fixes that, and also does some
tidy up that happened while trying to debug the error.
The main cleanup is that --deep is no longer used with codesign, rather
we sign all the executables ourselves manually. Various Apple forums
suggest that --deep is a Bad Idea for reasons that aren't really clear.
For reference, after spending days trying to debug the Gatekeeper
refusal to start DoM the way to reveal the problem was:
1. start a clean VM (there are caches everywhere, so once a failure has
happened you are even less likely to get any useful logging on the
second failure).
2. open "Console" on macOS; logs are written to un-greppable places so
you have to use this to see everything.
3. click "start streaming"; I don't know if this step is necessary.
4. put a search term in the search box (e.g. "dcp" for this)
5. start the thing that is not working.
And remember that otool without `-arch` on a fat binary will only really
operate / look at the first? native? architecture, so if you have
an x86_64/arm64 binary and the arm64 parts are wrong you won't see
anything about that with `otool -L`, only with `otool -arch arm64 -L`
|
|
|
|
|
|
|
|
|
|
It feels neat to have audio language in the audio tab, to match
the subtitle language in the subtitle tab. It also avoids the potential
confusion of there being an audio language setting in the DCP metadata
but no subtitle language setting. However:
- I am yet to find a need to describe multiple audio languages in the
same DCP (all previous users of Film::audio_languages() were just taking
the first language off the list).
- As Carsten points out it's fiddly to have to set the audio language
for 5 separate-channel WAV files, for example (you wouldn't actually
have had to do this, but it would have felt like you did).
I think subtitle language remains neater where it is (per-content)
as there is this additional subtitle language metadata and it makes
much more sense (and is much more likely) that there are multiple
subtitle languages in a DCP than it does multiple audio languages.
|
|
Now if you change left and click "link" the right will follow it,
and vice versa.
|
|
|
|
|