Requesting a little help with my x264 encoding settings (mencoder)

[Coogan]

I'll get this out the way first: I don't know what most of these options or settings do. I created this from cobbling together a few settings I'd found from a Google search until I got something that didn't error out and produced a decent picture that was within my acceptable file size range. I've tried reading the mplayer/mencoder documentation but it doesn't take long before my eyes begin the glaze over and my brain starts screaming "No mas!". I just don't have the acumen to figure some of this stuff out, so I just do the best I can with what I can find.

So, with that out of the way, this began with my desire to off-load my (time-consuming) DVD encoding from my Windows desktop system to the headless Linux system I connect to via SSH waaay back in 2006. Everything has, for the most part, gone well, but I'd like to get some advice about improving it.

I've added the script as an attachment; I'd REALLY appreciate it if somebody could take a look at it and provide some feedback. I'm in no way, shape, or form a professional bash coder - it's just something I threw together, tested, and repeated until it worked.

Thanks

Coogan

[qyot27]

My suggestion would be to use the x264 binary directly to get the right fit of options (read: preset and tune and then any options not covered by those), and then use those settings with an ffmpeg build that has x264 enabled.

There's really no need to go the long way and specify every option. And while I realize that's probably due to mencoder (have they added the ability to use preset and tune in the ovcopts?), there's also pretty good reasons to not use mencoder.

If you *must* have something similar to mencoder (as I do realize you're doing this directly from a DVD device rather than dumping the decrypted streams to the hard disk first), then I'd use mpv. It doesn't have direct stream copy, but you could always demux the audio with ffmpeg first and then remux it with ffmpeg afterward. Since it's an mplayer variant, mpv does have the standard mplayer template ability, so you can define the group of settings easily and then call it using -profile (which you can also do with mencoder, but mpv exposes ffmpeg's encoding options directly and therefore can use preset and tune options with libx264 if that turns out not to be possible with mencoder).

Summary of differences among mplayer, mplayer2, and mpv (https://github.com/mpv-player/mpv/blob/master/DOCS/man/en/changes.rst)
mpv encoding guide (https://github.com/mpv-player/mpv/blob/master/DOCS/encoding.rst)

[Coogan]

I'll certainly check MPV out and see what it can do. The primary reason I've kept using mencoder is it's the only one I've found that has both CLI and CPU throttling. My Linux system is a small form factor so managing the heat in the system is critically important. Using all 4 threads available shoots the internal temp past the CPU thresholds. Being able to enforce 2 threads allows the process to stay comfortably below that threshold.

I tried using Handbrake_CLI, which says it could throttle the CPU, but no matter what I set it at it used all 4 threads every time.

The main reason I'd like to get my settings re-examined is that recently I've been wanting to add subtitles to my videos. I could (and have in the past) use opensubtitles or any other subtitle repo to download what I need, but every subtitle I've downloaded for a TV show has been off-sync. The only other option I have is to make my own subs from the DVD (I've been using SubRip, since there seems to be no Linux CLI tool available*). However this will be very time-consuming to pull out my DVD collection and start re-ripping them. I'm concerned that my mencoder settings may be hosing the frame rates of my TV show rips and throwing downloaded subs out of sync. I just don't know enough about the settings I'm using the know if that's happening or not.

*I use Plex for my media center on some jailbroken AppleTVs. According to Plex, only SRT subtitles are usable on IOS, so vobsubs are out of the picture. A shame, since I was easily able to rip those out with mencoder.

I appreciate the help.

Chris

[nhakobian]

Using all 4 threads available shoots the internal temp past the CPU thresholds. Being able to enforce 2 threads allows the process to stay comfortably below that threshold.


There are standard linux utilities to manage how the system schedules a process onto cpu cores. The most standard way is using the command 'taskset'. If I remember correctly, you have to set a bitmask which says which CPU cores you want a program to run on; using a bitmask of 3 should limit it to CPU0 and CPU1. I suggest you use `man taskset` or do a quick google search if you're not familiar with it.

The benefits are now you can use ANY program and can limit which cores it works on. If you use a program which creates threads depending on the number of cores detected (such as x264), you may also want to force the number of threads to a lower value if you restrict the process to fewer CPUs. x264 by default sets --threads to 1.5x the number of logical CPU threads, for example.

EDIT: I just check the man page for taskset. You don't have to worry about bitmasks, there is an option where you just give it a list of cpu numbers to restrict a process to. Might make your job easier if you're not familiar with bitmasks.

[qyot27]

At least for ffmpeg, threads can be used for decoding (before the input) and for encoding (before the output) - that is, if I'm understanding that part right. If Handbrake is anything like that, it could only have been setting one of them to 2 threads and leaving the other at full tilt. mpv's threading is controlled with --lavdopts=threads= for decoding, and also possibly --ovcopts=threads= for encoding (at the very least --ovcopts=threads= was accepted without throwing up a warning or error).


RE: SubRip, it would seem possible to use subtitleripper (http://subtitleripper.sourceforge.net/) for that. It seems to depend on GOCR (http://jocr.sourceforge.net/) to do the OCR conversion. I've not looked into it any further than that, but from the thread on Fedora's forum about it, subtitleripper should be CLI (as KSubtitleRipper is a frontend to it). Obviously only if this is what ends up having to happen later. Depending on how predictable the skew is, it is possible to just use Aegisub or SubRip Minitools (http://subtools.sourceforge.net/) to correct the ones you get from opensubtitles, et al.