| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This commit changes the approach with video timing. Previously,
we would (more-or-less) try to use every video frame from the content
in the output, hoping that they come at a constant frame rate.
This is not always the case, however. Here we preserve the PTS
of video frames, and then when one arrives we output whatever
DCP video frames we can (at the regular DCP frame rate).
Hopefully this will solve a range of sync problems, but it
could also introduce new ones.
|
|
This is a bit cleaner and stops odd messages about stereoscopic assets
appearing in the logs.
|
|
|
|
|
|
|
|
|
|
|
|
are re-written, meaning that they can be encrypted.
This (along with the libdcp update) also fixes assorted Atmos bugs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the failure to keep track of the `position' of
each stream of a multi-stream file. It also tidies things
up a bit.
|
|
|
|
|
|
Before this commit, decoders try to guess whether they should
request a seek based on what they have in their buffers. This
seems reasonable for video and audio, which will always (I think)
have some data lying around to give an indication of where their
parent decoders are in the timeline.
It doesn't work so well for subtitles, as the storage of subs is
cleared out based on time (+/- 5s of "now") so there is a good chance
that the storage will be empty. This gives the subtitle decoder no
chance of knowing where its parent is, so it's very likely to seek.
This commit asks the parent decoder to seek if it wants to, and it
decides based on a knowledge of roughly where it is in the timeline.
Hence the sub-decoders just see if they have got the data that is being
requested, and if not they suggest to the parent that it might like
to seek. They then start calling pass(). Hence the parent should only
seek if some calls to pass() are not going to elicit the required data
in a reasonable time.
|
|
Previously we asked libdcp whether an imported J2K file was
RGB or XYZ. The answer it gives is sometimes wrong, for reasons
that are not clear (either the files are not marked correctly,
or openjpeg is not parsing whatever metadata correctly).
However it seems that, in general, we use the user's specified
colour conversion to decide what to do with an image, rather than
asking the image what should be done to it.
Hence it makes more sense to assume that if a user specifies no
colour conversion for a J2K file then the file is XYZ.
With preview, the colour conversion from XYZ back to RGB is done
by FFmpeg, so we have to set the pixel format correctly on the
Image that comes back from J2KImageProxy. Now we get that pixel
format from the configured colourspace conversion rather than
from openjpeg's guess as to the file's colourspace.
It's a bit ugly that the only thing we ask the file about is whether
or not it is in YUV (which governs whether or not FFmpeg applies
the user's configured YUV-to-RGB conversion). Everything else is
decided by the configured conversion.
I think there's still some uglyness in here that I can't put my
finger on.
|
|
Support for this seems to vary wildly across DoM's build
targets. Stuff that builds on 16.04 won't build on 14.04,
for example. Seems to not be worth the hassle now.
This reverts commit 5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f.
|
|
|
|
|
|
|
|
|
|
|
