Please add Ffmpeg Support

Please add import and export support via ffmpeg.
Fusion had/has import via ffmpeg which allowed almost any file format to to imported,
Why not have it in Resolve? This would add so much more flexibility to the system.

That would be amazing!

Gesendet von meinem LG-H818 mit Tapatalk

to some extend i second this request.

although ffmpeg/libav would be really nice solution to archive very well results on all platforms, it would be of particular interest to resolve users on the linux platform, because ffmpeg/libav are more or less the counterpart to similar system services on the commercial operating systems. but i don't see, why all this really nice precious parts of the free software should be utilized in an eclectic manner in closed sourced contexts, instead of just making the free alternatives a little bit more attractive? with this in mind, i would like to see ffmpeg support only in the free version of resolve for the linux platform, even though, this may sound utterly unacceptable/unsatisfying to the majority of resolve users.

i would like to see ffmpeg support only in the free version of resolve for the linux platform

I'm afraid the logical conclusion of this proposal would be to not having the Studio version at all.

Cheers.

Please add import and export support via ffmpeg.
Fusion had/has import via ffmpeg which allowed almost any file format to to imported,
Why not have it in Resolve? This would add so much more flexibility to the system.

+1 on that. FFMPEG support has been requested many times before and this surely becomes more pertinent as BMD move to integrate editing/coloring, audio and VFX platforms.

..although ffmpeg/libav would be really nice solution to archive very well results on all platforms..

And +1 on that, but not.....

i would like to see ffmpeg support only in the free version of resolve for the linux platform, even though, this may sound utterly unacceptable/unsatisfying to the majority of resolve users.

i would like to see ffmpeg support only in the free version of resolve for the linux platform

I'm afraid the logical conclusion of this proposal would be to not having the Studio version at all.

well -- perhaps not on the linux platform -- but it's even much more targeted against the "advanced" edition and similar unaffordable professional solutions (e.g. mistika ultima and baselight), which often make use/profit of the advantages of free software as an indispensable base for really powerful high end products, but do not like to give much in return to the concerned community. as a result, linux is perhaps the most common working horse in real demanding production environments in the film industries, but for ordinary users of this platform there aren't much satisfying options available. we still have to beg servilely for the most natural features and more acceptable support of our common working environments.

but that's just one side of the coin. in practice i still appreciate any attempt, to treat this alternative operating systems just in an equal manner -- although it may only a affect a very small user community and doesn't promise much economic profit. BMDs recent efforts, to make resolve finally usable on common linux machines, is a really estimable and encouraging signal in this regard. i'm rather happy about this development, and don't begrudge them any studio sales.

nevertheless i still think, that the rigorous rules of the GNU public license and the protection of open source software against absorption by profit driven interest and exclusion of access still makes sense. this kind of radical thoroughgoingness may look again a little bit nostalgic and out of fashion in the meanwhile, but linux could hardly have been created resp. survived without this kind of clear rules. limiting the utilization of valuable free software by closed source products, is more or less the nucleus of this approach. it usually isn't a very powerful mean, because there are many ways to bypass and ignore this intentions, but to some degree it even stand the test in real world. and if you accept this simple idea, my previous post shouldn't look utterly crazy and indefensible.

but it's perhaps also worth noting, that the GPL was never intended against economic utilization of software, but just emphasizing the freedom of users to adapt and improve existing solutions to their needs. support for ffmpeg in resolve is IMHO a very well example for this issue. in 'free' software of GNU manifestation it could be realized quite easy by any average software developer, but in the case of 'free beer' software, we can just debate our discontent and powerlessness in this regard in endless circles...

Being able to access ffmpeg from Resolve would be great, rather than constantly having to go over the extra hurdles manually doing conversions to prescribed formats outside of Resolve.
Has there been any update regarding documentation for the new scripting API that is supposed to exist in 15?

Currently Fusion does not install Ffmpeg, but it can allow non compliant input files to be pointed to an installed Ffmpeg, for importing into Fusion. Therefore there appears to be no reason that Resolve could not also use this method.
As for exporting, Resolve could just point to an installed Ffmpeg. Of course this would mean the user would have to add all the required Ffmpeg encoding parameters for it to work. There is certainly enough information on the web about using fffmpeg directly. This way BM would not have to become involved in supporting that side of their software at all.

The alternative would be to use a process known as frameserving. This technique transfer audio/video data from one application to another without doing a full encoding. Its generally done by using a fake AVI container that can be opened by other encoding programs.
Anyway this discussion could go on forever, but it seems to me that many users do require a lot of formats that Resolve does not currently support and probably never will, and this seems an easier solution for those users.

Frame serving may not be a solution, since DR is developed multi-platform. But since standalone Fusion is already supporting ffmpeg, I suppose it would be possible to integrate that.
Have some patience, Fusion integration is still in an early stage!

Best solution is to add support in the form that data is passed to ffmpeg (eg. as 16bit RGB or YUV user selectable). It's in the export GUI, but user have to download and point to ffmpeg by himself. This takes any licensing etc responsibility out of BM. This is exactly how some apps do it.

well -- perhaps not on the linux platform -- but it's even much more targeted against the "advanced" edition and similar unaffordable professional solutions (e.g. mistika ultima and baselight), which often make use/profit of the advantages of free software as an indispensable base for really powerful high end products, but do not like to give much in return to the concerned community. as a result, linux is perhaps the most common working horse in real demanding production environments in the film industries, but for ordinary users of this platform there aren't much satisfying options available. we still have to beg servilely for the most natural features and more acceptable support of our common working environments.

I'd not call a 300 buck product "unaffordable", given what Resolve Studio offers. I got a 2nd hand dongle for 160, for my hobbyist NLE work. And nobody forces you to buy it. Their free version offers most features of the studio version. If they wouldn't offer a linux variant, there were less options for linux users. You're also don't "have to beg", just use something else if DR doesn't fit your requirements. As far as BMD doesn't violate any licenses and terms of use, they don't owe anybody anything, besides their paying customers.

nevertheless i still think, that the rigorous rules of the GNU public license and the protection of open source software against absorption by profit driven interest and exclusion of access still makes sense. this kind of radical thoroughgoingness may look again a little bit nostalgic and out of fashion in the meanwhile, but linux could hardly have been created resp. survived without this kind of clear rules. limiting the utilization of valuable free software by closed source products, is more or less the nucleus of this approach. it usually isn't a very powerful mean, because there are many ways to bypass and ignore this intentions, but to some degree it even stand the test in real world. and if you accept this simple idea, my previous post shouldn't look utterly crazy and indefensible.

While I do appreciate your "open source spirit", you seem to be misunderstanding how the open source/free software ecosystem works. Without closed source software running on top of open source operating systems/middleware stacks/libraries, the market cap and hence the investment from involved parties would be much less. Just look who the main contributors for big OSS projects are. That's full time coders paid by companies monetising open source solutions. In an ideal world, everything would be OSS/FS, but that's not how current economy works. So your "all or nothing" approach is a bit naive. The trend goes into the OSS/FS direction, and that is a good thing. Open source companies acquire software, and release it to the public in a "free as in speech" manner (like Red Hat did with a lot of products). Many companies realise that they can make a living from support agreements, and open up their source. But still there are niches, where companies want to protect their value. Also there are more licensing options besides GPL. That's where BSD, LGPL, CC etc comes into place. And the community still profits, because one can use an open platform and run a closed NLE/CG suite on it. I'm all for options. If linux users were only allowed to run GPL software on top, we wouldn't be anywhere close to the point where we are today. Databases, SAP, Android, in-house software on top of LAMP/Jboss/etc.. There are endless examples. Don't get me wrong, I'd love an open sourced DR, and would still pay for it (donation, support, whatever). But it's just not realistic to expect every closed source company to release their source. Things will become commodity over time, with open source alternatives getting better. If you're unhappy with the BMD offering, just go ahead and submit code for open source alternatives. That would be time better spent than your personal vendetta vs BMD.

Yep, good point. If you want something specific in ffmpeg they will tell you to add it yourself or sponsor it. There is not that much in ffmpeg which is done "for free". There is quite a bit done by BBC employees, so as you said- people do get paid for their work. So as far as it's open source there is still a lot of money involved.

An old thread (which should really be in Feature Requests), but I'd like to add my +1.

I was just reading a thread on this forum indicating that Resolve's h264 falls behind x264, making me think that it would be very nice if one could go direct from Resolve to ffmpeg, without having to first export to an intermediate format.

I am sure there are other cases where ffmpeg's enormous flexibility and power would prove very useful. Therefore I'd love to see an ffmpeg option in the Deliver page of Resolve on all platforms. User would install their own copy of ffmpeg, point Resolve to it, and provide the command line arguments in a text box.

This would greatly increase the flexibility of export options, at very little development cost to BMD. To further minimise costs, I could see BMD providing such an option without support.

Its now more than 2 years since I suggested this and its been interesting how many time users have had problems importing and exporting certain codecs with Davinci Resolve in that time. Almost all of these issues could have been addressed with Ffmpeg.
Of course it could be a totally separate plugin if necessary, and even if there was a charge involved, I sure many users would take up the offer. Mind you if there was a charge, BMD would have to support it, where as they would not have to do that if it was just a link to Fffmpeg.
It would just add so much more flexibility to Resolve and save the development team quite a number of headaches in the long run.

+1

+1

+1

After my zoom topic I will add +1 too .
looks like we really need that compression.

You can already use FFMPEG in Resolve through the Reactor plugin. You guys must be talking about "official" support?

Screen Shot 2020-06-26 at 1737 1.png (218.36 KiB) Viewed 7807 times

You can already use FFMPEG in Resolve through the Reactor plugin. You guys must be talking about "official" support?

Have you actually got this working in Resolve?

Because so far as I can see, all the Reactor package does is install FFMpeg for the user. Intended to be used in Fusion Studio, where ffmpeg support is available. I believe the Reactor package is intended as a convenience for Fusion Studio users, providing them with a ffmpeg installation, saving them the trouble of installing it themselves, and also making sure the correct version is installed (in terms of having shared linking, rather than static). It also makes sure that Fusion can see it, via a PathMap link.

Resolve Fusion page Saver nodes are crippled compared to Fusion Studio, in that they only save EXR files. This blocks Resolve from accessing the full export formats of Fusion, and therefore there's no access to ffmpeg. I did re-test this after installing the ffmpeg Reactor package, but nothing changes that I can find. DR Fusion page Saver nodes will still only output EXR.

I've even tried copying an ffmpeg Saver node from Fusion Studio and pasting it into Resolve, but it fails as soon as you try and use it. Likewise a Loader node pointing to a file that requires ffmpeg (eg an MKV file) just does nothing in Resolve.

It's frustrating because so far as I can see, ffmpeg does still exist in Resolve's version of Fusion. The other day I scanned the Resolve binary for references to 'ffmpeg', and they are in there. But they appear to have blocked use of it by changing how Loader and Saver nodes work. Whether that was deliberate - they don't want Resolve to have access to ffmpeg - or just a side effect of the changes they made to Loader and Saver as part of integrating Fusion into Resolve, I don't know.

It'd be excellent if this does work, and please do let us know how if it's possible. But I couldn't find any way myself.

External FFmpeg integration is only available in Fusion Studio at this time.

Any script in Resolve that runs FFmpeg will have to render frames to disk first in Resolve, then run FFmpeg. The FFmpeg installer in Reactor is just for convenience, it doesn't add generic FFmpeg support directly inside Resolve.

So, as I understand it there is now on open API (correct me if I am wrong) for rendering in DR 17. Maybe some open-source devs will undertake it to create a plugin for FFMPEG.

I assume it will happen sooner or later.

+1

+1

+1
Just to loop back to this - if Ffmpeg could be made to work with Resolve on Windows, it would allow me to write proper wav files for Maya. We do CG Animation, and currently (for whatever strange reason) the wavs Resolve writes are not signed or formatted properly and can't be read by Autodesk Maya. We have to export from Resolve, drop into Audacity, and batch render them out again. I also change them over from stereo to mono in that process, which would additionally be a nice option to have natively.
I also can't export a jpg image or image sequence from the delivery tab, nor PNG.
Seems like Ffmpeg could open up a lot more options for encode and possibly decode as well, to fix some of these types of issues. You all know how it is - editing formats and the nuances within change super quickly and having a secondary option would keep things nimble.

+1

I also can't export a jpg image or image sequence from the delivery tab, nor PNG.

This has changed by now.

We really need an ffmpeg support for render!

i need use this to copy stream

ffmpeg -i 1.mp4 -c:v copy -c:a copy test.mp4

i want to cut some bad moments in clip and export it without re-coding

just copying the stream like a can do this in different other programs for example xvid4psp

can i do it in davinci ?

Find a programmer, start donation campaign and done.
Many will give a dolar for sure
It can be done- export API is there. BM will never do it themselves, don't count on it.

It's a grey zone anyway.
Since ffmpeg contains codecs that are not licensed for it, it is only tolerated as long as it's completely free. Integrating it into a product to pay for can cause trouble. There once was a commercial product by a Spanish company called CineMartin, which got pulled pretty fast.

BM could still do it as long as their version would not have any codec which is proprietary.
They provided export API and 99.99% they will never do ffmpeg integration themselves.

Find a programmer, start donation campaign and done.
Many will give a dolar for sure
It can be done- export API is there. BM will never do it themselves, don't count on it.

I'm surprised no one has tackled this yet. Either for a commercial product (just means that you can pay for it), or free and open-source.

I tried this solution from viewtopic.php?f=21&t=125058, but it's very limited. I was ready to purchase it, but the limitations held me back.

I'd gladly pay for a product that integrates FFMPEG directly into Resolve. It would save me time and disk space. On Windows 10, exporting H.264/H.265 files is horrible since it relies on the host system's codecs, which leads to poor results (to be very polite).

Currently, I export using the GrassValley format, then use an FFMPEG script to transcode to x265, and set a higher bitrate for AAC audio (which is also limited in Resolve on Windows 10). with :

-c:a aac -b:a 384k -c:v hevc_nvenc -preset slow -rc-lookahead:v 64 -cq:v 22 -pix_fmt p010le

Using handbrake with a preset is good too, or a GUI for FFMpeg like the simple open source nmkoder, but I'm so used to this workflow now.

On Windows 10, exporting H.264/H.265 files is horrible since it relies on the host system's codecs, which leads to poor results (to be very polite).

That's true only for the free version of DaVinci Resolve on Windows. If you're using the Studio version and since you have a 3090 you should be able to set the encoder to NVIDIA, then set Rate Control to Constant QP. Set the Constant QP IBP values to something a little lower, like 15.

Currently, I export using the GrassValley format, then use an FFMPEG script to transcode to x265, and set a higher bitrate for AAC audio (which is also limited in Resolve on Windows 10). with :

Code: Select all

-c:a aac -b:a 384k -c:v hevc_nvenc -preset slow -rc-lookahead:v 64 -cq:v 22 -pix_fmt p010le

That's not using x265. The -c:v hevc_nvenc parameter is telling it to use the Nvidia H.265 encoder, which you can literally use directly in DaVinci Resolve Studio.

I have it with -hevc_nvenc

I have two sets of settings. One with the -preset set to "slow" and another set to "medium." I fine-tuned these a while back, allowing me to choose between slightly higher quality with a higher CQ or a (relatively) smaller file size. Or faster encoding with a lesser quality. It depends on the video.

Previously, I also had a third set with software encoding, but I dropped it after discovering the -rc-lookahead 64, which works well with a lower CQ.

I used to constantly tweak my settings, always chasing perfect results and smaller files. I was a bit obsessed with pixel peeping, a huge waste of time. It just impossible to have something "perfect" anyway, because each frame is different anyway.

Ideally, I'd love to see these types of controls on the Delivery page, with integrated ffmpeg support. It would save me the extra step of exporting first with the Grass Valley codec.

I would like ffmpeg support too of course. I'm just saying that you can use the exact same encoder in Resolve Studio as you are currently using in your ffmpeg example. It's just a matter of tweaking the settings to match as they're both hevc_nvenc. The only thing you won't be able to replicate is the AAC bit rate for the audio stream.

I would like ffmpeg support too of course. I'm just saying that you can use the exact same encoder in Resolve Studio as you are currently using in your ffmpeg example. It's just a matter of tweaking the settings to match as they're both hevc_nvenc. The only thing you won't be able to replicate is the AAC bit rate for the audio stream.

I switched to this workflow because I'd had too many cases where glitches appeared in exports when 'Key Frames' was set to auto. In the past, I'd reduced it to 1, which worked, but of course, the file size became much larger. At least the glitches stopped.

Eventually I stopped trusting Resolve to export anything reliable in h264/265 on my Windows 10 machine at the time, I didn't realize it was because it was using the host's meh encoder. I spent hours trying to figure out what was wrong, thinking it was the transitions, the Fusion comps, or something else in my timeline. It just wasn't worth the risk.

When I finally read about what the 'Key Frames' setting actually does it clicked. I understood why these glitches were happening. On some quick transitions, call-outs, etc. But not always at the same place because I was changing things around.

Anyway, since then, I haven't had any issues, using HandBrake and ffmpeg instead.

Sometimes I still export in h264 from Resolve when I'm editing quick videos that just need to be shared somewhere, using auto settings, and I don't really care if a frame glitches. I haven't noticed any issues but I don't do QC on them either. Maybe something changed internally, but I just can't trust Resolve for that.

That said, this 320 Kb/s limit in the export settings with AAC is still a problem. They bumped the bitrate, but most peole don't know that it won't do a thing on Windows 10. I asked in another thread months ago to maybe revert to the previous "max" for Windows 10 users, so they are not mislead.

Eventually I stopped trusting Resolve to export anything reliable in h264/265 on my Windows 10 machine at the time, I didn't realize it was because it was using the host's meh encoder.

That's my point; it's NOT the host/Windows encoder if you explicitly set it to NVIDIA in your render settings. Then it's exactly the same encoder as you're using in your ffmpeg example.

There are still a lot of cases when Resolve exporter is not good enough and ffmpeg integration would be very useful. It got better over time, but still far from covering all requirements from different clients. If you start delivery to bigger places with strict rules then it quickly "fals apart" and lacks needed options.

You have to be careful with default ffmpeg settings as sometimes they are not very good and you need to tweak more than just a bitrate It's a powerful tool, but needs extra attention.

Eventually I stopped trusting Resolve to export anything reliable in h264/265 on my Windows 10 machine at the time, I didn't realize it was because it was using the host's meh encoder.

That's my point; it's NOT the host/Windows encoder if you explicitly set it to NVIDIA in your render settings. Then it's exactly the same encoder as you're using in your ffmpeg example.

I get what you're saying don't worry, but it doesn't matter because at the end, the audio side is still a problem anyway. I look at the whole picture, and my past experience (and what I read over the years on this very subject on the forum, it's not good).

All of this just isn't worth the hassle for me. It's outdated, underwhelming, and frankly, pretty archaic. FFmpeg and HandBrake have been reliable for years, there's no comparison with Resolve's export with h264/5. Even if there are good settings to use to get it there right most of the time, I don't trust it anymore.

I hope that something eventually changes in this area. Right now, we're stuck way in the past, especially on this particular issue. Open-source solutions have been available for years, yet there's been no effort to integrate them into Resolve.

If the issue is a licensing problem, I'm sure there are many people who are willing to pay a bit extra for BMD to develop an official integration of FFmpeg. I've seen it done in the past in other programs over the years, for different things because of licensing.

As a consumer, I don't care about the licensing details or why it is like it is today. I just see things stagnating while other things around move forward, adding new integrations, while BMD remains stuck on this particular point.

I always found it weird to have this amazing piece of software with the worst way possible to export basic h264/5 video files with proper audio, poor controls, etc.

It's still crazy to me that all the tools are out there, and nobody who has the coding knowledge took the opportunity to do something, when the user base of Resolve is growing so much. Either as a commercial 3rd-party plugin/tool or a free open-source 3rd-party plugin/tool.

This whole comment is not a response to you in particular btw but just my general view on the subject and mostly targeted at BMD

Open source community is not really that keen on providing something for big company
They much quicker do something new for ffmpeg, avisynth etc. Best bits are done from the passion and for the sake of "doing it" (or as well paid task).

There is quite good solution for Resolve out there now in form of MainConcept plugin. For this who need more export options it's a must addition. It's well proven solution which powers 70% pro and enterprise apps out there.

I second the MainConcept solution. They are behind Adobe's AME, BTW, just to note before someone cries "Premiere Pro is doing it better".
Apple is using their own encoders with Compressor, and they aren't bad either. Some folks keep a Mac mini around only for encoding, while working on a fully loaded PC for their creative work.

So, if you don't like to export a master version in a mezzanine codec and then use HandBrake for the distribution version, get one of those solutions. The integration of ffmpeg is not going to happen. Period. Licensing issues are much more complex than you think.

MainConcept is behind probably 70% of pro and enterprise tools out there (Adobe, Autodesk, Telestream, Vegas, Avid, cloud transcoding services, etc.). It's not the best, but it's proven and stable solution which produces files acceptable by clients.

update: their website claims 90% coverage of pro world. Probably bit exaggerated, but it's used a lot.

hi,

for export you have https://www.voukoder.org/ and this https://github.com/UDaManFunks

regards

I think the easiest way to get ffmpeg compatibility would be to create a frame server plugin for Resolve. The plugin would present raw video frames and PCM audio in a dummy “file” that any encoder could load and convert to the chosen format. I remember several in the past that worked with Premier and other NLEs, though I can’t remember their names.

Yes, this is simple and good way, but only for those more advanced.
Most people want GUI and parameters which they understand (markers support etc.).

With a frame server you could use just about any conversion program, not just ffmpeg.

Any? I know only few which support piping and all are open source.

One that I used many years ago was the DebugMode Frame Server. It would create a dummy AVI file that could be opened by "almost" any conversion program.