| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
InitializeMagick() call, fixing crash on loading still images.
|
|
|
|
|
|
|
|
|
|
With referenced video from a DCP decoder, no video will ever
be fetched from the decoder. Hence the code to discard given video
will be activated after _decoded builds up to the magic size.
Before this commit the code would attempt to fill with black up to
given frame N (with N very large) from the last frame in _decoded when
_decoded had been trimmed. This would result in exponential growth
in execution time for the VideoDecoder::give() path.
|
|
|
|
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.
|
|
don't know why yet."
This reverts commit eb3f28f4e614455a4d070d5fa2caaa24b9d9139c.
|
|
why yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ssh://git.carlh.net/home/carl/git/dcpomatic into fix-encoder-threading
|
|
When an encoder thread is interrupted we just want it silently
to stop, so catch boost::thread_interrupted separately and don't
pass it on.
I believe the interruption of jobs and subsequent catch of
boost::thread_interrupted will still work as that's the job thread
rather than the encoder threads.
|
|
|
|
Two fixes here; prevent the servers-list-changed callback being
called when Encoder is being destroyed, and stop ~Encoder throwing
exceptions.
I'm not sure if the catch (...) in ~Encoder will hide problems
that we should be handling, but I think by the time ~Encoder
is happening we'll already have seen any exceptions that we
need to report.
|
|
|
|
|
|
|
|
|
|
|
|
We used to do ._* and .DS_Store but there has been a report of
.com.apple.timemachine.supported.
|
|
|
|
It makes slightly more sense to discard 2D in the Transcoder
rather than the Encoder. Unfortunately this requires quite
invasive changes, mainly to remove Encoder::_position and instead
derive this information from the PlayerVideo that is being handled.
This is also nicer than before, I think.
A notable change is that in player.cc; using time rather than
content_video_to_dcp(). This means we are assuming that the decoder
returns video at the time we ask it to, rather than checking
what it has returned. I can't think of a problem with this (yet).
|
|
|
|
|
|
|
|
|
|
|
|
This puts a frame index with an Eyes, which simplifies code in
some areas. I can't think of a better name for it,
unfortunately.
|
|
|
|
|
|
get_video() promises to return all video frames at the given time,
but this wasn't working for none-SBS-3D as it would be satisfied
when it got the first (left) frame. Adjust get_video() to get all
required frames.
This showed up bugs in fill_both_eyes, whereby the from parameter
was ignored and the wrong things were done in some cases;
video_decoder_fill_test.cc tests this stuff.
|
|
|
|
This breaks things when there is a 3D ImageContent. When
you change the video frame type on this content the view
does not update because the re-used ImageDecoder recycles
the same video without noticing that the frame type has changed.
I guess this is sort of `because' the video frame type is used
in VideoDecoder::give, which sets up the cache.
Unfortunately I can't remember the case which the caching
of ImageDecoders was meant to speed up. Maybe this will
now become apparent.
|
|
than a casted enum.
|
|
|
|
|
|
|
|
|
|
|
|
Use the specified time period rather than looking
in the Subtitle.
|
