Rasperry Pi xine plugin

Zitat von seahawk1986

Wichtig ist nur, dass die Header-Dateien und Versionsstände der Bibliotheken auf den Build-Rechnern zueinander passen.

Das sollten die verwendeten Cross-Compiler auch, um Probleme noch weitgehender zu vermeiden.

Hi,

da ich nicht all zu oft nen kompletten Build mache, ist das Kompilieren über mehrere PC's nicht ganz so wichtig für mich.

Was mich nun aber irretiert, ist das ich auch nach nem Update immer noch auf glibc-2.13 bin. Bist DU sicher das Du ne neuere Version hast, bzw. Was für nen System setzt Du ein? Ich verwende Raspian.

Claus

Zitat von clausmuus

Was für nen System setzt Du ein?

Ich nutze Arch Linux ARM. ardi hat ja geschrieben, dass er es für raspbian gebaut hat, da sollte es eigentlich sowieso funktionieren.

Hallo Ardi

Habe jetzt auch mal dein Plugin getestet.
Habe ein 256mb Raspi mit 128 Mb Split.
Vielen Dank dafür läuft schon sehr gut.
Habe aber noch Ton Aussetzer überwiegend bei SD Sendern.
Und beim Umschalten von HD nach SD hängt sich vdr-fbfe auch auf.
Ich bin gespannt auf die Weiterentwicklung.

Habe jetzt aber nur Analog auf ner alten Röhre getestet.

mfg Thomas

Zitat von seahawk1986

... ich meinte das eher so:

Code

vdr -P "xineliboutput --local=none --remote=:37890"

Und dann davon unabhängig auf einer zweiten Konsole:

Code

vdr-fbfe -V rpi -A alsa -f

Super, das läuft mit einem USB2.0-DVB-T Empfänger hier sehr gut.
Vielen Dank für den Tipp!
Hier habe ich, wie in meinem letzten Post auch, die sehr kurzen Breaks im Ton...

Viele Grüße, Uwe

PS: alles unter raspbian und 256MB/256MB Aufteilung, über HDMI Ausgang....

Hi ardi,

das ist beim Yaepghd-plugin der Fall.

Viele Grüße skippy

[Blockierte Grafik: http://imageshack.us/a/img84/5241/yaepghd.png]

Hi ardi,

soweit es mir bekannt ist werden innerhalb eines Senders nicht einmal von Interlaced auf progressiv gewechselt.Interlaced ist für alte TV Geräte (Röhre) und Videorecoder wichtig gewesen und wird gegebenfalls vom SAT Receiver oder anderen Geräten über die Quellenauswahl gemacht und künstlich per Videoprocessor generiert.Das sogennante FBAS und für Schwarzweis TV BAS Signal werden im Interleacedmodus betrieben.Das jetzt komplett zu beschreiben sprengt hier den Rahmen.

mfg guigra

Zitat von guigra

Hi ardi,

soweit es mir bekannt ist werden innerhalb eines Senders nicht einmal von Interlaced auf progressiv gewechselt.Interlaced ist für alte TV Geräte (Röhre) und Videorecoder wichtig gewesen und wird gegebenfalls vom SAT Receiver oder anderen Geräten über die Quellenauswahl gemacht und künstlich per Videoprocessor generiert.Das sogennante FBAS und für Schwarzweis TV BAS Signal werden im Interleacedmodus betrieben.Das jetzt komplett zu beschreiben sprengt hier den Rahmen.

mfg guigra

Dann steht 1080i nicht für interlaced?

Hi ardi,

danke für deine Antwort.Ich denke das du das nicht ständig prüfen mußt.Ich würde eine Prüfung bei einem Senderwechsel machen, da man nicht wissen kann ob nicht der eine oder andere Sender doch interlaced Matrial ausstrahlt.Ich persönlich denke aber nicht das das noch geschied aber ich lasse mich gern eines besseren belehren.

googles

danke für deine Antwort.Das Kürzel 1080i steht natülich für interlaced.Das sagt aus das z.B ein TV Gerät z.B auf 1080 Zeilen hochgerechnetes Bild wiedergeben kann aber kein echtes HD.Quasi SchummelHD.

mfg guigra

Alle SD Sender senden interlaced. Sprich Halbbilder mit 25 Hz (PAL) 30 Hz (NTSC).
Alle 1080i Sender senden interlaced.
Alle 720p Sender (das sind aber nur die Öffentlichrechtlichen) senden Vollbilder.

Im normal Fall ist das Material bei 1080i interlaced. Es gibt aber die Ausnahme z.b. Filme die werden
bzw. können dann in 25Hz Vollbild gesendet.

Interlaced Material muß man nicht deinterlacen, wenn man es so direkt ausgibt.
So machen es die meisten DVB Receiver. Das Problem ist, man muß den Senderstream mit der Ausgabe synchronisieren. Ansonsten bekommt man unschöne Kämme.

Das Problem ist, daß dann das OSD nur genauso groß wie der Videostream ist.

Will man schönes OSD haben, dann muß man den Videostream erst deinterlacen, dann skalieren und dann ausgeben.
Außerdem braucht man Videostream und Ausgabe nicht mehr 100% genau synchronisieren.

Es ist theoretisch erlaubt, daß der Sender von 720p auf 1080i und umgekehrt umschaltet. In der Praxis kommt es nicht
vor. Wobei die Überprüfung 0 Rechenzeit kostet.

Problematischer ist die Erkennung von 1080p25 und 1080i50, dies unterstützt z.b. VDPAU in Hardware.
Theoretisch müsste man dies aber auch irgendwo im Stream stehen.

Ich hoffe ich konnte es vernünftig erklären.
Johns

Hi johns,

super erklärt.Die Kennung in welchem Format das Videomaterial gesendet wird immer mit gesendet.Das ist notwendig um das Bildmaterial korrekt zu decodieren und in richtiger Auflösung darstellen zu können.
Aber wo das im Datenstream zufinden ist weis ich nicht ich nehme an das es am Anfang übertragen wird.Aber das können sicher andere besser erklären als ich.

mgf guigra

Mit der Einschränkung, das eigentlich fast kein (wichtiger) Sender bis heute 1080[i|p] ausstrahlt. ÖR in D eben in 720p und BBC z.B. in 1440x1080.

Zitat von guigra

Aber wo das im Datenstream zufinden ist weis ich nicht ich nehme an das es am Anfang übertragen wird.Aber das können sicher andere besser erklären als ich.

Anfang ist bei deinem Stream bei dem man jederzeit einsteigen kann etwas komplizierter.

Hi decembersoul,

habe mal in meinen Unterlagen gekramt und rausgefunden das diese Infornation mit jedem neuen Bild im Bildheader mitgesendet wird.Das wird so gemacht weil man ja zu jeder beliebigen Zeit in den Bilddatenstrom einsteigen kann (z.B bei einem Film (egal ob Festplatte, DVD, VCD oder TV-sender).Es wird immer mit geteilt ob gerade ein ODD-Field oder EVEN Field vorliegt.Ist dem so liegt interleaced Material vor und der Bildprocessor z.B im TV setzt dann das Bild zu einem Vollbild zusammen.Wird in Vollbildern gesendet so entfällt das zusammensetzen des Bildes.Da ich mich auch mit FPGAs beschäftige und die Ansteuerung für LCD und TFT selbst regeln muss stand ich genau vor dem selben Problem wie ardi.Um TV oder Videostreams wiedergeben zukönnen mußte ich den Timingcontroller TPG051 für das TFT LCD Display mit dem Videostream synchronisieren.Das Display ist ein Toshiba TD036THEA1 Das Datenblatt und speziell die TPG051 Spec 1.3 enthalten die wichtigen Informationen und dabei ist es egal ob das nun für HD oder SD ist.Jedes Bild hat auch einen gleichlangen Audioanteil und die Decodierung muß so schnell ablaufen das Audio und Video nicht auseinander laufen. Ich weis leider nicht ob man das PDF hier hochladen kann und darf da beide PDFs zusammen etwa 1.2Mbyte groß sind.

mfg guigra

Ich vermute stark das ein Sender nicht im Stream von Deinterlacing auf Interlacing wechselt.

Hi decembersoul,

deine Vermutung ist richtig.Es kann immer nur mit einem neuen Stream(Video) gewechselt werden aber nicht im selbigen.

ardi

gibt es zum rpi HW Decoder technische Informationen(Datenblatt als pdf) dann könnte ich besser helfen.Alles andere würde nur Spekulation werden.

mfg guigra