m4tt075 commented Jan 9, 2019
@ymartin59 @cytec I've been reviewing this thread. Here my takeaways:
Synology has been disabling DTS (= dca) and e-ac encoders and decoders in their ffmpeg builds for some time already
We have some indications why Synology had to do that, but it should not matter to us. I understand that those encoders and decoders are compatible with the GPLv3 license. As such, we should be able to keep them in our builds.
Apparently, in the past, Synology's VideoStation has been able to "sideload" 3rd-party ffmpeg packages, but it seems that this is no longer possible.
There seems to be a "hack" to allow newer VideoStations to sideload 3rd-party ffmpeg packages, but not always and not for everybody (might indicate platform dependencies, and we know that Synology does heavily patch ffmpeg, at least for some architectures)
There is an idea to resemble the Synology ffmpeg builds as closely as possible, only enabling the missing en/de-coders, but it is not (yet) clear whether those builds would then be "accepted" by VideoStation as valid.
My conclusions:
We ship ffmpeg as standalone package, and as dependency for chromaprint, comskip, rtmpdump and tvheadend.
I believe we should focus on optimally supporting these packages. This includes keeping ffmpeg up-to-date with upstream.
I would not focus on trying to resemble the (mostly outdated) ffmpeg versions Synology is shipping, to work-around VideoStation limitations.
As such, I'd just update our ffmpeg package, keeping "e-ac" and "dts" codecs, but nothing else
Do you agree with this approach?
Note to those trying to resemble the Synology ffmpeg builds:
I believe Synology is publishing their source code (including ffmpeg) here:
https://sourceforge.net/projects/dsgpl/files/Synology NAS GPL Source/
I'd use that as starting point...
