Manual conversion

[gittyVenison]

What command can manual convert files to mkv if streamdvr fails to do it itself. I found this command. Replace it with .ts input and mkv outpt, but it seems to go a lot slower then streamdvr does

for i in *.avi; do ffmpeg -i "$i" -qscale 0 "$(basename "$i" .avi)".mov ; done

Is there something else I should do

[ghost]

Try replacing -qscale 0 with -c copy, that should just remux the video and audio track from the input container into the output mkv container.

[jrudess]

You can find the options that streamdvr uses in scripts/postprocess_ffmpeg.sh

ffmpeg -hide_banner -v fatal -i "$input" -c copy $mp4args -copyts -start_at_zero -analyzeduration 300000000 "$output" > $tmp/stdout 2> $tmp/stderr

[jrudess]

When converting to mkv $mp4args is empty. If you want to convert to mp4, then replace that part with -bsf:a aac_adtstoasc

[jrudess]

Reopening this issue. Will use this sighting to track implementation of a better flow to be able to automatically continue converting if streamdvr crashes, or is shutdown before all conversions can finish.

[jrudess]

I think what I will do is this:

• On startup, if any .ts files are found in the capturing directory, then streamdvr will begin converting them.
• But first, check if a file of the desired output name already exists. If so make the new output name be post-pended with (1), (2), etc.
• After conversion, if the .ts file can not be deleted (e.g. bad permissions), be certain a very obvious error is displayed, because every startup will result in a new converted file showing up.

[jrudess]

The post-process queue is an independent 'thread' from the main polling loop, so it should not delay startup. I will verify this in testing before committing.

[gittyVenison]

This is what works for me for i in .ts; do ffmpeg -i "$i" -c copy $mp4args -copyts -start_at_zero -analyzeduration 3000000000 "${i%.}.mkv" ; done

Although -c copy works as well

Can't get basename not to do double extension

[jrudess]

Some hiccups now that I'm starting implementation. The current postprocess flow relies on a few pieces of info that are not readily available in a startup situation.

• Which site the recording is for
• Which streamer the recording is for

This is not a simple resolution in the current code architecture, but one possible fix is to change how the capture directory works to be always hierarchical:

capturing/SITE/streamer/file.ts

Then it is possible, regardless of whether config.yml changes between restarts, to easily parse out the site and streamer for the file that is being converted.

[jrudess]

My initial idea was still going to be a pretty big rewrite of some sections of logic, so I've opted for a compromise for the near-term. Left-over .ts files that are converted at startup are now placed in "captured/UNKNOWN/filename.mp4"