[Prototyp] RPI Ausgabeplugin

Danke Vectra130,

Sind beide schon installiert aus den Raspbian quellen.

Vielleicht noch eine andere Idee ?

Zitat von rollercontainer

Es kommt zwar kein Fehler, aber auch kein rpi-Plugin raus.

Hast du schon eine Make.config aus der Make.config.template erstellt? (Ich nehme mal an, du baust mit vdr2.0)
Das ist wichtig. Dann funktioniert auch "make LCLBLD=1"
und die Plugins sollten da sein.

Nein, ich versuche es mit 1.7.28. Aber ich sehe schon, dass das meine Fähigkeiten übersteigt. Ich warte dann bis zum deb-Paket.

Hallo rollercontainer,

Fuer 1.7.28 habe ich die so Datei und ein angepasstes Makefile die kann ich dir heute abend hier hochladen.

Leider aber nur rpihddevice 0.0.3.

Die 0.0.4 kann ich nicht bauen da ich den weiter oben beschriebenen Fehler bekomme.

Gruss,

Franz

Warum aktualisiert ihr nicht erstmal den VDR?

OK, mit vdr-2.0.3 und streamdev aus dem git habe ich es übersetzen können.

Was noch fehlte für ein Plugin war libncurses5-dev.

Zitat von Mreimer

Warum aktualisiert ihr nicht erstmal den VDR?

In einigen Bereichen ist die aktuelle vdr Version ressourcenschonender, was gerade für schwache ARM Hardware gut ist.

Daumen hoch für das Plugin

Munter bleiben, Rossi

hi reufer,

nun auch von mir herzlichen dank für deine mühen!

claus hat mich nun doch genötigt mit beim pi rumzuspielen und ich muss sagen ich bin begeistert.

wegen den tonproblemen -> stottern. Mir ist gerade aufgefallen, das bei einer film -> werbung umschaltung es zu diesem stottern kam.

vllt hilft das ja weiter

(sorry, aber bis mir das problem klar wurde hatte ich schon nen reboot durchgeführt und somit keine logs -> vllt beim nächsten mal )

greetz MarMic

Hallo,
bzgl. ffmpeg versus libav.
Ich verwenden nur libav, da diese von vielen Distributionen als Standard verwendet wird.
Da sich die beiden branches auch in der API auseinander entwickeln, würde ich empfehlen nur eines von beiden zu verwenden.
Zu den anderen Fragen:

Zitat

Ich glaube nun begriffen zu haben, wie die Codec-Erkennung im SoftHdDevice funktioniert. Aber egal welcher Codec gefunden wird, decodiert wird immer ab Anfang der Payload vom PES-Paket - genau gleich wie bei meiner Implementation.

Es kann sein, dass sich der VDR bei seinen devices anders verhält, ich habe mir auch weder den Code bei softhddevices noch deinen Code angesehen.
Ich denke das sicher ist bei einem PES paket zu starten, bei dem das sync flag gesetzt ist. Es ist möglich das VDR diese Pakete zu einem Paket zusammenfasst, was bei vomp nicht gegeben ist. Daher würde ich nur die Möglichkeit das es zerstückelt sein kann im Hinterkopf behalten, falls es Probleme gibt.
Wobei bei deutschsprachigen Sender, meist keine zerstückelung vorliegt, ich habe das jedenfalls erst durch meine internationalen User herausgefunden und mich gewundert warum es nicht funktioniert.

Zitat

"Aber auch libav speichert teilweise Daten zwischen
Zusammen mit dem Flag CODEC_FLAG_TRUNCATED und dem Zwischenspeichern der Restdaten sollte das doch eigentlich immer funktionieren... oder?"

Ich hatte das am ANfang auch so, kann mich aber erinnern warum ich es ändern mußte. Es kann sein, dass es Codec abhängig ist oder vom vomp Design abhing.

Zitat

Inzwischen habe ich auch herausgefunden, dass der VDR die Stream-Id mitgibt - aber diese sagt mir lediglich, ob es sich um MPEG-Audio oder "was anderes", also einen privaten Stream handelt.

Hilft da nicht die SetPid Funktion? Ich vermute, das der type, der übergeben wird der type aus der PAT PMT für recording ist.
Schau mal in cDvbHdFfDevice::SetPid(cPidHandle *Handle, int Type, bool On) vom vdr, da ist ein Beispiel wie man an die tds kommt.
Damit kann man wenigstens zwischen 0x0F:AAC ADTS packaging, 0x11: // AAC LATM packaging , 3: case 4: mpeg audio unterscheiden.
Bzw. im Fall eines private Streams 5 oder 6 etwas anderes auswerten( ich weis nicht ob vdr hier was erkennt, aber möglich wäre, z.B. 0x7A: // Enhanced Ac3 Desriptor 0x6A: Ac3 descriptor, wenn es die PAT PMT ids sind).

Marten

Ich habe es gerade gegen ffmpeg-compat (1.0.8) gelinkt gebaut, damit klappt es bei mir auch mit dem Ton:

libavcodec.so.53 => /usr/lib/ffmpeg-compat/libavcodec.so.53 (0xb620b000)
        libavformat.so.53 => /usr/lib/ffmpeg-compat/libavformat.so.53 (0xb6109000)
        libavutil.so.51 => /usr/lib/ffmpeg-compat/libavutil.so.51 (0xb5e3e000)

Es liegt also an ffmpeg > 1.1.

Zitat von reufer

Ich bin mir noch nicht ganz im Klaren, wie ich hier weiter vorgehen soll, aber ich sehe gerade noch unzählige andere, wichtigere Baustellen, statt mich mit unstable-ffmpeg-Versionen zu beschäftigen.

Hauptsache es funktioniert
Das ffmpeg-Projekt stuft die 2.0 ja als Major Release ein und rät selbstbewusst:

Zitat von July 10 2013 FFmpeg 2.0

We recommend users, distributors and system integrators to upgrade unless they use current git master.

Gentoo ist da also recht konservativ mit den "stable"-Empfehlungen.

Zitat

Mal eine ganz naive Frage: Wenn die Formaterkennung so einfach ist und der VDR einem das so schön auf dem Silbertablett serviert, warum treibt denn das SoftHdDevice (und auch xineliboutput) einen solchen Aufwand?

Ich glaube, weil das vor vdr version 1.7. ?? nicht anders ging, als der vdr noch komplett pes basiert war und die beiden PlugIns sind schon ein wenig älter.

Marten

Ich glaube da kann man nur kls fragen...
Kann sein, dass es so nur funktioniert, wenn es auch aufnehmen kann, aber eigentlich ist wirklich unsinnig dem Ausgabeplugin, das Format vorzuenthalten.

Marten

Ich war mal so faul und dreist und habe mal das vdr wiki aktualisiert

Unter anderem auch die Seite
http://www.vdr-wiki.de/wiki/in…es_und_Komponentenbundles

um ein paar ARM-Boxen aktualisiert

finde nur den Titel "Barebones und Komponentenbundles" ein bisschen nichts sagend

"Hardware - Empfohlene Hardware, Komponentenbundles, ARM-Boxen"

wäre vielleicht Aussagekräftiger.

Zitat von MartenR

Hallo,
bzgl. ffmpeg versus libav.
Ich verwenden nur libav, da diese von vielen Distributionen als Standard verwendet wird.

Das würde ich so nicht unterstreichen. Es wird von Debian-Basierten verwendet. Und das liegt im Wesentlichen daran, dass Debian ein echter "Fork-Magnet" ist. Wo auch immer zu irgendeinem Projekt ein Fork entsteht ist Debian meist schnell mit dabei und stellt auf den Fork um.

War es nicht so, dass johns in seinem softhddevice zwischenzeitlich den libav-Support sogar einstellen wollte (oder gar hat?) weil es mit der libav mehr Probleme gab als mit ffmpeg?

Ohne FFMPEG-Support ist Archlinux auf jedem Fall außen vor.

Zitat von Mreimer

Ohne FFMPEG-Support ist Archlinux auf jedem Fall außen vor.

So schlimm ist es aktuell nicht - ffmpeg-compat ist teil der Arch Linux ARM Pakete:
http://archlinuxarm.org/packages?arch=&search=ffmpeg-compat