I’ve been able to compile DCP-o-matic on Raspberry Pi 2’s using the Raspian disk image. I had to install a few packages and compile/install a couple of third party libraries. I also had to make some changes to the script file to take into account that the CPU is an ARM chip, and not Intel x86.
Carl, any chance you’d be willing to take on another platform for your package distribution? Raspian is a direct Debian implementation, so you should be able to re-use a lot of your setup.
I’d be willing to donate a configured Pi 2 to the project if that would help.
-David
Am 28.07.2015 um 17:41 schrieb Carl Hetherington:
> Hi Carsten,
>
> Yes, it's a bit tricky ... in these cases the specified YUV to RGB
> conversion sort of means "if required". It would be better to grey it
> out if the content is not in YUV.
Yup - similiar for the case when using DCPs/MXF with or without recompression. I would choose 'none' for all these cases - assuming that the MXFs had been properly XYZ converted beforehand.
- Carsten
Hello there,
I played around with the DCP import feature of v2. I know quite a few people would love to be able to edit out certain passages of trailers, etc. - e.g. a trailing 'in 3D' or 'from Dec 5th'. This can be done, but with the current implementation only for both audio and video tracks of a DCP. Very often it would be necessary to do a split edit, apply different trim points to video and audio track. This can only be done in DCP-o-matic when importing the audio as a separate file. Now it is possible to extract an audio.MXF to a multichannel WAV file (DCP-o-matic will not read audio from an MXF file currently, as it is trying to find video in it). But maybe there is a way to dettach the audio track of a DCP so that it appears as a separate content? I know this leads to the discussion what DCP-o-matic is and should be capable of. But my intention is not to boost it's capabilities to a full fledged editor, but to make the most of the existing GUI with simple actions.
- Carsten
Hi all,
DCP-o-matic version 1.81.0 is now available from:
http://dcpomatic.com/download
This release includes:
Updated ru_RU translation from Igor Voytovich.
New pl_PL translation from Marek Skrzelowski.
Updated fr_FR translation from Thierry Journet.
Allow audio from different content streams to be used together in the same DCP (#274).
Set the default colour conversion slightly more intelligently depending on content type (#565).
Adjust colour conversion interface so that it's easier to use a preset.
Be more strict about what characters are allowed in DCP names.
Adjust job view in various ways (fixing #578).
Fix hang if you cancel a paused job.
Fix for distorted audio in some cases.
Slightly improve performance with high speed encoding setups.
Use j2c_<uuid>.mxf and pcm_<uuid>.mxf for picture/sound MXF filenames (#336).
Fix for failure to analyse audio or create DCPs with negative audio delay in some circumstances (#571).
Fix for failure to import video MXFs in some cases (#566).
Fix for crashes when using some colour conversions which result in out-of-range XYZ values.
Fix for failure to encode 3D from separate folders of images in some cases (#634).
Thanks are due to Carsten Kurz, Marek Skrzelowski, Thierry Journet and
Igor Voytovich.
With best regards,
Carl
Hi Carl - can you comment on the scaling types offered in DCP-o-matic? Is that performed by FFMPEG functions? I tried to look up the more exotic ones (e.g. 'X'), but did not find all references from here:
https://www.ffmpeg.org/ffmpeg-scaler.html
'X' could be the mysterious 'experimental scaler'?
I know it's useless for most applications except 'real' experimental ones, but I am currently missing 'nearest neighbor' or pixel repeat. I may find other ways to do what I want to do, but, just in case...
Wondering how I could downscale an image series with the most basic pixel repeat method. Maybe I have to batch image magick with the -sample resize option.
Leads us to my old issue that I think scaling options should be under the content tab and should be made content specific - not under DCP tab.
And that takes us to v2 where the strict separation of content and DCP options in the GUI is broken up (e.g. with audio). Anyone likes to discuss this?
I really preferred the strict separation of content related parameters and formal DCP parameters in v1. For my thinking, that is the most solid approach to create well defined compositions. Now that DCP-o-matic uses more inherent parameter constraining to assure formally correct DCPs, I would understand that it isn't necessary anymore - but I still don't like it ;-)
Anyone?
- Carsten
Hi all,
I plan to release version 1.80.0 (based on 1.79.8) within the next few
days. If anyone has any translation contributions or big problems with
1.79.8, do let me know.
Best regards,
Carl
I'm working on a video that was given to me by a film maker, it's an MP4
file and it has subtitles, the subtitles were given as a separate Excel
file. Does anyone know how I can use the .xls file as subtitles for an MP4,
or even to use it to make a new MP4/MKV file with subtitles embedded?
Below is an example of the xls file.
tc in tc out text 00:01:43:10 00:01:49:19 Stop spying you little perv
and fuck off! 00:03:29:11 00:03:31:22 Hey, cute boy. 00:03:31:22
00:03:35:01 Out! I´m taking a bath. 00:03:35:06 00:03:37:18 Get out Disa!
00:03:37:18 00:03:41:23 Mom tell Disa to go out!
I'm taking a bath.
Hello all.
While encoding a DCP from a Prores422HQ file last night, I noticed the
following error output:
[swscaler @ 0x103830800] Warning: data is not aligned! This can lead to
a speedloss
...lots of progress...
[prores @ 0x103811e00] invalid plane data size
[prores @ 0x103811e00] invalid plane data size
[prores @ 0x103811e00] ac tex damaged 3371, 1024
...progress until end
NB I was using dcpomatic_cli, rather than the GUI. The DCP-o-matic
project was created using the GUI, but then I use a script to call
dcpomatic_cli, in order to batch process multiple DCPs.
DCP-o-matic 1.79.0, Mac OS X 10.9.5.
A few questions:
1. These errors/warnings are not included in the log file - they were
just output to the terminal, presumably from FFMPEG. Shouldn't they also
go to the log file? If I'd run the encode from the GUI, the errors would
be silently ignored and there'd be no record of them.
2. Should I be worried about the "invalid plane data size" and "ac tex
damaged" lines? Presumably this indicates corruption in the source file,
but has FFMPEG quietly fixed that, or may the DCP be corrupt too?
3. Does "3371" indicate the frame number which is possibly corrupt?
4. I've noticed the "swscaler" warning message a lot before on various
files. Does this have a major impact on encode times?
I hope someone can advise...
Many thanks,
Jim
Hi all,
I'm experimenting with Zanata, a web-based tool for translating
things. I've uploaded the current translations for the 2.0 branch of
DCP-o-matic to:
https://translate.zanata.org/
with the name "DCP-o-matic". You will need to sign up with Zanata (or
use OpenID) and then you should (in theory) be able to make and update
translations right-in-your-browser (TM).
If anyone would like to try it, please do, and let me know how it
goes ... and if it's any better than poedit, or whatever you are
currently using.
If you want to try a language that is not yet translated, let me know
and I will add it to the list.
Thanks!
Carl
Hi all.
While teaching a group of people how to use DCP-o-matic last weekend
(DCP-o-matic is now on the syllabus at London Film School!), I came
across the change in v1.79.0 that default colour space conversion is now
Rec709.
For the majority of the people who'd brought their film to test on, we
found that sRGB was the best setting for them. We were comparing their
source files (mostly Quicktime) to the resulting DCP viewed in Doremi
Cineplayer (evaluation version) and found that Rec709 was changing the
colour balance of the image (most notably, making it darker).
What was the rationale for changing the default to Rec709?
And is there any way to examine a Quicktime file to find out what colour
space it's in? With shorts filmmakers, they often don't know themselves!
Presumably the default output from Final Cut Pro, Premiere Pro etc
remains sRGB rather than Rec709?
Many thanks,
Jim
