This space left intentionally blank.

  • 0 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle






  • Shell scripts were a mistake.

    I understand 1000% but I’m not sure I agree. With the peevishness of C and latent autism of assembly, something compiled or otherwise binary isn’t always simple and straightforward. Sometimes, you have a task that only needs to be done three times, and just replaying the commands is sufficient.

    sh, ash, and bash are all kinda dumb. Absolutely. But there are other shells that are significantly better. csh and zsh are both great. ksh has some history on it but is good too. But “shell scripts” don’t have to be in your shell language. The hashbang line will let you make a command file and so long as you can describe the command line you can get most shells to run it. Be that language line noise perl or python or even go.








  • I have some comments based on personal experiences with GPU av1 encoding: you will always end up with either larger or worse output with GPU encoding because currently all the encoders have a frame deadline. It will only try for so long to build frame data. This is excellent when you are transcoding live. You can ensure that you hit generation framerate goals that way. If you disable the frame deadline, it’s much much slower.

    Meanwhile CPU encoders don’t have this because CPU is almost never directly used in transcoding. And even with a frame deadline the output would still not be at the same speed as the GPU. However the CPU encoders will get frames as small as you ask for.

    So if you need a fast transcode of anything, GPU is your friend. If you’re looking for the smallest highest quality for archival, CPU reference encoders are what’s needed.