Beta version of vdr with dvb-s2 support

    Hi,


    Zitat

    Original von ollo
    HDTV Aufnahmen kann ich zwar machen, aber mit den files ist nix anzufangen.


    Frage:
    Kannst du damit das aktuelle Testbild (kein Ton) auf EinsFestivalHD

    Code
    EinsFestivalHD;ARD:12422:hC34:S19.2E:27500:11601+1601:0:0:28396:0:0:0


    (DVB-S, H264, 720p50) aufnehmen.
    Hier (mit gepatchtem vdr) erkennt er nix, also kein Video, und macht logischerweise emergency-exit.


    Über szap + /dev/dvb/adapterX/dvr0 ist die Aufnahme als ts einwandfrei
    (mplayer + vlc).

    Hi egal,


    auf EinsFestival HD habe ich gestern mal getunt, aber da kam nix. Kein Ton und auch kein Livebild. Eine Aufnahme kann ich mal heute Abend versuchen. Übrigens macht er bei mir kein emergency exit (vdr-1.5.8 + patches)....


    Gruß, ollo

    Hi,

    Zitat

    Original von ollo
    Eine Aufnahme kann ich mal heute Abend versuchen. Übrigens macht er bei mir kein emergency exit (vdr-1.5.8 + patches)....


    Emergency-exit nur bei der Aufnahme, weil IMO nix erkannt wird;
    der remuxer wird aber mit TS-Daten gefüllt.

    Hallo ollo,


    Zitat

    Standard TS wäre doch ausreichend (z.B. für Aufnahmen) und dabei noch resourcen schonend?!


    Ich weiß zwar nicht wie du auf die Idee kommst das TS Resourcen schonender ist, nur weil es alle benutzen?
    Im TS Stream wird in kleinen Stücken der PES übertragen. Dadurch verbraucht der TS mehr speicher.
    Im TS Stream wird der PES fortlaufend in 184 Bytes gesplittet und dazu kommen dann immer 8 Bytes für die TS Informationen.
    Diese werden dann im Remuxer schon entfernt weil man sie nicht mehr gebraucht werden. :D


    Der PES kommt eigentlich vom MPEG und wird mit ein paar Erweiterung auch bei DVD benutzt.
    Beim Digitalfernsehen hat man sich dann entschieden, dass es günstiger währe die Packete noch kleiner zu machen um eine bessere Fehlerkorrektur zu haben.
    Dadurch würden kleine Übertragungsfehler innerhalb eines TS Packetes nicht sofort auffallen.


    Durch Reinhard's Patch wird der Remuxer angepasst um die H264 Stream's richtig auszuwerten.
    Diese kommen in einem neuem PES Format den der Remuxer vom Vdr noch nicht auswertet.


    Zitat

    ... kann man den remuxer nicht (a'la Reelbox) umgehen?


    Warum willst du den Remuxer umgehen der Patch dafür ist doch fertig?
    Soweit ich weiss benutzt die Reelbox jetzt 2 Aufnahmeformate, aber ob das
    so das richtige ist.


    Warum alle Programme den TS Stream benutzen weiss ich nicht.
    Zum Schluss müssen eh alle dann wieder den PES auswerten um Video ,Audio , Untertitel oder Teletext auszugeben.


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

    Hi,


    Zitat

    Original von LordZodiac
    Durch Reinhard's Patch wird der Remuxer angepasst um die H264 Stream's richtig auszuwerten.


    Warum willst du den Remuxer umgehen der Patch dafür ist doch fertig?


    Genau um diesen Patch geht es hier, oder gibt es einen anderen als in der vdr-ML für h264?
    Funzt der bei euch auf/mit EinsFestivalHD?

    Hallo,


    es gibt nur einen Patch für H264.
    Hab es gerade mal probiert. Die Aufnahme bricht ab. Mit VLC und streamdev bekomme ich aber ein Bild angezeigt.


    Werde mal Reinhard fragen was da los ist.


    Der Eintrag für die channels.conf sieht vollständig so aus.

    Code
    EinsFestival HD;ARD:12422:hC34:S19.2E:27500:11601+1601:0:0:0:28396:1:1201:0


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

    Code
    Zuzüglich folgender plugins:
 cd PLUGINS/src
 cvs -z3 -d:pserver:anonymous@xineliboutput.cvs.sourceforge.net:/cvsroot/xineliboutp
 ut co vdr-xineliboutput
 mv vdr-xineliboutput xineliboutput
 cvs -d:pserver:anoncvs@vdr-developer.org:/var/cvsroot co streamdev
 cd ../..
 make


    wenn ich hier Make mache kommt folgender Fehler:


    christian@test:~/test/vdr-1.5.6$ sudo make
    g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -I/usr/include/freetype2 dvbdevice.c
    In file included from dvbdevice.c:17:
    /usr/include/linux/dvb/video.h:27:28: error: linux/compiler.h: No such file or directory
    dvbdevice.c: In member function »virtual void cDvbTuner::Action()«:
    dvbdevice.c:348: Warnung: Variable »LastStatus« wird nicht verwendet
    make: *** [dvbdevice.o] Fehler 1

    LordZodiac,


    mit "resourcen schonender" meine ich den Aufwand fürs remuxen. Wenn bei HDTV die CPU sowieso an der Kante ist (wie bei mir), dann könnte man sie davon doch einfach entlasten. Die Tools kommen ja damit zurecht, Plattenplatz ist vorhanden und Probleme eben durchs remuxen werden vermieden.
    Aber das scheint ja eine philosophische Angelegenheit zu sein ;)


    Du nutzt VLC + streamdev lokal? Und der VLC kann was anzeigen - nur die HDTV Kanäle die progressiv senden, oder?


    Gruß, ollo

    Hallo ollo,


    ich glaube nicht das es für die CPU ein "grosse" Entlastung bringt auf den Remuxer zu verzichten.


    Ich sehe das ehr anderrum das eine TS Verwaltung mehr Aufwand bedeutet.


    Welche Probleme meinst du beim remuxen?


    Ich hab Stremdev auf meinem Vdr. Der VLC läuft unter Windows. Allerdings ist der Rechner nicht dafür geeignet um HDTV auszugeben.


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

    Einmal editiert, zuletzt von LordZodiac ()

    :moin LordZodiac,


    Zitat

    ich glaube nicht das es für die CPU ein "grosse" Entlastung bringt auf den Remuxer zu verzichten.


    Naja, Reel sieht das anders (ok, mit 'ner 300MHz CPU). Außerdem gibt es hier im Forum genügend Beiträge, die über erhöhte CPU Last berichten als der neue (Audio-)Remuxer eingeführt wurde.


    Zitat

    Ich sehe das ehr anderrum das eine TS Verwaltung mehr Aufwand bedeutet.


    Das laß ich mir von Dir gern erklären. Mit meinem "minimal technical underständing" dachte ich der TS wird einfach so wie er vom Transponder kommt durchgereicht?


    Zitat

    Welche Probleme meinst du beim remuxen?


    ... siehe aktuell EinsFestival HD bzw. die Probleme mit Aufnahmen von HDTV Sendern?!? Ok, der h.264 remux ist halt noch nicht fertig. Aber geht's nicht auch ganz ohne??


    Ich will hier nicht rumstänkern! Schließlich profitiere ich hier von prima Arbeit :respekt und bin so vom DigitalTV Virus infiziert worden. Aber irgendwie ist mir der tiefere Sinn des TS->PES remuxens noch nicht ganz klar...


    Zitat

    Ich hab Stremdev auf meinem Vdr. Der VLC läuft unter Windows. Allerdings ist der Rechner nicht dafür geeignet um HDTV auszugeben.


    Danke für die Ausführungen - da sind wir dann schon 2 (bzgl. Rechner nicht dafür geeignet um HDTV auszugeben) :schiel


    Gruß, ollo

    Hallo ollo,


    es gibt einmal den Remuxer und einmal die Repacker. Der Remuxer ist schon ewig im Vdr. Die Repacker sind dazugekommen.
    Ich habe noch nicht gemerkt das die Repacker zusätzlich Last erzeugen .
    Wenn sie dich stören kannst du sie im Quellcode auch ausschalten.


    Das Problem ist wenn man TS benutzt dann betrifft es nicht nur die Aufnahmen.
    Vdr bekommt jetzt von den Plugins die Grafik oder Audio liefern die Daten im PES Format.
    Die Schnittstelle für die Ausgabegeräte benutzen auch PES.
    Die Hardware die ich kenne (FF-Karte, DXR3, PVR350 ...) wollen die Daten auch im PES Format mit oder ohne PES Header haben.
    Dadurch müssten dann die Ausgabeplugins und Vdr selber die Daten vom TS wieder nach PES "konvertieren". Die Einagbeplugins müssten die Daten dann im TS Format liefern.
    Zusätzlich müssten zu den TS Packete auch noch die PMT Table mitgesendet werden damit dann die Daten richtig "konvertiert" werden können.
    Zusätzlich würdest du durch die kleinen TS Packet die zusätzliche Headerdaten enthalten wieder neuen Overhead erzeugen.


    Ich hoffe ich habe es einigermaßen verständlich erklärt.


    Zu EinsFestivalHD:


    Es gibt im Moment ein Problem mit den Videostream.
    Die Daten enthalten einen Fall den Reinhard noch nicht testen konnte weil er bis jetzt nicht vorgekommen ist.


    Wenn du mit streamdev den TS Stream zu VLC sendest wird der Remuxer gar nicht benutzt. Dort werden die Daten direkt von der Karte gelesen und weitergereicht.
    Der Remuxer wird erstmal zum Aufnehmen gebraucht. Die Ausgabe im PES Format geht im Moment nur mit Xine soweit es mir bekannt ist.


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

    Die Gründe, warum mir der Remuxer (und Repacker) unsympatisch sind, sind folgende:


    1) remux.c ist mit libsi so ziemlich der kritischste Teil im ganzen vdr. Die bekommen den Kram samt Empfangsfehlern und dürfen sich durch nichts aus der Ruhe bringen lassen. Also weder unkorrekte Ausgabe noch einen Crash erzeugen. Und das ist halt fast unmöglich. Alle Nase lang gibts einen neuen Sender mit einer seltsamen, aber korrekten Interpretation der ISO-Spec, dann passt wieder irgendwas mit dem Repacking nicht und sorgt für Freude erst bei der Wiedergabe. Allein der h264-Patch für remux.c ist ja recht happig. Versteht da (ausser Reinhard ;) ) noch irgendwer, was da eigentlich passiert? Warum muss die Aufnahme wissen, was sie da eigentlich aufnimmt und es noch dazu Byte für Byte selber anschauen? Je weniger Syntaxcheck da gemacht wird, umso zuverlässiger ist doch das ganze...


    2) Der Repacker ist eigentlich notwendig, nicht jeder fängt tatsächlich mit einem neuen PES ein neues Frame an oder macht AC3 richtig. Und das zieht CPU, wirf nur mal einen Blick mit gprof oder oprofile drauf. Insbesondere das dauernde Speicherkopieren macht kleineren CPUs arg zu schaffen. Und wenn ich der vdr-ML trauen darf, auch Epias... Sicher merkt man das auf 2.xGHz nicht mehr, aber das ist kein Argument. Dann könnte man ja auch gleich bei der Aufnahme gzipen ;) Normalerweise kann man mehrere Aufnahmen gleichzeitig machen, aber nur eine anschauen. D.h. spätestens bei der zweiten parallelen Aufnahme lohnt es sich, den rohen TS aufzunehmen, selbst wenn die Konvertierung von TS nach (P)ES bei der Wiedergabe erfolgen muss.


    3) PES hat der vdr, weil es die FF-Karte so wollte. Jedenfalls später. Am Anfang hatte sie das AVPES-Format, das noch inkompatibler war. Ich bin mir ziemlich sicher, dass der vdr heute TS aufnehmen würde, wenn es die FF-Karten erst nach den Budgets gegeben hätte...


    4) Das vdr-PES-Format ist und bleibt eine Insellösung. Damit kommen nicht viele (kommerzielle/PD) Tools zurecht. Sicher kann man irgendwie konvertieren, aber praktisch ist das nicht. Jedenfalls sind das die Erfahrungen von RMM (bzw. deren Kunden...). Die Abweichungen bei Audio/AC3 sind notwendig, damit man mehrere Tonspuren haben kann. Das Problem hätte man gar nicht erst, wenn man einfach TS aufnehmen würde. Vorne dran PAT/PMT und das wars dann. Und das ist kein grosser Aufwand. Sind beim RB-vdr ein paar Zeilen. Und den Overhead (plus die 4Byte pro TS-Paket) lasse ich hier bei den heutigen Festplattengrössen nicht mehr gelten, die 2% (90s weniger pro Stunde...) gehen im Rauschen unter.

    :moin,


    LordZodiac & real_schorsch - vielen Dank für die Erläuterungen, nun seh' ich viel Clara :streichel
    Sorry, irgendwie habe ich den remuxer und repacker durcheinander gehauen.


    Übrigens streaming von TS zum MPlayer (lokal) klappt solange bis sich der MPlayer an den interlaced pictures verschluckt. Der VDR bleibt dabei stabil.


    Gruß, ollo

    Hallo real_schorsch,


    bis jetzt kann ich mich nicht dran erinnern das der Remuxer oder Repacker schonmal abgestürtzt sind.
    Wenn die empfangenen Packete fehlerhaft sind dann hab ich so oder so Störungen in der Aufnahme.


    Bei der libsi gab es in den letzten Jahren 2-3 mal den Fall das Fehler zum Absturz geführt haben, wenn ich mich richtig erinnere.


    Baut ihr jetzt auch die libsi aus weil sie Absturzgefärdet ist? ;)


    Zitat

    und es noch dazu Byte für Byte selber anschauen


    Es wird nicht jedes Byte angeschaut. Es werden die Header ausgewertet um zu schauen ob die berechnete Länge mit der empfangenen Länge übereinstimmt.
    Für H264 ist es für den Vdr schon interessant ob er die Daten zur FF Karte schickt oder nicht.
    Die FF-Karten reagieren bei fehlerhaften MPEG Daten doch sehr empfindlich.


    Zitat

    PES hat der vdr, weil es die FF-Karte so wollte.


    Wie gesagt die FF-Karte ist nicht die einzige Karte die PES Daten verarbeitet.


    Das Vdr-PES Format entspricht dem DVD Format, daher würde ich es nicht Insellösung nennen.


    Wenn dich das PES Format so stört dann wechsele doch den cRecoder und den cDvbPlayer aus und gut ist. ;)


    Ich glaube es gibt beim Vdr wichtigere Sachen als sich über TS oder PES zu streiten.


    bis dann LordZodiac


    Vdr1: vdr-1.7.0 HDe, Nexus 2300-S und TT S2-3200
    Vdr2: vdr-1.4.7 Nexus CA, Terratec Cinergy 1200s
    Plugins: dvd-0.3.6b03+, femon-1.1.3
    System: Suse 9.1 Kernel 2.6.28


    Testkarten: Dxr3, Hauppauge DVB-c 2.1, Terratec Cinergy 1200c, Nova-t
    Alphacrypt Light 3.11
    AMD Sempron 2400+ 512MB Epox 8RDA3I Pro
    Pentium III 384MB BX440
    Panasonic SA-XR 15 EG-S :)

    LordZodiac:


    Nein, die libsi bauen wir nicht aus ;) Den Remuxer/Repacker haben wir/ich für den RB-vdr neugemacht, weil der wirklich arg ineffizient ist. Man kann auch beim Repacken da einiges optimieren. Dazu braucht es aber auch den Leidensdruck von 300MHz.


    "Es wird nicht jedes Byte angeschaut."


    Was macht ScanVideoPacket sonst? Es sucht nach SequenceHeadern und die können (ohne Optimierung) überall vorkommen. Wie gesagt, schaus dir mal mit gprof an...


    "Wenn dich das PES Format so stört dann wechsele doch den cRecoder und den cDvbPlayer aus und gut ist."


    Wir haben (unseren...) remux.c um die h264-Erkennung(!) ergänzt und eine PlayTS-Methode in device.c drin. Das fügt sich alles sehr smooth in den vdr und tangiert die "erprobten" Wege nicht. Damit kann man auch "plötzlich" ganz normale TS-Files ohne extra Medienplayer abspielen.


    "Das Vdr-PES Format entspricht dem DVD Format, daher würde ich es nicht Insellösung nennen."


    AFAIK ist da schon noch was anders... Du hast nicht die verzweifelten Kundenanfragen, wie sie jetzt die Aufnahmen weiterverarbeiten können ;)


    "Ich glaube es gibt beim Vdr wichtigere Sachen als sich über TS oder PES zu streiten."


    Ich streite auch nicht. Ich wollte nur darlegen, warum wir vor knapp 12 Monaten angefangen haben, den vdr mit TS zu ergänzen und nicht auf externe Lösungen zu warten. Da war eben von h264-Remuxer noch keine Spur. Es gab in der Vergangenheit genügend Anfragen, auch MPEG2 als TS aufzunehmen. Wo ist das Problem, wenn der vdr wählbar PES/TS aufnehmen und ohne Erweiterungen auch beides wiedergeben kann?

    Hi,


    Zitat

    Original von LordZodiac
    Wenn sie dich stören kannst du sie im Quellcode auch ausschalten.


    Für H.264 ist zumindest der cVideoRepacker verpflichtend!

    Zitat


    Zu EinsFestivalHD:
    Es gibt im Moment ein Problem mit den Videostream.
    Die Daten enthalten einen Fall den Reinhard noch nicht testen konnte weil er bis jetzt nicht vorgekommen ist.


    Wenn ich ehrlich bin: der Fall steht in der Spec drin, hab's auch gelesen, war aber zu Faul es umzusetzen, da bei den bisher vorhandenen Sendern nicht notwendig.
    Anbei ein Patch der zusätzlich zum bereits existierenden Patch anzuwenden ist und das nun nachrüstet. Um's aber gleich vorwegzunehmen, der komplexeste Fall ist nicht berücksichtigt, da noch nicht benötigt.

    Zitat


    Der Remuxer wird erstmal zum Aufnehmen gebraucht. Die Ausgabe im PES Format geht im Moment nur mit Xine soweit es mir bekannt ist.


    Schön langsam wird's Zeit für ein neues vdr-xine Release. Hoffentlich klappt's im Laufe der Woche.


    Bye.

    Hallo Reinhard,


    ich habe Deinen Patch mal eingebaut und 2 Aufnahmen gemacht und diese dann versucht mit dem MPlayer abzuspielen:


    1. EinsFestival HD - kein Bild, kein Ton



    2. Astra HD - kein Bild, aber Ton



    Dann habe ich per streamdev-server einen TS gestreamt:


    1. EinsFestival HD - Bild kommt, kein Ton (wird wohl nicht gesendet!)




    2. Astra HD - Bild & Ton



    Gruß, ollo

    Hi,


    jo, ebenfalls EInsFestivalHD aufgenommen;
    auch xine (1.1.7) erkennt kein video.


    Habe mal die "primary_picture_type" (oder so) bytes mit "00" hinter der AUD-Kennung "09" auf > "0x00" geändert, also anstatt "00 00 01 09 00" z.B. "00 00 01 09 10";
    dann erkennt xine die Aufnahme und spielt sie komplett ab.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden