Unify video metadata in VideoClips

[fmassa]

This PR unifies the metadata information in VideoClips, relying on the new unified backend functionality from #1514

It still keeps the call to the internal _read_video_from_file, because we still need to pass _video_height / etc for efficiency (but maybe that can be removed in the future?)
The downside of the current approach is that we now need to call _probe_video_from_file at every call to get_clip, which should be fine given that _probe_video_from_file is very cheap.

cc @stephenyan1231 , as this will probably break old checkpoints from internal runs that relied on the old metadata.

[codecov-io]

Codecov Report

Merging #1527 into master will increase coverage by 0.04%.
The diff coverage is 55%.

@@            Coverage Diff            @@
##           master   #1527      +/-   ##
=========================================
+ Coverage   64.56%   64.6%   +0.04%     
=========================================
  Files          87      87              
  Lines        6694    6742      +48     
  Branches     1033    1034       +1     
=========================================
+ Hits         4322    4356      +34     
- Misses       2071    2085      +14     
  Partials      301     301

Impacted Files	Coverage Δ
torchvision/datasets/video_utils.py	72.25% <51.51%> (+7.16%)	⬆️
torchvision/io/_video_opt.py	65.89% <71.42%> (+0.03%)	⬆️
torchvision/models/detection/roi_heads.py	54.63% <0%> (-1.52%)	⬇️
torchvision/transforms/functional.py	71.67% <0%> (+0.61%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30cb4e1...9694d5d. Read the comment docs.

[stephenyan1231]

It seems a few arguments of _read_video_from_file , such as video_width, video_height, video_min_dimension, are not used here, and can not be specified in API _read_video.

Video frame resizing is fast if done inside of video reader. I would like to keep those argument exposed.

However, pyav backends does not support such resizing. For now, you already raise ValueError when they are not zero. In the long-run, we can consider applying video resizing transform to keep the same behavior between pyav and video_reader backend.

[fmassa]

My thinking is that I want to first properly benchmark the benefits of having the rescaling happening in ffmpeg to have an idea of how much improvements it will bring us.

Once we have the numbers, we should analyze them and then decide on how to expose the resizing functionality in a clean way to the users. I think this should be done after December though

Note that power users can still use the private API for specifying the video_width / etc, so this functionality is available but not part of the public API