Zwei Klassen mit dem gleichen Namen? Böse... 
Ich hab's bisher auch nicht in jedem meiner Plugins geschafft, aber das Benutzen von namespaces hat Vorteile.
Siehe z.B. recsearch: https://github.com/flensrocker/vdr-plugin-recsearch
Aber cool, dass du das gefunden hast!
Lars.
Hi Patrick
sooo ich glaub ich hab jetzt den Grund gefunden...
Ich habe mich gerade durch den Code mit dbg "gedebugt"und bin dabei auf das das Verhalten gestoßen, dass er den Konstruktor der "falschen" cAudioParser-Klasse aus der remux.c nimmt und ausführt.
Code#0 cFrameParser::cFrameParser (this=this@entry=0x74cde0) at remux.c:1055 #1 0x000d9c68 in cAudioParser::cAudioParser (this=0x74cde0) at remux.c:1069 #2 0xb68cf794 in cAudioDecoder::cAudioDecoder (this=0x4e2b18, omx=0x4e2990) at audio.c:680 #3 0xb68d0c6c in cOmxDevice::cOmxDevice (this=0x4e0030, onPrimaryDevice=) at omxdevice.c:42 #4 0xb68c7e64 in cPluginRpiHdDevice::Initialize (this=0x1ad488) at rpihddevice.c:62 #5 0x000ca3f4 in cPluginManager::InitializePlugins (this=this@entry=0x1) at plugin.c:363 #6 0x00063900 in main (argc=12, argv=0xbefff764) at vdr.c:730das liegt daran, dass beide Klassen gleich heißen. Keine Ahnung, ob der Compiler das richtig macht, oder da ein Bug hat?
Vielleicht hilft es ja die cAudioParser Klasse hier in der audio.c umzubenennen.Soweit meine momentanen Erkenntnisse. Vielleicht helfen diese ja weiter!
Vielen Dank für deine Bemühungen und den Hinweis mit dem doppelten Klassennamen! Das ist natürlich falsch und ein Versehen meinerseits!
Ich habe inzwischen versucht, mit ffmpeg unter Raspian das Verhalten zu reproduzieren, aber leider immer noch ohne Erfolg. Ich würde gerne den Effekt bei mir sehen, um sicher zu sein, dass ein Fix auch funktioniert.
Hast du denn die Klasse im Plugin mal umbenannt, um deine Vermutung zu bestätigen?
Als Fix für das Problem sehe ich folgende Möglichkeiten
- umbenennen - wobei mir cAudioParser eigentlich ganz gut passt
- generell namespaces verwenden oder
- cAudioParser innerhalb von cAudio deklarieren - was ja auch sowas wie ein namespace wäre
Letzteres scheint mir auf den ersten Blick am logischsten, aber wohl ein bisschen unkonventionell... was meinen die C++-Experten dazu?
Gruss
Thomas
Hi,
Hast du denn die Klasse im Plugin mal umbenannt, um deine Vermutung zu bestätigen?
Ja, nachdem ich die Klasse umbenannt habe, hat es funktioniert.
Als Fix für das Problem sehe ich folgende Möglichkeiten
- umbenennen - wobei mir cAudioParser eigentlich ganz gut passt
- generell namespaces verwenden oder
- cAudioParser innerhalb von cAudio deklarieren - was ja auch sowas wie ein namespace wäre
Ich bin zwar kein c++ Experte aber ich würde einen eigenen namespace vorschlagen.
Schöne Grüße
Patrick
wie ich weiter vorne geschrieben habe, ich hab das Verhalten auch nur mit FFMPEG 1.0.8 + GCC 4.8 auf Wheezy gesehen - mit der Standard FFMPEG Version auf Wheezy + GCC4.8 scheint es problemlos mit dem Originalcode zu funktionieren.
Gruss
Umbenennen ist der einfache Weg, danach kannst du immer noch namespaces einbauen.
Lars.
wie ich weiter vorne geschrieben habe, ich hab das Verhalten auch nur mit FFMPEG 1.0.8 + GCC 4.8 auf Wheezy gesehen - mit der Standard FFMPEG Version auf Wheezy + GCC4.8 scheint es problemlos mit dem Originalcode zu funktionieren.
Ich hab alles was mit ffmpeg/libav zu tun hatte runtergeschmissen und mir ffmpeg 1.0.9 aus den Sourcen kompiliert. Die 1.0.8 habe ich auf den offiziellen Seiten nicht mehr gefunden... such mir das aber noch zusammen, ist ja grad Ostern.
Gruss
Thomas
Edit: schon gefunden...
Umbenennen ist der einfache Weg, danach kannst du immer noch namespaces einbauen.
Einfach schon, aber ich mag den Kreis nicht in ein Dreieck umbenennen und dann wieder zurück, wenn das eigentlich Problem gelöst ist. Ich denke, ein eigener Namespace fürs Plugin ist der richtige Weg und mit wenig Aufwand gemacht.
Gruss
Thomas
Mal kurz ne Frage an alle...
Habt ihr bei bewegungen bei den SD Kanaele auch ein ziehmlich gepixeltes Bild oder mache ich was Falsch ?
Gruss,
Franz
Bei SD habe ich keine Probleme, triitt das vlt. nur bei bestimmten Kanälen auf (nenn doch einfach mal die problematischen Kanäle).
Gruss
Macavity
Danke für die Version 0.0.9 und Deine tolle Arbeit.
Bei mir läuft noch die Revision f0b7ff1f aus dem Git, mit der ich keine Probleme mehr hatte (die grauen Zwischenbilder bei verschlüsselten HD-Sendern, die ich noch hatte, hatten mit dem Ausgabeplugin nichts zu tun).
Die 0.0.9 werde ich heute Abend mal testen.
Gruss
Macavity
Hallo Zusammen,
ich hoffe ich bin hier einigermaßen richtig.
Zuersteinmal möchte ich Thomas für sein geniales Plugin danken. 
Ich benutze dieses nun bei mehreren PI's im ganzen Haus verstreut. Die "Zentrale" ist ein Server (DELL Optiplex 740 mit 8GB RAM und 6TB Festplatte), indem 4 TV-Karten verbaut sind. Der ist die Schaltzentrale für alle VDR-Signale. Nun wollte ich einen Samsung-Fernseher mit HDMI-Eingang mit dem PI verbinden auf dem gemäß der Anleitung "Raspbian VDR Streaming Client mittels Stremdev und rpihddevice" auf vdr-wiki.de ein Betriebssystem installiert ist. Der Monitor meldet aber "Nicht unterstützter Modus".
Also habe ich versucht über die config.txt des PI die Auflösung so einzustellen, dass der Monitor damit zurecht kommt. Er kann nämlich "nur" 720p (Details zum Monitor findet ihr hier). Aber alle Versuche über die config.txt haben lediglich die Auflösung beim Starten verändert. Sobald der VDR startet kommt ein schwarzer Bildschirm und der Fernseher meint "Nicht unterstützter Modus".
Kann mir hier jemand einen Tipp geben was ich einstellen muss? Habe ich mit der Config.txt an der falschen Stelle versucht die Einstellungen zu ändern?
Der gleiche PI an einen BENQ angeschlossen läuft bestens.
Vielen Dank ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Gruß
Oliver
Er kann nämlich "nur" 720p
nativ,
als Eingangsformat könnte er auch 1080i ( laut deinem Chiplink) Du könntest mal auf der Konsole mit :
/opt/vc/bin/tvservice -m CEADir die vom Monitor unterstützten Formate anzeigen lassen
mein Beispiel:
root@pi:~# /opt/vc/bin/tvservice -m CEA
Group CEA has 16 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
(native) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
(prefer) mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressivewenn Mode 19 bsw. bei Dir dabei ist, könntest Du den dann auf der Konsole vor dem VDR Start mitgeben:
/opt/vc/bin/tvservice -e "CEA 19"Dann sollte die Ausgabe auf 720p laufen
PS: Bei weiteren Fragen solltest Du dann besser einen eigenen Thread aufmachen
Hallo,
zunächst mal ein dickes Danke an reufer für dieses großartige Projekt. Läuft bei mir bis auf ein Problem super.
Leider habe ich aber in unregelmäßigen Abständen kurze Tonaussetzer von 2-3 Sekunden. Im syslog ist dazu nichts zu sehen, obwohl es anfangs ein paar Buffer stalls gibt. Top zeigt eine CPU-Auslastung bei HD-Sendern über streamdev von 10-15% und eine Speicherbelegung von etwa 17%.
Mein Raspi ist übrigens ein nicht übertaktetes Modell B aus der ersten Serie (also nur 256 MB).
Hatte jemand ähnliche Probleme und eine Lösung gefunden?
Gruß, Dennis
check mal das netzteil
80% der steckernetzteile sind mist (meiner meinung)
wenn das ding nicht genug strom bekommt läuft es auch mies
Könnte schon sein, dass es etwas wenig Ampere bietet.
Hatte bisher dieses dran: http://www.conrad.de/ce/de/product/646800/USB-Ladegeraet-Steckdose-Goobay-46554-Micro-USB-1-x-1000-mA/?ref=detview1&rt=detview1&rb=1
Habe jetzt testweise mal ein Blackberry-Netzteil dran gehabt, dass aber sogar nur 700mA hat. Gefühlt waren es deutlich weniger Aussetzer, kann aber Zufall sein.
Ich würde jetzt mal dieses bestellen: http://www.conrad.de/ce/de/product/406348/USB-Ladegeraet-Steckdose-HN-Power-HNP10I-MicroUSB-C-Micro-USB-1-x-2000-mA/?ref=detview1&rt=detview1&rb=1
Oder kannst Du ein bestimmtes empfehlen?
viele liefern nur einen bruchteil von dem was draufsteht
ab 2000mAh sollte es aber gut gehen
bei mir hängt das cubieboard und der pi gemeinsam an einer 60w picopsu
Hi Dennis
Leider habe ich aber in unregelmäßigen Abständen kurze Tonaussetzer von 2-3 Sekunden. Im syslog ist dazu nichts zu sehen, obwohl es anfangs ein paar Buffer stalls gibt. Top zeigt eine CPU-Auslastung bei HD-Sendern über streamdev von 10-15% und eine Speicherbelegung von etwa 17%.
Stimmt die Wiederholrate des HDMI Ports mit der des Materials (wahrscheinlich 50Hz) überein? Ich glaube, solche Probleme können auftreten, wenn ein z.B. PC-Monitor mit 60Hz benutzt wird, habe das allerdings noch nicht genau untersucht.
Gruss
Thomas
Ja, die Frequenz müsste eigentlich passen. Das Material ist 720p und 1080i per Sat. Der Pi hängt am AVR oder direkt am TV.
Don’t have an account yet? Register yourself now and be a part of our community!
