Option for output directory

[pat-e]

As like in "video transcoding" has the option -o, --output FILENAME|DIRECTORY It seems to be missing for "Other Video Transcoding". Would it be possible to add this feature / option?

Thank you in advance

[lisamelton]

@pat-e Sorry I took so long to add a comment. I've been traveling all day.

Technically it would be possible to add an option to the other-transcode tool which sets the output directory. However I don't plan to ever do this.

I intentionally designed other-transcode to create all its output in, and only in, the current working directory, i.e. the directory selected via the cd command.

Why? Because...

1. I want users new to the command line to be mindful of their current working directory lest they damage their original rips or files in their home directory. This scenario actually happened to one user of my older transcode-video tool.

2. Using the cd command is trivial. Especially since the argument to the cd command would be the same as any argument to an --output option.

I'll leave this open for now to allow you and any other users to comment.

[rhapsodians]

Hi @pat-e, welcome to one of the most common topics and requests :-)

When we started to help @donmelton test other-transcode throughout 2019 long before its public release, this topic came up early and there were two schools of thought: 1) you have to include an output name/path because we use it either at the command line or via wrapper script variables or 2) it's error-prone for both experienced and non-experienced CLI users due to potential reading/writing to the same folder/directory.

In the end, we all came to the same conclusion that it's better to avoid it and there are a number of better alternatives.

other-transcode accepts full path names to movies/tv shows as its input so you just switch focus to the output folder and run from there. It also accepts multiple inputs like *.mkv so it's even more important to run the command from the output folder/directory. In this scenario, you can't easily change names either as *.mkv will be determined at runtime by other-transcode itself.

When adding a wrapper script around other-transcode, it's trivial to set and switch to the output folder as a single folder or even be dynamic (e.g. make a folder called Movie (2020), cd "Movie (2020)", other-transcode "/path/to/source/Movie (2020).mkv" and the transcode will appear in the correct folder above.

The biggest win is that it completely avoids accidental mistakes (which we've all made on occasion) because you cannot overwrite the source or get errors where it tries to do so because you're already in the output folder. Once you try it and get used to the approach, you quickly start to understand Don's reasoning for avoiding a name or output mechanism.

That's my 2-cents so hope it helps.

[pat-e]

Hello everyone,

thank you for your help. I never got other-transcode to work with my current Ubuntu - Installation (something wrong with FFMPEG, and I'm too lazy to fix it) so my main PC used for "transcode-video" is a Windows-machine. I mainly use PowerShell for batching multiple files of the same format (like a TV-Series):

Foreach ($file in gci *.mkv) { transcode-video @file --add-audio 2 -o c:\temp }

Now I will just use a different input and run the script from the output-directory:

foreach ($file in gci -path c:\videos *.mkv) { other-video $file --add-audio 2=surround }

Hope this also help some other Windows/PowerShell users.

Best regards,

[skj-dev]

@pat-e

If you're only using coarse filtering, such as a file extension, then you can glob that with the tool.

Using your example, instead of a foreach, you could do:

other-transcode --add-audio 2=surround c:\videos\*.mkv

(and I'm assuming that works with Windows ... I rarely use that OS in any meaningful way)

As for the Ubuntu problem, if you're feeling adventurous, and are okay with using Intel GPU (i.e. not NVidia), I have a Docker container that might help with that. The big advantage is it bundles in FFmpeg because that thing can be a royal pain.

The biggest difference is the source directory (i.e. where the rips are) needs to be a sub of the output directory because the output directory is bind mapped to the container. So, if your source rips are in /path/to/videos, then you would cd /path/to, and using your example as a template, the command on your Ubuntu system would look like this:

docker run --device /dev/dri:/dev/dri -v $(pwd):$(pwd) -w $(pwd) \ 
  docker.pkg.github.com/ttys0/docker-transcode-vaapi/other-transcode-vaapi:0.2.0 \
  --add-audio 2=surround videos/*.mkv

[asheimo]

@ttyS0

I was using the method with transcode-video and @donmelton suggested that was an unreliable method due to how windows processes the . @donmelton correct me please if I didn't explain that correctly. So does this now mean that other-transcode is less likely to have problems with this method?

[skj-dev]

@asheimo I will absolutely defer to @donmelton, as his Windows expertise vastly outshines my own. 😄

My shell globbing experience is all UNIX/Linux based, and it's not unusual for it to work differently in the land of Windows. 😿 Having said that, since the wildcard gets processed by the shell, not the tool, I surmise any unreliability would manifest irregardless of the tool being used. 🤷‍♂

[lisamelton]

@asheimo Sorry I took so long to respond. I somehow missed the last two notification comments. (Due, no doubt, to advanced age and some kind of cognitive problem on my part. :) )

As usual, @ttyS0 is correct here. Using a wildcard gets processed by the shell. That behavior can seem a bit odd at times in cmd.exe but doing that in PowerShell isn't any more of a problem than using Bash or another UNIX shell.

The limitation or unreliability (that I probably mentioned months ago) comes from having a wildcard match so many files that the particular shell you're using either fails or simply drops the excess matches when the path names are "expanded" to pass along as arguments.

This is why you don't pass *.mkv in a path that would contain hundreds of matches.

[lisamelton]

@pat-e OK, much like Tom Bombadil, I will take the Ring or implement --output only if asked by all the Free People of the world. And clearly that has not happened. Yet. :)

So, I will close this issue for now. Thanks again for opening it.