[Suggestion]: Process the video on the server to make it more web friendly

[RealFascinated]

Processing the video on the server to make the file smaller and more web friendly

[ShaneIsrael]

Already on the list of things to do eventually, the problem is that it needs to be set up to also work with a gpu since cpu processing to smaller sizes is extremely slow and very dependent on the server hardware and I want to keep Fireshare as minimalistic as possible when it comes to setup and configuration.

Until then, you'll just need to make sure you process them to be small enough that your upload bandwidth can handle them before adding to your Fireshare instance.

[RealFascinated]

Yeah that makes sense, thanks :)

[oblivioncth]

Perhaps this should be it's own request, but I'll add to this that it would be nice if once processing in general is implemented, to also allow super simple clip trimming. Just a start and end time.

My shadow play is set to 1 minute for the odd time I can't hit record right away or something cool that's long happens; however, most of the time what I actually wanted to clip is no more than 10 to 20 second long. It's an absolute pain to go through and manually load each clip into a DLE, trim it, and then export it and wait for it to render on my local system before then uploading it to YT or something.

This obviously solves the second half of that problem, but it would be amazing if I could basically use this as my main clip store full-stop.

Drop a video in, it uploads, I drag two little sliders with some kind of preview to mark the section that matters, and then Fireshare trims and transcodes that clip into a final one to keep that way forever. It would be perfect.

For now, the ability to share a btimestamped link solves this issue when it comes to actually sharing the clip, it just means lots of wasted space on the server for me.

I just think this would be a killer feature once you've already gone through the trouble to add video processing.

[ShaneIsrael]

I'll be honest, video editing even something as basic as "trimming" is a lot more complex than it sounds, especially considering Fireshare is a web app and not a desktop application. Depending on the user the base video could be anywhere from a couple megabytes in size to a couple gigabytes in size. Trying to add a responsive trimming interface that must allow a user to move start and stop sliders around while updating the preview all seamlessly is a tall order.

I decent solution would require the video to be served not from nginx which is how they are currently being served, the fireshare app server would need to serve the videos in order to have the required control. On top of that, because videos can be massive in size the preview images (the part you see as you are moving the sliders around to show you where you are at in the video) would need to be transcoded to a smaller size on the fly, which comes back to the whole cpu/gpu issue.

I'm sure there is a lot more complexity to it that I'm not thinking of and wouldn't know until I starting attempting to build out such a feature. So.. with that being said, this is likely not a feature that I will be attempting to implement anytime soon.

[oblivioncth]

I do understand that this is a bit more complex that I may have made out at first.

To be clear, by no means would the preview need to be updated, nor would any pre-transcoding need to be done (unless the user had already done so before). I did not mean to ask for too much initially!

Even if it's as basic as only entering two timecodes, or moving markers on a separate track that's below the video with no feedback that would be fine. The player for the original upload that already exists can be used to determine where you want to cut the clip. A slightly fancier version would be to have the sliders dim out the parts of the trackbar that are getting omitted, but again that isn't necessary and is just icing on the cake.

Then all of the transcoding can be done at once.

A vague idea could be something like the page/view for each clip having an "Optimize" button and the general settings of Fireshare having an auto-optimize option:

• If you have auto-optimize on, clips are transcoded immediately after upload with pre-determined settings presumably configured by the user elsewhere.
• If you use the manual "Optimize" button, you can use these controls to optionally trim the video as well.

How you handling the transcoding UI as you originally intended is totally up to you obviously.

While having a super snazzy, live feedback implementation would obviously be awesome and I did somewhat imply that as part of my original request, to be clear I'd take anything that would allow me to use Fireshare to perform the trim at all. Just so that the work is done by my server and I can manage my clips in one place instead of having to do the cuts manually on my desktop.

My point is, once you already have transcoding as an option anyway, if you end up using something like ffmpeg behind the scenes it would then be trivial to simply slap these offset values into the ffmpeg call (that you're presumably already doing) like so:

ffmpeg -ss hh:mm:ss -to hh:mm:ss -i "../../bs.mp4" -c copy "../../output.mp4"

where -ss is the start time and -to is the end time.

Also, if you wanted to add the option to just trim without doing any other transcoding, you could also add the -c copy option, which makes the processing extremely fast and efficient since it doesn't do any re-encoding and just copies the source data.

Assuming you can add the slider/timecode boxes without too much effort, it might not actually be that bad to get a basic version of this working :). Of course it's reasonable to start small go from there.

[ShaneIsrael]

A version like you outlined is more likely something I would be willing to experiment with. There's still a couple things I'd have to think about how to handle, such as the new trimmed video. The super simple solution is to just save the trimmed video right next to the original. The better solution is to have it also linked to the original in the database which would allow me to make a better ui for handling your base video and all corresponding trimmed clips.

ffmpeg is already used by fireshare to create the thumbnail data and get other data related to the video that is stored in the db so nothing new would need to added there. It would definitely be a -c copy command though. At least initially, potentially could expand upon it with more "advanced" user settings later.

This might be one of the next things I work on, not sure when just depends on when I'm feeling up to spending a weekend on my own projects. I spend all day coding for my day job haha.

I would say v1 would probably look something like this:

1. Basic slider under the video, maybe with a button to set the "start" and "end" handles based on where your cursor is on the actual video.
2. Button to start the trim process.
3. Trimmed video will be placed next to the base video, with some uuid appended to the name. <original_name>_trimmed_<uid>.mp4
4. Once the ffmpeg process finishes, immediately scan in.
5. Pass a link back to the trimmed video to the user (unless the process is taking too long and the connection times out).

The hardest part of this will be adding it in such a way that the UI makes sense. I'll probably have an entirely separate "edit" screen as to not clutter the preview ui or the /w/ ui.

To be honest I would also find this quite useful as a feature myself. Probably won't get a chance this weekend to experiment but maybe next week/weekend.

[oblivioncth]

A version like you outlined is more likely something I would be willing to experiment with. There's still a couple things I'd have to think about how to handle, such as the new trimmed video. The super simple solution is to just save the trimmed video right next to the original. The better solution is to have it also linked to the original in the database which would allow me to make a better ui for handling your base video and all corresponding trimmed clips.

This does make sense, especially if you store your footage in Fireshare exclusively, as keeping the original source can be important; however, regardless of the approach you take I'd appreciate it, even if not right away, there was an option to replace the original clip outright, as that's what I personally would do probably 80% of the time.

ffmpeg is already used by fireshare to create the thumbnail data and get other data related to the video that is stored in the db so nothing new would need to added there. It would definitely be a -c copy command though. At least initially, potentially could expand upon it with more "advanced" user settings later.

SGTM 👍

This might be one of the next things I work on, not sure when just depends on when I'm feeling up to spending a weekend on my own projects. I spend all day coding for my day job haha.

No pressure man, totally get it. Sometimes working on my FOSS projects is almost like a fever dream, picking them up and putting them down when I can.

I would say v1 would probably look something like this:

1. Basic slider under the video, maybe with a button to set the "start" and "end" handles based on where your cursor is on the actual video.
2. Button to start the trim process.
3. Trimmed video will be placed next to the base video, with some uuid appended to the name. <original_name>_trimmed_<uid>.mp4
4. Once the ffmpeg process finishes, immediately scan in.
5. Pass a link back to the trimmed video to the user (unless the process is taking too long and the connection times out).

Makes sense.

The hardest part of this will be adding it in such a way that the UI makes sense. I'll probably have an entirely separate "edit" screen as to not clutter the preview ui or the /w/ ui.

I did figure this would be the most annoying part, since obviously just adding the command-line switches is easy enough. A separate edit screen would be how I'd do it since I can be a bit OCD with organization, but it's likely a bit more work of course. Obviously you're the artist here though.

To be honest I would also find this quite useful as a feature myself. Probably won't get a chance this weekend to experiment but maybe next week/weekend.

Glad to hear it. Get to it whenever you can. Even if it ends up being a year from now, I'll be here :)

[Korgen1]

Are there still any plans to implement the video trimming idea? It would be a really useful feature.

[ShaneIsrael]

@Korgen1 Not anything from me for a while other than standard bug fixes and updates. I've got a very busy schedule with work and side projects.

Of course, if somebody wants to attempt building it in I would support that and would make time to review PR's and give feedback.

[krth8]

+1 for ffmpeg transcoding!

Great app