| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This means we can fix the case of a VF having no known size in a nice way,
in turn fixing problems caused by the fix to #2775.
|
|
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.
|
|
|
|
|
|
Since FFmpeg does not do video level conversion for RGB sources
when we (sort of) ask it to in Image::crop_scale_window() it seems
to make more sense to compensate for that by calling
full_to_video_range() in the same place (rather than in
FFmpegImageProxy).
|
|
|
|
|
|
|
|
Video that comes in with RGB pixels will not have its video level
ranges changed by libswscale (it only does this for YUV and greyscale).
Here we add code to do it ourselves for RGB content coming in
via image files (e.g. PNG/DPX etc). Part of #1851.
|
|
|
|
|
|
|
|
|
|
|
|
to decode images. Hence remove {Image,Graphics}Magick.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
a _parent to VideoContent (mainly, but not only, for signalling)
and moving the video shared_ptr into Content, which makes much
more sense to replace dynamic_cast tests for whether something
has video or whatever. Nearly builds.
|
|
but only for preview.
|
|
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
|
|
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.
|
|
I believe both are necessary; doing floor instead of round caused #648.
|
|
|
|
This feels wrong: it means that it is possible for FFmpegDecoder
to discard packets. I can't see how this is ok in all cases:
maybe we were lucky that it worked at all.
|
|
|
|
subtitles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
