Playing HLS streams with mpd

If you're playing with the idea to turn your Raspberry Pi into an internet radio you will sooner or later come across the MusicPlayerDaemon (mpd).  It's a server daemon without an user interface with the sole objective to play music and manage playlists.  It exposes however a control port over which command line utilities, apps on mobile phones, or even desktop applications can talk to it using a common “command language”.  This way they can make mpd create playlists which can be stored on the server, play songs from a playlist, stop the playback, skip titles etc.

Even though the content usually resides on your hard disc mpd can fetch it from other devices, e.g. a NAS on your LAN, or even from (web radio stations on) the internet.  The list of your favourite stations boils down to a simple playlist containing their urls, switching stations is the same as skipping to the next song in the playlist of your favourite artists.

Most stations use MP3 or AAC streams which are easily handled by the version of mpd available in the repository of your Linux distribution, even though that version might be a little dated.

HLS streams - as deployed by the BBC for example - are a little trickier.  In order to get to the music various playlists have to be downloaded and parsed, and every 10 seconds or so, the next chunk has to be downloaded from another url.  ffmpeg (or its fork avconv) can handle this overhead but even though ffmpeg is compiled into most version of mpd installed from repositories, trying to open an HLS stream will not work.

The current (Feb. 2017) repository version of mpd is 0.19.1.  You can check the decoder plugins:

$ ./mpd --version
Music Player Daemon 0.19.1
...
Decoders plugins:
...
[ffmpeg] 16sv 3g2 3gp 4xm …

The solution to remedy this situation is already in the source code – perhaps a little hidden. You will have to compile mpd as described below.

However, I did install the version from the repository first. It comes with some system integration like start and stop scripts for the boot process, setting up of an mpd user account on the Raspberry, etc. I've modified the scripts in a few places to point them to the freshly compiled mpd version.

As we have to compile it anyway, let's us the newest version from the mpc homepage.

(The following steps have been tested with mpc 0.20.4 on a Raspberry Pi 3.
In the description below change the version number accordingly.)

Start by installing the required libraries:

sudo apt-get install g++ \
  libmad0-dev libmpg123-dev libid3tag0-dev \
  libflac-dev libvorbis-dev libopus-dev \
  libadplug-dev libaudiofile-dev libsndfile1-dev libfaad-dev \
  libfluidsynth-dev libgme-dev libmikmod2-dev libmodplug-dev \
  libmpcdec-dev libwavpack-dev libwildmidi-dev \
  libsidplay2-dev libsidutils-dev libresid-builder-dev \
  libavcodec-dev libavformat-dev \
  libmp3lame-dev \
  libsamplerate0-dev libsoxr-dev \
  libbz2-dev libcdio-paranoia-dev libiso9660-dev libmms-dev \
  libzzip-dev \
  libcurl4-gnutls-dev libyajl-dev libexpat-dev \
  libasound2-dev libao-dev libjack-jackd2-dev libopenal-dev \
  libpulse-dev libroar-dev libshout3-dev \
  libmpdclient-dev \
  libnfs-dev libsmbclient-dev \
  libupnp-dev \
  libavahi-client-dev \
  libsqlite3-dev \
  libsystemd-daemon-dev libwrap0-dev \
  libcppunit-dev xmlto \
  libboost-dev \
  libicu-dev

Download the source code:

wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.4.tar.xz

You might want to check the GPG signature:

wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.4.tar.xz.sig
gpg --verify mpd-0.20.4.tar.xz.sig

Unpack the archive:

tar xvfJ mpd-0.20.4.tar.xz
cd mpd-0.20.4
./configure

Now to the special magic. The ./configure utility has scanned the system environment and has written its findings into configure.h. Open that file with an editor. You should be able to find the following line:

#define ENABLE_FFMPEG 1

This means that the ffmpeg libraries have been detected and will be used.
Now add the following line and save the file:

#define HAVE_FFMPEG 1

This line will change the fallback decoder in src/decoder/DecoderThread.cxx from “mad” to “ffmpeg”. ffmpeg can handle m3u8 playlists typically used by HLS while mad can not.

Now start the build process with

make

and if there are no errors install mpd:

sudo make install

On the Raspberry this new version is stored in /usr/local/bin while the original version still remains in /usr/bin.

Confirm the version of the new file:

$ /usr/local/bin/mpd --version
Music Player Daemon 0.20.4

Additional changes

The following changes of the initial mpd install are necessary to get the new version running on the Raspberry Pi.

Raspberry uses systemd.  There is a control file for the mpd service that needs to be changed:

sudo nano /lib/systemd/system/mpd.service

change:
ExecStart=/usr/bin/mpd --no-daemon $MPDCONF
to the new location:
ExecStart=/usr/local/bin/mpd --no-daemon $MPDCONF

Keep in mind that this change might be overwritten if the repository version of mpd is being updated later on... which doesn't happen that often.

Uncomment the following line in /etc/default/mpd. This will define the variable MPDCONF.

MPDCONF=/etc/mpd.conf

Let us change some settings in mpd configuration file /etc/mpd.conf

sudo nano /etc/mpd.conf

In the default configuration mpd and its client must run on the same machine. In order to allow access via the network change:

bind_to_address         "localhost"
to
bind_to_address         "any"

For convenience I've changed my music_directory to a place where I can more easily add music files. Keep in mind that his folder needs to be world readable so that mpd running as user “mpd” can access it.

music_directory         "/home/pi/Music"

Now we have to tell the system to read the new configuration and restart the mpd service.

sudo systemctl daemon-reload
sudo service mpd restart

Check the status of the service:

sudo service mpd status

Unrelated problem

In my first attempts mpd froze after playing the first title.  Someone suggested to remove pulseaudio... and it worked.

sudo apt-get remove pulseaudio
sudo reboot

Links

• https://www.musicpd.org/doc/user/install_source.html

• https://www.musicpd.org/download.html

• https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

How to "average" PNG files with ImageMagick

In a recent post on CgCookie Kent Trammell explained that you can improve the quality of a Cycles render by rendering the image multiple times if you use a different value for the sampling seed.

In his case those images were calculated by different computers of his render farm.

But the same is true, if you waited for an hour for a render to finish, and you are pleased with the image except for the noise.  In this case save the image, change the seed value and render it again.  This way the first hour was not in vain.

In any case you will end up with one or more PNG files with look similar except for the noise pattern which changes with the seed value.

If you calculate the mean image of these images the noise level will be reduced.

Kent Trammell showed how this calculation can be achieved with the Blender node editor (his math was a bit off, but the principle is sound).

The same could be accomplished with other programs like Photoshop or The Gimp or command line tools like ImageMagick.

The ImageMagick command for doing this is:

convert image1 image2 image3 -evaluate-sequence mean result

However, if you try this with PNG files that contain an alpha channel (RGBA) the result is a totally transparent image. 

In this case use the option "-alpha off", e.g. like this:

convert render*.png -alpha off -evaluate-sequence mean result.png

A final note: Keep in mind that all images will be loaded into memory during this process - i.e. you want to limit the number of images.

How to store images in mp3 files using eyeD3

(This post refers to version 0.7.1 of eyeD3)

eyeD3 is a powerful python utility for manipulating id3 tags from the command line, but it also exposes these function as a python module.

Unfortunately the documentation on the site on how to use it as a python module is sparse, although it covers most use cases:

import eyed3

audiofile = eyed3.load("song.mp3")
audiofile.tag.artist = u"Nobunny"
audiofile.tag.album = u"Love Visions"
audiofile.tag.title = u"I Am a Girlfriend"
audiofile.tag.track_num = 4

audiofile.tag.save()

Information on how to access images are not readily available. But being open source, you can look at the source code to find out:

Example on how to append an image

import eyed3

# load tags
audiofile = eyed3.load("song.mp3")

# read image into memory
imagedata = open("test.jpg","rb").read()

# append image to tags
audiofile.tag.images.set(3,imagedata,"image/jpeg",u"you can put a description here")

# write it back
audiofile.tag.save()

The constant 3 means Front Cover, 4 means Back Cover, 0 for other.
The complete list can found at eyed3/id3/frames.py

"image/jpeg" is the mime type.
u"...” is a description, which must be provided in a unicode string. EasyTAG e.g. stores the original file name in this field.


Example on how to access the images

import eyed3

# load tags
audiofile = eyed3.load("song.mp3")

# iterate over the images
for imageinfo in audiofile.tag.images:
   ...

Amoung the infos available via imageinfo are:
 .image_data - image binary data
 .mime_type  - e.g. “image/jpeg”
 .picture_type - 3, 4, 0, see above
 .description - the description field

You can access the imageinfo also like this:

audiofile.tag.images[x]

Where x is the index into an array starting with 0. Eventually you will get an out of range exception.

AVCHD and avidemux

Many current camcorders store video according to the AVCHD specification. This is a MPEG2 transport stream with video encoded in H.264 and audio in Dolby AC-3 format.

avidemux which usually is my Swiss army knife for video conversion could not handle the .MTS files produced by the camcorder - at least not the version which are currently available in the Ubuntu repositories (avidemux 2.5.x).

After visiting the avidemux homepage I was pleased to find out, that version 2.6 can handle that format.

This post describes how to compile avidemux 2.6. It mostly reflects the process laid out in the avidemux wiki with some additional information to avoid some pitfalls.

I tested it on vanilla installs of Ubuntu Natty and Precise and the compilation works like a charm. Please keep in mind that you compile from nightly builds and not all functions are implemented yet (May 2012, git revision 7949).

Requirements:

First we need git to pull the source code:

sudo apt-get install git

For the core application

sudo apt-get install libxml2-dev gcc g++ make cmake pkg-config libpng12-dev fakeroot yasm

For the GUI (QT4)

sudo apt-get install libqt4-dev

For the common plugins

sudo apt-get install libaften-dev libmp3lame-dev libx264-dev  libfaad-dev libfaac-dev

For the PulseAudio plugin

sudo apt-get install libpulse-dev

Download the source

git clone git://gitorious.org/avidemux2-6/avidemux2-6.git

Compile it

cd avidemux2-6

bash bootStrap.bash --deb

This will produce four .deb files in the ./debs folder.

Install it

cd debs

dpki -i *

Run it

avidemux3_qt4

Configure it

Sometimes you have to select the correct audio device in Edit - Preferences - Audio - AudioDevice:

Links:

avidemux homepage + wiki

How-to abcde from an audio CD image

abcde is a command line CD encoder.  It rips CDs and encodes it in MP3, OGG or other formats.

By default it reads from your CD drive.  If you only have an image of your CD you are out of luck. You can either first burn the image on let abcde work on the CD, or use the only other format abcde currently accepts as input: a flac file with embedded cue sheet.

There are two common images files for audio CDs: cue/bin and toc/bin

The bin file contains the digital representation of the audio, whereas the remaining file describes where the tracks start and end.

cue/bin

You can create the flac file from cue/bin files using the following command:

flac --best --force-raw --sample-rate=44100 --channels=2 --bps=16 --endian=big --sign=signed --cuesheet=image.cue image.bin -o image.flac

Check the compression ratio after flac has finished.  A ratio of approx. 0.99 usually indicates that the byte order is reversed.  This may happen if the image was created on a Mac. If you play back the flac file, you will hear mostly noise. In this case change the byte order to

--endian=little

Normal compression ratios are in the range of 0.6 to 0.7.

You can then convert the flac file to single tagged MP3 files using:

abcde -d image.flac

toc/bin

flac can't process TOC files. You have to convert them into the CUE format. Fortunately there is an app for that: cueconvert from the cuetools package:

cueconvert image.toc image.cue

I had to find out that cueconvert will abort with a syntax error when I used toc files created by Brasero.

In this case load the toc file into a text editor and remove the CD_TEXT { … } block, if present.

And while you're at it, delete all lines containing ISRC codes, as flac does not like these.

After the conversion use the resulting CUE file as described earlier.

Replay Gain on Sansa Clip+ with mp3gain

If you play MP3 songs from different sources in shuffle mode on a MP3 player, their difference in loudness become apparent and you are constantly keep adjusting the volume.

In order to prevent that, Replay Gain can be used. With this function the MP3 player uses loudness information in the header of a MP3 file to adjust the volume automatically.

However, the loudness information is not present by default. You need software to analyse the content and store those values in the MP3 header. Replay Gain does not change the underlying (music) data, thus avoiding loss in quality by decoding, processing and re-encoding.

A popular utility in the Linux world to calculate these values and tagging the file is mp3gain.

I used it regularly, but I was still adjusting the volume on my Sansa Clip+ ...

What I didn't know was, that by default mp3gain stores the information in the APEv2 tag which the Sansa Clip does not read. In order to be used by the Sansa Clip's Replay Gain function, it must be stored in the ID3v2 tag.

mp3gain has an option to do exactly that: -s i

I'm now using the following command to analyse and tag my MP3 files:

mp3gain -p -s i *

Where the option -p also preserves the original file date.

WinTV-HVR-1900 under Ubuntu 10.04 and 10.10

A few weeks ago I bought a Hauppauge WinTV-HVR-1900 (USB id 2040:7300) which I wanted to use with a (32 bit) Ubuntu 10.04 and 10.10 system.
 
Quick installation summary:

• Does it work out of the box: No
• Does it work at all: Yes
• If you are able to update to Ubuntu 10.10, do it.

This post only describes how to get the basic functionality working (i.e. display/record a signal on the composite video input).
 
The HVR 1900 is a small box which is connected via a USB2 port (USB1 is not supported for bandwidth reasons). There are inputs for composite video (e.g. VCR or set-top box) an antenna input and a S-VHS input. The device comes with a UK power supply (with a UK mains plug) and a bulky mains plug adapter for continental Europe.
 
In order to get the digitizer running, this device needs firmware.  Ubuntu comes with a selection of firmware images for various Hauppauge systems, but none was suitable for this device.
 
The firmware is included on the Windows driver disk you get with the device, but which files do you need?  Fortunately there is a perl script available that scans the CD and extracts the files you need based on a bunch of MD5 sums stored in that script.  Perl is installed by default on a Ubuntu system, so slide in the CD, open a terminal and enter
 
perl fwextract.pl /media/XXXXXXXXXX
 
(where XXXXX is the CD title)
 
In my case the following files were found:

• v4l-cx2341x-enc.fw
• v4l-cx25840.fw
• v4l-pvrusb2-29xxx-01.fw
• v4l-pvrusb2-73xxx-01.fw

 
For the next steps you need root privileges:
 

• Change the ownership of those files to root (for security reasons)
  sudo chown root:root *fw 
• Copy the extracted files to /lib/firmware
  sudo cp *fw /lib/firmware
  

 If you're running Ubuntu 10.10, that's all you have to do.
 
Keep an eye on the system log when you now plug the digitizer into the USB port.
tail -f /var/log/syslog
 
Among other messages, it should confirm that the firmware was uploaded successfully.
 
...
cx25840 5-0044: firmware: requesting v4l-cx25840.fw
cx25840 5-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
...
 
Utilities for controlling the device from the command line can be found in the package ivtv-utils (from the Ubuntu repo).
 
v4l2-ctl --set-input 1
 switches to the composite video input
 
v4l2-ctl --set-ctrl=brightness=128,hue=0,contrast=68,volume=54000
 sets basic parameters for the digitizer.
 
Call v4l2-ctl without parameters for more help, and you will definitively want to try the switch -L
 
Recording is as simple as:
cp /dev/video0 video.mp2
 
This works most of the time.  Approx. 5% of the recordings contain a distorted audio stream. This distortion is present for the whole length of the recording and usually ends the next time the device /dev/video0 is opened. 
 
If the audio is ok at the beginning, it stays that way.  This looks like an initialization problem when the device is opened.  I haven't found a fix, yet.
 
Now to the more difficult part:

Getting the device to work under Ubuntu 10.04.
 
As mentioned before, many Hauppauge devices need firmware, which is uploaded to the unit when you plug it into the USB port.  Older hardware only needed 8192 bytes of firmware.  The firmware for this device however is 16382 bytes long (see the above firmware upload message from the log).  The device driver controlling the HVR-1900 (pvrusb2) that comes with kernel 2.6.32 and earlier is only capable of transferring 8192 bytes. And Ubuntu 4.10 LTS uses... 2.6.32.
 
Newer versions of the pvrusb2 driver can also upload the larger firmware.  For older kernels (like the one used in Ubuntu 4.10), you have to compile the updated driver yourself.
 
Compiling a kernel is usually a simple task, because the kernel source code already contains all dependencies. But this time, there were complications.
 
You need:

•  the kernel source
•  the tools to compile the kernel
  
•  and the source of the updated driver

The easiest way to get the Ubuntu Linux source is by installing a package named "linux-source". It will store the source code as an archive in /usr/src/linux-source-2.6.32.tar.bz2 
 
You have to unpack it - make sure that you have plenty of disk space available:
 
cd /usr/src
tar xvfj linux-source-2.6.32.tar.bz2
 
Then run the following commands
 
cd linux-source-2.6.32
make oldconfig
make prepare
 
This will "regenerate" the .config file used by your distribution's kernel.  This file is needed during the kernel compilation.
 
Now we have to download the source code of the current pvrusb2 driver which can be found here. Unpack it and copy the content of the directory driver to /usr/src/linux-source-2.6.32/drivers/media/video/pvrusb2/ overriding the current files with the same name.
 
(Please note: the pvrusb2 documentation is describing a different approach, that did not work for me (modprobe rejected the module))
 
The next step would be:
 
make modules
 
But due to a totally unrelated bug  the compilation will fail, while trying to compile the "omnibook" files.
 
Download the patch for this bug from here and apply it
 
cd /usr/src
patch -p0 _name_of_the_path_file_
 
Now it's time to compile the modules:
 
cd /usr/src/linux-source-2.6.32
make modules
 
This step is very time consuming. If you have a multi core processor use the -j# option (where # is the number of cores you have).
 
Copy the new module from
/usr/src/linux-source-2.6.32/drivers/media/video/pvrusb2/pvrusb2.ko
to
/lib/modules/`uname -r`/kernel/drivers/media/video/pvrusb2/pvrusb2.ko
 
(where `uname -r` (backticks!) will be replaced by the name of your current kernel)
 
Keep in mind that you have to repeat that process after each kernel update.
 
After the next reboot the new module should be active. If you can't wait, unload the old one and load the new module manually:
 
rmmod pvrusb2
modprobe pvrusb2
 
Again, check /var/log/syslog for any problems.
 
Links:

• http://www.isely.net/pvrusb2
• http://www.isely.net/pipermail/pvrusb2/
• https://help.ubuntu.com/community/Kernel/Compile
• http://www.isely.net/downloads/fwextract.pl

Touch Me, Tux - die Zweite

Im Zuge der in einigen Tagen beginnenden Fußball-WM 2010 verkaufte Aldi-Süd letzte Wochen den „TEVION® Tragbarer 11 cm/4,3'' Touch Multimediaplayer“ (MD 82700) mit eingebautem DVB-T-Empfänger. So können sich die Fußballfans per „Überall-Fernsehen“ auf dem Laufenden halten - wenigstens „überall“ dort, wo es empfangbar ist.

Im Lieferumfang befinden sich neben dem Netzteil, ein USB-Kabel, ein Ohrhörer und eine kleine DVB-T-Magnetfußantenne.

Daneben gibt der Player Videos, Musik und Fotos wieder. Und auch Text kann man sich anzeigen lassen; natürlich kein Vergleich zu Kindle und Co – weshalb das Feature wahrscheinlich nicht einmal beworben wurde.

Das Gerät meldet sich unter Linux als USB-Massenspeicher (MD 82700) an. Je nachdem, ob eine zusätzlich Micro-SD Karte eingelegt ist, erscheinen ein (intern: 4 GB) bzw. zwei USB-Laufwerke. Bilder und Video lassen sich auch mit gängigen Werkzeugen unter Linux so codieren, dass sie vom Player wiedergegeben werden.

Als Wiedergabeformate werden JPEG, MP3, MPEG4, RM, RMVB, Divx und Xvid beworben. Zu RM und RMVB kann ich nichts sagen, da ich unter Linux keine Encoder dafür laufen habe.

Die Angabe von MPEG4 ist zwar nicht falsch, aber vielleicht etwas missverständlich. MPEG4 ist ähnlich wie AVI ein Container-Format. Es sagt nichts über die darin verwendeten Codecs aus.

Um normale Dateien zu  komprimieren gibt unterschiedliche Algorithmen (ZIP, RAR, LZH, usw.). Ein sehr bekannt Algorithmus für Audio ist MP3, aber er ist halt nicht der einzige. Im Open-Souce-Bereich ist auch Ogg Vorbis verbreitet, Mac-User kennen AAC usw. Und auch bei den Videocodecs sind mittlerweile nicht nur Eingeweihten mehrere Codecs bekannt: DivX (und sein Open-Source-Pendant Xvid) sowie MPEG2 von den DVDs.

Häufig genutzte Quellen für MP4-Dateien sind heutzutage Video-Portale wie Youtube und Vimeo. Die dort erhältlichen Videos werden mit dem sehr effektiven Codec H.264 für Video und häufig mit AAC für Audio komprimiert. Diese beiden Codecs versteht das Gerät allerdings nicht. Solche Dateien können nicht direkt wiedergegeben werden und müssen auf dem Computer umcodiert werden.

Wenn man einmal vom DVB-T absieht, so erinnert der Player sehr an das Technaxx-Gerät, mit dem dieses Blog vor über einem Jahr begann. Die verfügbaren Formate, Aufbau und Inhalt der Menüs, exotische Funktionen wie Liedtext-Wiedergabe mit .lirc-Dateien, ähneln sehr der Software im Technaxx-Player. Selbst der vor einem Jahr genannte Konvertier-Befehl kann so (und in leicht abgewandelter Form) verwendet werden.

Von der Auflösung her unterscheiden sich der Technaxx- (320 x 240) und der Medion-Player (480 x 272) nicht sonderlich. Die höhere Pixelzahl ist fast ausschließlich dem Wechsel vom 4:3- zum 16:9-Format zu verdanken; aber natürlich ist der Bildschirm jetzt deutlich größer.

Der Wiedergabe-Chip ist leistungsstärker geworden, so dass viele Einschränkungen weggefallen sind: Es werden höhere Bildfrequenzen (Technaxx: max. 20 Bilder pro Sekunde) und höhere Bitraten für Video und Audio wiedergegeben. Auch B-Frames werden nun unterstützt, die eine höhere Komprimierung erlauben.

Die alten für den Technaxx kodierten Dateien lassen sich daher weiter abspielen. Und da diverse Einschränkungen wegfallen, lassen sich mit Avidemux erstellte Dateien nun direkt verwenden.

Erfolgreich getestete Formate:

Container-Formate: AVI, MP4
Videocodecs: DivX, Xvid
Audiocodecs: MP2, MP3, AC3
Videofrequenz (Bilder/Sekunde): 20, 25
Bildformate: JPEG, BMP

Hier ein Konvertierbefehl im Bausatz

Dateinamen, Ausgabeformat: AVI
mencoder -noodml QUELLDATEI -of avi -o ZIELDATEI

Videocodec XVID, Bitrate
-ovc xvid -xvidencopts bitrate=VIDEOBITRATE:quant_type=h263:me_quality=6
VIDEOBITRATE: je nach Qualität, typische Werte 800 bis 1000

Audiocodec
-oac AUDIOCODEC
AUDIOCODEC: mp3lame, mp2, ac3

Beispiel:
mencoder -noodml ein.mp4 -of avi -o aus.avi -ovc xvid -xvidencopts bitrate=1000:quant_type=h263:me_quality=6 -oac mp3lame

Eigene Videos auf das Cybershot

Das Handy Sony Ericsson Cybershot C902 ist keine eierlegende Wollmilchsau (auch Eier legende Wollmilchsau) wie das iPhone - sondern eher zum Telefonieren gedacht.

Nun gut - ein paar Multimedia- und Organizer-Funktionen hat es dann doch, sowie einen 5 Megapixel-Fotosensor, und es kann Videos aufnehmen und wiedergeben.

Die Handhabung ist ... naja - aber hier geht es ja um...

Die Zusammenarbeit mit Linux

Die Kamera wird unter Linux über das mitgelieferte USB-Kabel als Standard-Massenspeicher erkannt und wie ein normaler USB-Stick behandelt, was den Datentransport sehr beschleunigt. Und seitdem unter Ubuntu Jaunty die Bluetooth-Treiber wieder funktionieren, klappt der Datenaustausch auch drahtlos.

Als Videoformate können 3GP- und MP4-Dateien wiedergegeben werden. Das Display hat 320 x 240 Pixel. Was die Bildgröße der Videos angeht, so skaliert und dreht das Handy (es hat einen Lagesensor) den wiedergegeben Clip, wenn dieser größer oder kleiner als das Display ist.

Erstellen einer MP4-Datei über die Kommandozeile

Ein auf verschiedenen Seiten empfohlener Workflow ist - das Codieren mit mencoder:

mencoder input_file \
-vf scale=320:240 \
-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=300 \
-ofps 25 \
-oac faac -faacopts br=64:object=2 -channels 2 -srate 44100 \
-o output.avi

Dieser Aufruf skaliert das Video auf 320x240 Pixel, codiert es als mpeg4 mit einer Bitrate von 300 kbps und 25 Bildern pro Sekunde. Das Audio wird mit AAC codiert (hierzu muss ggf. das Paket libfaac0 nachinstalliert werden). Audioeinstellungen: Bitrate 64 kbps, Stereo (2 Kanäle) und eine Samplerate von 44100 Hz.

Weil mencoder angeblich kein normgerechtes MP4 erzeugen kann, wird das Ergebnis zunächst als AVI gespeichert, und im nächsten Schritt mit mplayer wieder in eine Video- und eine Audio-Datei getrennt:

mplayer output.avi -dumpvideo -dumpfile temp.mp4v
mplayer output.avi -dumpaudio -dumpfile temp.aac

Diese werden dann mit dem Programm mp4creator (aus dem Paket mpeg4ip-server) wieder zusammengefügt - diesmal normgerecht:

rm output.mp4
mp4creator -r 25 -c temp.mp4v output.mp4
mp4creator -c temp.aac output.mp4
mp4creator -optimize output.mp4

Das Ergebnis ist dann eine MP4-Datei, die vom C902 wiedergegeben werden kann. Die Bildrate (in diesem Beispiel 25 fps) muss hier explizit angegeben werden.

Man kann mit den Werten ein wenig spielen und z.B. die Audio-Abtastrate an das Quellmaterial anpassen. 300 kbps für Video und 64 kbps für Audio liefern für die Wiedergabe auf dem Handy brauchbare Ergebnisse.

Erstellen der MP4-Datei mit Avidemux

Avidemux ist ein Videokonvertier-Programm mit einigen rudimentären Schnittmöglichkeiten und diversen Bearbeitungsoptionen. Es lässt sich meist über das Repository der jeweiligen Distribution nachinstallieren.

Im Programm selber nimmt man dann - in Anlehnung an die von mencoder verwendeten Werte - folgende Grundeinstellungen vor:

Video: MPEG-4 ASP
Audio: AAC (FAAC)
Format: MP4












Video - Konfigurieren


Benutzerschnittstelle
Kodier-Modus:
Einfacher/zweifacher Durchlauf mit (Durchschnitts-)Bitrate

Bitrate (kb/s): 300






Audio - Konfigurieren

Konfigurieren:
Bitrate: 64 kb/s






Nun können auch die restlichen Filter und Bearbeitungsfunktonen zum Einsatz kommen. z.B. das Zuschneiden des Clips, Änderungen in der Bildgröße, De-Inferlace-Funktionen, Anlegen neuer Tonspuren, um nur einige zu nennen.

Das Ergebnis ist nach einem "Datei - Speicher - Video speichern" direkt auf dem C902 einsetzbar.

Und sollte die Wiedergabe des Videos das Handy einmal zum Absturz bringen - die Batterie lässt sich ja einfach aus- und wieder einbauen.

Touch Me, Tux

Das Technaxx TOUCHME ist ein portabler Multimedia-Player mit einem 2,8“ Farb-Touchscreen. Es kann Audio (MP3, WMA), Video (MPEG4 AVI) und Bilder (JPG, BMP) wiedergeben.

Es hat eine USB 2.0-Schnittstelle und ist mit einer MicroSD-Karte erweiterbar.

Der Hauptbildschirm ist dem Handy einer bekannten amerikanischen Firma nachempfunden. Die Icons sind jedoch statisch und auch sonst kommt die Benutzerführung nicht an das Vorbild heran.

Mit Linux lässt sich das Gerät aber hervorragend betreiben.

Es meldet sich als normaler USB-Massenspeicher an, und man kann die Dateien in der gewohnten Art und Weise kopieren und löschen. Kein DRM, nur Formate, die man unter Linux auch erstellen kann.

Das mitgelieferte “Konvertierungs-Tool“ ist natürlich ein Windows-Programm. Ein Blick mit dem Hex-Editor auf die damit erzeugten Dateien zeigt, dass diese mit mencoder erstellt wurden, ein unter Linux weit verbreiteter Open-Source-Videokonverter.

Das Windows-Konvertierungs-Tool ist also nichts anderes als eine GUI für mencoder.

Schnell ein kleines Windowsprogramm geschrieben, dessen Aufgabe es war, die Aufrufparameter anzeigen, und dem Konvertierungs-Tool anstatt mencoder untergeschoben, schon standen die Parameter fest:

mencoder -noodml INPUTFILE -of avi -o OUTPUTFILE -ofps 20 -vf-add scale=SCALEX:SCALEY -vf-add expand=320:240:-1:-1:1 -srate 44100 -ovc xvid -xvidencopts bitrate=VIDEOBITRATE:max_bframes=0:quant_type=h263:me_quality=4 -oac lavc -lavcopts acodec=mp2:abitrate=AUDIOBITRATE

Je nach gewünschter Qualität für VIDEOBITRATE die Werte 450, 500 oder 600 und für AUDIOBITRATE die Werte 64 oder 128 einsetzen.

SCALEX und SCALEY sind die Höhe und Breite in Pixel, auf die das Video herunter gerechnet werden muss, um unverzerrt angezeigt zu werden. Bei 4:3-Material sind das 320:240, bei 16:9 muss hier 320:180 eingesetzt werden („expand“ fügt dann die schwarzen Ränder hinzu).

Die erzeugte Datei muss einen Stereo-Track enthalten. Andernfalls kommt es bei der Wiedergabe zu seltsamen Effekten.

Ich kodiere jetzt schon seit längerer Zeit mit diesen Parametern erfolgreich kleine Clips z.B. von YouTube für den Player. Längere Videos sind zwar auch möglich, die prellenden Vor- und Rückspultasten (On-Screen) machen die Wiedergabe aber zur Geduldsprobe.

Podcasts kann man mit dem Player natürlich auch wiedergeben. Der Player merkt sich beim Ausschalten aber leider nicht, an welcher Stelle man war. Für Songs also geeignet, für längere Audiodateien leider nicht.

Bilder sollte man vorher skalieren. Der Player kann das zwar auch, nimmt sich aber Zeit dafür.

Ich habe diesen Player vor über einem Jahr bei einer Supermarktkette erworben. Wenn Geräte bereits dort verkauft werden, zerschlagen sich jegliche Hoffnung auf Updates – Schade.