Video thumbnails

[Dirk Hohndel]

> On Jul 6, 2018, at 2:56 AM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at> wrote:
>> 
>> To produce thumbnails (which seems to be even more urgent) I looked again
>> into ffmpeg and that appears to be the tool of choice: It is available for
>> all relevant operating systems, many users probably already have it
>> installed (e.g. as part of VLC) and if not installing it is pretty straight
>> forward (if no patents prevent you to do so but that would not be our
>> problem). We would simply have a preference with the path to the ffmpeg
>> binary. Then (maybe triggered by the user) we could run a command like
>> 
>> ffmpeg -i myvideo.avi -vf fps=1/60 img%03d.jpg
> 
> That is indeed my plan B - given that Qt turned out to be not nearly as 
> helpful as I would have expected / hoped. As I have mentioned in a PR, my next 
> attempt will be using the ffmpeg project's LGPL libraries libavcodec and 
> libavformat but we should definitely also consider the option of calling an 
> external application. That might be less of a hassle.

The advantage of calling an app vs. linking against the libraries is that for
calling an app we need to tell the user how to do that, vs. for shipping the
libraries we need to build them on all the platforms, integrate them into our
package and deal with the potential licensing / patent pain created by that.
You can guess which way I'm leaning here :-)

> Concerning shipping with either ffmpeg or one of its libraries, they provide a 
> mini-FAQ here:
> 
> https://www.ffmpeg.org/legal.html
> 
> Not sure what to make of that (since we're neither private nor commercial 
> users).

Yes, that's part of the problem. While typically the license holders don't go
after "small projects" - if they decided to do so, the person creating the
binary distribution and providing it for download is the likely target of such
legal action. And that makes me even more excited about a solution where
all we do is call external software that we didn't ship.

/D