Radio-Aufnahme via Direkt ?

[klez]

Hi

Wollte mal nachfragen, ob es irgendwie möglich wäre das ganze so umzubauen, daß Neutrino im Radio Modus direkt ein mp2 Audio File aufzeichnet / schreibt. Per Direkt Recording scheint nämlich überhaupt keine reine Audio Aufzeichnung möglich zu sein :/

Immer für Radio Aufnahmen den Streaming Modus auf "Server" umzustellen kann ja auch nicht die Dauer-Lösung sein.

MfG

[Regloh]

also ein direktes mp2 bekommst du nicht. ich hab mal nen radiomitschnitt per direktaufnahme gemacht, glaube so wars:
- ts-modus ausschalten
- streamen
- ergebnis durch project x gejagt
- stream nach mp3 gewandelt
Regloh

[jmittelst]

Das man zur Direkt-Aufnahme einer Radio-Sendung den für die Aufnahme von TV nötigen TS-Modus deaktivieren muß ist ziemlich unlogisch. Könnte es dafür vielleicht eine Lösung geben? Cool wäre ein Aufnahme-Modus, der alle Radio-Sender eines Transponders in ein TS-File packt
cu
Jens

[Regloh]

soweit ich mich erinnere gab es diese diskussion schon mal.
es geht wohl einfach nicht mit direktaufnahme. deshalb ts modus für die radioaufnahme abschalten.
Regloh

[petgun]

Hi,
doch es funktioniert auch wenn die TS-Treiber geaden sind....Direktaufnahme starten und auf einen anderen Radiokanal des gleichen Transponders schalten und verweilen, dann funktioniert es. Ich find's auch schade dass es ohne diese Verrenkung nicht klappt und es ist sicher fuer die Entwickler nur eine Kleinigkeit, dass zu fixen.

cu,
peter

[Npq]

Das man zur Direkt-Aufnahme einer Radio-Sendung den für die Aufnahme von TV nötigen TS-Modus deaktivieren muß ist ziemlich unlogisch.

Nein, es ist sehr logisch, wirf einen Blick in die Sourcen oder lies (nochmal) was ich damals in deinem Thread dazu geschrieben habe.

Der SPTS-Modus ist für den Demux als Hack realisiert (weil das gesamte Treiber-Design auf DualPES ausgelegt war). Radio paßt nicht in die Bedingung, die dieser Hack stellt.

http://forum.tuxbox-cvs.sourceforge.net ... hp?t=31350

[petgun]

hi,

Nein, es ist sehr logisch...

..also leben wir weiter mit dem oben beschriebenen Wuergaround wenn wir Radio-Direktaufnahmen mit geladenem SPTS-Treiber machen wollen da alles so ist wie es sein soll und der SPTS-Modus ein (quick and dirty?) 'Hack' ist an dem keiner von den Entwicklern was aendern wird?
Fuer mich pers. ist der SPTS-Modus das Beste an der Box...ich kann aufnehmen _ohne_ das ich ein weiteres Programm benoetige und kann auch noch ein beliebiges Programm auf dem gleichen Transponder waehrend der Aufnahme schauen.

cu,
peter

[klez]

Bedeutet das jetzt, daß das ganze unmöglich oder einfach nur zuviel Aufwand ist, so das es keiner realisieren will ?

Ich war noch nie ein Fan von Workarounds (auch wenn es letztendlich funktioniert).
Habe auch den anderen Thread gelesen. Wenn ich das ganze richtig verstanden habe, müsste lediglich der Treiber entsprechend angepasst werden (Auch wenn das nicht so einfach zu sein scheint).

Ich selbst kann zwar auch C / C++ und würde mir das ganze mal ansehen... Doch leider habe ich damals schon gemerkt das es für "nicht Insider" unheimlich schwer ist sich in das Thema einzuarbeiten. Die gesamte Architektur und Aufbau der einzelnen Komponenten in der Dbox ist mir nämlich nicht 100% bekannt und eine vernünftige Doku habe ich auch noch nicht gefunden.
Würde es trotzdem gerne mal anschauen und versuchen zu verstehen. Diesen Aufwand scheue ich nicht...

P.S.: Wo seid ihr mittlerweile eigentlich im IRC vertreten ?
P.P.S.: Wenn ich mir die Aufrufe dieses Threads nach 1 Tag so ansehe, dann scheint das Interesse auch nicht wenig zu sein...

[petgun]

Hi,

Würde es trotzdem gerne mal anschauen und versuchen zu verstehen. Diesen Aufwand scheue ich nicht..

super! Ich wuensche Dir viel Erfolg dabei...und wenn Du schon mal dabei bist, kannst Du Dir vielleich auch mal die fehlenden PMT/PAT beim Neutrino-TS Stream anschauen...

cu,
peter

[Npq]

Ich war noch nie ein Fan von Workarounds (auch wenn es letztendlich funktioniert).
Habe auch den anderen Thread gelesen. Wenn ich das ganze richtig verstanden habe, müsste lediglich der Treiber entsprechend angepasst werden (Auch wenn das nicht so einfach zu sein scheint).

Das Problem ist auch nicht einfach zu verstehen, ich habe damals mehrere Stunden gebraucht, bis ich die Zusammenhänge verstanden habe, ich hatte auch keinen, den ich fragen konnte. So schlimm ist es nicht, nur eben relativ komplex.

Ok, ihr wolltet es so:

Das ist der Hack (avia_gt_ucode.c):

Code: Alles auswählen

	/* Special case for SPTS audio queue */
	if ((queue_nr == AVIA_GT_DMX_QUEUE_AUDIO) && (type == TS))
		target_queue_nr = AVIA_GT_DMX_QUEUE_VIDEO;
	else
		target_queue_nr = queue_nr;

Der Demux hat drei feste Queues für Video, Audio und Teletext (das sind die Puffer im Speicher wo die Daten reingeschrieben werden). Der Avia liest die Daten dann direkt aus diesen Queues aus (ohne Zutun der CPU per DMA).

Es gibt 32 queues. Setzt man eine PID, so wird automatisch entweder eine der 3 System-Queues (falls Video/Audio/Teletext) oder eine der andere 29 Queues ausgewählt. Streamt man von den Systemqueues, so wird zwar auch eine der 29 Queues gesetzt aber in der bottom half des IRQs wird dann nachgesehen, ob eine der 3 Systemqueues eine PID der 29 Queues hat und entsprechend umgeschaufelt.

Bei SPTS wird nun beim Setzen der PID im ucode-RAM geprüft ob der SPTS-Modus aktiv ist. In dem Fall wird statt der eigentlich vorgesehenen Audio-Queue dann ucode-intern die Video-Queue genommen. Beim Avia kommt somit Video/Audio zusammen in einer Queue an und er ist happy. Damit es vom Platz her paßt, wird die Queue erweitert.

Beim Streamen wird dann zwar Video- und Audio-PID gesetzt, aber über die Video-PID kommen beide Daten an, so daß im Endeffekt beide Ströme wie erwartet zusammen auftreten. Daß theoretisch nur die Video-PID schon das erwünschte Ergebnis liefert spielt keine Rolle.

So, im Radio-Modus kommt nun aber das Problem, daß nur die Audio-PID gesetzt wird. Der Radio-Modus ist ein Betrieb ohne Video-PID.

In diesem Falle landen die Audio-Daten aber nach wie vor in der Video-Systemqueue. Der Avia liest sie ja auch von dort weil es für ihn eine Queue ist wo Audio und Video auftreten dürfen. Will man aber nun streamen, so wird nur für die Audio-Queue der IRQ-Callback eingeschaltet. Daher löst er nie aus (die Audio-Queue bleibt ja leer).

Es gibt in dem Fall für die Video-Queue keine PID, also kann man sie nicht setzen.

Jetzt kommt noch erschwerend hinzu, daß
a) das Setzen asynchron geschieht (sprich, man kann nicht wissen, ob die Audio-PID nun irgendwann mal von der Video-PID gefolgt wird oder ob nie eine Video-PID kommt).
b) man ja auch umschalten können soll, beim Übergang aber weitergestreamt werden soll.

Der Treiber darf dem Benutzer keine Policy aufzwingen, es muß also egal sein, ob ich zuerst Video, dann Audio, oder erst Audio, dann Video setze bzw. zurücksetze. Es soll immer das Richtige[TM] geschehen.

Ich habe das damals recht lange probiert und irgendwo ging immer was schief. Es ließ sich nicht befriedigend lösen ohne den bisherigen Ansatz des "eine PID = eine Queue" zu ändern.

P.S.: Wo seid ihr mittlerweile eigentlich im IRC vertreten ?

#dbox2dev im ircnet

Aber ich bin da selten in letzter Zeit, habe momentan keine Zeit fürs dbox2-Programmieren selber übrig. Leider gilt das Zeitproblem scheinbar auch für alle anderen treiberbewanderten.

[klez]

Erstmal vielen Dank für die ausführliche Erklärung. Auch wenn ich diesbezüglich noch 1-2 Fragen hätte.

Was verstehst du unter PID setzen ?
Ich dachte die Audio / Video PID ist im TS Strom enthalten ?

Und warum braucht der Avia Video und Audio in EINER Queue ?
Ich dachte der Demux trennt die einzelnen Ströme eines TS und führt diese einzeln zum Avia ?

P.S.: Ich glaube ich brauch laaange um das zu blicken

[Npq]

PID setzen heißt, die Linux DVB-API fordert eine neue PID an und der Ucode-Teil vom Demux setzt im ucode die entsprechenden Parameter, damit der Demux-RISC aus dem Gesamt-TS nur die Daten mit dieser PID herausfiltert.

Der Userspace kommuniziert mit den jeweiligen /dev/dvb-Devices. Der Demux-Treiber kommuniziert aber nicht mit dem Userspace direkt sondern mit der NAPI-Schicht (eigentlich NokiaAPI, da kommt die Linux DVB-API nämlich ursprünglich her).

Es gibt dort ein Demux-Device, darüber setzt man die PIDs.

Um TS oder PES vom laufenden Programm zu bekommen mußt du aber aus dem DVR-Device lesen (da kann man auch reinschreiben, das macht der Movieplayer). Außerdem muß man die PIDs als Tap-Feed setzen, da sie ja schon für den Dekoder gefiltert werden.

Auswertung der PIDs muß aber die Anwendung machen, in diesem Fall zapit/neutrino. Schließlich entscheidet die welche sie haben will, gibt ja mehrere Dienste pro TS. Deshalb gibt sie auch die PIDs vor.

Und SPTS = Single Program Transport Stream, der Avia erwartet die Daten in einer Queue. Wieso die so einen seltsamen Modus erfunden haben kann ich dir nicht beantworten (theoretisch hätten die ja auch einen DualTS machen können, dann hätten wir die Probleme nicht, wenn wir die Dokumentation zum RISC hätten ginge das evtl. sogar, wer weiß... )