Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add Aspect Ratio to File Info (i.e. to Filter VR Scenes, Pick Scenes for Screen Size) #3637

Open
desertwitch opened this issue Apr 4, 2023 · 3 comments

Comments

@desertwitch
Copy link

desertwitch commented Apr 4, 2023

Is your feature request related to a problem? Please describe.
I'm basically frustrated there's no real option to filter scenes by VR and non-VR (virtual reality).
There are times when I'm looking for VR-scenes only and other times when I just want to watch regular scenes.

Describe the solution you'd like
I'd like to see another field for "aspect ratio", which scenes could then be filtered with, in the "File Info" section.

  • VR videos almost always have a 2:1 aspect ratio
  • non-VR videos almost always don't have that 2:1 aspect ratio (rather 16:9, 4:3, ...)

By utilizing the "aspect ratio" attribute instead of another mechanism, users wouldn't just be limited to this VR/non-VR filter scenario. They could also filter their scenes by aspect ratios such as 16:9, 4:3 to choose appropriate videos for appropriate screens (and screen sizes).

Describe alternatives you've considered
A plugin, but this would probably be much easier to implement as part of the existing "File Info" information gathering process.

Additional context
It seems ffprobe is already used extensively to populate the "File Info" section (dimensions, frame rate, bit rate etc.). This would just mean fetching one more informational attribute (aspect ratio) during the existing scanning process and adding it as field.

Example for VR/non-VR detection utilizing ffprobe's aspect ratio information:
https://askubuntu.com/questions/1217238/how-to-identify-on-command-line-vr-videos-and-batch-delete-them

@desertwitch desertwitch changed the title [Feature] Add Aspect Ratio to File Info (i.e. to filter VR scenes, pick scenes for screen size) [Feature] Add Aspect Ratio to File Info (i.e. to Filter VR Scenes, Pick Scenes for Screen Size) Apr 4, 2023
@Tweeticoats
Copy link
Contributor

use this plugin to add a tag https://github.com/scruffynerf/aspectratio

@desertwitch
Copy link
Author

desertwitch commented Apr 4, 2023

use this plugin to add a tag https://github.com/scruffynerf/aspectratio

Thanks a lot, that'll definitely help my situation, but I still think this would overall be a good addition to Stash.
If not fetching the aspect ratio itself from the video file, it could rather easily be calculated via the resolution.

In any case I think it'd make a worthwhile new "File Info" parameter and filter in the baseline Stash application.
Implementation shouldn't be too hard either compared to the benefits of offering more filter possibilities.

The existing plugin (linked above) basically does a mass-tag operation based on the calculated aspect ratio.
This is both more invasive and hard to modify (tag names etc.) in the future, so I'd prefer a "simpler" solution.

If not for my use case of VR/non-VR, aspect ratio is still an important "File Info"/video attribute worth adding IMO.

@itsame-luigi
Copy link

I have a local branch where I've added relevant information to Scene. I'd started looking into doing it for VideoFile, but ended up using Scene for a number of reasons:

  • A VR scene is generally filmed using a specific lens which often determines the projection mesh used in the resulting videos, and is the same regardless as to the specific resolution. While there may be post-processing involved by the studio producing the scene, they still distribute all resolutions of the scene using the same projection mesh and stereo mode.
  • VR projection information can often be scraped for a given Scene, even if the local scene does not have files associated with it.
  • VideoFile does not have a data entry UI suitable to this purpose, while Scene does. To support data entry for an individual VideoFile would require a far more significant change to the UI.

The information I'm currently tracking consists of:

  • StereoMode - The list of inputs specified in https://ffmpeg.org/ffmpeg-all.html#stereo3d. The most relevant ones are:
    • sbsl/sbs2l - Side-by-side (left/right)
    • sbsr/sbs2r - Side-by-side (right/left)
    • tbl/tb2l - Top-to-bottom (left/right)
    • tbr/tb2r - Top-to-bottom (right/left)
    • As well as cuv - A custom UV used with the rf52 projection, necessary for proper display in apps like DeoVR.
  • Projection - The projection mesh to use for the video:
    • flat
    • dome (180° equirectilinear)
    • sphere (360° equirectilinear)
    • fisheye (180° fisheye)
    • fisheye190 (190° fisheye)
    • rf52 (190° fisheye specific to Canon RF52 lens)
    • mkx200 (200° fisheye specific to the iZugar MKX200 lens)
    • mkx220 (220° fisheye specific to the iZugar MKX220 lens)
    • vrca220 (220° fisheye specific to the ZCam VRCA220 lens).

I'm also planning to add VR correction information (x, y, brightness, contrast, and saturation) as this information is frequently used to correct for poor IPD, camera orientation, and lighting conditions and is also frequently stored along with scene information from various sites. I'm also planning to add VR passthrough information such as that supported by DeoVR including chroma keying, alpha packing, and external mask files.

In my working branch I'm able to use the user-supplied VR information to pass along additional video filter commands to ffmpeg when generating screenshots, scrubber sprites, thumbnails, and previews. The results aren't perfect, but

I've also tried setting the default projection in videojs-vr, but there are a number of modes supported by VR headsets that videojs-vr does not support.

If it's imperative that this information be stored on VideoFile and not Scene, I would need some guidance as to how best to structure the data entry UI to support that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants