The installed software is descent, tunes fast and didn’t crash (yet). It supports decoding multiple channels from a single multiplex (known as multirec in the MythTV-world). The manual (local copy) could be more thorough, though. The recording-scheduling simply sucks, especially if you’re used to MythTV’s scheduling.

To watch TV Vlaanderen, you need a smartcard and the corresponding CAM. The physical CAM, however doesn’t seem capable (dutch link) of decoding multiple streams in parallel. So we switched to an alternative firmware…

I chose to use the openPLI image. I’m currently using the daily snapshot 2009-12-07 (local copy). Flashing the device was easy. The manufacturer even provides a procedure and tool (local copy of version 1.3.3.4) to do it.

After flashing with the new firmware, I installed the CCcam plugin, which is a software implementation of the CAM (commonly referred to as softCAM). I’m not sure what the legal status of this setup is, but since it still requires an official (and payed-for) smartcard, I guess it’s ok.

Additional notes

When using the networkbrowser (also a plugin), I couldn’t get my NFS-mount to work properly. It seems that the dreambox-configuration defaults to NFS over TCP, which somehow doesn’t play well with my server. Explicitly configuring the mount to use UDP solved the problem.

I wanted to get an idea what kind of quality/time gains could be archived with these settings. Usually the first steps of extra quality are barely noticeable in encoding time, while the last bits of quality cost significantly more. To verify this statement and to quantify it, I encoded 2 video sequences at 2 resolutions using all 9 available presets. I used PSNR as metric. I’d be the first to admit that PSNR does not correspond to quality, but it correlates reasonably well.

The results in short: the “slower” profile seems to give very high quality (-0.1dB PSNR loss) while reducing encoding time by roughly a factor 4! “veryfast” gives a substantial quality-boost (2.1dB PSNR) while only requiring 15% more encode time compared to ultrafast.

This graph shows the relative speed gain/loss vs PSNR gain/loss. The “slower” profile is taken as a reference.

The presets

Since they seem to be removed from the wiki, here is a copy:

• ultrafast: subme 0, ref 1, me dia, b-adapt 0, partitions none, trellis 0, bframes 0, weightp 0, no-mixed-refs, no-mbtree, no-scenecut, no-deblock, no-cabac, no-8x8dct, aq-mode 0
• veryfast: subme 1, ref 1, me dia, partitions i8x8,i4x4, trellis 0, weightp 0, no-mixed-refs, no-mbtree
• faster: subme 4, ref 2, weightp 1, no-mixed-refs, no-mbtree
• fast: subme 6, ref 2, rc-lookahead 30
• medium: No changes
• slow: subme 8, ref 5, me umh, b-adapt 2, direct auto, rc-lookahead 50
• slower: subme 9, ref 8, me umh, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2
• veryslow: subme 10, ref 16, me umh, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2, bframes 8, merange 24
• placebo: subme 10, ref 16, me tesa, b-adapt 2, direct auto, rc-lookahead 60, partitions all, trellis 2, bframes 16, no-fast-pskip, slow-firstpass

• No B-frames
• No CABAC
• No weighted predictions
• No 8×8 DCT
• Max resolution around 640×640 (technically 1620 MacroBlocks, 16×16 each)
• Max 25fps at that resolution (technically 40500 MacroBlocks per second)
• Max 10Mbps

The iPhone imposes some extra limitations:

• Max 640×480, 30fps
• Max 2.5Mbps

Most guides on the internet additionally force the number of reference frames down to 1 (ffmpeg‘s -refs parameter), although I could no find any specsheet imposing this limit. So I decided to test this.

Testing the number of usable reference frames isn’t easy. For starters, you can’t force an encoder to use a certain frame as reference, you can only allow it to use that many if it sees fit. However, by hand-picking the input frames, you can create a frame sequence that almost certainly will use the reference frame you want. Simply take N frames from different shots. Just concatenate these N frames after each other in a loop: frame 0 is exactly the same as frame N. The encoder will try to minimize the residual image by choosing the reference frame which is most similar. Since the N frames are totally different, the encoder will almost certainly choose frame I-N as a reference for frame I.

Upon decoding the stream, the decoder will fetch the referenced frame from its Decoded Picture Buffer (DPB) and work from there. That is, as long as the referenced frame is still available. If the referenced frame is no longer available, the decoding will fail. Depending on the decoder, it might stop, crash, or attempt to cover up it’s mistake. The iPhone implements the last option. It seems to use a “wrong” reference frame and work from there.

After some trail and error, it seems that the iPhone keeps 6 frames for reference, which is what a level 3.0 decoder should do (6.59 according to the spec).

Update 2009-11-27

The above was for for 640×480 frames; Since the DPB is specified in bytes, smaller frame sizes should result in more reference frames. My iPhone 3G 3.0.1 however does NOT play this correctly. This is the result with 512×288 video (specs says 13 reference frames in the DPB):

Strangely, an iPod Touch plays it just fine… So here I’d like to call for help:

If you have access to an iPhone and/or iPod Touch, try playing the first 30 seconds of Big Buck Bunny encoded with 7 reference frames (4.5MB). Please report using the comments below:

• Your hardware type (2G, 3G, 3GS, Touch, …)
• Your model number (Settings -> General -> About -> Model)
• Your version number (Settings -> General -> About -> Version)
• Does it play with or without artifacts
• Anything else that might be important

The list

• iPhone 2G (MB346F) 3.1.2 NOT OK
• iPhone 3G (MB496NF) 3.0.1 NOT OK
• iPhone 3G (MB501DN) 3.1.2 NOT OK
• iPhone 3G  (MB489NF) 3.1.2 NOT OK
• iPod Touch 1st gen (MB376C) 3.1.2 NOT OK
• iPod Touch 1st gen (MA623ZD) 3.1.2 NOT OK
• iPod Touch 2nd gen (MB528KN) 2.2.1 OK
• iPod Touch 3rd gen (MC008MF) 3.1.2 OK
• iPhone 3GS (MC132NF) 3.1.2 OK, confirmed twice
  

The source image is a frame from an HD-SDI stream, which has a color-depth of 10 bits instead of the usual 8. The sample packing seems to be UYVY, but using 16bit per component (with the lower 6 bits always 0).

Since I only wanted to have a quick view of the frame, I just discarded the lower 2bits (i.e. byte) and converted that instead. This perl-script discards the least significant byte:

while( read STDIN, my $block, 2 ) {
 my @value = split //, $block;
 print $value[0];
}

The output can be fed into ImageMagick’s convert tool:

convert -size 1280×720 -interlace none -sampling-factor 4:2:2 8bit.uyvy out.bmp