Showing posts with label codecs. Show all posts
Showing posts with label codecs. Show all posts

The Story of the VP8 Encoder and Decoder

An x264 developer blogs about the work on writing a decoder for ffmpeg and how the code is not really perfect and the spec not really existing:

For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug? Or is this how it’s supposed to work? It’s hard to tell — there isn’t a spec to say so.
-- x264dev

Interesting to see the story of the great new universally accepted web video codec from his view. I bet developers at Firefox, Opera, and last but not least Google think similarly...

The Devil's in the Bitrate - A Crazy Detail about Recording FullHD Video with the Canon EOS 500D

Okay. So the Canon EOS 500D does create FullHD video. Well, alright, it's just with 20 fps. But that's actually not as bad as I had feared. Yes, there are no options whatsoever. That's kind of weird. And then there's this tiny details related to the options...

First I thought my computer was suddenly too slow for playing even 720p movies. Then I tried streaming them to my netbook with hardware accelerated video playback. And guess what: the excellent 18 Mbit/s I got on my wifi are not enough.

The photo camera uses a bitrate of over 20 Mbit/s (720p) and over 30 Mbit/s (1080p) for video recordings in AVCHD. That's significantly (at least +100%) more than e.g. the Panasonic HDC-SX1 uses for recording 50 interlaced fps with FullHD in the high quality setting. Either the encoding chip is not too good with compressing. Or they just locked the birate on freaking high to make it bothersome to record with the photo camera and keep out competition from their own video cameras.

Sometimes x264 gives spikes with e.g. 24 Mbit/s, so I think it's not just the bitrate being locked in. Maybe they could just not be bother to write a VBR video codec. And the sounds is uncompressed pcm. But of course with 30 Mbit/s, 0.7 Mbit/s sound doesn't matter much.

I recoded a 720p video (also over 20Mbit/s) with x264 and a CRF (quality) value of 23 (rather high):
ffmpeg -i "$IN" -acodec libmp3lame -vcodec libx264 -vpre normal -crf 23 "$IN small.mov"
The result: roughly 4 Mbit/s. 1/6th of the original data rate for as far as I can see the same quality. The file size usually goes down to 10-30% (!) of the original file.

It's kind of like the videos are recorded in a raw-like mode. The only thing is that you can't change it to normal compression. And yes, now I know why the camera records only 20 fps and not 25 or 30 in FullHD. Because otherwise it would probably use over 40 Mbit/s...

It actually sounds worse than it is. It just means you should probably have a nice script to recode your videos to a less crazy quality after getting them from the camera chip. The good thing is actually that the original quality is so high that the losses of transcoding should not be too high. And you should make sure your SD card can handle at least a steady 5 MByte/s writing per second if you want to record videos with your Canon SLR photo camera.

I'd love to hear about your experiences! Maybe it's only my camera that uses as much? But it definitely does.

Convert 1080i AVCHD directly to 720p avi with ffmpeg 0.5

With the realease off ffmpeg 0.5 there is much better AVCHD support in my experience, so you can use it for perfect conversions. You can download ffmpeg from ffmpeg.org and then use this script:

#!/bin/sh
# ffmpeg-avchd script by linux-tipps.blogspot.com
# to encode a directory use this command:
# for i in *.m2ts; do ffmpeg-avchd $i; done
IN="$1"; shift
OUT=$(echo $IN | sed 's/.m2ts//')-720p.avi
echo Encoding $IN to $OUT.
ff="ffmpeg -deinterlace -i "$IN" -acodec copy -vcodec libx264 -vpre normal -crf 25 -sws_flags lanczos -s hd720 -r 25"
echo $ff $OUT
nice $ff "$OUT"

The only thing I'm not really happy with yet is the deinterlacing and deshaking. I would like to use a sharper deinterlacer, but I guess I'd need mencoder for that. The Lanczos software scaler does make steady images pretty sharp already, though.

"Never use the second pass encoding again" - Using 'Constant Ratefactor' Instead of Average Bitrate in x264

Okay, I may not be able to completely fulfill that promise, but you will most likely be saved from the second pass and thus a lot of encoding time quite often with this tip. If you don't need the resulting file to e.g. fit on a CD, Constant Ratefactor aka Constant Quality is probably perfect for you. Let me supply you with a quick overview and my quick mencoder script that does the job.

Did you know you can use a roughly vorbis-like quality selection, constant quality crf even in x264? This will save you a lot of encoding time with more or less the same quality. Or maybe not? Well it will look different, but it should be fine. For x264 a range of 18-26 is recommended. The higher the number the lower the bitrate and thus the file size will be.

Nice! Finally I don't need to adjust and calculate bitrates myself anymore! The algorithms really seem to work, because when I now change the codec settings to more efficient ones (e.g. increase the frameref, subq or enable mixed_refs) the quality (SSIM) remained pretty similar, while the bitrate sank.

Some experience with the parameters: The mixed_refs parameter did regularly increase the SSIM for me, but also took a lot more time to encode. Frameref=2 increases the efficiency with little performance impact in my experience. I wonder why it's not the default. Bframes decrease the quality slightly but shave a lot off the bitrate and even increase performance a bit for me.

Let me show you my "quick" example script for mencoder.
#!/bin/bash

CRF=23.5 # 21-26 recommended, the higher the smaller the resulting file, see http://mewiki.project357.com/wiki/X264_Settings#crf

INPUT="$1"; shift
X264OPTS="$1"; shift
OUT=`basename "$INPUT"`"-x264.avi"
echo Encoding $INPUT to $OUT

mencoder="time nice /usr/bin/mencoder -quiet -cache 16384"
enc="$mencoder -ovc x264 -oac copy -x264encopts crf=$CRF:trellis=1:frameref=2:bframes=2:8x8dct:psnr:ssim:$X264OPTS"
# I suggest nr= of no more than 2 or 3 with current x264 from svn.
# something along the lines of -vf
# eq=contrast=20:brightness=2,hue=saturation=1.25 for bleak videos
# denoise3d for noisy and unsharp=l:3x3:1.045 for blurry videos.
# I recommend to try out the result with mplayer first.
# A combination of all may work well, too.

echo $enc -o "$OUT" "$INPUT" $*

[ -f "$OUT" ] && echo File exists && exit 1;

$enc -o "$OUT" "$INPUT" $*

# You can call the script like this:
# script.sh input [x264encopts] [mencoder parameters]
# $ sh menc.sh somefile.mpg "interlaced" "-vf crop=..." or
# $ sh menc.sh somefile.mpg "" "-vf crop=..." or simply
# $ sh menc.sh somefile.mpg
# to get the right crop settings try $ mplayer -vf cropdetect


Feel free to get out the flame thrower - or just make some productive comments.