| #!/bin/sh | |
| # File from which the video is taken | |
| inputFile=$1 | |
| # File to which the HEVC-encoded video bitstream will be written | |
| hevcFile=${inputFile%.*}.hevctranscoded.hevc | |
| # File to which the final generated output video will be written | |
| outputFile=${inputFile%.*}.hevctranscoded.mkv |
| #!/bin/sh | |
| # Helper script to transcode to high-quality AV1 clips via ffmpeg | |
| # | |
| # Uses best possible settings with two-pass encode. | |
| # Encoding a full will take months or years! | |
| # | |
| # File from which the video is taken | |
| inputFile=$1 |
| #!/bin/sh | |
| # Converts audio from BluRay or lossless source into high quality | |
| # AAC files with custom stereo downmix parameters | |
| # | |
| # Use like this: | |
| # ./transcode-audio my_movie.mkv ger51 eng51 skip jpn20 | |
| # | |
| # Each parameter after the movie name tells the script which kind | |
| # of audio channel to handle. |
| #!/bin/sh | |
| # Helper script to transcode to high-quality x265 clips via ffmpeg | |
| # | |
| # Uses best possible settings with two-pass encode | |
| # See below for additional options. | |
| # | |
| # File from which the video is taken | |
| inputFile=$1 |
Obviously, don't do this unless you have a pressing reason. Matroska (.mkv) is
the better and free-er format and this only works if the video was in an .mp4
supporting format from the start (i.e. H.264 / H.265 with AC3 / AAC).
Requires mkvtoolnix (for mkvextract) and gpac (for MP4Box)
Step 1 - Unbox the Matroska Container
| #!/bin/sh | |
| # Helper script to transcode movies using the free VP9 codec | |
| # in very high quality (a full movie will take several days!) | |
| # | |
| # File from which the video is taken | |
| inputFile=$1 | |
| # File to which the final generated output video will be written |
| #!/bin/bash | |
| # Takes a screenshot of a predefined area of your desktop | |
| # Good for comparison images and making animations where FPS is too low for OBS | |
| # | |
| # Dependencies: | |
| # - scrot | |
| # - graphicsmagick | |
| # Change these values to match your preferences |
If you've ever ended up in the unlucky position of maintaining a poorly maintained codebase, you may know why experienced programmers generally advocate for smaller units of code.
The amount of code (or design) a human being can keep in active memory is limited, thus, if a unit of code is allowed to grow until the mental limit of the average team member is exceeded, code just gets /piled/ on top of what already existed. The capacity for suffering through this is sometimes astounding and a single unit of code can spiral into thousands of lines of features piled on top of each other with no knowledge of the assumptions and patterns that were once present in the rest of the code.
Of course, the solution is to break it down into smaller units a single mind can pick up and understand.
When writing instance methods that do not change the state of their instance but rather return a modified copy of the instance, it is often better to implement these methods as static methods accepting an instance as an argument rather as a argument-less instance method.
DO NOT Return Mutated State from Instance Methods
When many factors weigh into a condition, the condition statement can become unreadable, especially if combined with a poor line wrapping technique. This is a very basic technique that achieve much better readability when writing conditions.