The program should be pretty user friendly yet flexible. The --target option is flexible but not very easy to read. The --target option should probably be more verbose, show hierarchy, and use named arguments

Inpsired by rust structs .transcoderc file could be in a format like:

mypreset = mkv {
    video: maxres {
        maxheight: 1024,
        maxwidth: 768,
        encoder: h264 {
            crf: 18,
            speed: normal
        }
    ),
    audio: opus {
        bitrate: 192
    }
}

If it's very hard to implement an parser, consider using some json format.

If you select a video only file, ffmpeg seem to report an error and the file is skipped.
Not tested but i suspect the same happens with audio files.

It should be possible to add additional targets.

Should consider whether to enable users to pass options directly to ffmpeg or to parse them. Or both.

FFmpeg outputs the amount of seconds processed.
We also know the amount of total seconds.

We assume amount processing speed for a single conversion is constant. (though this could cause significant an error).

Each file should have a calculated field called "Work"

It's the estimated amount of processing needed to complete.

The significant factors (that we can know before processing) could be:

• input audio decoder
• input video decoder
• hardware decoders are present or is done by cpu
• output video encoder
• output video encoder
• hardware encoders are present or is done by cpu
• input width
• input height
• output width
• output height
• duration
• frames/sec

Need some kind of system to collect all these variables and estimate the amount of work.

We can probably just learn as we go from the computer, which make "hardware support" constant.

Also probably these variables are not completely independent.

A formula could be:
work = output_decoder * input_decoder * width * height * (frames/sec * duration)
where input_decoder and output_decoder are some number.

When a conversion fails, it exists earlier.
When a conversion is shorter than expected, it exists earlier.

This messes up the amount of work done, especially when a big file fails in the beginning. The calculated processing speed becomes way too high.

A fix would be to change the way progress works:
Status::Done(Done{target}) = Status::Progress(Progress{processed})
Status::Fail(Fail{target}) = Status::Progress(Progress{processed})

Suggest adding a new video encoder layer that downscale to be within a specified maxwidth and maxheight

The target files should have their file extension changed to match the target container format.

The table is too long. Maybe only show the current file being processed and the total progress.

Maybe a new option or a null encoder

--no-video and --no-audio
--format=mkv,null,opus,192 --format=mkv,h264,18,normal,opus,192

Sources are filtered away if they are not video/audio files. The way it's implemented is to discard any source that had any ffprobe error.

If ffprobe fail for some unknown reason, it is simply silenced and skipped.

Only certain errors from ffprobe lead to a skip, not all errors.

Or maybe just a percentage representing the compression ratio

If ffmpeg errors happen, the target file should be deleted, and the processing should just skip it and continue.

Report the errors in the end of script.

The order of processing right now is by command line order and whatever walking a dir returns.

Another idea is to do the smallest (quickest) conversions first. In this way if the user decides to cancel, there are at least some finished conversions.

A use case is that you start the conversion, and then check out the result immediately to check the quality.

It should be possible to cancel the script and when you run again it picks up where you last cancelled.