Blackmagic Forum

Can't render PAL mpge2 decoding format。
The mov format renders aac audio, the audio options are too few, and the sound quality is relatively poor, failing to meet the broadcast requirements.
No render dvd format presets

What formats are you missing requiered for broadcast? maybe you need a codec pack from a third party
As for the dvd part, Resolve does not yet include dvd/Bluray authoring /as far as I know) so you will need a third party application for that. Hope this at least helps you a bit on the way to a solution

I can't find a decoder package that I can use. Is there a free pass decoder package?

Does the following davinci resolve achieve this?
Video: MPEG-4 AVC, 720x480, 29.97 fps, 1 pass CBR (constant bitrate), 4500 kb/s and Audio: MPEG-4 AAC (LC), 48000 Hz, Stereo, 384 kbps.

wutongdegugeyouxiang wrote:I can't find a decoder package that I can use. Is there a free pass decoder package?

Does the following davinci resolve achieve this?
Video: MPEG-4 AVC, 720x480, 29.97 fps, 1 pass CBR (constant bitrate), 4500 kb/s and Audio: MPEG-4 AAC (LC), 48000 Hz, Stereo, 384 kbps.

Hello again
Seems like you will need another tool for this, what aplication ar you using to autur the DVD, check what input formats it supports and exsport that from resolve

I'd love to be able to render H264 into either .mov or .mp4 on Linux. I'm guessing it's a licensing issue?

David Franzo wrote:I'd love to be able to render H264 into either .mov or .mp4 on Linux. I'm guessing it's a licensing issue?

Not really.

Implementing the ffmpeg libraries would provide for all that.

The supported codecs lists QuickTime as having the ability to decode and encode H.264 on Linux. I have ffmpeg installed as well as the x264 libraries (not that they play a role I suppose). Running DaVinci Studio 15 on CentOS and I’m not seeing H.264 as an option. There’s MPEG-4 but I’m pretty sure they aren’t the same thing.

Cheers,
Mike

Technically, BMD can pick their solution if they want to. Handbrake, for one, does excellent x264 / hevc encoding on a Linux with ffmpeg libraries - far better than the native Resolve export, in fact.

Should BMD go down this route, imagine that. Resolve on Linux would have a host of new ins and outs, everything native users would logically expect. Throw in MESA support, and you get one powerful NLE.

I’d be curious as to why they aren’t going through with implementing ffmpeg (yet). It’s been radio silent and even just doing an internal build separate from system files or packages would open so many doors here for ingest and delivery. It’s a tried and true solution so I can’t see the business issue here.

I’m not sure but I don’t think if they did provide ffmpeg they can distribute it with the non-free codecs built. Particularly with GPL licensed work (aka libx264). This could possibly be why. If they have a commercial copy of libx264 then it wouldn’t matter but I don’t think they do. And GPL licensing has always been weird to me.

Cheers,
Mike

Since BM is using ProRes encoding on the PC under license from Apple, there might be another licensing issue: ffmpeg is using non-approved ProRes.
So it might be part of the Apple contract not to integrate ffmeg. Remember, Apple could stop such encoding in ffmpeg any time they like, as they did for commercial products like Miraizon.

Prores enconding is already in the Linux port, the Advanced Panel version. They'd need not ffmpeg, if that'd be a problem.

For sure, ffmpeg can be compiled to use the nonfree codecs. At that point, it should be the end user's responsibility. BMD may be unable to provide with a complete out-of-the-box ffmpeg solution. A solution would be to leave at the discretion of the user - whether they want to use ffmpeg or not.


The radio silence on BMD's part is nothing new. The Linux port is the red-headed stepchild, which they are trying to figure into the overall "offer it to everybody" plan with Resolve. Since the end of v12's development cycle, there's been an effort, by BMD, to bring that port as a free version to interested users, without much of a warranty.

It was a no-win situation at first. The only real way to accumulate data out of the Linux ports functionality was to release it. This meant putting a spotlight on the solutions in the turnkey system. After the initial euphoria, people found it difficult to install on various configs. The audio required BMD I/O, which was less than liked. For casual users, the Linux port seemed to come with inherent restrictions and a nightmare setup.


A year later, BMD unveiled v15, with system audio output. The install can still be a handful, but at least the port has progressed on the interim. This suggest the Linux port plays into BMD's overall plans with Resolve. However, turnkey legacy is still felt with the lack of MESA support, which directly limits the amount of compatible configs - and ffmpeg.

Both of these I could foresee, if BMD can figure out how to implement them, given they'd both have a positive effect to virtually all Linux port users. They seem to like ubiquitous fixes; such things certainly justify the effort spared better than fixing one thing on a certain distro. We'll see.

If BMD just supplied all the ffmpeg and codec sources with a build script that did all the work (assuming we have all the necessary tools locally), I think they could get around the licensing issue. Personally, I’d be totally down for that. Or at least set an ffmpeg version and let us link to it in Resolve.

Cheers,
Mike

MikeRochefort wrote:If BMD just supplied all the ffmpeg and codec sources with a build script that did all the work (assuming we have all the necessary tools locally), I think they could get around the licensing issue.

Actually all they need is an open interface for a frame server both for input and output.
Then we can write a filter to marshall to and from their required frame format.

Cary Knoop wrote:Actually all they need is an open interface for a frame server both for input and output.
Then we can write a filter to marshall to and from their required frame format.

That’s definitely the cleaner method. My suggestion was more from the standpoint of if they wanted to support 1 version of ffmpeg and wanted it to be uniform regardless of the user/distro. But being able to plug our own in would be a much simpler choice and it doesn’t fall on them to provide anything.

Cheers,
Mike

Cary Knoop wrote:Actually all they need is an open interface for a frame server both for input and output.
Then we can write a filter to marshall to and from their required frame format.

i'm not sure, if this should be seen as a really satisfaying solution?
frame servers are usually not the optimal solution, if you want to preserve metadata, timecode and audio tracks as well. and frameservers are usually not the most efficient way to implement this kind of desires.
but this approach would indeed provide a kind of process isolation, which is necessary to comply with the GPL and similar licensing restrictions.
utilizing the already available openfx-io plugin, which would just need additional sound support, would otherwise look more attractive to me.
anyway -- i would really appreciate any kind of improvement in this regard too.

Martin Schitter wrote:

Cary Knoop wrote:Actually all they need is an open interface for a frame server both for input and output.
Then we can write a filter to marshall to and from their required frame format.

i'm not sure, if this should be seen as a really satisfaying solution?
frame servers are usually not the optimal solution, if you want to preserve metadata, timecode and audio tracks as well. and frameservers are usually not the most efficient way to implement this kind of desires.
but this approach would indeed provide a kind of process isolation, which is necessary to comply with the GPL and similar licensing restrictions.
utilizing the already available openfx-io plugin, which would just need additional sound support, would otherwise look more attractive to me.
anyway -- i would really appreciate any kind of improvement in this regard too.

It's certainly not trivial and for BM there has to be a convincing business reason to invest in this.

However with a frame server interface you would be able to render 4K or 8K feature films over multiple computers, a small market segment but one with dollars to spend.

Cary Knoop wrote:It's certainly not trivial and for BM there has to be convincing a business reason to invest in this.

you are right -- but BMD wouldn't be the first company, which outsourced the codec handling to a third party provider. autodesk did exactly the same, to concentrate all their development resources on more important tasks concerning their own products.

and the OpenFX interface is one of the few possibilities and well established standards, which really works on all platforms and in almost any professional video software.

Martin Schitter wrote:utilizing the already available openfx-io plugin, which would just need additional sound support, would otherwise look more attractive to me.

btw.: it's a very strange and unhappy coincidence, that the author of the mentioned 'OpenFx-IO' just today had to write a very alarming cry for help to the open source community, whereas we all celebrate our happiness about closed source software on the linux platform...

https://forum.natron.fr/t/building-a-co ... ystem/2150

it's really an important problem, that davinici resolve and fusions success isn't only a challenge to commercial competitors. it also weakens the interested in really outstanding non-commercial open source alternatives, like natron, a lot.

and while BMD is usually eliminating all the sorrows of the victims on the commercial side by simply purchasing their companies, it's harder to guess, if they have adequate answers for core developers of open source software too?

just asking for the integration of valuable open source components and more satisfaying linux support is therefore perhaps not the most forward looking strategy to support the open source ecosystem in the long run. this is why i would prefer to see a solution, which is of of real benefit to both side, much more, than just another attempt to bypass the GNU license resp. the respectable interests of the open source community in any tricky manner...