[Feature] Support multiple Scenes in a single file

[stg-annon]

Is your feature request related to a problem? Please describe.

There are cases where a stash user would want to view scenes that may exist in a single file separately without re-encoding the source file into separate files so they can be viewed as separate scenes within stash

Describe the solution you'd like

The solution has been discussed a few times and usually revolves around utilizing a similar system to Markers to determine the start and end points of a "sub-scene" within a file that has multiple scenes while leaving the source file as is

Describe alternatives you've considered

re-encoding the source file into separate files, this is undesirable as it changes the fingerprints of the file and goes against a core feature of stash where the source files remain untouched

related issues: #260 #779

[stg-annon]

continuing from #724 with a narrowed description of the requested feature

C.C. @GronsoBitburg @xx790 @firrets

[xx790]

Answering to @firrets and bringing one more related issue not mentioned above yet: #2511 worded differently but has the same goal essentially (also spawned #3147 and #3197 which might be redundant)

[firrets]

Describe the solution you'd like

The solution has been discussed a few times and usually revolves around utilizing a similar system to Markers to determine the start and end points of a "sub-scene" within a file that has multiple scenes while leaving the source file as is.

I think the easiest would be to consider them fully fledged scenes with access to scene parameters: Performers, Tags, Description, etc and a reference to Movies with a Scene #. Multiple scenes would have the same source file, with additional fields start_time and end_time in the scenes_files table. The calculated delta could be used as scene length on the Scenes page (as today the scene length is taken directly from the video file metadata, I assume) as to not mess up the Stash statistics.

Describe alternatives you've considered

re-encoding the source file into separate files, this is undesirable as it changes the fingerprints of the file and goes against a core feature of stash where the source files remain untouched.

I'd also add that cutting the original file without re-encoding depends on the location on the key frames and can only be done "cleanly" with a key frame exactly between the scenes. Too many have either a key frame too early or too late to make this a viable alternative.

[xx790]

Thinking about the wording of virtual files of #2511, I think I got an idea!

Now, that we have scenes and files detachable, it is possible to have an elegant solution that will

• require probably the smallest effort to implement,
• introduce minimum number of features to support,
• keep all scene features, not reinventing the same thing again but on a different level,
• solve not only this feature request but also other requests (ability to set custom start or end time for a scene to skip over empty intro/outro, cbb to look for the issue numbers).

The idea:

• binding from a scene to a file should contain start and end time. That's it, no more database changes probably needed;
• player should handle these times, playback counter, duration value, etc should be checked to compute their value correctly;
• start and end time of a scene should be editable via UI;
• there should be a scene UI tab similar to Markers tab with the list of all scenes bound to the same file (it can probably be combined into the same tab);
• it would be good to have a common UI to edit Scenes and Markers of a file (this is where most effort might go to make a good UI, but this is not what enables the feature but what makes it convenient to use. Some corners can be cut to deliver it faster).

Given a big file, I can have it as a single scene, and/or I can add scenes bound to the same file but only individual parts. Each scene has the full set of features and can be searched for along with all other existing scenes.
I think this will work nicely for me.
(For example, I want to have CockHero/FapHero/etc videos playable both as a whole and as a randomized queue of individual rounds mixed with other individual PMVs/HMVs.)

[stg-annon]

binding from a scene to a file should contain start and end time. That's it, no more database changes probably needed

that solution would also address #1497

[firrets]

• there should be a scene UI tab similar to Markers tab with the list of all scenes bound to the same file (it can probably be combined into the same tab);

I don't see the use case for this, and how it would look. Scenes reference files, not the other way round.
The rest of your description is exactly what I'm looking for though.

[xx790]

that solution would also address #1497

Yes, that's the issue number I was lazy to look up. (Maybe there are more? I just don't follow that request as much, even though solving that would be nice for me as well.)

• there should be a scene UI tab similar to Markers tab with the list of all scenes bound to the same file (it can probably be combined into the same tab);

I don't see the use case for this, and how it would look. Scenes reference files, not the other way round.

(⚠ initially I misread the comment and replied as if the last bullet point was questioned, I'll keep my original answer as well, below under a line)

there should be a scene UI tab similar to Markers tab with the list of all scenes bound to the same file (it can probably be combined into the same tab)

Motivation for this:
I think it should be easy to navigate between scenes within the same file.
If not through this "automatic playlist", then it would have to rely on manual actions like tagging or defining a movie.
I think it might be pretty natural, considering when you switch to scenes/markers editing - those scenes might be seen there.
It is also not too dissimilar from the current queue UI that also exists within the scene page.
If this arrangement problem can be solved - it would likely be solved together with the queue UI.

---

it would be good to have a common UI to edit Scenes and Markers of a file (this is where most effort might go to make a good UI, but this is not what enables the feature but what makes it convenient to use. Some corners can be cut to deliver it faster)

It would still be called from a scene page. But it raises some technical questions, since times have to be referenced to the video file at least internally. So, it seems natural to have the editor UI to operate in the whole file timeframe.
I imagine the ideal solution as following:

• it might potentially work in 2 modes - full file timeline and "zoomed-in" to a single scene;
• full file timeline might be reminiscent of a multi-track audio/video editor, multiple overlapping strips can be drawn. New strip added here will introduce a new scene on save;
• markers are still attached to scenes (unless they are actually detached from scenes in the database), they certainly have to be editable within a single scene, and there can be a way to transfer them across overlapping scenes.

As I said, this might be too much UI.
The problem that has to be solved - there should be a natural way to spawn new scenes from the existing one and specify start and end times for them. If there is a simpler way - I'm fine with that.
Current solution for detaching/attaching files to scenes is pretty hidden - it might be a pain to add many scenes. If the feature gets its prime-time then it needs something better.

One aspect I'm not going deep into here: I find current Markers system pretty useless as it is. But working on the shared UI might achieve a synergetic effect (make both new and existing features better).

[amanaplan]

There are many cases where chapter metadata (start and end timecodes, chapter titles) is already embedded in source files and can easily be extracted. It would be very convenient if the UI also included functionality enabling users to import chapter metadata as scenes, allowing users to edit and tweak using the proposed updated UI to adjust timecodes and remove chapters (like opening titles and closing credits) which are not scenes.

[GronsoBitburg]

Navigating and creating markers for each scene isn't the most fun currently.

Stash excels at individual scenes and it's metadata, but becomes a complete mess when importing a full movie. Some movies have upwards of 8 or 9 scenes and 20 odd performers. It's a pain to find what you're looking for if you have no markers on a movie yet.

My thinking is by using the already existing markers and marker tags to virtually split these scenes. Possibly having a Stash-App specific tag for defining scene start and endpoints that can be edited at any time to get the timing just right for each scene. Depending on the amount of start and endpoint 'groups' could easily be programed to be the number of scenes for the collective movie those scenes represent.

Once generated my thinking is that by creating a movie page and filling it with all those split scenes would be a good way to keep this in one cohesive unit. Have some sort of identifier on the movie and scene pages to let users be reminded that a specific scene and movie has been created using virtual scene creation... just in case they wish to delete one of the scenes. etc.

Also, following on from amanaplan said previously, these start and endpoints could possibly be imported into stash from chapters available already in some video files already. Start of the file should be scene start then the proceeding chapter point should be an end then a new start point within a 500ms gap or something... all the way until the end of the movie.

I feel that when it comes to making or editing markers for the individual 'split' scenes, the UI should still have use of the full movie to do so when making those changes, so that users have access to adding or removing those scene marker points to suit their needs without feeling they have lost that big file at any point.

It would be great to just be able to go to the movie section and see those split up scenes and be able to populate them with individual metadata.

[gaytomi]

I made Contribution #660850 towards #3797 which was a duplicate of this. I'd love to be able to break a Movie into it's Scenes fully in Stash!

[WithoutPants]

$50 bounty assigned (contribution #660850)

[WithoutPants]

$100 bounty assigned (contribution #679133))

Total bounty $150

[scruffynerf]

will this involve making multiple phashes by creating a phash using the start and end of a scene (and the 25 shots between the two)?

[gaytomi]

I think for a phash we should still run the whole video, and use that as a key to match any stash server db data. Best case, given a match and the scenes breakdown having been uploaded already, it could sync that data too. Then you could watch the full video, or you could go to one of the scenes of it (and that scene would also have it's own performers, etc).

[gaytomi]

Stash could also work at it this way, which might be easier?

• User syncs, full movie file is scanned and added
• User adds markers to the file at the start of each scene
• User triggers action to create the scenes for the movie
• ffmpeg is used to extract scenes based on the timecodes for the markers
• New scene files are added with identical title/description/actors/etc as the movie, except the scene number is set
• The scenes are themselves otherwise added just like any other video file would be.
• There could be an option to then hide in the UI the full movie so that the scenes are all that shows.

[xx790]

ffmpeg is used

This defeats the main goals of the feature - no reencoding, no duplicate files.

[gaytomi]

I agree - was just tossing out an idea of one approach. I do think it's better to not have to reencode like this, and certainly better from a storage size perspective. It should be easy enough to save the scene timestamps and play from that point to the next timestamp from a single file.

[ConteZero76]

The easiest solution (not the best, but the quickest and easier to implement) is using index (or "referral") files.
Let the program generate index files containing a referral to the "stream" file, pointers for beginning and end inside the stream and maybe other fields.
This way the underlying stream itself can be shown (or hidden, depending on how are you going to manage the thing) along with the "pseudo extracted" scenes and since the pseudo extracted scenes are files by their own right it wouldn't require a heavy code rework on the server itself (just some excepiton in handling those index files).
As long as those index files are held in the same directory as the stream it wouldn't litter the directory structure that much.

The program must be able to recognize those index files as "pseudo files" and act in a way to remap the play/seek/etc to the underlying stream file, but that cannot be avoided in any way except with re-encoding or linear editing.

Referral to the underlying stream could be by MD5 (this way even if the file is moved or renamed it wouldn't break the whole thing), by name, by stash unique ID (this way even if the file is lightly tampered it wouldn't break the whole thing) or a mix of them (maybe in a self-healing way).

On the other end the "programmer heavy" solution would be handling resources (scenes) and streams (files) as different entities inside the program itself but it won't change this much from this (brute) fix and it could also be a worse solution (because index files can be imported, moved around and maybe even edited at hand while in-database references are harder to manage).
Also: being index files they wouldn't burden the database engine this much because hardcoded data (beginning, ending, referral) aren't going to change and can be sourced directly from the index file without database queries.

Just my two cents.

PS: Using a similiar approach (since most "films" are made up of several single scene files) it might be nice to have a "by film" view using the same index trick: "generate" a virtual "film" file by putting multiple references one after another inside an index file and manage it indipendently from the steams.

[xx790]

See my comment above: #3530 (comment)
Stash already has scenes functioning as "pseudo files", referring to actual files.

The only technical thing missing - start and end time for the scene.
Then, there will be a lot of tiny details in UI and player to handle it properly.

[ConteZero76]

Please, consider also the possibility to put more than one reference in a virtual file, so "films" can be packed from single scenes.

[aaakkknnn]

Please add my $50 bounty contribution (id #719294) to this issue!

[WithoutPants]

$50 bounty assigned (contribution #719294))

Total bounty $200

[WithoutPants]

$200 bounty assigned (contribution #726150)

Total bounty $400

[WithoutPants]

$50 bounty assigned (contribution #726485)

Total bounty $450

[laurus-lx]

There is an existing proposal to separate file system and finger-prints from galleries /scenes/ movies and to link them via "File Ranges" (e.g. clips from files that have start and end time). So one file can have several scenes (linked by "File Ranges")

"File design draft #1958"

There is a detailed description and UML diagrams for the system design and the revised DB schema. It's a fairly comprehensive enhancement that would cover a lot of new use cases (DVDs, cams, compilations)