Month: Juni 2010

Ich hatte es ja heute morgen schon vom Androiden aus angeteasert: ich bei den entscheidenden Schritt weiter beim Aufbau einer »VDR-Server-Farm«, die beiden designierten »Pizzaschachteln« sind in den Keller gewandert, am Netgear GS-108T dort (auch wenn die Boxen nur 100 MBit/sec-Schnittstellen haben) als auch am DVB-S-Verteiler angeschlossen und laufen.
Mit den beiden Kistchen kommen 4 DVB-Eingänge zum »VDR-Gesamtsystem« hinzu, derzeit sind das 2x DVB-S, 1x DVB-S2 (HDTV-tauglich) sowie 1x DVB-T. Das zu ersetzende Wohnzimmer-VDR-System mit 2x DVB-S läuft derzeit noch weiter, das neue, HD-taugliche, Wohnzimmer-System hat derzeit 2x DVB-S (davon eine in Benutzung, da im Arbeitszimmer nur 1x SAT-Anschluß vorhanden ist), wobei noch nicht klar ist, ob es bei beiden Karten bleibt oder ggf. auch diese durch eine Single- oder Dual-Tuner-PCIe-Karte ersetzt werden oder auf eine reduziert.
OS-Basis ist jeweils Ubuntu 9.10, im Falle des HDTV-VDRs in Form von yaVDR — allerdings noch in der Version 0.1.1. Die beiden »headless VDRs« benutzen konsequenterweise die Pakete aus dem yaVDR-Repository.
Sinn der Übung: der VDR im Wohnzimmer, mit gut 100 Watt Energieaufnahme kein sparsamer Geselle (AMD Athlon(tm) 7750 Dual-Core Processor auf einem Asus V-M3N8200 mit nVidia-onboard-Grafik), soll, aus Energie- und Lärmgründen, möglichst nur dann eingeschaltet sein, wenn auch fern gesehen wird — anders als der bisherige, einzige, VDR-Server. Um dennoch Aufnahmen anfertigen zu können, sollen Systeme mit geringer Energieaufnahme (so ein Scenic Xs zieht rund 20 Watt, Platte eingeschlossen) im Keller diese Tätigkeiten durchführen, und da ich ein Serienjunkie sein kann, halte ich 2 DVB-Karten schon für etwas knapp.
Was bislang schon funktioniert:

• Dank des Kopiertricks kann der HD-VDR auf mehr als eine per streamdev-Plugin über’s Netz bereitgestellte Quelle zugreifen. Allerdings muß man beim Update des streamdev-client-Pakets dran denken, auch die Kopie(n) erneut zu duplizieren …
• Dank Konfigurationsänderungen kann der HD-VDR auch das IPTV von T-Entertain empfangen — die nicht grund(los)verschlüsselten Programm des öffentlich-rechtlichen Rundfunks zumindest. Komischerweise bringen weder der P3 800 noch der Celeron mit 1,2 GHz in den Scenics auch die eine störungsfreie Bereitstellung des (SD-) Signals zu Stande; selbst ohne streamdev-Overhead bei lokaler Aufzeichnung gibt es Dropouts und Artefakte — und lokale Aufzeichnung sollte ja eigentlich relativ simpel sein, hat man erst mal den h.264-Stream aus dem DVB-IP extrahiert, oder?
• Selbst der Zugriff auf eine DVB-S2-Quelle per streamdev scheint zu funktionieren — sofern ich das richtig erkenne, denn streamdev-Geräte sind zwar, wie auch das IPTV-Plugin, für VDR Datenquellen, aber das femon-Plugin, welches die Signalstärke ausgibt und insbesondere die direkte Auswahl eines Eingabegerätes ermöglicht, kann damit leider nichts anfangen. Weitere Voraussetzung: der streamdev-Client muß auf einen streamdev-Server treffen, der auch zu einer DVB-S2-Karte verbinden. Da beide Keller-VDRs hybride Systeme sind (DVB-S & DVB-S2 bzw. DVB-S & DVB-T) ist das … nicht so einfach.

Und damit bin ich auch schon bei meiner »Hall of Shame«, den Problemen, angekommen:

• Augenscheinlich transportiert streamdev keine Informationen über die Geräte, weder meldet streamdev-server an den -client, wlecher Art die bereitgestellte Datenquelle ist, noch kann der streamdev-client hier augenscheinlich etwas anfordern. Dies ist auch erst einmal sinnvoll, denn IIRC arbeitet streamdev-server dynamisch, er stellt die Verbindung zu einem freien Device her, sodaß ein VDR mit 2 Karten z. B. eine lokale Aufnahme tätigen kann und die zweite per streamdev einem anderen VDR (oder einem vlc, mplayer, …) bereitstellen).
  Allerdings kann dann durchaus eine DVB-S-Karte per streamdev Tuning-Informationen auf DVB-T bekommen — was natürlich nicht funktioniert; auch verschlüsselte Kanäle sind hier weniger vorteilhaft :(

  Jun 8 21:26:36 hdtvdr vdr: [16125] ERROR: Streamdev: Couldn't tune 192.168.2.62:2004 to channel S4C

  Wie gut sich die Nutzung von streamdev-Geräten in der Praxis erweisen wird, wage ich noch nicht zu schätzen. Wahrscheinlich werde ich aber eher die DVB-T-Karte in den HD-VDR bauen und dafür die 2. DVB-S2-Karte in die VDR-Box, die schon DVB-S2 hat …

• Ein verteiltes VDR-System ist konfiguratorisch augenscheinlich nicht vorgesehen. Das live-Plugin läut jeweils lokal auf dem VDR, per OSD programmierte Aufnahmen sind ebenfalls nur für den lokalen VDR vorgesehen. Abhilfe schaffen hier ein wenig die Plugins remotetimers und/oder remoteosd. Angenehm ist, da auch mein alter VDR schon die Erweiterung für remoteosd hatte, daß ich vom HD-VDR auch den alten VDR fernsteuern kann. Noch nicht probiert habe ich, ob bzw. wie man auch remoteosd mehrfach installieren kann (ich habe ja einen »bedienten« VDR und 2 (oder mehr) VDRs, die »headless« arbeiten.
• Zum Filesystem bzw. der sinnvollen Verteilung/Verlinkung muß ich mir auch noch Gedanken machen; vom HD-VDR sollen ja im Wohnzimmer alle Aufnahmen abspielbar sein; also werde ich wohl die Filesysteme der beiden »VDR-Server« im Keller in das des HD-VDRs »einmontieren« müssen.

Wahrscheinlich bin ich mal wieder im »where no one seeked pain before«-Land mit meinem Ansinnen ;) Nichtsdestotrotz finde ich es wahnsinnig Klasse, was schon alles mit VDR out-of-the-box machbar ist. Mal gucken, wo das noch endet ;)

Narf. Zitat:

On Wed, Dec 3, 2008 at 3:12 PM, sean darcy <seandarcy2 at gmail.com> wrote:

I’m using ffmpeg to repackage vob files to play on a ps3 ( for some reason the ps3 doesn’t like some vob’s, but always likes ffmpeg’s )
I often get the message that the codec frame rate differs from the container frame rate. How does a “container” have a frame rate? Is this a interlacing issue?
ffmpeg even with vcodec copy changes the frame rate of the video stream to 29.97 from 59.94. Should I force ( -r 59.94) the original frame rate, or does ffmpeg know what it’s doing?

 
The video container specifies a framerate, as does the video stream itself. In some cases, usually caused by badly written encoding programs, the two can disagree. When this happens, ffmpeg is obviously forced to believe one and not the other.
If ffmpeg picks the wrong one, you can, ask you mentioned, force the other framerate if you believe it to be correct.
Dark Shikari

 
Nunja. Ein ffmpeg-kodiertes File erzeugt bei mir:

Seems stream 0 codec frame rate differs from container frame rate: 30000.00 (30000/1) -> 29.97 (30000/1001)

Und während es super in mplayer abgespielt wird, ist das Ergebnis der Nutzung in OpenShot eine reine Katastrophe. Keine Ahnung, welche fps OpenShot sich da ausdenkt, sie ist nur eines: total falsch. Und Drecks-ffmpeg ist nicht in der Lage, ein korrektes File zu erzeugen, obige Meldung wird erzeuigt nach:

ffmpeg -i 25fps-source.mp4 -r 30000/1001 -sameq -vsync -1 -acodec libmp3lame -ac 2 -ar 44100 -ab 192k -threads 2 -y -copyts 29.97fps-target.mov

Videobearbeitung unter Linux: Foltermethoden des 21. Jahrhunderts.
Fsck³ :(