obs-studio
obs-studio copied to clipboard
obs-ffmpeg : Add time controls
Description
Add several options to control media source
- Delay (start play after some times)
- In Point (start play from specific amount of time (calc from start)
- In Point Loop (choose to loop to another point)
- Out Point (don't play file after some amount of time)
The first commit is the one of PR https://github.com/obsproject/obs-studio/pull/6735
Current UI :
I suppose there will be some comments about the UI. For now i use spinbox in ms for time selection The outpoint is set using two control (one to select if you want to go to the end of the file, or setting a custom point) The first idea was to set out point based on media duration when file is selected. But in practice, when changing the media file there can be two use cases, and only setting the duration from file can made unwanted behaviour :
- Keep the same out point
- Or use new file duration if a new file is longer than the previous selected one It's the reason i keep this mode for this first version (but i'm open to UI look and behaviour suggestion).
For start delay, i choose to apply the start delay, when source is start (start of obs, or restart when visible) and not when updating source properties (in that case source restart withotu delay after closing the properties dialog).
Motivation and Context
Currently Media source lack support of common media time controls. Lot of use cases can benefits from better control :
- delay playing some media
- Don't start media right after scene have be selected (to finish transition first)
- Avoid to keep unwanted content at start or end
- Custom loop point (to have for example a file who have In animation then loop (loop point in that case is not the in point)
Request in several Ideas : https://ideas.obsproject.com/posts/1462/media-source-advance-options https://ideas.obsproject.com/posts/1587/a-b-or-in-out-for-media-sources https://ideas.obsproject.com/posts/327/a-delay-function-media-sources
How Has This Been Tested?
Mac os Intel 11.6.7 Tested with prores file with burn timecode to check that time is correct. Probably need more test with various kind of files (don't know how to enable Artifact builds)
Types of changes
- New feature (non-breaking change which adds functionality) -->
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
Would it be possible to not restart the video when there is speed change? It would be such a cool feature if we could change video speed to do fast forward for certain parts of a video based on a spin control attached to it. Currently whenever there is a playback speed change video starts at the very beginning (at least when using Windows).
Is editing a video before using it not an option? The problem is that when using a program for the first time, I dislike it when a user is overwhelmed with options right up front like this. I feel like it already happens too much as it is. I can understand why this would be a feature for a video editor, but OBS is more of a live tool. I feel like you should generally have your assets ready and edited before production. I don't know, that's just my opinion. Should something like this really be obs' responsibility?
Would it be possible to not restart the video when there is speed change? It would be such a cool feature if we could change video speed to do fast forward for certain parts of a video based on a spin control attached to it. Currently whenever there is a playback speed change video starts at the very beginning (at least when using Windows).
Yes, this can be an interesting feature in obs. You should open an idea for this, to avoid to lost it in PR comments
Is editing a video before using it not an option? The problem is that when using a program for the first time, I dislike it when a user is overwhelmed with options right up front like this. I feel like it already happens too much as it is. I can understand why this would be a feature for a video editor, but OBS is more of a live tool. I feel like you should generally have your assets ready and edited before production. I don't know, that's just my opinion. Should something like this really be obs' responsibility?
I think a live production tool, need to have time controls for playing media. Of course in theory all media should be already correctly prepared before a live. But in practice, let some adjustement directly in the software use to play media, seems to be important in lot of situations. In this PR, Delay and loop point, are more a playout option, than something who can be fix in editing.
I also agree that Media source properties have lot of options who can confused new users. It's i think more a question about UI (like putting some tabs, to start on the basics features, and move more advanced options in other tabs), than don't have features at all.
Adding my support for the idea of playback speed and in/out controls. They definitely have a place in a live compositing tool like OBS. Setting in/out points can significantly improve workflow turnaround time when you don't have to feed a video through an editor first, and allows for on-the-fly adjustment up until go-live time.
Last update fix merge conflicts
Would it be possible to not restart the video when there is speed change? It would be such a cool feature if we could change video speed to do fast forward for certain parts of a video based on a spin control attached to it. Currently whenever there is a playback speed change video starts at the very beginning (at least when using Windows).
https://github.com/obsproject/obs-studio/pull/7455 tried to prevent source media restarts. Note that media source currently restart every time the settings are changed, not only when there is a speed change. However, I was not able to implement speed change without restart cleanly. I was able to do it by changing the time elapsed internally, but there was an audio buffering issue, which I imagine requires freeing audio/video frames upon a speed change, which is something I do not know how to do, so I left it alone.
Thanks for your contribution, but we don't really think this is a good fit for OBS at this time.