This is great, I don't have a concrete use-case right now but can definitely see myself returning to this in the future. One thing that would be handy is having a way to either accept a ffmpeg cli command, or convert from a cli command to the typescript syntax. My experience with ffmpeg if you often do a lot of copying and pasting of commands from documentation or random guides, it'd save a bit of time if you didn't need to transcribe the commands into streampot's syntax.
StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
11–20 of 37 posts
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#12Is there any way I can run this in a fully local setup? Curious if a config for nginx could be provided?
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#13Is there any way I can run this in a fully local setup? Curious if a config for nginx could be provided?
Looks like you could potentially point this at Minio local S3 compatible storage based on env vars?
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#14Jack from StreamPot here. So happy to see it shared here. We'd love you to try it out and give us any feedback or requests.
Looks really nice, great work!
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#15Seeing the need for polling the job status is off putting, especially for a js api that already is using async. If you _need_ to use polling, at least provide a convenience method I can just await. Better yet, add some signaling to the http api via eventsource or something.
Can you elaborate on what you mean by signaling to the http api?
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#16Is there any way I can run this in a fully local setup? Curious if a config for nginx could be provided?
Isn't the local version just running ffmpeg as a command line?
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#17Earlier quoted context omitted.
Highly prefer and recommend websocket connections for polling. This is what I ended up doing for my side project's video encoding needs[1]. It lets me get silky smooth progress indicators on multiple encoding resolutions at once. [1] https://github.com/jjcm/nonio-video-cdn/blob/master/route/en...
Do you mean over* polling (instead of polling)? Polling (repeatedly asking the server) and pushing (the server telling you directly) are two different things; polling over WebSocket seems sort of weird.
A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. This does save you an explicit round-trip in your own code though.
Ultimately the only element that isn’t polling in a classical machine architecture is the interrupt handler in the top half of the kernel (or system equivalent).
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#18Earlier quoted context omitted.
Do you mean over* polling (instead of polling)? Polling (repeatedly asking the server) and pushing (the server telling you directly) are two different things; polling over WebSocket seems sort of weird.
A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. This does save you an explicit round-trip in your own code though. Ultimately the only element that isn’t polling in a classical machine architecture is the interrupt handler in the top half of the kernel (or sys…
Servers doing polling internally and sending you periodic status updates over WebSocket is relatively common. I don't think polling over WebSocket is a good idea in this situation though (as in sending periodic requests to the server asking for a reply).
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#19Earlier quoted context omitted.
Do you mean over* polling (instead of polling)? Polling (repeatedly asking the server) and pushing (the server telling you directly) are two different things; polling over WebSocket seems sort of weird.
A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server. This does save you an explicit round-trip in your own code though. Ultimately the only element that isn’t polling in a classical machine architecture is the interrupt handler in the top half of the kernel (or sys…
> A push over a websocket is still fundamentally a polling behaviour; it’s just happening further down the stack, below the awareness of application code on the client and implemented internally on the server.
Not necessarily. The server may internally use interprocess signalling or sockets or something to find out when the process is ready instead of busy-waiting. For example, if ffmpeg is run as a child process, the parent process can sleep a thread waiting for the child to terminate.
Just about any sort of busy-wait polling behaviour is a code smell in my book. Stop wasting cycles. Let the thing you're waiting on tell you when its ready. If it can't, fix it until it can. This is all opensource code.
Re: StreamPot: Run FFmpeg as an API with fluent-FFmpeg compatibility, queues and S3
#20Seeing the need for polling the job status is off putting, especially for a js api that already is using async. If you _need_ to use polling, at least provide a convenience method I can just await. Better yet, add some signaling to the http api via eventsource or something.
Highly prefer and recommend websocket connections for polling. This is what I ended up doing for my side project's video encoding needs[1]. It lets me get silky smooth progress indicators on multiple encoding resolutions at once. [1] https://github.com/jjcm/nonio-video-cdn/blob/master/route/en...
Eh adding websockets is a significant complexity jump, in my experience it's hard to write websocket client code which doesn't ever end up in a bad state despite connection breaks, and I still haven't figured out how to avoid random long delays in creating a websocket in my own projects. If you only need a completion callback and not continuous progress updates, long polling is an excellent solution which adds very little complexity compared to websockets.