3 ms·
Isn't a lot of that related to how the video is encoded/decoded though? I have only a basic understanding of how it works through working with video (not devel
by soylentcola 11y ago
Isn't a lot of that related to how the video is encoded/decoded though? I have only a basic understanding of how it works through working with video (not developing or tweaking actual codecs) but when I'm doing VJ-type stuff in Resolume (for example) I use a setup where all clips are encoded with a keyframe every frame. It makes for some huge clips but I can scrub or jump around or manipulate clips with no delay at all.
On the opposite end you've got streaming video or even many common formats and settings for ripped/downloaded video. Those do a keyframe every (x) frames and then between keyframes the file only contains the data for changes to the keyframe. This gets you smaller files so your downloads are quicker and your streams look nicer while using less bandwidth.
I know there's a lot more to it but at least with locally stored files, I thought it mostly had to do with keyframes. With streaming I'd imagine it's related more to how the stream is managed to download in chunks and maximize quality versus bandwidth (rather than focusing on quick scrubbing or quick access to random points of the video).
I'm interested in this stuff so if there's something I'm missing or flat-out wrong about, feel free to educate me.
- nickpsecurity 11y agoOh I'm not a subject matter expert on video compression. I just know the difference between using a general-purpose CPU and the ASIC version of decoders is huge. It's why you have all these weak, low-power SOC's that can do 720/1080p etc. That's the hardware acceleration. I doubt it's designed for the random access I'm describing, though. So, one for that might solve the problem. Might also need to be integrated with a good, storage subsystem if that causes any difficulties. Cool, though, that yours lets people jump around at will. :)