convert frames10/frame001.png frames20/frame001.png frames30/frame001.png -adjoin frames/frame001.tiff

• Flush the stupid green tint with lutyuv=u=128:v=128.
• Avconv’s -nr option is there but doesn’t seem to do anything (at least for compressibility, with libavtools 4:0.8.6-0ubuntu0.12.04.1).
• hqdn3d does improve compressibility, but tends to wash frames to look like animation. Dark scenes with different shades of black particularly seem to suffer, though depending on how the source material is compressed it may look blocky to begin with.
• At least for the one sample film I’ve tested, CQ level has to be pretty big for transcoding to make sense at all in terms of compression. My eyes seem to have good tolerance for it though: the crappy-to-start-with B&W material compressed with --cq-level=30 doesn’t look overly bad compared to better-to-start-with color material compressed with --cq-level=10. --min-q will of course further limit the quality, but for values that matter for compression it starts to show.
• For the sample in question, the extra parameters (for arnr, pct and kf-dist) in WebM Guide’s “2-Pass VBR Encoding for Noisy / Low-quality Input Source” example increased the (resulting transcoded file’s) size, possibly for a gain in quality (but not apparently enough for my admittedly low visual acuity).

Edit: To back up my “CQ30 is good enough” claim, here’s a frame where the effects of CQ=10 vs CQ=20 vs CQ=30 are of the most obvious kind:

Just try and claim you’d prefer one of those over the others for your 1/25th of a second.

I came up with a better way to crop the videos: as before, figure out the best deinterlacer (say, yadif) with Avidemux, but then just look up the timecode (say, 123 seconds) for a good reference frame and go straight to avconv:

avconv -ss 123 -y -i input.mpeg -vsync 1 -r 1 -t 1 -vf yadif=0:0 -an frame%d.png

(Note that putting seek time with -ss prior to the input -i makes seeking faster but less precise.)

Now open the frame in Gthumb (or whatever is the snappiest photo resizing and cropping tool at the time), and go through the resize and cropping procedure I described earlier. Turns out Avidemux 2.5.4 is pretty clumsy at this: for example, it forbids resizing to odd numbers while avconv allows it, so getting the numbers in a visual tool that also allows odd numbers makes better results.

Back in the day, multiples of 16 in pixel dimensions were all but required for codecs’ compression not to crash and burn, but from my tests it would seem multiples of 4 or even 2 are fine for VP8.

In CQ mode, --target-bitrate becomes “target maximum rate”. If requested quality (--cq-level) can be achieved with less (than --target-bitrate) bits, it will be encoded so, but --target-bitrate does set the hard upper limit for bitrate. In addition, it defaults quite low if unset, even in CQ mode; at least my intuition (stemming from experience with Vorbis, probably) assumes CQ mode without set bitrate would take all the bits it needs to achieve the requested quality, but not so.

So, if reaching a certain size doesn’t matter, but quality does, I suggest --end-usage=cq and overshooting --target-bitrate with a high enough number to guarantee that quality is limited by CQ controls (--cq-level, --min-q and --max-q) alone, not by bitrate. Remember, any crazy big bitrate value will still be undershot if all of those bits aren’t actually needed to hit the quality target.

The default --cq-level value of 10 seems quite well struck (for certain material I can’t tell the difference from level 5 despite the +30% increase in file size), but even level 20 still doesn’t seem too bad (again, for the material I’ve tested it with, resulting in additional 30% saved in file size).

For my Intel Pentium G2120, `lshw -class cpu` and `dmidecode -t processor` both claim only one core is enabled on my dual-core Intel Pentium G2120. This is despite ‘All’ being enabled in the UEFI settings for cores enabled.

This is apparently just because lshw and dmidecode are not smart enough. `lscpu` tells it how it really is:

CPU(s):                2
On-line CPU(s) list:   0,1

Two-lobe Lanczos is fine. It’s Lanczos (or any other sinc-based filter) with more than two lobes that gets problematic.

However, if you’re going to use 2-lobe Lanczos, you might as well use Catmull-Rom [bicubic] since as mentioned previously the two are virtually identical. The reason you see any difference between the Lanczos filter and the “bicubic” filter in various image processing apps is that the bicubic they are using is generally not Catmull-Rom. Typically it’s a Mitchell-Netravali filter with the coefficients tweaked to be “sharper.”

Can you tell that I like Catmull-Rom a lot? I do. I like Lanczos2 as well, but again, the two are practically identical.

Post #47 on the topic of “Lanczos vs Bicubic comparison”, Page 2, @ AVS Forums

As I wrote at the end of the previous post, the second pass may fail with “Application provided invalid, non monotonically increasing dts to muxer in stream 0″ when auto-alt-ref=1 is used. The VP8 Parameter Guide now tells me that lag-in-frames depends on auto-alt-ref being enabled. Specifying lag-in-frames when using 2 passes therefore apparently won’t do any good (not as long as avconv chokes on auto-alt-ref=1). Additionally, auto-alt-ref is (“currently”) only available in 2 pass mode, so it’s a catch-22.

The arnr-* parameters are an alternative reference frame construction kit (alternative for auto-alt-ref + lag-in-frames), but auto-alt-ref can, according to the guide, “substantially improve quality in many situations (though there are still a few where it may hurt)” whereas arnr-* filtering is considered experimental and is disabled by default. Additionally, arnr-type is unsupported. All libvpx preset files provided with avconv currently have arnr-maxframes=7, arnr-strength=5 and arnr-type=centered.

The deadline parameter’s options best, good and realtime apparently translate to quality at the cost of speed, with “best” being “best quality, slowest to encode” and “not a recommended setting unless you have a lot of time on your hands.” The “good” option can be further tweaked with the cpu-used option: with cpu-used=0, quality will be “very close to and even sometimes better than” with deadline=best, but typically twice as fast. Bigger values of cpu-used (1-5) each translate to more encoding speed than the previous, but with equally noticeable impact on quality.

For slices, the ffmpeg wiki recommends “1 for small images, 4 or 8 for HD“. The aforementioned presets have 4 for 720p and 1080p, and no setting (probably meaning slices=1) for 360p.

For non-zero values of profile, the encoder increasingly optimizes low powered devices at the expense of quality.

I do video transcoding so rarely that I need to recall everything by trial and error each time, so this time I’m going to write my recipe down here. Note that a lot of the parts here (avconv, libvpx in particular) are moving, so parts of this’ll probably get stale pretty fast.

1. Figure out the filters using Avidemux. 2.5.4 works okay apart from an annoying bug, where closing the preview window closes the filters window as well. Workaround: use the Qt interface (eww!).
2. Preferable filter order:
   1. De-interlace
   2. Resize
   3. Crop

   Note 1: for 16:9 material stored in 720×576 without letterboxing (at least some old DVB recordings) seem to need an initial resize to 1024×576 prior to deinterlacing, for the deinterlacing to work better.

   Note 2: For deinterlacing, yadif seems to work generally well, although the Avidemux wiki does recommend Decomb Telecide for telecined DVDs. In any case, you should try different values for the parameters to see which ones are best with each source material. With yadif, preview using one of the bob modes for getting the field order right. “If you see the video jumping back and forth all the time, then the selected Field Order is wrong!”

   Note 3: Resizing prior to cropping means some tweaking back and forth between the parameters. My recipe for doing this for 720×576 (letterboxed 16:9 or true 4:3) material is:

   1. Resize to 640×480.
   2. Do precise cropping (cutting all and only excess parts from the frame).
   3. Go back and tweak the resize number bigger so that either X will be 640 or Y will be 480 after the crop, and the other bigger than it should be. (For example, if precisely cropped picture was 622 px wide, scale the resize up to X=640 + (640-622) and Y according to aspect ratio to closest even number.)
   4. Go back to cropping and cut the now longer-than-desired-target dimension. Also check that the precisely-targeted crop is still good (not excessive).
   5. (Optional 1) If the longer-than-desired dimension’s cut seems excessively intrusive, go back and resize the frame to a slightly smaller size than previously. (For example, X=650 instead of X=658, with Y again according to aspect ratio.)
   6. (Optional 2) Go back to cropping, adjust both dimensions aiming for the desired final resolution. Note that the new resize translates to some excess material possibly being left on the initially precisely-targeted dimension, but also to more expendable pixels to cut from the other (i.e. a less invasive crop).
3. Translate filters into avconv parameters. Note particularly that for yadif, “order” is 0 for “bottom first” in Avidemux, but 0 for “top first” in avconv. Do test clips with -ss and -t.

   For example, a two-pass MPEG-to-VP8-WebM:

   avconv -y -i in.mpeg -c:v libvpx -crf 10 -pre libvpx-360p -filter:v yadif=0:0,scale=664:498,crop=640:336:18:76 -b:v 717k -pass 1 -an out.webm
   avconv -y -i in.mpeg -c:v libvpx -crf 10 -pre libvpx-360p -filter:v yadif=0:0,scale=664:498,crop=640:336:18:76 -b:v 717k -pass 2 -c:a libvorbis -q:a 3 out.webm

   For yadif’s mode 1 to actually result in double-the-framerate, fps needs to be specified with -r. So for example, from a 25 fps source to a 50 fps 1 frame/field:

   avconv -y -i in.mpeg -c:v libvpx -crf 10 -pre libvpx-360p -filter:v yadif=1:0,scale=664:498,crop=640:336:18:76 -r 50 -b:v 717k -pass 1 -an out.webm
   avconv -y -i in.mpeg -c:v libvpx -crf 10 -pre libvpx-360p -filter:v yadif=1:0,scale=664:498,crop=640:336:18:76 -r 50 -b:v 717k -pass 2 -c:a libvorbis -q:a 3 out.webm

   (This caused me some headscratching at first, when mode 1 didn’t seem to result in the jerky effect clearly observable in Avidemux.)

   Note that libvpx/avconv may fail with “Application provided invalid, non monotonically increasing dts to muxer in stream 0” when a preset file with auto-alt-ref=1 is used, or (e.g.) with “Option lag-in-frames not found” when using presets and doing the second pass with audio (as I did above).

   The workaround for is to provide the options from the preset file in /usr/share/avconv/ as command-line parameters, except for auto-alt-ref, which fails either way.

   avconv -y -i g.mpeg -ss 280 -t 1 -c:v libvpx -crf 10 -filter:v yadif=1:0,scale=654:490,crop=640:480:8:6 -r 50 -g 120 -lag-in-frames 15 -deadline good -cpu-used 0 -slices 4 -profile 0 -qmax 63 -qmin 0 -b:v 768k -maxrate 1.5M -minrate 40k -arnr-maxframes 7 -arnr-strength 5 -arnr-type centered -pass 1 -an g.webm
   avconv -y -i g.mpeg -ss 280 -t 1 -c:v libvpx -crf 10 -filter:v yadif=1:0,scale=654:490,crop=640:480:8:6 -r 50 -g 120 -lag-in-frames 15 -deadline good -cpu-used 0 -slices 4 -profile 0 -qmax 63 -qmin 0 -b:v 768k -maxrate 1.5M -minrate 40k -arnr-maxframes 7 -arnr-strength 5 -arnr-type centered -pass 2 -c:a libvorbis -q:a 3 g.webm

Adapted this from yuvilio’s solution to down prioritize a PPA:

jani@saegusa:~$ cat /etc/apt/preferences.d/getdeb-unprefer
Package:  *
Pin: release o=GetDeb
Pin-Priority: 400

On Precise, this lets me install avidemux2.6 from GetDeb without pulling updated versions of other packages (transmission etc.) when doing a general update.

I once bought a DVD from outside my region, partly just to see if I could make it work. Regionset is the commandline tool to change your drive’s region setting, but it’s somewhat exciting to use due to the premise that DVD drives usually limit your chances of changing the region to 5 times, so mistakes can be costly. I figured I’d make this note of how it went, because examples of how it should go are reassuring to see prior to executing such delicate operations oneself.

My first issue was with the drive going bonkers (even before using regionset) every time I tried reading the out-of-my-region disc. After that region-compatible discs wouldn’t work either, and as regionset requires a working drive with a working disc in it, it would just fail with a “Please ensure there is a readable CD or DVD in the drive” prompt.

After a cold boot I made sure to insert a region-compatible disc in the drive, and that allowed me to run regionset.

jani@saegusa:~$ sudo regionset /dev/sr0
regionset version 0.1 -- reads/sets region code on DVD drives
Current Region Code settings:
RPC Phase: II
type: NONE
vendor resets available: 4
user controlled changes resets available: 5
drive plays discs from region(s):, mask=0xFF

Would you like to change the region setting of your drive? [y/n]:y
Enter the new region number for your drive [1..8]:1
New mask: 0xFFFFFFFE, correct? [y/n]:y
Region code set successfully!

Note that the comma immediately following “drive plays discs from region(s):” indicates my drive was initially unset for any region (as I reckon many of them are, so it’s not unusual).

To make it things even that much more exciting, regionset doesn’t tell you here what regions the numbers correlate to; for that you’ll have to consult the Interwebs or the listing in /usr/share/doc/regionset/README. Above, I set my drive to region 1, which is the North American region, which is where my expatriate DVD is from (I’m from region 2).

Here’s another run without changing the setting, just to show how the “drive plays discs from region(s)” now displays the new region code.

jani@saegusa:~$ sudo regionset /dev/sr0
regionset version 0.1 -- reads/sets region code on DVD drives
Current Region Code settings:
RPC Phase: II
type: SET
vendor resets available: 4
user controlled changes resets available: 4
drive plays discs from region(s): 1, mask=0xFE

Would you like to change the region setting of your drive? [y/n]:n