Passing VideoReader to video models

[brimoor]

This PR updates the eta.core.learning interface for models that previously took paths to videos on disk to instead take VideoReader instances that can read the frames.

This is preferable because it separates the abstraction of loading the video from applying the model.

The impetus for this was the need to write modules that apply video models to either a video path/frames sequence, which can be read by eta.core.video.FFmpegVideoReader or a video frames directory containing not necessarily sequential frames, which can be read by eta.core.video.SampledFramesVideoReader. Much easier to do now!

Note that this is safe to do now because there are not yet any concrete instances of VideoModel, VideoClassifier, or VideoObjectDetector in develop.

[jasoncorso]

This is the right thing to do but two comments/questions:

1. The pipeline system sees a video path and knows to create a video reader? What if, previously, certain other module parameters would impact how the video was read, such as ranges and rates?
2. VideoReader will need to support seeking formally in order for this to work as modules may need to go back and forth or at the very least "reopen" a video.

[brimoor]

1. This module shows how one would configure the VideoReader as desired (any sources, any parameters, etc): https://github.com/voxel51/eta/pull/383/files#diff-73bfe1f6c2c139a1be5f0b3b743ccacd

2. Yes good point. I'll leave the work of upgrading VideoReader to expressly support seeking/re-reading videos to the first person who needs that functionality. Shouldn't be too hard. VideoReaders need to be able to seek to specific frames #373 is updated to reflect this ask

[mattphotonman]

Isn't there some code in the concrete subclasses that needs to be modified accordingly? Or are there currently no concrete subclasses of VideoClassifier?

[benjaminpkane]

There are no concrete subclasses.

[benjaminpkane]

LTGM!