Tag: SPHPBLOG

Nachdem ich mehrere Anläufe unternommen habe, einen VDR mit DVB-S2-Support und Full-HD-Ausgabe per VDPAU auf Ubuntu-Basis zurechtzustöpseln – und ein ums andere Mal in einer Dependency-Hell mich wiederfand – habe ich nun der jüngst veröffentlichten Version 0.1.1 von yaVDR eine Chance gegeben — und bin auch nach einem Tag noch sehr angetan!
Das, was yaVDR aus der Masse hervorhebt, ist die konsequente Ausrichtung auf einen Zweck: einen Linux-PC mit nVidia-Grafik zur Medienzentrale machen; dafür wird nicht nur ein aktueller (experimenteller) VDR mit (experimentellen) DVB-S2-Treibern in einem per CD oder USB-Stick installierbaren Ubuntu-basierten Image zusammengepackt, nein, auch der (experimentelle) PVR-Zweig von XMBC findet sich hier wieder, mehr noch: per Webinterface kann man zwischen xine, vdr-sxfe und(!) XMBC als VDR-Frontend wählen. Wer XBMC kennt, weiß, daß spätestens letzteres Eye-Candy vom Feinsten verspricht; aber auch das (Full-)HD-OSD der mitgelieferten VDR-Version ist schon sehr nett anzuschauen, kein Vergleich mehr mit dem begrenzten OSD der Full-Featured-Karten (wie sie auch noch mein Wohnzimmer-VDR zeigt):

Auch nett ist, daß man aus dem VDR-OSD heraus zu Firefox, XBMC und ‘nem Terminal wechseln kann. Beenden von XBMC und Firefox startet dann wieder (bei mir) vdr-sxfe als VDR-Frontend; der VDR-Prozeß an sich läuft, wie es sich gehört, in all der Zeit weiter – schließlich soll er ja auch ggf. was aufnehmen. Einziges Manko dieser Lösung – mit OpenBox als leichtgewichtigem Fenstermanager – bei mir: weder bei xterm noch in Firefox ist ein größerer Font wählbar — und die Standardgröße ist schon bei den ca. 1,5 Meter von der Tastatur bis zum 22″-Full-HD-Display an der unteren Lesbarkeitsgrenze, später im Wohnzimmer am 47″-Full-HD-TV werde ich gut 3 Meter vom Display entfernt sitzen, auch da wird’s zu klein sein … Ich habe schon alles erdenklichen Fonts installiert, vermutlich fehlt aber entweder ein Fontserver oder aber OpenBox schlicht die Unterstützung verschiedener Fonts :( Aber vielleicht fixen die Entwickler das ja noch, Version 0.1.1 ist ja auch mehr Beta als was anderes ;)
Ich werde mich jetzt ein bißchen einarbeiten und insbesondere noch eine lirc-Fernbedienungsmöglichkeit eruieren (lirc_ttusbir, ein Modul für ein USB-Dongle von Technotrend mit einem IR-Receiver, bricht auf dieser Hardware leider nachhaltig ins Essen; während es auf einem Medion-Laptop mit Intels Pentium Dual-Core 1a rennt (Ubuntu 9.10), gibt’s auf dem Asus-Board mit dem Athlon(tm) 7750 Dual-Core nur USB-Fehler und einen kernel-Hänger beim Versuch, das Modul wieder zu entladen :(). Bei Bedarf liefere ich auch gerne noch bißchen »Footage« von XBMC-PVR als VDR-Frontend; das macht beim ersten Blick jedenfalls einen super Eindruck, VDR ist soweit integriert, daß man auch Aufnahmen aus der XBMC-Oberfläche heraus starten kann.

(Bitte erst bis zum Ende lesen, bevor irgend etwas aus diesem Artikel ausprobiert wird!)
Basierend auf Alexander Hollers Anleitung, aus einem Seagate DockStar eine kleine Version des SheevaPlugs zu machen, dokumentiere ich hier meine Schritte, um meinen DockStar meinen beiden SheevaPlugs (sowie dem NSLU2) möglichst ähnlich zu machen, d. h. Ubuntu-/Debian-basiertes full-blown System, welches hier dann von einem USB-Stick startet (meine Sheevas starten vom NAND-Flash mit UBIFS, /var & Co. liegen ggf. auf einer externen USB-Platte; der NSLU2 startet von einer 1-TB Platte), …
Da Alexander Gentoo präferiert, ich aber keinen neuen Bastelschauplatz aufmachen möchte, habe ich aus dem SheevaPlug Installer das rootfs.tar.gz auf eine ext3-Partition (/dev/sdX2; die erste Partition muß wg. U-Boot VFAT oder ext2 sein (enthält nachher das Kernelimage), was man beides für / nicht möchte) eines 1-GB-USB-Sticks kopiert:

root@greebo:~# fdisk /dev/sdc
root@greebo:~# mke2fs -L /boot -m 2 /dev/sdc1
[...]
root@greebo:~# mke2fs -j -L /dockstar -m 2 /dev/sdc2
[...]
root@greebo:~# mkswap /dev/sdc3
[...]
root@greebo:~# mkdir /mnt2
root@greebo:~# mount /dev/sdc2 /mnt2
root@greebo:~# mkdir /mnt2/boot
root@greebo:~# mount /dev/sdc1 /mnt2/boot
root@greebo:~# cd /mnt2
root@greebo:~# tar --same-owner --numeric-owner -p -zxvf /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/rootfs.tar.gz
[...]
var/local/
root@greebo:/mnt2# tar --same-owner --numeric-owner -p -zxvf /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/modules.tar.gz
[...]
./lib/modules/2.6.30.2/source
root@greebo:/mnt2# cp -p /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/uImage boot/
root@greebo:/mnt2# ls -la boot/
total 5832
drwxr-xr-x 2 root root 4096 2010-03-07 18:44 .
drwxr-xr-x 21 root root 4096 2009-07-23 04:01 ..
-rw-r--r-- 1 wusel wusel 2620504 2009-07-23 04:11 uImage
root@greebo:/mnt2# chown -R root:root boot/
root@greebo:/mnt2# ls -la boot/
total 5832
drwxr-xr-x 2 root root 4096 2010-03-07 18:44 .
drwxr-xr-x 21 root root 4096 2009-07-23 04:01 ..
-rw-r--r-- 1 root root 2620504 2009-07-23 04:11 uImage
root@greebo:/mnt2# cd
root@greebo:~# umount /mnt2

Nett gedacht, aber zu kurz gesprungen; im Mailwechsel machte mich Alex’ auf Hardwareunterschiede zw. SheevaPlug & DockStar aufmerksam, sodaß eine simple Übernahme des Kernels leider ausscheidet. Also sind die weiteren Ausführungen Alex’ zu befolgen, als da wären:

• Installation of the kernel (Linux)
  Wobei ich hier auf den SheevaPlug-Kernel setze; ich habe also meinen Kernel-Source auf dem Desktop geklont (neben linux-2.6.32.2-SheevaPlug habe ich nun auch ein Verzeichnis linux-2.6.32.2-DockStar). Danach wurden Alex’ Patches runtergeladen (in ein neues Unterverzeichnis DockStar-Patches) und per Hand applied: [EDIT: Auch wenn im Folgenden der 0001-Patch nicht gelistet ist, ist jener wichtig für das weitere Vorgehen im Verlauf dieser Artikelserie. Sorry, hatte ich augenscheinlich zu kopieren vergessen.]

  wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0002-MTD-partitons-used-by-the-Seagate-FreeAgent-DockStar.patch
  patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
  wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0003-LED-definitions-for-the-Seagate-FreeAgent-DockStar.patch
  patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
  wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0004-Change-board-name-for-the-SheevaPlug-to-reflect-the-.patch
  patching file arch/arm/mach-kirkwood/Kconfig
  Hunk #1 succeeded at 27 with fuzz 1.
  patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
  wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ ls DockStar-Patches
  0001-ARM-Add-option-CMDLINE_FORCE-to-force-usage-of-the-i.patch
  0002-MTD-partitons-used-by-the-Seagate-FreeAgent-DockStar.patch
  0003-LED-definitions-for-the-Seagate-FreeAgent-DockStar.patch
  0004-Change-board-name-for-the-SheevaPlug-to-reflect-the-.patch
  linux-2.6.33_patches_dockstar.tar

• Installation of the boot loader (Das U-Boot) sowie Patches for the boot loader (Das U-Boot)
  Hier habe ich die Werte wie von Alex beschrieben geändert, auch wenn ich bislang netconsole nicht genutzt habe. Ich habe U-Boot auf einem meiner SheevaPlugs kompiliert (anders als Alex in seinem Beispiel), dabei fiel auf, daß das Skript »./mkDockStar.sh« hier stolpert; gibt es eine Fehlermeldung wie folgt, den Aufruf in der ersten Zeile des Skriptes von /bin/sh auf /bin/bash ändern:

  Image Type: Kirkwood Boot from NAND Flash Image
  Data Size: 185616 Bytes = 181.27 kB = 0.18 MB
  Load Address: 00c00000
  Entry Point: 00c00000
  Building u-boot.bin.pagesize
  [: 19: Illegal number: $[262144-185616]

Da ich keine Lust hatte, die Box aufzumachen und die serielle Schnittstelle zu bemühen, habe ich das »blparam«-Kommando der PogoPlug-/DeskStar-Installation bemüht¹:

 98 PATH=$PATH:/usr/local/cloudengines/bin/
99 blparam
100 blparam "oldbootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000"
101 blparam 'oldbootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
102 blparam "bootargs_usb_root=root=/dev/sda2 rw rootdelay=5 rootfstype=ext3"
103 blparam "bootload_kernel=ext2load usb 0:1 0x800000 /uImage"
104 blparam 'bootcmd_usb=usb start'
105 blparam 'newbootcmd=${bootcmd_usb}; ${bootload_kernel}; setenv bootargs ${bootargs_usb_root}; bootm 0x800000'
106 blparam "bootcmd_MLL_yes=setenv mainlineLinux yes; saveenv"
107 blparam "bootcmd_MLL_no=setenv mainlineLinux no; saveenv"
108 blparam "arcNumber=2097"
109 blparam "bootcmd_pogo=run bootcmd_MLL_no; run oldbootcmd"
110 blparam "bootcmd_plugapps=run bootcmd_MLL_yes; run newbootcmd"
111 blparam 'newbootcmd=usb start; ext2load usb 0:1 0x800000 /uImage; setenv bootargs ${bootargs_usb_root}; bootm 0x800000'
112 blparam 'bootcmd=run bootcmd_plugapps'

Leider funktionierte dies nicht, das Schätzchen bootete nicht mehr :( Nun muß also doch der Pegelwandler her und über die serielle Schnittstelle debugged werden …
Wiederbelebung – hoffentlich ;) – in Teil II.
(Redaktioneller Hinweis: Da meine Blogsoftware nicht vorsieht, Artikel zu schreiben und später zu veröffentlichen, trickse ich i. d. R. durch eine Velagerung in die Zukunft um diese Unzulänglichkeit herum; dieser Artikel sollte eigentlich auch die Lösung, also die Reanimierung meines DockStars, enthalten, nur kam ich zeitlich nicht dazu, diesen Teil in der Zeit, die ich den Artikel vorverlegt hatte, auch zu realisieren. Dadurch wurde der Artikel offensichtlich schon von anderen gelesen, und nach der zweiten Bitte auf (Wieder-) Veröffentlichung ist er hier nun also, als Teil I von (geplant) Zweien. Have fun, but: DON’T TRY THIS AT HOME, YOU’LL DEFINITIVELY BRICK YOUR DOCKSTAR AND IT’S UNCERTAIN IF IT’S UNBRICKABLE!)
___

#!/bin/bash
# This script updates the pogoplug uboot enviroment in preparation for running
# plugapps on the pogoplug v1, pogoplug v2 and dockstar.
# This script adds environment variables to make usb booting possible
# This script assumes that it is being run on a pogoplug that has
# firmware at least at rev 2.0.1 with the blparam executable.
# Preparation
mount -o rw,remount /
# Add boot commands
cd /usr/local/cloudengines/bin
./blparam "arcNumber=2097"
./blparam "bootcmd_mtd1_usb=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bootargs_usb_root) $(bootargs_mtdparts); bootm 0x800000"
./blparam "bootcmd_pogo=run bootcmd_MLL_no; run bootcmd_mtd1_mtd2"
./blparam "bootcmd_MLL_yes=setenv mainlineLinux yes; saveenv"
./blparam "bootcmd_MLL_no=setenv mainlineLinux no; saveenv"
./blparam "bootargs_mtd2_root=root=/dev/mtdblock2 ro"
./blparam "bootcmd_mtd3_usb=nand read.e 00x800000 0x02500000 0x200000; setenv bootargs $(console) $(bootargs_usb_root) ; bootm 0x800000"
./blparam "bootcmd_mtd1_mtd2=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bootargs_mtd2_root); bootm 0x800000"
./blparam "bootargs=console=ttyS0,115200 root=/dev/mtdblock2 ro"
./blparam "bootargs_usb_root=root=/dev/sda1 rw rootdelay=10 rootfstype=ext2"
./blparam "bcktopogo=setenv bootcmd run bootcmd_pogo; saveenv"
./blparam "bootcmd_plugapps=run bootcmd_MLL_yes; run bootcmd_mtd3_usb"
./blparam "bootcmd=run bootcmd_pogo"
# Replace rcS
cd /etc/init.d
mv rcS rcS.backup
wget http://plugapps.com/os/pogoplug/full/rcS
chmod 755 rcS
# Write new kernel (2.6.32.7) to the free partition
cd /tmp
wget http://sheeva.with-linux.com/sheeva/2.6.32.7/sheeva-2.6.32.7-uImage
# Now, how do we write it?
# Download and extract Plugbox-1.0.tar.gz to USB drive
touch /tmp/.cemnt/mnt_sda1/plugapps

Nachdem ich dankenswerterweise @_refugee_ beim Zusammenschneiden des B-Day-Videos für @ifranz über Tastatur und Maus schauen durfte, weiß ich nun, wie weit OpenShot wirklich noch entfernt ist von auch nur ansatzweisem professionellem Videoschnitt … *seufz*
Aber es sind gar nicht die Goodies, die fehlen, wie die Einsetzung eines externen Objektes basierend auf der Bewegung des darunterliegenden Motivs (s. El Burros schwarzer Balken im B-Day-Video). Mit meinen Quelldateien scheitert OpenShot leider schon an den Basics; das folgende Video zeigt leider zu deutlich, was ich meine:

Die Videodatei wurde erstellt mit meiner Kodak Zi8 (leider habe ich erst beim Schnitt feststellen könne, daß es nicht ganz scharf ist). Für diverse Effekte mußte ich natürlich Schnitte setzen, leider kotzen ffmpeg als Backend bzw. OpenShot als Editing Suite ins Essen dabei: (fast) jeder Schnitt beginnt mit einem weißen Frame, im Video als helles Aufblitzen zu sehen. Das will man natürlich nicht; gut, ich bin nicht auf den Kopf gefallen und nachdem »die Großen« ja auch munter nach »Apple Intermediate« (MJPEG?) wandeln, habe auch ich das Quellvideo vom h264-aac-.MOV in ein mjpeg-mp3-.AVI gewandelt. Alles noch mal auf Start und neuen Schnitt probiert — aber halt, was ist das? Das Video läuft nicht mit, nur die Tonspur wird abgespielt, Video hingegen eher gar nicht denn überhaupt außer direkt vom Start auch nur halbwegs tonsynchron abgespielt :( Videoschnitt ohne zu sehen, bei welchem Bild man tatsächlich ist, ist zu optimistisch für mein Alter :(
Ähnliche Probleme habe ich mit den MTS-Files (AVCHD lite) meiner Panasonic TZ7 gehabt — und schlimmere: teilweise – ich weiß nicht, ob das an dem Mixing von 29,97 fps-Clips (Zi8) und 25 fps-Schnipseln (TZ7) lag –, liefen Ton und Bild bei den MTS-Dateien auseinander :(
Ich weiß nicht, ob meine Probleme an den HD-Dateien liegen; in Screencasts finde ich in der Regel nur Beispiele von toll laufendem OpenShots mit SD-Dateien … Aber auch in dem Bereich ist nicht alles Gold, was glänzt :( Denn als ich heute eine Doctor-Who-Folge archivieren wollte (Mitschnitt von BBC HD per VDR dank meiner Schüssel auf Astra 28 Grad Ost im Garten), sperrte sich OpenShot auch gleich mehrfach:

• Die orginale Datei in OpenShot zu bearbeiten war unmöglich, mit …
  Input #0, mpeg, from '../Doctor_Who_S05E01/all.vdr':
Duration: 01:15:00.44, start: 30259.218122, bitrate: 10174 kb/s
Stream #0.0[0x1e0]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 256 kb/s
Stream #0.2[0x80]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s
Stream #0.3[0x20]: Subtitle: dvdsub
  … mochte OpenShot nicht arbeiten bzw. ich nicht, denn ich benötige die Tonspur 0.2; 0.1 enthält Ton + Bildbeschreibung für Blinde, das möchte man als Sehender nicht als primäre Tonspur. Leider bietet OpenShot keine Möglichkeit, eine Tonspur zu selektieren. (HINT!)
  (Das 1440×1080 ein recht eigenwilliges Format ist – ich kannte bei HDTV bislang nur 1280x720p50 und 1920x1080i50 –, seit mal dahingestellt.)
• Die mittels …
  ffmpeg -i ../Doctor_Who_S05E01/all.vdr -ab 128k -ar 44100 -vcodec libx264 -acodec libmp3lame -aspect 16:9 -s 720x406 -b 2500k -map 0:0 -map 0:2 -y Doctor_Who_S05E01-SD.avi
  … erstellte SD-Datei (an HD rechnet der eine benutzte Kern des Quadcores noch immer …) wollte ich dann in OpenShot kürzen (6,5 Minunten am Anfang raus, 5 Minuten am Ende) — aber beim Schnitt begann OpenShot mit dem Video immer von 00:00:00, nur der Ton wurde entsprechend der Schnitte positioniert.

Letzteres war – leider – denn auch konsequent dem WYSIWYG-Prinzip folgend das, was OpenShot kodierte:

Ich weiß leider nicht, an welcher Stelle da was versagt; ich habe mal ganz stark ffmepg im Verdacht, aber habe mich zu wenig um OpenShot-Interna gekümmert für auch nur einen educated guess; Fakt ist, daß Videoschnitt mit OpenShot ein Abenteuer bleibt :( Es mag mit vielen Ausgangsdateien schon super laufen — mit so ziemlich nichts, was ich OpenShot vorwarf, wurden OpenShot oder ich glücklich :(