Wie bekomme ich ein lauffähiges System für xineliboutput mit vdpau?

  • Hi zusammen,


    da hier immer wieder Neueinsteiger und auch Umsteiger von FF-Systemen die gleichen Probleme/Fragen/Meinungen schildern,
    versuche ich mal mit meinen Erfahrungen den Weg/Möglichkeiten/Fallstricke zu einem wohnzimmertauglichen System zu beschreiben.
    Hier liegt der Hauptblickpunkt auf dem Zusammenspiel aus passender Hardware und der passenden Software.
    Ich möchte mit dem Thread keinen Glaubenskrieg zwischen Intel und AMD anzetteln.
    Zudem möchte ich auch nicht dass irgendwelche Diskussionen aufflammen, welche VDR-Version die Beste ist oder was man für eine xine-lib oder Plugin-Version man einsetzt.
    Der Thread soll eine „kleine“ Zusammenfassung meiner bisherigen Erfahrungen mit dem Thema sein.


    Was vdpau ist und für was man es gebrauchen kann, siehe hier:


    http://www.vdr-wiki.de/wiki/index.php/VDPAU


    1. Los geht’s in der Regel mit der Auswahl der passenden Hardware:


    1.1 Mainboard mit onboard-Grafikarte:


    1.1.1 Mainboardwauswahl:


    Bei der Auswahl des Mainboards trifft man schon eine wichtige Entscheidung => Intel oder AMD.
    Auf ION-Systeme gehe ich hier nicht ein, da diese System in meinen Augen noch zu viele Einschränkungen für einen vollwertigen VDR mitbringen,
    bzw. eben zu wenige PCI/PCI-Express-Steckplätze mitbringen oder auch keine LPT- oder seriellen Schnittstellen haben.


    Grundsätzlich ist es im Moment so, dass Intel-Mainboards im Gegensatz zu AMD-Mainboards unproblematischer in Verbindung mit VDPAU laufen.
    Hintergrund ist, dass die Intel-Mainboards beim Heruntertakten nur die CPU heruntertakten und nicht den Bustakt oder/und den Speichertakt.

    Die AMD-CPU’s der K8-Reihe (z.B. AMD-BE-Serie, Sempron 1640, usw.) haben die Eigenschaft beim Heruntertakten sowohl den Bustakt und den Speichertakt herunterzutakten.
    Somit gibt es jede Menge Framedrops => Bildverluste (Mikroruckler), teilweise schon bei SD-Content (= 720x576 interlaced). Bei HD-Content ( 1920x1080 interlaced) sieht man das dann noch ausgeprägter.
    Umgehen kann man das in dem man den CPU-Takt auf mindestens 2000 MHz hält. (Siehe AMD-Thread in den Referenzlinks.)


    Seit kurzem gibt es neue AMD-CPU’s der K10-Reihe, die haben auch bei gesenktem CPU-Takt die oben genannten Eigenschaften nicht.
    Beispiel sind der AMD Sempron 140 (Boxed, OPGA, "Sargas") oder auch der AMD Athlon II X2 240 (OPGA, "Regor").
    Das sind zwar beide AM3-CPU’s, aber auch in vielen AM2+-Boards sind diese CPU’s lauffähig.
    Der User gda hat eine solche Sempron-140 CPU im Einsatz und auch schon positives berichtet.


    Grundsätzlich haben die onboard-Lösungen alle auch das Problem, dass der mitgelieferte Chipsatz-Kühler passiv ist.
    Dadurch wird der Chipsatz, in dem auch die GPU (Grafikkarte) sitzt, sehr heiß, ca. 65 bis 75 Grad. ich empfehle jedem sich gleich nach einem leisen Lüfter umzusehen, der den Kühlkörper anbläst.
    Ab ca. 75 Grad kann es dann zu Bildstörungen/Ruckler/Grüne Punkte kommen, da die GPU automatisch den Powerlevel (Takt der GPU) heruntersetzt.



    1.1.2 Dual-Channelram:


    wichtig für den Speicherdurchsatz (auch der Grafikkarte) mindestens 2 Module a’1024 MB, um der Grafikkarte 512 MB zuweisen zu können per Bioseinstellung.
    Speichertakt der Module sollte mindestens 800 MHz haben ( = passende Busgeschwindigkeit)



    1.1.3. Mainboard-Chipsatzbezeichnungen:


    AMD => 8200 und 8300
    Intel => 9300 und 9400



    1.1.4 Referenzlinks zu passenden Systemen:


    http://www.vdr-wiki.de/wiki/in…n_und_Grafikkartenauswahl


    VDR mit aktueller Hardware (Nvidia 9300 Board) und Software (xine-vdpau)


    Aktuelle AMD-Plattform für vdpau



    1.2 Älteres Mainboard mit zusätzlicher PCI-Express-Grafikkarte:


    Beste Wahl erscheint mir hier eine Grafikkarte mit 9500erGT-Chip.


    Schafft problemlos bei HD-Content erweitertes Deinterlacing mit höchstem Deinterlacer => temporal_spatial, dazu mehr bei der Software.


    Die 9400erGT haben zuwenig Streamprozessoren und auch Shaderprozessoren um das erweiterte Deinterlacing von xine-vdapu bei HD-Content ( 1920x1080 interlaced) zu schaffen.


    Auch hier gilt das oben erwähnte Temperaturproblem der GPU, => passive Karten unbedingt von leisem Lüfter anblasen lassen.



    1.3 CPU-Auswahl zum Mainboard:


    1.3.1 Intel:


    jede Core2Duo-CPU oder vergleichbar. Auch Intel Celeron 440 (35 Watt).


    Empfehlung ganz klar eine Dual-Core-Cpu => OSD-Aufbau schneller und auch das Konverten und Kompilieren lässt den VDR in Ruhe.


    Geheimtip ist hier der 7200er, der läuft bei mir mit 0,95 Volt in dem Gigabyte E7AUM-DS2H
    bei vollem CPU-Takt mit 2,53 GHz. Das Board bietet die Möglichkeit die CPU via Bios zu Untertakten!


    1.3.2 AMD: siehe 1.1.1



    2. Softwareauswahl und deren momentane Fallstricke


    2.1. Beispielgrundkonfiguration (BS und Grundtreiber):


    - Debian – Lenny von der Netinstall
    - eigengebauter Kernel: 2.6.30.2 mit SMP-Unterstützung
    - Nvidia-Treiber: 185.18.36


    2.2 VDR-Versions-Auswahl:


    Im Moment ist es so, dass es da nicht so einfach ist, die für sich passende VDR-Version zu finden. Hintergrund ist die im Moment laufende Integration des neuen Aufzeichungs-Formates „ts“ in den VDR. Betroffene VDR-Versionen ab 1.7.2.
    Durch diese gravierende Änderung laufen eben viele Gooddies mit dem VDR nicht mehr.
    Beispiele:


    - Lifebuffer => wurde via Patch (Zulu’s Extension Patch) dem VDR einverleibt, geht seit VDR 1.7.7 nicht mehr)


    - noad-Skripte => Schneiden und Schnittmarken, Springen in Aufnahmen usw.


    - Plugins: Auch hier ist es so dass etliche wichtige Plugins erst nach und nach an das neue Aufzeichnungsverfahren angepasst werden müssen.
    Beispiel => xineliboutput mit diversen Problemen, z.B Ton auf HD-Sendern, richtige Puffergröße usw.


    Kurzum, in meinen Augen ist nach wie vor die beste Wahl für einen HD-VDR mit xineliboutput und vdpau die VDR-Version 1.7.0.



    2.3 Patches für den VDR-1.7.0 um eine gute Basis zu haben:


    2.3.1 Zulu’s VDR-Extension-Patch-Version 72 =>


    [ANNOUNCE] VDR Extensions Patch v.72


    Dieser Patch stellt viele zusätzliche Funktionen/Addons und Notwendigkeiten zur Verfügung um auch andere Plugins und Gooddies mit dem VDR zum Laufen zu Bewegen.


    Der Patch beinhaltet bereits den HD-OSD-Patch (OSD kann bis auf 1920x1080 übers Setup aufgezogen werden).


    Wichtig ist hier, dass die DVB-S/-S2-User den vdr-1.7.0-ext_h264-s2ng-speedup.diff einspielen,um die entsprechenden Anpassungen für h264 zu haben.


    Wie man Patches einspielt und mit Ihnen umgeht, das schenke ich mir hier und auch in den folgenden Passagen.


    Grundsätzlich braucht man also:


    - vdr-1.7.0_extensions.diff
    - vdr-1.7.0-ext_h264-s2ng-speedup.diff


    Bitte die beiliegende README unbedingt lesen => wichtige Tips zur Make.config!


    DVB-C User brauchen grundsätzlich keinen Patch um HD mit dem VDR nutzen zu können, aber ich empfehle diesen Benutzern trotzdem gleich den extp72 einzuspielen.




    2.4 xine-lib, xineliboutput-plugin oder xine-plugin, na was denn jetzt?


    2.4.1 Grundsätzliches:


    Das Thema ist ein nicht einfaches Thema, da man viele Begrifflichkeiten und Bezeichnungen dazulernt. Zudem sind viele wichtige Parameter für die Plugins in seperaten config-Dateien auf dem System.


    Links für Grundinformationen:


    http://www.vdr-wiki.de/wiki/index.php/Xineliboutput-plugin


    http://www.vdr-wiki.de/wiki/index.php/Xine-plugin


    Ich persönlich nutze nur das xineliboutput-Plugin und werde nachfolgend nur auf diese Ausgabemöglichkeit ein bisschen tiefer eingehen. Mit dem xine-Plugin selbst habe ich mich noch nicht beschäftigt.



    2.4.2 Welche xinelib-version will ich nutzen?


    Die xine-lib ist die Basis für das Ausgabeplugin xineliboutput.


    Dabei gibt es im Moment in Verbindung mit vdpau zwei Möglichkeiten, die den weiteren Weg ( was brauche ich dann noch?) festlegen.



    2.4.2.1 xinelib-1.1.x


    Erstere ist die im xine-vdpau-cvs Zwieg schon beinhaltete xine-lib-1.1.16. Diese Version hat einen etwas älteren Softwarestand, aber ist für die Entwickler von xine-vdpau von jeher schon die Basis für die Entwicklung von xine-vdpau. Die xine-lib-1.1.16 ist eine stabile Version.


    Das heisst, wer den xine-vdapu-cvs-Zweig benutzt, braucht sich um die xinelib-Installation nicht kümmern, da die bei der Installation von xine-vdpau miterledigt wird.


    Beispielhafte Installation mit diesem Zweig


    http://www.vdr-wiki.de/wiki/in…llation_.2F_Konfiguration



    2.4.2.2 xinelib-1.2


    Zweite Möglichkeit ist die cvs-Version der xinelib, also die xinelib-1.2. Diese Version ist die Entwicklerversion der xinelib. Hierbei ändert sich fast täglich der Softwarestand, sodass es immer wieder dazu kommen kann, dass sich xinelib-1.2 auf dem eigenen System nicht kompilieren lässt. Allerdings muß man auch sagen, dass diese lib sehr viele neuere Features mitbringt, die man nicht nur wegen vdpau braucht.


    http://hg.debian.org/hg/xine-lib/xine-lib-1.2 xine-lib-1.2 auf hg.debian.org


    und den entsprechenden xine-vdpau-Patch dazu von hier:


    http://www.jusst.de/vdpau/files/xine-lib-1.2/


    Ok, was soll das jetzt? Je nach dem für was man sich entscheidet, erreicht man den selben Stand mit vdpau, aber man hat einen unterschiedlichen Stand der xinelib als Basis für das Ausgabe-Plugin. Deshalb ist es wichtig, dass man sich wenn man hier im Portal postet, eine vernünftige Signatur anlegt, die den jeweiligen Zweig beschreibt. Denn wie man sieht, ist vdpau dann eben nicht vdpau wegen der unterschiedlichen Basis der xinelib-1.2 oder eben der xinelib-1.1.



    2.4.3 Welche xineliboutput-Versionen gibt es, welche ist zu empfehlen?


    Auch hier ist es so, dass man zwischen zwei Wegen wählen kann => ne stabile Version des Ausgabeplugins = xineliboutput-1.0.4


    oder


    der Entwicklerversion = vdr-xineliboutput aus dem cvs


    Hier verhält es sich wie bei der xinelib, die cvs-Version kennzeichnet die Entwicklerversion des Plugins und hat etliche Neuerungen drinnen, die speziell mit xine-vdpau/VDR/HD abgestimmt sind.


    Neueste Features sind HD-OSD, spezieller HD-Buffer und einige Bugbereinigungen.


    Die cvs-Version und auch die 1.0.4er Version laufen grundsätzlich mit den beiden xinelib-vdpau-Zweigen.


    Haben aber den einen oder anderen Nebeneffekt, dazu später mehr.




    2.4.4 Grundsätzliche Empfehlung:


    2.4.4.1 Mein Favorit (Stand 24.08.2009):


    xine-vdpau aus dem cvs (mit Patches von durchflieger in Version 9 = xine-vdpau-r279-crop-v9.diff.gz)

    mit


    xineliboutput-1.0.4 ( mit Patch von Durchflieger in Version 8 = xineliboutput-1.0.4-vdpau-support-v8.diff.gz)


    Patches von DF, siehe hier:


    [patches] xine-vdpau+xineliboutput+xine-plugin verbesserter vdpau support



    Positiv:

    - sehr stabil ab r273 von xine-vdpau aus dem svn


    - Autocropping = automatisches Aufziehen des Bildes (Letterbox-Automatik)


    - schnelles Umschaltverhalten (bei PES-Buffers = 900) und sehr gute Tonerkennung auch bei PassThrough bei HD-Sendern


    - Schneiden und Springen in Aufnahmen geht sehr schnell und sicher


    - kein Tonerkennungsproblem bei HD-Sendern


    Negativ:


    - Neuerungen und Bugfixes die nach dem eingesetzten Entwicklerstand der xinelib-1.1.16 eingeflossen sind, können nicht genutzt werden.


    - Wiedergabe von VDR-Aufzeichnungen im h264-PES-Format bei lokalem Frontend fehlerhaft. Abspielen über => Medien (xineliboutput hat einen eingebauten Medienplayer) geht einwandfrei.


    -



    2.4.4.2 Weiterer Zweig:


    xinelib-1.2 mit (vdpau-Patch = xine-lib-1.2-vdpau-r278.diff.bz2 , sowie Patch von Durchflieger in Version 9 = xine-vdpau-xine-lib-1.2-r278-crop-v9.diff.gz)


    mit


    xineliboutput-cvs ( mit Patch von Durchflieger in Version 8 = xineliboutput-head-vdpau-support-v8.diff.gz)



    Positiv:


    - HD-OSD-Erkennung via Plugin
    - Sehr schnelles Umschaltverhalten seit 25.08.2009


    Negativ:


    - die cvs-Version von xineliboutput hat im Moment ein ausgeprägtes Problem mit der Tonerkennung auf diversen HD-Sendern (ZDF HD, ARD HD, )
    Dies äussert sich durch Bildruckler und Tonaussetzer/kein Ton für ca. 25 Sekunden.
    Zusammenhang => xineliboutput versucht das Bild und den Ton synchron zu halten, deshalb kommt es in der Zeit der korrekten Tonformaterkennung zu vemehrten Framedrops, und das bedeutet Bildruckler und gleichzeitg kein Ton.
    An dem Problem wird sehr intensiv gearbteitet, ne Lösung steht in Aussicht.


    Stand: 25.08.2009 die Tonprobleme sind behoben und auch kleinere Bugfixes sind erledigt. Bitte die entsprechenden Einträge in der config beachten => siehe 2.4.6.2


    2.4.5 Startmöglichkeiten des xineliboutput-Plugins und deren Auswirkungen:


    2.4.5.1 als lokale Variante


    d.h über die RunVDR gleichzeitig mit dem VDR


    \"-Pxineliboutput --local=sxfe --video=vdpau --display=:0 -p --post tvtime:method=use_vo_driver --audio=alsa:hw:0,3 -f\


    Wichtig hierbei ist, da die Ausgabeparameter fürs Deinterlacing bereits mit dem Plugin-Aufruf mitgibt, dass man übers OSD im Setup zu xineliboutput keine zusätzlichen Parameter ändert (Punkt Deinterlacing = TvTime).


    Vorteile:


    - einige Pluginparameter können zusätzlich übers OSD gesetzt werden



    Nachteile:


    - VDR wird beim Beenden komplett beendet



    2.4.5.2 als Remote Variante

    d.h. über seperates Startaufruf, z.B über Skript.


    RunVDR:


    xineliboutput --local=none –remote=37890


    und seperater Aufruf, via skript, z.b start-vdrsxfe:


    /usr/local/bin/vdr-sxfe -f --display=:0 "xvdr+tcp://127.0.0.1:37890" --video=vdpau --post=tvtime:method=ues_vo_driver --audio=alsa:hw:0,3 --buffers=2500 --fullscreen --reconnect >/var/log/xinelib.log 2>&1


    Ich lasse alles was über die jeweilige Konsole des VDR's ausgegeben wird in ein seperates log laufen, da sieht man dann ganz gut wenn man umschaltet, was mit vdpau passiert. Minipatch für xineliboutput:



    Der Patch funktioniert sowohl mit lokalem Startaufruf, als auch mit Remote-Aufruf.



    Vorteile:


    - Frontend kann auch auf einem anderen Rechner im Netzwerk aufgerufen werden


    - sehr stabil



    Nachteile: wird ergänzt



    2.4.6 Wichtige Parameter des xineliboutput-Plugins für vdpau und wo finde ich die:


    Wichtig dabei ist, das man Änderungen an der .../config und .../config_xineliboutput bei gestopptem VDR macht. Ansonsten werden die Änderungen überschrieben.


    2.4.6.1 xineliboutput-1.0.4 (meist in /root/.xine/config_xineliboutput)


    1. HD-Deinterlacing für chipsätze 8200/8300/9300/9400:


    Erläuterung: Bei SD-Inhalten nimmt xine-vdpau grundsätzlich den besten Deinterlacer => temporal_spatial.
    Bei HD-Content (= Anixe HD, Astra HD, in 1920x1080interlaced ausgestrahlt) bestimmt man den Deinterlacer mit diesem Paramter.
    Die onboard-Lösungen sind hardwaretechnisch nicht in der Lage höhere Dieinterlacer-Stufen zu schaffen, => Framedrops/Ruckler. Allerdings bringt der bob-Deinterlacer mit xine-vdpau schon ein klasse Bild.


    ....
    # vdpau: HD deinterlace method
    # { bob half temporal half temporal_spatial temporal temporal_spatial }, default: 3
    video.output.vdpau_deinterlace_method:bob
    ....


    2. Parameter für Progressives Material


    ....
    # vdpau: disable deinterlacing when progressive_frame flag is set
    # bool, default: 0
    video.output.vdpau_honor_progressive:1
    ....


    3. Parameter durch DF-Patch, da xine-vdpau bei SD diese Parameter nicht regeln kann:


    ....
    # vdpau: restrict enabling video properties for SD video only
    # { none noise sharpness noise+sharpness }, default: 0
    video.output.vdpau_sd_only_properties:noise+sharpness
    ....


    Die Einstellparameter "noise reduction" und "sharpness" im xineliboutput setup werden standardmäßig bei SD UND HD-Videos angewendet.
    Mit der xine config Einstellung "video.output.vdpau_sd_only_properties:noise+sharpness" wirken die Einstellparameter nur noch bei SD-Videos. Bei HD-Videos wird in der Regel keine "Nachbesserung" benötigt und das Abschalten spart natürlich Rechenleistung in der GPU.


    Weiterhin sollte man die Display-Queuelänge vergrössern mit der xine config Einstellung "video.output.vdpau_display_queue_length=4".
    Damit sollte die Wiedergabe ruckelfreier während eines aktiven "grabbing" laufen. Eventuell bringts auch was bei der normalen Wiedergabe ohne aktiven "grabbing".



    4. Parameter um das Deinterlacing auf der GPU zu entlasten.


    ...
    # vdpau: disable advanced deinterlacers chroma filter
    # bool, default: 0
    #video.output.vdpau_skip_chroma_deinterlace:0
    ...
    ...


    5. Anzahl Audiopuffer


    ....
    # Anzahl der Audiopuffer
    # numeric, default: 230
    #engine.buffers.audio_num_buffers:230
    ....


    6. Anzahl Videopuffer => bei Version 1.0.4 unbedingt per Hand setzen:


    ...
    # number of video buffers
    # numeric, default: 500
    engine.buffers.video_num_buffers:2500
    ....


    7. Anzahl Videobilder zum Analysieren welcher Content (HD oder SD, usw.)


    ....
    # Standardanzahl von Videobildern
    # numeric, default: 15
    engine.buffers.video_num_frames:22
    ....


    2.4.6.2 xineliboutput-cvs (/etc/vdr/plugins/xineliboutput/config)


    Hier stehen dann die neueren Paramter von der cvs-Version die in der 1.0.4 nicht vorhanden sind. Ansonsten siehe 2.4.6.1


    Bitte unbedingt die neue cvs-Version testen, bei mir sind damit die Tonprobleme auf den deutschen HD-Sendern behoben.


    Wer trotzdem noch Probleme hat, kann diesen Patch auf die cvs anwenden:


    LINK:


    #Number of buffers for HD content
    # numeric, default: 2500
    media.xvdr.num_buffers_hd:4000


    # SRC tuning step
    # numeric, default: 5000
    media.xvdr.scr_tuning_step:150


    # number of audio buffers
    # numeric, default: 230
    engine.buffers.audio_num_buffers:500


    # number of video buffers
    # numeric, default: 500
    engine.buffers.video_num_buffers:1000


    # default number of video frames
    # numeric, default: 15
    engine.buffers.video_num_frames:22




    2.4.7 Wichtige Parameter des xineliboutput-Plugins für die Video-Ausgabe und wo finde ich die:



    2.4.7.1 xineliboutput-1.0.4 (meist in /root/.xine/config_xineliboutput





    2.4.7.2 xineliboutput-cvs (/etc/vdr/plugins/xineliboutput/config)



    2.5 Häufig gestellte Fragen:


    1. Wie erkenne ich ob vdpau als Ausgabemethode genutzt wird?


    Verlässlichste Methode ist das Loggen der Start-Konsole des VDR bzw. des Remote-Frontends (siehe obigen Patch fürs Logging), darin sollten dann solche Meldungen auftauchen:



    2. Warum gibts es beim Umschalten oft 1 bis 3 Sekunden Bild-/Tonaussetzer?


    Beim Umschalten ist es so, das xine-vdpau erstmal ermitteln muß, was kommt als Videostream an, also SD-Content oder HD-Content.
    Je nachdem was ankommt und welcher Deinterlacer verwendet wird, kann das bei Datenmengen bis zu 20 MBit schon etwas dauern und es treten eben Framdrops auf. Auch das empfangene Tonformat muß aus dem Stream ermittelt werden und dann gesetzt werden.
    Hier im Forum wird der Vorgang "Einpendeln genannt.
    Je nachdem welche Hardware und Deinterlacer man einsetzt, kann das alles eben bis zu 3 Sekunden bei HD-Content dauern.
    Wenn der bob-Deinterlacer bei HD-Content eingesetzt wird ist das Bild sehr schnell stabil.


    - Kleiner Logauszug beim Umschalten, hier sehr schnell ( kleiner 1 sec.) von SD auf HD mit 1280x720:



    - Kleiner Logauszug beim Umschalten, hier schnell ( kleiner 2 sec.) von HD mit 1280x720 auf HD 1920x1080:



    3. Tips zur Einrichtung des X-Servers, hier speziell xorg.conf:



    3.1 Wichtige Modelines in der xorg.conf:



    Diese Modelines sind für alle gängigen Video-Formate in Verbindung mit dem Nvidia-Treiber nutzbar. Man sollte darauf achten, dass das verwendete Display mit einem 50 Hz-Mode angesprochen wird, also 50 Hz interlaced oder 50 Hz Progressive.


    Das verhindert in meinen Augen sehr oft Bildhänger und leichte Ruckler.


    3.2 Tearing (= Trennung des Bildes durch eine waagrechte Linie) vermeiden:


    - kein Compositting aktiv, auch kein compiz oder sonstiges


    Eintrag in der xorg.conf:

    Code
    1. ….
    2. ….
    3. Section "Extensions"
    4. Option "Composite" "Disable"
    5. EndSection
    6. …..
    7. ….



    Soderle das wars soweit.


    Wer Ergänzungen, Vorteile, und Nachteile nennen kann, nur her damit, dann pflege ich das hier ein. Auch Lob und Tadel sind willkommen. Noch fehlende Parameter und Einstellungen werde ich diese Woche noch ergänzen, speziell im Bereich 2.4


    Lauffähige Systeme siehe Signatur!


    Gruß
    Wolfgang

  • Die Empfehlung für den VDR 1.7.0 (PES Aufnahme) kann eigentlich nur gelten, wenn man kein HD/h.264 aufzeichnen möchte, ansonsten ist das eine sehr schmerzhafte Sackgassen, denn h264-PES Aufnahmen werden in keinem "Vanilla" VDR unterstützt und können auch mit Hilfe von Patches in keinem aktuelleren VDR (mit TS format, mangels patches für h264-PES) abgespielt werden!

  • Quote

    Original von Razorblade
    Die Empfehlung für den VDR 1.7.0 (PES Aufnahme) kann eigentlich nur gelten, wenn man kein HD/h.264 aufzeichnen möchte, ansonsten ist das eine sehr schmerzhafte Sackgassen, denn h264-PES Aufnahmen werden in keinem "Vanilla" VDR unterstützt und können auch mit Hilfe von Patches in keinem aktuelleren VDR (mit TS format, mangels patches für h264-PES) abgespielt werden!


    Das verstehe ich jetzt nicht, ich kann mit meinem gepatchten VDR 1.6.0 ZDF/ARD HD sehen, aufnehmen und abspielen. Wenn ich mich richtig erinnere habe ich dafür einen 1.7.0er Patch backgeportet. Ich habe das gerade nochmal getestet, geht immer noch.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hallo Gerald,


    razor meint, dass neuere VDR-Versionen die mit "ts" kommen dann keine h264-PES-Aufnahmen abspielen könne, normale PES schon.


    Aber es gibt ja nicht nur den VDR zum Abspielen von h264-PES-Aufnahmen sondern auch noch den mplayer oder eben über xineliboutput => Medien.


    Mich stört diese Einschränkung nicht.


    Gruß
    Wolfgang

  • Tausend Dank Wolfgang,


    genau sowas hat die ganze Zeit gefehlt. Mich hast Du mit diesem Thread zu 100% erwischt und grade im Bereich xine* alle Fragen beantwortet :)


    Danke,


    Matthias

    HW: Athlon II X2 240 | Asus M4N78 Pro Geforce 8300 + GT 610 | 2 GB RAM | 2000 GB SATA | 2x Skystar2 | Silverstone LC10m | Harmony 555 ueber igorplugusb
    SW: Gentoo | Kernel > 3.12.xx| VDR 2.1.6 | Plugins:softhddevice, externalplayer, live| xbmc > 12



    "Informatiker trinken Bier!"

  • Quote

    Original von wbreu
    razor meint, dass neuere VDR-Versionen die mit "ts" kommen dann keine h264-PES-Aufnahmen abspielen könne, normale PES schon.


    Ach so, alles klar.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Prima Zusammenfassung....und ein herzliches Dankeschön für Deine Arbeit!


    Gruß
    iNOB

  • HI,


    Wbreu
    Vielen dank für Deine Bemühungen. Dieser Thread sollte hochgepinnt werden.


    Btw. Soll das ins Wiki? Das ist es gut aufgehoben. Würde mich auch anbieten das zu übernehmen.....


    MFG
    Kris

  • :portal1


    Super - So was hat man hier lange nicht mehr gesehen. 10 x :tup


    vdr-xine plugin und xine-ui: Dass hiermit auch das atmo-plugin läuft, sollte nicht verschwiegen werden ;)


    Gruß,
    Chris

    <font color="#0000ff">Gigabyte P35-DS3, Pentium E2140, GT220, 2 x DVB-C im Thermaltake DH101<br>gen2vdr V3 &amp; yaVDR 0.3.0a <br></font>

  • Vielen Dank, Wolfgang!


    Auch Wolfgang.

    Software: yaVDR0.6.1 mit VDR 2.2.0-13yavdr0~trusty, Kernel 4.4.0-146-generic, nvidia 384.130, dddvb 0.9.36.0easyVDR0
    Hardware: ASRock B75 Pro3-M, Intel G2030, RAM 4GB, SSD 64GB, HDD 4TB, Zotac GT630 ZONE Edition 1024MB GK208 (SKU:ZT-60408-20L), DD Cine C2/T2 V7
    Fernseher: SONY KDL-32D3000



  • Hallo Kris,


    gegen das Wiki spricht nichts von meiner Seite. Wenn du es übernehmen willst, mach nur. Danke dafür.


    Warte aber noch ein bisschen, ich habe noch so drei Din A4-Seiten unstrukturierte Doku liegen, die werde ich diese Woche nach und nach noch einarbeiten in den ersten Post.


    Wenn noch jemand was zu ergänzen hat, bitte posten.


    Gruß
    Wolfgang

  • Hallo Wolfgang,


    auch von mir ein riesen Lob, echt der Wahnsinn wie Du deine Freizeit für uns alle hier opferst!


    VG
    Marcus


  • Ich habe mir mal erlaubt den Thread oben anzupappen ;)
    Sobald der komplette Beitrag von wbreu im Wiki auftaucht, papp ich den Thread wieder ab.


    Und nebenbei dann auch noch ein Dankeschön an wbreu.
    Da werden sich hoffentlich noch einige User was rauslesen können :D


    jo01

  • Äußerst informativ und interessant.
    Vielen Dank auch von mir dafür.


    Gruß, bax2000

    easyVDR 3.0 stable, Gigabyte GA-Z87M-D3H, Intel Core i3-4130, 16 GB, Nvidia GT 630 Rev. 2, Samsung 840EVO 120GB SSD System, 16TB-NAS als zentraler Speicherplatz (Raid-Z2), DD Cine S2 v6.5 Dual DVB-S2, Antec Fusion V2 Silver

  • Hi,


    wbreu

    Quote

    gegen das Wiki spricht nichts von meiner Seite. Wenn du es übernehmen willst, mach nur. Danke dafür. Warte aber noch ein bisschen, ich habe noch so drei Din A4-Seiten unstrukturierte Doku liegen, die werde ich diese Woche nach und nach noch einarbeiten in den ersten Post.


    Das Wiki ist ja schnell angepaßt.


    Btw. ich möchte den gesamten Text unter http://www.vdr-wiki.de/wiki/index.php/VDPAU ablegen.


    Ich würde zwei Stufen vorsehen.


    Stufe 1. Wbreus Doku am Ende als "Enstehende Dokumentation" eintragen
    Stufe 2. Wenn Wbreu seine Sammlung komplettiert hat, würde ich beides verschmelzen.


    Ist Irgendwer dagegen oder hat Anmerkungen dazu?


    MFG
    Kris