Just for the information of anyone who has the same need as me, I found
that re-encoding could be forced on current stable version of DOM as
follows:
1. Create an SRT file with a single subtitle that starts at 0 and ends
at 10 hours
2. Import the original DCP into DCP-o-matic
3. Import the SRT file
4. Adjust trim on SRT file so it matches exactly play length of original DCP
5. Set position of the SRT subtitle so it is moved out of the frame
So DCP-o-matic sees a subtitle is being superimposed on each frame and
therefore re-encodes each frame, however the subtitle is actually
outside of the picture, so the frames are not altered by the faux
"subtitle" in any way.
NB On Mac OS, the rendering of the subtitle in DOM preview is not
correct, but in the actual DCP it is rendered correctly.
Setting the transparency of the subtitles had no effect, so a subtitle
with 100% transparency didn't work. But Carsten's suggestion lead me to
the solution above.
Hope this may be useful to someone.
Cheers!
Jim
On 08/11/2018 13:49, Jim Dummett wrote:
Thanks for the replies.
Carsten I think the 100% transparent SRT trick would work with no
damage/change to the image. A bit of a faff, but workable. Thank you.
Markus I believe DCP-o-matic is smart enough to not re-encode frames
when you trim. It just throws away the frames you trim off and keeps
the rest without re-encoding. But thanks for the suggestion.
Carl Thanks for implementing this. If it's possible to backport this
to 2.12.x, that'd be great. I'll use the test version for this DCP,
but it's something that would have been useful on a few other DCPs
recently so it'd be great to get it in the permanent pipeline when
that's possible.
By the way, I saw the changelog for latest test version and there's a
ton of brilliant features in there. The keyboard shortcuts for frame
forward and backwards are particularly appealing (it's the simple
things!). When do you think this is all likely to make it into 2.12.x?
Please don't take that as me trying to push you if it's not stable yet
- the rock-solid stability of DCP-o-matic is a massive asset - just
asking...
Jim
On 07/11/2018 23:28, Carl Hetherington via DCPomatic wrote:
Hi all,
Now now, play nicely ;)
I've added a button which will be in 2.13.68 if you're in a position to
use the test version (even for just this DCP). It's not tremendously
invasive so I could be persuaded to backport to 2.12.x I expect.
Best,
Carl
On Wed, 7 Nov 2018, Carsten Kurz via DCPomatic wrote:
Hi Jim,
I have an open feature request for this on Mantis, but you know how
stubborn Carl can be at times ;-)
Currently I think the only way to force reencoding is to do some
minor damage - e.g. cropping a single line. Another less obtrusive
option could be to burn-in an invisible char, e.g. small dot. I
guess you can set it's transparency to 100% and still force
reencoding. The timing for that SRT burn-in has to extend from the
first to the last frame so that all frames have to be reencoded.
- Carsten
...gesendet von unterwegs
Am 07.11.2018 um 18:41 schrieb Jim Dummett via
DCPomatic
<dcpomatic(a)carlh.net>et>:
Hi all.
Is there any way to force re-encoding of a DCP? We have a DCP which
has an illegally high bitrate, and would like to re-process it to
re-encode the frames at a lower bitrate.
Usually, where you don't alter the image (crop, colour conversion
etc) DCP-o-matic is clever enough just to repackage the original
J2K frames without re-encoding. But is there any way to force it to
do a re-encode?
Or can anyone suggest a workaround? A good way to export to an
image sequence and then re-import that for example?
Many thanks,
Jim
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic