Believe you me, this is definitely in the works! We hit a snag with our working implementation (not sure how much I can disclose here) and need to re-implement the muxer to create MOV files. There’s a bunch of incredibly frustrating stuff I can’t share and it’s not that we’ve been ignoring you. I’m buying Paul a celebratory cake when this is done. There may be dancing in the streets of Winnipeg (at least by me).
Just a quick poll of the crowd here: How important is audio support, and what features of the MOV container do you absolutely need? Writing the muxer, we need to figure out what features we need to support first to make it valuable for most people, then fill in the rest of it after most clients are working.
Hi Edwin,
sorry about this post, i could not resist in nagging you guys a bit…didn´t know it is such an emotional topic (but somehow great to hear it is)…
Did I read your post correct that it is not so much a licensing as it is a technical implementation issue? As it was working once (in the beta…3 years ago) so I am surprised to hear this (it does still run through FFMPEG, correct?).
Regarding your question:
I am not an encoding expert, so not sure how to answer the “features of the muxer” question.
Audio would definitely one day be of relevance but currently we don´t need it and would be happy with any implementation.
Hope this will one day be part of Draft, counting the days and counting on you,
I can’t go into all the business details here, but we’re not legally allowed to bundle quite a few different codecs for Draft that are provided by FFMPEG. In fact, they may not be able to ship it themselves. I’m pretty sure ProRes support is one of the many reasons FFMPEG doesn’t host a single one of its own builds.
In the meantime, we have a problem in that we need to take all of the image frames we generate from AfterEffects and Cinema4D and convert them into a ProRes of varying flavours in certain frame rates, sometimes with Alpha channels etc.
So since we’re all Mac based I was able to write a bash script that will automate the encode of image sequences without the need for any technical knowledge by the graphics team. Its simply runs an interface in which the team selects various options and at the end builds the appropriate Ffmpeg command
Just a sample of what the script does:
echo "\n\t\tWhat framerate is the material?"
echo ""
echo "\t1) 23.98fps"
echo "\t2) 24fps"
echo "\t3) 25fps"
echo "\t4) 29.97fps"
echo ""
echo "Answer 1,2,3 or 4? \c"
read framerate
Ask the user what frame rate they want for the output:
echo "\n\t\tWhat ProRes format would you like?"
echo ""
echo "\t1) ProRes422 (Proxy)" # -profile:v 0 gives a 11.4MB size and moves you to 10-bit 4:2:2 space
echo "\t2) ProRes422 (LT)" # -profile:v 1 ranges at around 28MB, it too is in 10-bit 4:2:2 space
echo "\t3) ProRes422 (Normal)" # -profile:v 2 moves us up to 45.2MB with 10-bit 4:2:2 space and finally
echo "\t4) ProRes422 (HQ)" # -profile:v 3 goes to 67.9MB at 10-bit 4:2:2
echo "\t5) ProRes4444 "
echo "\t6) ProRes4444 (Alpha Channel)"
echo ""
echo "Answer 1,2,3 etc? $flavour \c"
read flavour
if [[ "$flavour" = "1" ]]; then
flavour_out="prores -profile:v 0 -pix_fmt yuv422p10"
ProRes=ProRes422Proxy
elif [[ "$flavour" = '2' ]]; then
flavour_out="prores -profile:v 1 -pix_fmt yuv422p10"
ProRes=ProRes422LT
elif [[ "$flavour" = '3' ]]; then
flavour_out="prores -profile:v 2 -pix_fmt yuv422p10"
ProRes=ProRes422Normal
elif [[ "$flavour" = '4' ]]; then
flavour_out="prores -profile:v 3 -pix_fmt yuv422p10"
ProRes=ProRes422HQ
elif [[ "$flavour" = '5' ]]; then
flavour_out="prores_ks -profile:v 4 -pix_fmt yuv444p10"
ProRes=ProRes4444
elif [[ "$flavour" = '6' ]]; then
flavour_out="prores_ks -profile:v 4 -pix_fmt yuva444p10"
ProRes=ProRes4444Alpha
else
echo "Unknown parameter"
fi
And then builds a FFmpeg command that runs and drops the file in a designated drop folder for pickup.
Sounds like this was actively being worked on almost 3 years ago? Did it get permanently killed due to complications? I might be working on a tool for our studio soon regarding automatic ProRes creation, but before I go down that road, I figured I’d bump this up
Is this dead? We’re about to test the DNxHD option to see if it’s a valid path for us but we’d vastly prefer ProRes. We use 422HQ and Proxy throughout our pipeline and 4444 sometimes where it makes sense. I’m going to test if the concatenate function works on codecs that Draft doesn’t support… it might but I’m going to guess it will not… Is there any hope here?
?