| Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
We were checking for 3D content going into a 2D project in
the DCPEncoder, but we also need to do the same thing when exporting.
Moving the check into Player::emit_video() means that it is
applied to both DCP transcoding and export.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
i.e. as a block of memory rather than a file. Also, get the
fonts from the decoder rather than the content.
Together, these changes allow us to use fonts from SMPTE DCPs
added as content. Before, fonts would be messed up in those
cases (#1885).
|
|
While playback is happening we need to do that in the butler's
buffers and in the little delay inside Player.
This removes the seek on every crop change, making it a lot
quicker (#1758).
|
|
|
|
|
|
are re-written, meaning that they can be encrypted.
This (along with the libdcp update) also fixes assorted Atmos bugs.
|
|
|
|
|
|
|
|
1. scales the content up to fit the DCP container,
preserving aspect ratio, or
2. stretches the content to a custom aspect ratio, or
3. scales the content to some custom size.
|
|
|
|
|
|
4219d4b76c5cd5690b1f4fa0c248d93ced26d05a.
|
|
playlist's length, as appropriate.
|
|
Film's.
Previously Empty would use the length of the film for its end point.
Now it takes a Playlist (rather than a list of Pieces) and uses the length
of that playlist for its end point.
This fixes #1543, in which single-content audio analysis jobs would run for the whole
length of the film, rather than the length of the content, producing
strange graphs and incorrect progress reports.
|
|
|
|
complicated copy_from.
|
|
|
|
Before this fix, the following situation could happen in threads
A and B:
A: Some DONE signal happens; this triggers setup_pieces which
takes a lock on the player mutex.
B: FFmpegContent::examine takes a lock on the content mutex.
B: FFmpegContent::examine adds a stream
B: That causes STREAMS PENDING to be emitted.
B: This tries to take a lock on the player mutex so it can update _suspended
A: setup_pieces tries to access some content information, hence
tries to take a lock on the content mutex.
Now B is holding the CL and awaiting the PL and A is holding
the PL and awaiting the CL.
It feels like the root cause of this is that while setup_pieces
is happening another change (which would itself cause setup_pieces)
is announced, and this isn't dealt with properly.
There are two steps here; _suspended is protected with an atomic
rather than using _mutex, and also it can cope with being updated
recursively.
|
|
|
|
coming from the content and the calculated periods of silence.
It sees that there is some scope for disagreements here when
trim start/end times are rounded to frame boundaries.
Fixes #1708.
|
|
|
|
|
|
Forward-ported from 4141f01e25abd5050db09ff85da47ff059909669 in master.
|
|
|
|
|
|
|
|
content B has had its start trimmed. In this case when we seek
inaccurately in A we previously also seeked inaccurately in B.
This meant that at the transition the first frame we see of B
may not be the first frame of B.
After this we seek accurately in B so that we definitely get to the
start of it.
This is especially important if the start of B has been trimmed to
within two keyframes so that an inaccurate seek is not sufficient.
|
|
(if available) to recover the list of reels from, rather than having
to scan the filesystem again.
|
|
|
|
then convert it back to resampled content frames using the DCP
rate rather than the resampled content rate, which seems wrong.
If we want to go from metric time to frames we surely have to use
the frame rate of the thing we are working with (not the frame rate
which that thing will be played back at).
|
|
not work for RGB. See #1509.
|
|
|
|
|
|
|
|
|
|
|
|
|