Na endlich ein Update
Sitze schon die ganze Zeit auf heißen Kohlen
Werd's gleich mal kompilieren und testen.
Na endlich ein Update
Sitze schon die ganze Zeit auf heißen Kohlen
Werd's gleich mal kompilieren und testen.
Irgendwie hört sich das am analogen Ausgang mit mpeg-Ton jetzt wie Donald Duck mit Presslufthammer im Hintergrund an...
Oct 14 23:14:02 archberry vdr[1698]: [30B blob data]
Oct 14 23:14:02 archberry vdr[1698]: [1698] rpihddevice: set clock scale to 1,00 (65536)
Oct 14 23:14:02 archberry vdr[1698]: [1698] rpihddevice: SetPlayMode(Audio/Video)
Oct 14 23:14:02 archberry vdr[1698]: [1736] rpihddevice: SetClockState(eClockStateWaitForAudioVideo)
Oct 14 23:14:02 archberry systemd[1]: Started Video Disk Recorder.
Oct 14 23:14:03 archberry vdr[1698]: [1736] rpihddevice: set audio codec to MPG with 2 channels, 48000Hz
Oct 14 23:14:03 archberry vdr[1698]: [1736] rpihddevice: set analog audio output format to PCM stereo
Oct 14 23:14:03 archberry vdr[1698]: [1736] rpihddevice: set video codec to MPEG2!
Oct 14 23:14:03 archberry vdr[1698]: [1712] rpihddevice: decoding video 720x576i
https://dl.dropboxusercontent.com/u/960809/Raspb…erry_analog.mp3
Bei digital-Ton ist es eher ein MG:
Oct 14 23:22:21 archberry vdr[1698]: [1736] cStreamdevDevice::GetTSPacket(): disconnected
Oct 14 23:22:21 archberry vdr[1698]: [57B blob data]
Oct 14 23:22:26 archberry vdr[1698]: [1734] cStreamdevFilters::Action(): stream disconnected ?
Oct 14 23:22:36 archberry vdr[1698]: [1698] switching to channel 2
Oct 14 23:22:37 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:42 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:42 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:43 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:43 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:43 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:43 archberry vdr[1698]: [ac3 @ 0x180ce20] frame sync error
Oct 14 23:22:43 archberry vdr[1698]: [eac3 @ 0x180bca0] frame sync error
Oct 14 23:22:43 archberry vdr[1698]: [dca @ 0x186e830] Not a valid DCA frame
Oct 14 23:22:43 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:43 archberry vdr[1698]: [1802] rpihddevice: set audio codec to AC3 with 6 channels, 48000Hz
Oct 14 23:22:43 archberry vdr[1698]: [1802] rpihddevice: set analog audio output format to PCM stereo
Oct 14 23:22:48 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:48 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:48 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:48 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [1802] rpihddevice: Clear()
Oct 14 23:22:49 archberry vdr[1698]: [1802] ERROR: TS packet not accepted in Transfer Mode
Oct 14 23:22:49 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:49 archberry vdr[1698]: [ac3 @ 0x180ce20] frame sync error
Oct 14 23:22:49 archberry vdr[1698]: [eac3 @ 0x180bca0] frame sync error
Oct 14 23:22:49 archberry vdr[1698]: [dca @ 0x186e830] Not a valid DCA frame
Oct 14 23:22:50 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:50 archberry vdr[1698]: [1802] rpihddevice: set audio codec to AC3 with 6 channels, 48000Hz
Oct 14 23:22:50 archberry vdr[1698]: [1802] rpihddevice: set analog audio output format to PCM stereo
Display More
https://dl.dropboxusercontent.com/u/960809/Raspberry/DD2.0.mp3
Also wenn ich im Setup das durchreichen des Digitaltons abstelle ist der Ton gut. Wenn man die Funktion jedoch aktiviert sind die Beispiele von seahawk1986 in Bezug auf die Tonqualität schon sehr passend.
Also wenn ich im Setup das durchreichen des Digitaltons abstelle ist der Ton gut. Wenn man die Funktion jedoch aktiviert sind die Beispiele von seahawk1986 in Bezug auf die Tonqualität schon sehr passend.
Hmm... Also das kann ich nicht nachvollziehen. Scheint ja sowohl die Ausgabe über HDMI wie auch über den Analogausgang zu betreffen.
Ich teste mit ProSieben und SRF1 HD und benutze media-video/libav-0.8.7. Ich habe auch keine solchen Meldungen im Log:
Oct 14 23:22:43 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Oct 14 23:22:43 archberry vdr[1698]: [ac3 @ 0x180ce20] frame sync error
Oct 14 23:22:43 archberry vdr[1698]: [eac3 @ 0x180bca0] frame sync error
Oct 14 23:22:43 archberry vdr[1698]: [dca @ 0x186e830] Not a valid DCA frame
Oct 14 23:22:43 archberry vdr[1698]: [mp3 @ 0x180ca50] Header missing
Diese Meldungen kommen sicher vom Durchtesten der einzelnen Codecs, wobei mp3 hier komischerweise zweimal auftaucht...
Edit: Ich habe gerade gesehen, dass Marten im vompclient jeweils das flag CODEC_FLAG_TRUNCATED setzt - könnte das der Grund sein? Ich war der Ansicht dass dies nicht nötig sei, da ich ja ganze PES Pakete bearbeite...
Gruss
Thomas
Angenommen ich habe schon mal kompiliert aber im laufe der Jahre den Faden verloren, wo lese ich mich am Besten schlau wenn ich hier mitmachen möchte?
Quote" Statt die Audiodaten von Hand zu analysieren, teste ich einfach alle verfügbaren Deocder durch. Wenn einer mit den Daten was afangen kann -> voilà. Spricht etwas gegen dieses Konzept?
Ja das spricht etwas dagegen, nicht immer ist der Beginn des Audiopackets am Anfang des PES Packets. Man muss daher einen Parser dazwischenschalten der die Framegrenzen des jeweiligen Formats findet.
Sagt vdr dem devices nicht den Typ der Audiodaten? Wenn ja würde ich die Information verwenden.
Quote
Ich öffne gleich zu Begin in cAudioDecoder::Init() alle Codecs. Spricht performancemässig etwas dagegen, diese "offen" zu halten?
Nein, da spricht nichts dagegen. Die Performance sollte eher besser werden dadurch.
QuoteAAC und DTS konnte ich mangels Testmaterial nicht testen. Wenn mir hier jemand ein paar Ausschnitte zur Verfügung stellen könnte, wäre das sehr fein.
Die gibt es im deutschsprachigen Raum nicht. AAC wird in Großbritanien verwendet und DTS in den nordischen Ländern.
QuoteFür DTS und MPEG audio pass-through bin ich mir nicht sicher, ob die OMX-Parameter passen. Ich habe auch keine Beispiele im Netz gefunden, sowohl der vompclient wie auch der omxplayer unterstützen dies nicht."
Hier sollte erstmal herausgefunden werden, ob die angeschlossenen Geräte das unterstützen. Mpeg audio geht wahrscheinlich nicht, ich hatte nichts gefunden. Aber bei beiden gilt, mein Fernseher setzt die HDMI Signale nicht auf SPDIF um, daher konnte ich das nicht testen und daher habe ich es nicht in vomp implementiert.
QuoteDiese Meldungen kommen sicher vom Durchtesten der einzelnen Codecs, wobei mp3 hier komischerweise zweimal auftaucht...
Edit: Ich habe gerade gesehen, dass Marten im vompclient jeweils das flag CODEC_FLAG_TRUNCATED setzt - könnte das der Grund sein? Ich war der Ansicht dass dies nicht nötig sei, da ich ja ganze PES Pakete bearbeite...
Leider machen das viele Sender sehr unterschiedlich. Die Audiopackete sind teilweise sehr zerstückelt über viele Pakete verteilt bei einige Sendern. Ich habe da es den unterschiedlichsten Ländern jeweils andere Aufteilungen gesehen. Daher ist der Code auch so komplex geworden.
Marten
Also was ich gerade positiv festgestellt habe ist das der Ton bei kurzen Bildrucklern sehr schön synchron bleibt
Beim 0.0.3 reicht ein kurzes ruckeln um den Ton völlig aus der Bahn zu werden. Sehr schön.
Auch Aufnahmen werden jetzt synchron wiedergegeben.
Hi Marten
Zitat
" Statt die Audiodaten von Hand zu analysieren, teste ich einfach alle verfügbaren Deocder durch. Wenn einer mit den Daten was afangen kann -> voilà. Spricht etwas gegen dieses Konzept?
Ja das spricht etwas dagegen, nicht immer ist der Beginn des Audiopackets am Anfang des PES Packets. Man muss daher einen Parser dazwischenschalten der die Framegrenzen des jeweiligen Formats findet.
Sagt vdr dem devices nicht den Typ der Audiodaten? Wenn ja würde ich die Information verwenden.
Vielen Dank für den Hinweis! Der VDR gibt zwar eine Id mit, aber was die genau bedeutet ist nirgens richtig dokumentiert. Oder ich war einfach zu doof zum suchen... Werde mir aber dazu nochmals den Code vom SoftHdDevice anschauen.
Kann es sein, dass sich hier die libav und ffmpeg anders verhalten? Für mich ist dieses Gebiet recht neu, und ich habe mich für die libav entschieden, weil ich die problemlos unter Gentoo überskreuzkompillieren konnte...
Die gibt es im deutschsprachigen Raum nicht. AAC wird in Großbritanien verwendet und DTS in den nordischen Ländern.
Alles klar, das wusste ich nicht.
Hier sollte erstmal herausgefunden werden, ob die angeschlossenen Geräte das unterstützen. Mpeg audio geht wahrscheinlich nicht, ich hatte nichts gefunden. Aber bei beiden gilt, mein Fernseher setzt die HDMI Signale nicht auf SPDIF um, daher konnte ich das nicht testen und daher habe ich es nicht in vomp implementiert.
Das mache ich, und zwar in cRpiSetup::IsAudioFormatSupported() - mein Receiver erlaubt hier PCM und AC3 (von dem was ich bisher testen konnte), MPEG akzeptiert er nicht, weshalb hier auf dem Rpi decodiert wird.
Leider machen das viele Sender sehr unterschiedlich. Die Audiopackete sind teilweise sehr zerstückelt über viele Pakete verteilt bei einige Sendern. Ich habe da es den unterschiedlichsten Ländern jeweils andere Aufteilungen gesehen. Daher ist der Code auch so komplex geworden.
Ok, in dem Fall muss ich wohl die "Reste" zwischenspeichern, so wie es auch das SoftHdDevice macht...
Gruss
Thomas
Angenommen ich habe schon mal kompiliert aber im laufe der Jahre den Faden verloren, wo lese ich mich am Besten schlau wenn ich hier mitmachen möchte?
Hi rollercontainer,
das wird genau wie jedes andere VDR Plugin gebaut. Ist also nichts besonderes zu beachten.
Claus
also ist auf dem rp vdr zu "installieren"?
Natürlich. Das ist ja der Sinn der ganzen Aktion.
das wird genau wie jedes andere VDR Plugin gebaut. Ist also nichts besonderes zu beachten.
Danke für deinen Versuch, aber das beantwortet nicht meine Frage. Ich stehe hier mit einem nackten wheezy und weiß nicht so recht wie ich weitermachen muss.
Stichwörter würden mir schon reichen.
Ich habe das erst letzte Woche gemacht, ist ganz einfach:
1. die source repositories für apt-get hinzufügen (/etc/apt/sources.d/*)
2. "apt-get install build-essential" und "apt-get build-dep vdr"
3. vdr sources besorgen und auspacken, ich habe die developer version direkt von Klaus gezogen
4. die Plugins für streamdev und rpihddevice einspielen und die Versionnummern der directories entfernen
5. im VDR directory einfach ein "make", dann u.U. ein "make plugins" und dann ein "make install"
6. vdr starten
Viele Erfolg, ollo
Danke für die Starthilfe!
Was bei mir noch nachinstalliert werden musste: libavformat-dev und libavcodec-dev.
Damit baut er schonmal ohne Fehler.
Edit:
Dachte ich. Es kommt zwar kein Fehler, aber auch kein rpi-Plugin raus.
Hi Marten
Ich muss da nochmals nachhaken....
Ja das spricht etwas dagegen, nicht immer ist der Beginn des Audiopackets am Anfang des PES Packets. Man muss daher einen Parser dazwischenschalten der die Framegrenzen des jeweiligen Formats findet.
Sagt vdr dem devices nicht den Typ der Audiodaten? Wenn ja würde ich die Information verwenden.
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.
Zusammen mit dem Flag CODEC_FLAG_TRUNCATED und dem Zwischenspeichern der Restdaten sollte das doch eigentlich immer funktionieren... oder?
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.
@Alle: Bei Audioproblemen wäre für mich hilfreich zu wissen, um welche Kanäle es sich handelt und welche avlib ihr verwendet, damit ich das Problem nachstellen kann.
Gruss
Thomas
@Alle: Bei Audioproblemen wäre für mich hilfreich zu wissen, um welche Kanäle es sich handelt und welche avlib ihr verwendet, damit ich das Problem nachstellen kann.
Ich nutze ffmpeg 2.0.2 unter Arch Linux ARM. Die Soundprobleme habe ich auf allen Kanälen (Empfang über Kabel D) - wenn es dir hilft, kann ich dir gerne eine Aufnahme zukommen lassen.
Ich nutze ffmpeg 2.0.2 unter Arch Linux ARM. Die Soundprobleme habe ich auf allen Kanälen (Empfang über Kabel D) - wenn es dir hilft, kann ich dir gerne eine Aufnahme zukommen lassen.
Danke für die Info - ich werde es mal mit ffmpeg versuchen. Aber bei Bedarf komme ich gerne auf Dein Angebot zurück!
BTW: Bei Gentoo ist ffmpeg-2.0.x hard masked: http://packages.gentoo.org/package/media-video/ffmpeg
Gruss
Thomas
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.
Evtl. hilft der pes-Scanner im burn-Plugin (scanner.c) beim Analysieren.
Danke reufer fuer das neue Update.
Habe schon sehnsuechtig drauf gewartet Super arbeit die ihr hier leistet
Habe ein kleines problem beim Kompiliren der 0.0.4 variante:
In file included from /usr/include/libavutil/avutil.h:318:0,
from /usr/include/libavutil/samplefmt.h:22,
from /usr/include/libavcodec/avcodec.h:30,
from audio.h:12,
from setup.h:10,
from rpihddevice.c:12:
/usr/include/libavutil/common.h: In function 'int32_t av_clipl_int32_c(int64_t)':
/usr/include/libavutil/common.h:168:47: error: 'UINT64_C' was not declared in this scope
make: *** [rpihddevice.o] Error 1
kann mir da jemand vielleicht helfen ?
Alles auf dem aktuellen Raspbian image, vdr 1.7.28 aus dem repo.
mit der 0.0.3 hat alles geklappt.
Gruss,
Franz
Ich musste zum kompilieren
libavformat-dev
libavcodec-dev
Installieren.
Probier's mal.
Don’t have an account yet? Register yourself now and be a part of our community!