Re: [FFmpeg-devel] Discussion of all-inclusive full stack builds
On May 12, 2019, at 4:14 PM, Reimar Döffinger wrote: > > On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote: >> On May 12, 2019, at 11:54 AM, Nicolas George wrote: >>> >>> Tim Jones (12019-05-12): >>> >>>> --disable-all-proprietary/--enable-all-proprietary >>> >>> As for this one, on the other hand, there will be opposition: we do not >>> want encourage users to use proprietary software. In fact, there is >>> currently a discussion to refuse including new proprietary components, >>> and possibly getting rid of the ones we included without thinking. >> >> I don't want to start a thread war here, but isn't the purpose of any >> toolchain to allow for the support of a given task? If there isn't a FOSS >> option and an easily obtained proprietary solution exists, why block it? >> >> This is one of the things I hear from new Linux users when running into the >> FOSS vs. proprietary brick walls - they just want a platform that works. >> The FUD that is continuously promoted concerning adding non-FOSS components >> - Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device >> drivers - has caused a number of potentially large Linux opportunities to >> move to Windows. >> >> I've long been a proponent of FOSS where it is apropos, but I also >> understand Heinlein's TNSTAAFL :) . > > Well, which is a fairly good argument to enable proprietary components > only in specific cases. Which is why I asked in my original question if an optional config setting had been discussed previously. If autodetection is an issue "in general", then the option should be to --disable-external, or my --disable-all-proprietary, by default. This flag could then be reversed by the builder to include any external/proprietary libraries found with the understanding that if something is broken, the builder must revert to the --disable-external config and rebuild before attempting to report a bug or other problem. Then it would be up to the builder to determine which of their external features/libraries were causing the build failure or problem. We do this with a few sensor-specific library collections I work with on the Arduino and Raspberry Pi platforms. The user builds with the defaults - if it works, add their custom sensor packages. If it breaks, report that to the creator of your custom sensor module package instead of the upstream team. Works perfectly in each case and the primary team doesn't have to worry about that new hydrology sensor that has added salinity levels to the mix (which we don't even know about). -- Tim ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Discussion of all-inclusive full stack builds
On May 12, 2019, at 11:54 AM, Nicolas George wrote: > > Tim Jones (12019-05-12): > >> --disable-all-proprietary/--enable-all-proprietary > > As for this one, on the other hand, there will be opposition: we do not > want encourage users to use proprietary software. In fact, there is > currently a discussion to refuse including new proprietary components, > and possibly getting rid of the ones we included without thinking. I don't want to start a thread war here, but isn't the purpose of any toolchain to allow for the support of a given task? If there isn't a FOSS option and an easily obtained proprietary solution exists, why block it? This is one of the things I hear from new Linux users when running into the FOSS vs. proprietary brick walls - they just want a platform that works. The FUD that is continuously promoted concerning adding non-FOSS components - Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device drivers - has caused a number of potentially large Linux opportunities to move to Windows. I've long been a proponent of FOSS where it is apropos, but I also understand Heinlein's TNSTAAFL :) . -- Tim ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH][TESTERS WANTED] avfilter: add apitch filter
On May 12, 2019, at 11:51 AM, Nicolas George wrote: > > Paul B Mahol (12019-05-12): >> Calling atempo filter atempo when it also modifies pitch is bad for users and >> at same time not having apitch filter, user would think that they can >> not alter pitch. >> Sorry if you can not understand my fears. > > As I have pointed to you (but you made a show of misunderstanding on > purpose), changing the pitch and changing the speed of an audio signal > are fundamentally the same thing, they are connected by the sample rate. > > In my experience, most people are aware of that, including completely > non-technical people: they know that if you speed up or down a sound, > its pitch changes. Coming from the audio world, tempo, and pitch are different things. Using a smart algorithm. I can speed up the tempo of clip without changing the pitch. Or, inversely, I can modify the pitch without changing the tempo. We look at "tempo" as beats per period (usually minutes). We look at pitch as the "tone and timbre" of a given sound (transposing a note from D to F#, for example). > The documentation, of course, can be enhanced to make sure it contains > all keyword a user is likely to search. And if the options can be > tweaked to allow setting exactly the wanted output in the most > convenient way (like we have a setdar, even though only the SAR exists > in the library), it is even better. This would be helpful since I had previously looked into adjusting the playback rate without the associate "Alvin and the Chipmunks" effect and didn't uncover anything within a deep DDG and Google search. -- Tim ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Discussion of all-inclusive full stack builds
Hi Folks, I've long been a fanatic for ffmpeg and now have the bandwidth to dip my toes into the developer pool. My primary experience is in file I/O in C, C++ , and Python, and I force my team to pay close attention to smaller-is-better refactoring. With the enormous number of config options, newcomers to the development side of things (yes, that means me, too) can find the inclusion of a specific capability to be quite daunting (and I've been coding since before autoconf existed). Has anyone previously discussed or offered up a simplified set of config macros for something like: --disable-all-proprietary/--enable-all-proprietary I have run into situations where I've needed to recompile to meet a specific situation that could have been easily handled by simply enabling everything - regardless of it's status as FOSS or proprietary. If such a build level were created, would there be a recognizable performance hit with such an option? -- Tim ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
