new feature: live streams generated on the fly via .dms.json

[irsl]

new feature: live streams generated on the fly via .dms.json config files
bugfix: Samsung Frame TVs crashed when fetching transcoded/live streams due to HEAD request

I can finally watch my cams in HD without transcoding :)

[anacrolix]

Thanks, this is looking very nice. Do you want to refer to it as "dynamic streams", as it doesn't have to be a live stream, it's content that just doesn't exist in a fixed form on the disk. Additionally, rather than requiring a shell command string, what about having it call into an executable file that generates the output as required. This makes it easier to use alternative shells, or have stand alone programs generate the content, which may be easier on some plaforms. For example rather than trying to cram a shell command into a JSON string like "/my/preferred/shell -c \"the actual thing i want to do\"" it would be an executable file containing

#!/my/preferred/shell
the actual thing i want to do

[irsl]

Hehe, I renamed it to "live streams" in the last minute as I thought it would be more clear for end users. Now reverted it back.

Originally, I wanted Command to be a string slice (so the embedded way to use it would have been sth like this: ["sh","-c","exec long-ffmpeg-command-here"]), but that would have required changing the transcodeSpec interface, which I didn't prefer. Now I added a helper function to parse the command string - I wouldn't like storing one more shell script for a (long) oneliner - especially as it would need to go outside the media root dir to avoid the logstream spam ("... ignored: non-media file").

If you prefer decoupling this feature from serveDLNATranscode and duplicate that code partially, let me know.

[anacrolix]

I think I'll trust your instinct on the executable command thing. I think I prefer the old version with just a slice or string to be passed to the shell, I don't know about having a parser embedded, but I'll merge now and let it mellow. Thanks for your contribution!