Allow configuration of VOD segmenting behavior and audio/video encoder

[hheimbuerger]

For my use case, I need to tweak the HLS-VOD segment behaviour, as well as switching to GPU-accelerated encoding. So far, I hardcoded those changes in my own fork, but here's a suggestion of how this could be made configurable.

The segment length/offset/buffer min/buffer max can be set either on the CLI (--segment-buffer-min 8) or in the config YAML (segment-buffer-min: 8).

The encoder parameters can currently only be set in the configuration YAML (see the README) -- I'm now wondering if maybe the README should reconfigure this so non-standard. Someone might take the config from the readme as a template, and not remove those customizations.

If you don't change your configuration, the system should behave as before.
All of this only applies to VOD (or at least that's all I tested).

Disclaimer: once again, this code has mostly been written by the o3 and GPT-4.1 models.

---

As part of this research into the configuration of the transcoder, I've produced this documentation of the workflow. It helps me a lot, I'm wondering if it might be useful for others, too?
Note that it has been entirely extracted by o3 (in many long analysis back-and-forths), and I have not reviewed it for accuracy against the code.

VOD_architecture_concise.md

It's definitely work-in-progress, I'm still tweaking it every day. Let me know if you'd like to use it somewhere.

[hheimbuerger]

In some ways, this can be considered resolving #45.

[hheimbuerger]

The workflow documentation also resolves/explains a lot of the many misconceptions I had in 2022, when you tried to explain the process to me on #42. :)

[m1k1o]

This is definitely welcome, to have more options for configuration. I'll test it out.

[hheimbuerger]

As previously considered, I've moved that video encoder reconfiguration out of the 360p profile in the README. It didn't make sense to change that profile (and only that one), and to something very particular (requiring an Nvidia GPU and corresponding system configuration). Instead, I've created a new profile (1080p_nvidia_gpu), which clearly marks this as an unusual use case.

I've also changed the key codec back to encoder. I had previously changed it the other way because I had misread an existing usage of codec.
Anyway, doesn't matter, we're instructing ffmpeg how to encode here (e.g. copy), not which codec to use, so this is clearly the better identifier.

[hheimbuerger]

@m1k1o I wanted to let you know of my decision to create my own fork, due to the complexity of managing overlapping branches and my need for custom changes. This isn't criticism—I genuinely appreciate your work and acknowledge your expertise. I rely heavily on help of an LLM for my modifications to go-transcode.

I understand the direction I'm taking might differ from yours. So I think it makes sense for me to pursue my own fork. I honestly believe a lot of my changes are not a particularly good fit for the direction you might want to take this project in.

Apart from the bug fixes, configuration expansions, and logging statements to track transcoded and downloaded segments (which are presented graphically in the app I'm developing), I plan to address parallel transcoding jobs to accommodate the limitations of consumer-grade GPUs.

Everything will remain open and public. I'm happy to contribute back if you find any of my changes useful, but I'll leave it to you to request specific contributions. I hope this aligns with your project's license.