transcode static video files #12
Comments
|
basic info (number of streams, duration) : output
more info (stream type, language, quality) for audio video subtitles: output
get frame segments: output
|
|
ffprobe frames list is "slow". not bound by cpu or disk i think took 40-60s for a 4GB 2h video probable HTTP timeout from client. i don't know how complicated to extract frames but if not hard go-transcode should do it not ffprobe edit: if playlist is in cache it's ok. maybe start probe before requests to warm cache? |
|
For the first version, I don't think, that we need to transcode the whole static file. We need to convert it to live HLS stream with offset. For example, when I want to watch file from the start, I simply start streaming it. When I want to seek, I just start new stream with wanted time offset. Or do you want to have returned full manifest and process chunks on demand? I think we should investigate multile approaches, and maybe implement them: And having ability to switch them in config file. Because there are multiple usecases (for users with fast seeking, or just not seeking at all). |
for option 1 you need custom client no? if manifest is ready option 2,you can use seeking in every hls program like vlc or web
i don't know what is fast seeking but no seeking i don't think useful except for livestream? what idea do you have?
yes why not but it's more work |
|
i added output example for ffprobe.. i dont know if files can have multiple video track maybe when input is HLS stream ? will livestream and vod code be same? maybe vod will have more features (audio/sub select) but maybe features are also good for livestream if source supports it ? for library and hls playlist create, maybe we can provide script to warm cache and advice use with cron, and have config.yaml setting to start process for warm cache? plus setting for cache directory for cache directory i dont know if /tmp is always good answer, it can grow full with ramdisk, and maybe someone wants keep copy of livestream (for library you want to keep playlists, maybe not all segments because its big) |
|
so problem for transcode all file is skip ahead wont work because server transcoding will be slow. i thinked maybe transcode chunk by chunk helps. but to encode one chunk ffmpeg must probe source again. so transcoding one chunk is slow when we go deep into source (linear slow not exponential). i think if we get byte offset for chunks it's easy to cut video before we call ffmpeg to skip probe, but i dont know how to get byte offsets for video frames. Less good but maybe a setting for chunk count to encode 50 chunks (example) so when we ask for chunk n25 transcode starts for chunks 51-100. but better is we can have timeout when user quit, so we transcode from starting point (maybe skip ahead maybe start of video) to the end/timeout. best case playback follows transcoding. worst case user skips different times, so 3 or more transcoders run in background and maybe transocde the same chunks several times. but i dont know how to make timeout like this. ffmeg has interactive commands but only for filters i think. we could stop earlier transcoding process when asking for transcode at later start point, but what if user2 is watching video from start and user1 skip ahead (problem)? |
I would like to keep live as subset of the same codebase.
We should be able to cache static files and their playlists (or segments, depeding on user preferences, but most likely no) along with some infomations (ffprobe output) in cache directory. And it should only be optional, user doesn't want to have persistent cache, it should work (even though maybe not that fast).
We should give ability to users to choose own temporary directory in config. But we should differentiate berween cache and temporary transcoding directory. And definitely
I think mst reliable solution would be to skip only by length of one segment, and in that case same segments from multiple transcoding instances could be reused. But I am not sure how well ffmpeg could do that, how reliable would it be. |
ok so all profile (hls, http, etc) must deal with vod/live? (btw maybe change name for api/http, there is already http, main.go and api/router for http. ideas?)
with risked HTTP timeout from client
like
client-side skip can go anywhere because HLS client will know what segment in playlist for download, but just if playlist is complete it works. on server ffmpeg can do it with for me problem is more server side process strategy for transcode, ill run local benchmark and try read jellyfin source how it do it and update here |
It should yes, although that implementation is going to take some time. We could guard it with capabilites, what output profile can deal with vod and what not. Switching to modules could help us with naming convention.
Yes, exactly. Multiple types of cache.
That sound as a good idea. Maybe we can see PoC and how it pereforms. Hard to predict what would be the best approach here. |
|
benchmark 20 minute video, transcode 1/10 chunk (0, 10, 20, 30...), time for encoding 1 chunk: we see start individual chunk transcode has cost, bigger cost when starting later in file EDIT: chunks.log was real time used by process (/usr/bin/time -f "%E") |
good plan
hls-vod-too do like that i don't know if good strategy but initial test look ok. will test more |
Yes, they can be a good starting point for us. |
good hope im wrong!!!! 1/10 chunks (0, 10, etc, 450) time for one chunk (seconds) The -ss parameter needs to be specified somewhere before -i: or there is slow seek. i put -ss before -i and the results look good like you see in graph chunk-by-chunk is realistic! so go-transcode just need to transcode few chunks before request (n+5-10 for request chunk n) |
inspiration hls-vod-too
edit: for static streams maybe config should support directories?
library: /media/videoin config can serve all files/directories with /profile/library/folder/video.mkv/index.m3u8 (or other url format from #13)The text was updated successfully, but these errors were encountered: