Support for extracting a series of video thumbnails

[ReallyVasiliy]

This PR adds support for extracting thumbnails/frames from video as Bitmaps, while applying an optional set of filters.

VideoThumbnailExtractor serves as the entry point, and requires ThumbnailExtractParameters which defines the extraction behavior and other parameters.

One behavior, MediaMetadataExtractionBehavior (based on MediaMetadataRetriever), is included. The intent is that other behaviors can be added by consumers -- for example, consumers might opt to provide a custom FFmpeg-based or MediaCodec-based extractor, which may yield performance or functional improvements over MediaMetadataRetriever, while still retaining the ability to apply video filters to extracted frames.

Demo app has an example of creating a "film strip":

[izzytwosheds]

Since we are preserving original aspect ratio, passing a resolution (smaller dimension) should be better. What happens when destSize's aspect ratio is different from video's? Or should we just scale the video to fit destSize like when we do in transcoding?

[ReallyVasiliy]

Let me add this image just so we're using the same language around this

passing a resolution (smaller dimension) should be better

Can you clarify what you mean by resolution? Do you mean we would perform "aspect fit" scaling instead of "aspect fill"?

What happens when destSize's aspect ratio is different from video's?

Right now it will scale with "aspect fill": the video frame will be resized and cropped to fill the destSize area, and the aspect ratio of the video frame is preserved.

[ReallyVasiliy]

Actually, do you mean we should do this? --

1. the resulting bitmap will always have the same aspect ratio as the source video (i.e. we won't add any whitespace/padding)
2. instead of "destination size", we pass in something like "maximum width" and "maximum height"

[izzytwosheds]

Originally, I was thinking of doing this:

• thumbnail bitmap will have the aspect ratio of video
• by default, thumbnail will also have a resolution of source video (true frame preview)
• optionally we can pass the "resolution" parameter, thumbnail bitmap's smaller dimension will be equal to resolution. This is closer to how video is defined on Android - resolution + rotation in 90 degree increments.

For thumbnail use case, it is probably reasonable to aspect fill (AKA center crop) the thumbnail, as long as it is clearly defined in the API.

[izzytwosheds]

This is exposed externally? We should make these internal
Note to self: In general, we should change our build config to enforce explicit access qualifiers in Kotlin classes, to prevent clients from using stuff that is not meant to be exposed.

[ReallyVasiliy]

Ah good catch, done. I also made the executor/task related classes internal (they were originally being injected so they were open)

[izzytwosheds]

Do we still need this here? Does this get inherited from parent interface?

[ReallyVasiliy]

Yeah I believe we still need this -- basically this is propagating the opt-in requirement to whoever is using this concrete behavior. If I leave this out, we'll get warnings in this class that it's using an experimental API. So we have two choices: opt in, or propagate. If we opt in here, then callers won't know this class is using experimental APIs. So instead we propagate the requirement. https://kotlinlang.org/docs/opt-in-requirements.html#propagating-opt-in