| Age | Commit message (Collapse) | Author |
|---|
|
AV_PIX_FMT_XYZ12LE.
Prepare the image for where it is going to next. I don't understand the difference
in this situation between XYZ12LE and RGB48LE (it seems they are both 16-bit-per-channel)
but there you go.
|
|
|
|
Previously too many frames were queued for encoding, which AFAICS meant
that (if the CPU was busy) we would get to the point where too many frames
were in the encoder queue, so that we blocked waiting for it to clear,
and then simultaneously too many frames were in the writer queue, which
(in this test) would never clear.
At this point we would be backed up waiting for Writer::write() to happen
in J2KEncoder::encoder_thread() so that the encoder queue could be cleared,
but nobody is calling Writer::write().
|
|
|
|
Instead store details of a previously-created asset in the film's
metadata and then look there for potential video files to re-use.
|
|
|
|
(#2784).
This feels like a hack, but I can't think of a nicer way to do it.
The interruption disable makes sense because when we destroy encoder threads
during a DCP encode (because a remote server goes away, for example) we don't
want any frames to be lost due to the encode thread being interrupted between
taking the frame off the queue and sending it to the writer.
When we're destroying the encoder we don't care about this, but I can't see
how you'd differentiate.
Maybe the encoder queue could have two lists: to-do and in-progress;
the encoder thread atomically moves a frame from to-do to in-progress,
but then how do you know when the in-progress ones are orphaned and need
to be re-added to the main queue.
You could make the writer return saying "no" if the queue is full (rather
than blocking and waiting for the queue to empty) but that seems wasteful
as then the frame would be re-encoded.
|
