fix(server): avoid transcoding thumbnail streams

[mincrmatt12]

Currently the only property of video streams used when picking one to transcode is their lengths (always trying to select the longest one). Certain video formats embed thumbnails as "video" streams but then don't report back their lengths in frames via ffprobe.

For example, some WMVs from an ancient camera of mine have an embedded thumbnail as stream 0 and the actual video as stream 1, but ffprobe doesn't report an nb_frames for either so they both get treated as length 0 and the first one is selected, which causes ffmpeg to explode.

This patch adds a second layer to the sort for "main video streams", where if two streams are of the same length but one was marked by ffprobe as having the disposition attached_pic (which is used for video thumbnails), the one not marked as attached_pic is preferred. In this way, ffmpeg is given the correct stream and successfully generates a transcoded version of my ancient WMVs on a test instance. I wouldn't be surprised if this is the problem behind #11100 as well, but there isn't enough information in that report to check.

Currently the only consumer of this new holdsThumbnail property is the transcoding logic; there is probably some more intelligent way to use it when generating our own video thumbnails but I have not explored that here.

[mincrmatt12]

Just checking, am I supposed to do something about the CI failures on this? I don't see any useful error on the erroring job.

[mertalev]

The GH runner ran out of storage apparently 😅