David Kimura
PRO
said almost 4 years ago
on
Adaptive Bitrate Streaming with Active Storage
:
☒
Honestly, I forget the resources that I came across while researching this episode. It was several weeks of research to get to this final product. However, the github pages for the videojs and https://github.com/videojs/http-streaming are good resources
☒
The web now-a-days works pretty good using MP4. So far, I've not seen any issues on the browsers and devices that i've tested on.
I didn't want to add an additional dependency to my application. The bash script is complicated, but easy enough to debug locally.
I run the conversion in a background job. The background job handles retrying as well as notifications. As far as resources go, and since these are happening in a background job, I would rely on the infrastructure to handle notifications of peaks and autoscaling.
I would probably include a tiny video file within my repo and use that as my test case. As edge cases arise, perhaps with other formats, those could be added as well. I would try to keep each video file <= 1MB (or have them externally available).
So far, I've not had to worry about this. Everything has been working fairly well. It is actually what I'm using on Drifting Ruby right now. However, if I did have to debug a production issue, I would probably pull down the video file in question and test it locally.
- I'm wondering whether you could provide a few more resources about what you researched in order to figure out how to work with FFMPEG and HLS. For example, how often and where might you look to keep tabs on new developments/make updates so that you keep up with high quality video serving?
Honestly, I forget the resources that I came across while researching this episode. It was several weeks of research to get to this final product. However, the github pages for the videojs and https://github.com/videojs/http-streaming are good resources
- What are the tradeoffs that you've found to using mp4 over webm ? Since we have already broken out ffmpeg, should we add a step to transcode to webm instead of mp4?
The web now-a-days works pretty good using MP4. So far, I've not seen any issues on the browsers and devices that i've tested on.
- I'm curious why did you choose to go with a bash script over writing an FFMPEG wrapper in ruby (or using an existing gem, like streamio-ffmpeg)?
I didn't want to add an additional dependency to my application. The bash script is complicated, but easy enough to debug locally.
- When you deploy this to production -- how do you monitor resource usage/failures?
I run the conversion in a background job. The background job handles retrying as well as notifications. As far as resources go, and since these are happening in a background job, I would rely on the infrastructure to handle notifications of peaks and autoscaling.
- How might you write tests for an the `ConvertHls` class?
I would probably include a tiny video file within my repo and use that as my test case. As edge cases arise, perhaps with other formats, those could be added as well. I would try to keep each video file <= 1MB (or have them externally available).
- How might you debug the bash script if you deploy to prod?
So far, I've not had to worry about this. Everything has been working fairly well. It is actually what I'm using on Drifting Ruby right now. However, if I did have to debug a production issue, I would probably pull down the video file in question and test it locally.