[ANNOUNCE] VDR developer version 1.7.1

Hallo,

erstmal Danke für die neue Version.

Lese ich richtig, dass schon im TS Format aufgezeichnet wird ?

Viele Grüße cHrIsZ

@ Klaus (in der Hoffnung, dass Du hier mal reinschaust )

ich habe vdr-1.7.1 mit dem API-wrapper von Udo kompiliert und getestet, ob mein pvr350-(Ausgabe)-Plugin damit noch läuft. Es kompiliert auch, aber ich habe bei Live-TV keinen Ton und am unteren Bildrand sind Artefakte. Die Funktion PlayAudio meines Plugins liefert die Fehlermeldung:

pvr350: 16:32:33 pvr350: PlayAudio unknown audio format, Id=0x00

Die Wiedergabe von vorhandenen Altaufzeichnungen klappt einwandfrei.

Muss ich eventuell wie in dvddevice.c die Funktionen PlayTsVideo() und PlayTsAudio() implementieren?

+int cDvbDevice::PlayTsVideo(const uchar *Data, int Length)
+{
+  Length = TsGetPayload(&Data);
+  return PlayVideo(Data, Length);
+}
+
+int cDvbDevice::PlayTsAudio(const uchar *Data, int Length)
+{
+  Length = TsGetPayload(&Data);
+  return PlayAudio(Data, Length, 0);
+}

Ich hoffe, dass vdr auch weiterhin mit Ausgabegeräten verwandt werden kann, die kein TS sodnern nur PES wiedergeben können.

Zitat

Originally posted by Dr. Seltsam
@ Klaus (in der Hoffnung, dass Du hier mal reinschaust )

ich habe vdr-1.7.1 mit dem API-wrapper von Udo kompiliert und getestet, ob mein pvr350-(Ausgabe)-Plugin damit noch läuft. Es kompiliert auch, aber ich habe bei Live-TV keinen Ton und am unteren Bildrand sind Artefakte. Die Funktion PlayAudio meines Plugins liefert die Fehlermeldung:

Code

pvr350: 16:32:33 pvr350: PlayAudio unknown audio format, Id=0x00

Die Wiedergabe von vorhandenen Altaufzeichnungen klappt einwandfrei.

Muss ich eventuell wie in dvddevice.c die Funktionen PlayTsVideo() und PlayTsAudio() implementieren?

Alles anzeigen

cDevice implementiert selber eine Default-Version von PlayTsVideo() bzw. PlayTsAudio().
Allerdings ist dort die frühere "Id" nicht mehr bekannt, und wird daher auf 0 gesetzt.
Anscheinend habe ich übersehen, das zu dokumentieren...

Zitat

Ich hoffe, dass vdr auch weiterhin mit Ausgabegeräten verwandt werden kann, die kein TS sodnern nur PES wiedergeben können.

Sollte gehen, denn die FF-Karten können es ja auch (wenn auch noch mit kleinen Störungen, aber ich hoffe mal, daß wir das noch in den Griff kriegen).

Klaus

Zitat

Original von kls
cDevice implementiert selber eine Default-Version von PlayTsVideo() bzw. PlayTsAudio().
Allerdings ist dort die frühere "Id" nicht mehr bekannt, und wird daher auf 0 gesetzt.
Anscheinend habe ich übersehen, das zu dokumentieren...

wie heilt man das? (nicht die fehlende Doku, sondern dass die Id jetzt immer 0 ist)

Zitat

Original von Dr. Seltsam

wie heilt man das? (nicht die fehlende Doku, sondern dass die Id jetzt immer 0 ist)

Was für eine Id ist das? Die "Stream ID" des PES-Headers?

CU
Oliver

das ist die PES-Stream-ID und entspricht der Id in

PlayAudio(const uchar *Data, int Length, uchar Id)

Wenn ich 0x00 der Behandlung für MPEG-Audio gleichsetze, habe ich auch wieder Ton.

In Verbindung mit dem pvrinput-Plugin, dass MPEG-Audio liefert, kommt es aber zu Fehlermeldungen
"PlayAudio(): PES Packet seems to be corrupted"

Der betreffende Code ist nicht von mir, so ganz blicke ich mit dem Aufbau der PES-Pakete nicht durch. Ich poste mal die komplette Funktion, die bis einschließlich vdr 1.7.0 einwandfrei funktioniert:

int cPvr350Device::PlayAudio(const uchar *Data, int Length, uchar Id)
{
	int PESHeader_len;
	uint8_t *PESPacketData;
	int PESPacketData_len;
	int PES_Packet_Length;
	int len;
	static uchar Last_Id = 0;


	log(pvrDEBUG2, "cPvr350Device::PlayAudio()");


	if (Id != Last_Id) {
		Last_Id = Id;
		log(pvrDEBUG1, "cPvr350Device::PlayAudio(): Length=%d, Id=0x%02x", Length, Id);
	}


	/*
	 * PES Packet Length:	Specifies the number of bytes remaining
	 * 			in the packet after this field.
	 */
	len = Data[PESPACKETLEN1];
	PES_Packet_Length = (len << 8) + Data[PESPACKETLEN2];
	PES_Packet_Length += PESPACKETLEN2 + 1;
	if (Length != PES_Packet_Length) {
		log(pvrERROR, "cPvr350Device::PlayAudio(): PES Packet seems to be corrupted");
		log(pvrDEBUG1, "cPvr350Device::PlayAudio():Length=%d, len=%d, Id=0x%02x", Length, PES_Packet_Length, Id);
	}


	PESHeader_len = Data[PESHEADERLENGTH] + PESFIXHEADERLEN;
#ifdef DEBUG
	if (Length <= PESHeader_len) {
		log(pvrDEBUG1, "cPvr350Device::PlayAudio():Length=%d <= PESHeader_len=%d", Length, PESHeader_len);
		return Length;
	}
#endif
	PESPacketData = (uint8_t *)&Data[PESHeader_len];
	PESPacketData_len = Length - PESHeader_len;


	switch (Id) {
	case 0x80 ... 0x87 :		// AC3
		if (!m_AC3toMP2Init) {
			// Create a new decode/encode audio thread
			m_AC3toMP2 = new cAC3toMP2(m_AC3DecodeStatePtr, Pvr350Setup.AC3Gain);
			m_AC3toMP2Init = true;
		}


		ProcessAC3Audio((uint8_t *)Data, PESHeader_len, Length);


		len = Length;	// Return success to VDR
		break;


	case 0xA0 ... 0xA7 :		// LPCM
		if (!m_AC3toMP2Init) {
			// Create a new decode/encode audio thread
			m_AC3toMP2 = new cAC3toMP2(m_AC3DecodeStatePtr, Pvr350Setup.AC3Gain);
			m_AC3toMP2Init = true;
		}


		// ToDo: PCM to MP2 conversion


		len = Length;	// Return success to VDR
		break;


	case 0xC0 ... 0xDF :		// MP2
	case 0x00:			// assume MP2
		if (m_AC3toMP2Init) {
			// Delete decode/encode audio thread
			delete m_AC3toMP2;
			m_AC3toMP2Init = false;
		}


		len = WriteAllOrNothing(fd_out, Data, Length, 1000, 10);
		if (len <= 0) {
			log(pvrERROR, "pvr350: PlayAudio[MP2] written=%d error=%d", len, errno);
		}
		break;


	default:
		log(pvrERROR, "pvr350: PlayAudio unknown audio format, Id=0x%02x", Id);
		len = Length;	// Return success to VDR
		break;
	}
	return len;
}

Zitat

Original von Dr. Seltsam
das ist die PES-Stream-ID und entspricht der Id in

Code

PlayAudio(const uchar *Data, int Length, uchar Id)

Wenn ich 0x00 der Behandlung für MPEG-Audio gleichsetze, habe ich auch wieder Ton.

Das ist offenbar ein Fehler in VDR. Wenn man PES-Pakete bastelt, sollte man ihnen eine sinnvolle Stream ID geben. Z.B. also:

0xBD  Dolby Digital (Private Stream 1)
0xC0  MPEG audio
0xE0  MPEG video

CU
Oliver

Zitat

Originally posted by UFO
Das ist offenbar ein Fehler in VDR. Wenn man PES-Pakete bastelt, sollte man ihnen eine sinnvolle Stream ID geben. Z.B. also:

Code

0xBD  Dolby Digital (Private Stream 1)
0xC0  MPEG audio
0xE0  MPEG video

VDR entfernt lediglich den TS Header und faßt die Payload zusammen. Er schaut da nicht groß "rein".

Oder wie meinst du das?

Klaus

Zitat

Original von kls

VDR entfernt lediglich den TS Header und faßt die Payload zusammen. Er schaut da nicht groß "rein".

Oder wie meinst du das?

Na ja, der Payload muß doch wohl ein PES-Header vorangestellt werden. Oder sehe ich das falsch?

CU
Oliver

Ist es eigentlich angedacht das man den VDR z.B. mit einer eHD auch ohne Patches verwenden kann?

Zitat

Originally posted by UFO
Na ja, der Payload muß doch wohl ein PES-Header vorangestellt werden. Oder sehe ich das falsch?

Also soweit ich das sehe erhält man, wenn man eine Sequenz von TS-Paketen nimmt, bei denen das erste das "payload start" Flag gesetzt hat, und die bis zu dem Paket geht, auf das wieder eines mit diesem Flag folgt, jeweils den TS-Header entfernt und die restlichen Daten aneinanderhängt, jeweils ein komplettes PES-Paket. Was da genau drin ist, braucht VDR (zumindest im Transfer Mode) nicht weiter zu interessieren.

Oder sehe ich da was falsch?

Zumindest mit einer FF-Karte läßt sich das so abspielen (bis auf die kleinen Störungen, aber das wird sich ja hoffentlich noch finden lassen, woher das kommt - wenn die Diskussion über "wie soll VDR entwickelt werden" auf der ML mal abebbt und wieder tatsächlich getestet und gedebugd wird ;-).

Klaus

Zitat

Originally posted by Dr. Seltsam

wie heilt man das? (nicht die fehlende Doku, sondern dass die Id jetzt immer 0 ist)

Die Id müsste sich aus dem PES-Header ermitteln lassen (müsste aber auch erst genau nachschauen).

Klaus

Zitat

Original von kls

Also soweit ich das sehe erhält man, wenn man eine Sequenz von TS-Paketen nimmt, bei denen das erste das "payload start" Flag gesetzt hat, und die bis zu dem Paket geht, auf das wieder eines mit diesem Flag folgt, jeweils den TS-Header entfernt und die restlichen Daten aneinanderhängt, jeweils ein komplettes PES-Paket. Was da genau drin ist, braucht VDR (zumindest im Transfer Mode) nicht weiter zu interessieren.

Oder sehe ich da was falsch?

Daß vdr die Daten nicht zu interessieren braucht, ist richtig. Allerdings erwartet das video/audio-Device doch PES-Pakete, d.h. PES-Header+PES-Daten. Nicht nur PES-Daten.

Zitat

Zumindest mit einer FF-Karte läßt sich das so abspielen (bis auf die kleinen Störungen, aber das wird sich ja hoffentlich noch finden lassen, woher das kommt - wenn die Diskussion über "wie soll VDR entwickelt werden" auf der ML mal abebbt und wieder tatsächlich getestet und gedebugd wird ;-).

Evtl. liegt genau hier der Hund begraben: Wenn der Treiber nur die reinen Daten erhält, könnte es passieren, daß zufällig in den Daten eine Bytefolge vorkommt, die fälschlich als PES-Header interpretiert wird, was natürlich das Datenpaket zerstört...

Wie ist das denn bei vdr 1.6? Du reichst den PES-Header aus den Aufzeichnungen doch an das Device durch, oder?

CU
Oliver

Zitat

Originally posted by Frodo
Ist es eigentlich angedacht das man den VDR z.B. mit einer eHD auch ohne Patches verwenden kann?

Natürlich - deswegen mach' ich doch den ganzen Zinnober mit der Umstellung auf TS und so.

Klaus

Zitat

Original von UFO

Daß vdr die Daten nicht zu interessieren braucht, ist richtig. Allerdings erwartet das video/audio-Device doch PES-Pakete, d.h. PES-Header+PES-Daten. Nicht nur PES-Daten.

Evtl. liegt genau hier der Hund begraben: Wenn der Treiber nur die reinen Daten erhält, könnte es passieren, daß zufällig in den Daten eine Bytefolge vorkommt, die fälschlich als PES-Header interpretiert wird, was natürlich das Datenpaket zerstört...

Wie ist das denn bei vdr 1.6? Du reichst den PES-Header aus den Aufzeichnungen doch an das Device durch, oder?

Alles anzeigen

Korrektur:
Ist natürlich Unsinn, denn der TS-Datenstrom enthält ja komplette PES-Pakete.

Also doch Debuggen.

Dazu wäre es allerdings vorteilhaft, wenn man zwecks Reproduzierbarkeit mit TS-Aufzeichnungen arbeiten könnte.

CU
Oliver

Zitat

Originally posted by UFO

Daß vdr die Daten nicht zu interessieren braucht, ist richtig. Allerdings erwartet das video/audio-Device doch PES-Pakete, d.h. PES-Header+PES-Daten. Nicht nur PES-Daten.

Hmm, das muß ich mir nochmal näher anschauen. Danke für den Hinweis.

Zitat

Evtl. liegt genau hier der Hund begraben: Wenn der Treiber nur die reinen Daten erhält, könnte es passieren, daß zufällig in den Daten eine Bytefolge vorkommt, die fälschlich als PES-Header interpretiert wird, was natürlich das Datenpaket zerstört...

Wie ist das denn bei vdr 1.6? Du reichst den PES-Header aus den Aufzeichnungen doch an das Device durch, oder?

Stimmt, die Aufzeichnungen werden 1:1 an das Device geschickt.

Klaus

Zitat

Originally posted by UFO

Korrektur:
Ist natürlich Unsinn, denn der TS-Datenstrom enthält ja komplette PES-Pakete...

CU
Oliver

Jetzt hattest du mich schon fast überzeugt

Klaus

Zitat

Original von kls

Jetzt hattest du mich schon fast überzeugt

Sicherheitshalber habe ich dann doch noch mal im Standard nachgesehen.

CU
Oliver