Sinn und Unsinn von "emergency exit"

Zitat von johns

So ich habe leider noch 1.7.35; ist aber nicht so wichtig.

Du könntest aber einfach die Dateien transfer.[hc] aus der 1.7.36 zum Testen nehmen.

Zitat

Wenn ich jetzt in cDevice::PlayVideo bzw. cDevice::PlayAudio bzw. cDevice::PlayTsAudio
(ich meine meine abgeleitetete Klasse) die Pakete wegwerfe, wenn mein interner Puffer
voll ist, dann habe ich Artefakte bei der Wiedergabe von Aufnahmen.

Du sollst ja auch keine Pakete "wegwerfen", die du noch brauchst.
Wenn dein Puffer voll ist, dann gibt 0 zurück und es wird nochmal versucht. Allerdings musst du das Paket "zeitnah" annehmen, denn es wird nicht beliebig lange versucht. Im Normalfall solltest du das Paket sofort annehmen, daß es mal erst beim zweiten Versuch angenommen wird, sollte schon die ganz große Ausnahme sein.

Zitat

Die Ursache ist, daß cDevice::Poll nicht richtig ausgewertet wird.

In dvbplayer.c wird DevicePoll(Poller, 10); mit 10ms aufgerufen, der Return Wert aber
nicht ausgewertet.

dvbplayer.c hat doch mit dem Transfer-Mode, um den es hier geht, gar nichts zu tun!?

Zitat

Mein Ausgabedevice schläft nur 10ms und damit werden meine Internen Puffer
natürlich sehr schnell bis zum erbrechen voll.

Entweder darf ich in cDevice::Poll länger schlafen oder der VDR sollte den Rückgabewert
auswerten.

Ich glaube, du bringst hier die Wiedergabe einer Aufzeichnung und den Live-Modus durcheinander.
Wird eine Aufzeichnung wiedergegeben, dann stehen die Daten quasi beliebig schnell zur Verfügung, und es ist klar, daß der Puffer eines Ausgabedevices vollläuft. Das ist völlig normal und unschädlich.
Im Live-Modus kommen die Daten vom Sender im Mittel in der Geschwindigkeit, wie sie das Ausgabedevice verarbeiten können muß, um ein Live-Signal in Echtzeit darzustellen. Wäre das Ausgabedevice zu langsam, dann würde sein Puffer auch hier volllaufen, und eine Live-Wiedergabe wäre nicht mehr möglich.

Klaus

Zitat von kls

Du könntest aber einfach die Dateien transfer.[hc] aus der 1.7.36 zum Testen nehmen.

Habe ich inzwischen gemacht. Funktioniert.

Zitat

Du sollst ja auch keine Pakete "wegwerfen", die du noch brauchst.
Wenn dein Puffer voll ist, dann gibt 0 zurück und es wird nochmal versucht. Allerdings musst du das Paket "zeitnah" annehmen, denn es wird nicht beliebig lange versucht. Im Normalfall solltest du das Paket sofort annehmen, daß es mal erst beim zweiten Versuch angenommen wird, sollte schon die ganz große Ausnahme sein.

dvbplayer.c hat doch mit dem Transfer-Mode, um den es hier geht, gar nichts zu tun!?

Ich glaube, du bringst hier die Wiedergabe einer Aufzeichnung und den Live-Modus durcheinander.
Wird eine Aufzeichnung wiedergegeben, dann stehen die Daten quasi beliebig schnell zur Verfügung, und es ist klar, daß der Puffer eines Ausgabedevices vollläuft. Das ist völlig normal und unschädlich.
Im Live-Modus kommen die Daten vom Sender im Mittel in der Geschwindigkeit, wie sie das Ausgabedevice verarbeiten können muß, um ein Live-Signal in Echtzeit darzustellen. Wäre das Ausgabedevice zu langsam, dann würde sein Puffer auch hier volllaufen, und eine Live-Wiedergabe wäre nicht mehr möglich.

Alles anzeigen

Mir ist schon klar das es hier um Transfermodus geht und das die Wiedergabe von Aufnahmen
über eine andere Funktion gehen.

Im Laufe dieses Thread war ich der Meinung, daß ein Ausgabe Plugin Pakete wegwerfen darf,
wenn seine Ausgabepuffer voll sind. Und diese Meinung ist und war falsch.

Ein Ausgabeplugin muß die Pakete sofort annehmen oder ablehnen.
Es darf selbst keine Pakete wegwerfen.

Und mit dem Poll mache ich dann mal einen eigenen Thread auf.

Johns

Zitat von johns

Habe ich inzwischen gemacht. Funktioniert.

Nur zur Sicherheit nachgefragt: das heißt also, damit klappt der Transfer-Mode mit softhddevice auch für den Fall, daß vom gleichen Empfangsdevice zugleich mehrere Aufnahmen stattfinden?
Kommt jemals die Log-Meldung "ERROR: TS packet not accepted in Transfer Mode"?

Zitat

Im Laufe dieses Thread war ich der Meinung, daß ein Ausgabe Plugin Pakete wegwerfen darf,
wenn seine Ausgabepuffer voll sind. Und diese Meinung ist und war falsch.

Ja, das war wohl ein Mißverständnis.

Zitat

Ein Ausgabeplugin muß die Pakete sofort annehmen oder ablehnen.
Es darf selbst keine Pakete wegwerfen.

Nun ja, wenn es (aus irgendwelchen Gründen) "weiß", daß es ein bestimmtes Paket nicht braucht, dann darf es das durchaus ignorieren (also TS_SIZE zurückliefern ohne das Paket zu verarbeiten).

Klaus

Also, wenn ich das richtig sehe werden die Daten ohne jede Prüfung direkt an die SD-FF geschickt.
Also landen auch die Daten von einem HD-Sender erst mal auf der Karte und werden da dann wohl vom Decoder verworfen.
(Bitte korregiert mich, falls ich da irgendwo einen Test übersehen habe)

Wenn das so ist wundert es mich nicht, wenn die Karte da irgendwann schlapp macht. Besonders wenn die nicht über einen fullTS-Mod verfügt.
Dümmstenfalls könnte das sogar Rückwirkungen auf den PCI-Bus haben.

Auf einem System ausschliesslich mit PCI-Karten wird das deutlich grössere Auswirkungen hat als bei einer PCIe-Budgetkarte als Datenquelle.
Ich denke die letztere Konstellation wird bei den DVB-S2 Nutzern inzwischen her der Standard sein.

Wenn meine Vermutung so stimmt dürften die Probleme auch beim VDR 1.7.36 bestehen bleiben.
Dann hilft es auch nur sicher zu stellen, dass die SD-FF nur "verdauliche" Daten bekommt.
Konkret könnte man im DVBSDDEVICE-Plugin in den Paketen nach MPEG2 Picture-Headers suchen und falls eine Weile keine kommen die Pakete bis zum nächsten Header verwerfen.

Zitat von SHF

Wenn meine Vermutung so stimmt dürften die Probleme auch beim VDR 1.7.36 bestehen bleiben.

Vermutungen helfen hier nicht weiter. Hat es denn nun mal jemand getestet? Gibt es in der Praxis irgendwelche Probleme, wenn eine FF-Karte einen HD-Kanal abspielen soll?

Zitat

Konkret könnte man im DVBSDDEVICE-Plugin in den Paketen nach MPEG2 Picture-Headers suchen und falls eine Weile keine kommen die Pakete bis zum nächsten Header verwerfen.

m.E. geschieht genau das im av7110-Treiber

Zitat von kls

Nur zur Sicherheit nachgefragt: das heißt also, damit klappt der Transfer-Mode mit softhddevice auch für den Fall, daß vom gleichen Empfangsdevice zugleich mehrere Aufnahmen stattfinden?
Kommt jemals die Log-Meldung "ERROR: TS packet not accepted in Transfer Mode"?

Ich habe ohne Aufnahmen getestet. Ich habe noch eine Meldung eingebaut, wenn der Sleep verwendet wird.
Im normalen Betrieb gibt es keine Sleeps. Wenn ich meinen Audiopuffer auf 1s erhöhe (dies ist ein Problem
in meinem Code) kommt es zu Sleeps.
Man könnte dies weiter verschärfen und dann prüfen ob die Aufnahmen in Ordnung sind.
Leider fehlt mir dafür im Moment die Zeit.

TomJoad du bekommst ja die "ERROR: TS packet not accepted in Transfer Mode" Meldungen, kannst mal mit
Aufnahme testen?

Johns

Zitat von johns

Wenn ich meinen Audiopuffer auf 1s erhöhe (dies ist ein Problem in meinem Code) kommt es zu Sleeps.

Das verstehe ich jetzt aber nicht so ganz. Du sagst, es kommt (in cTransfer::Receive()) zu cCondWait::SleepMs(RETRYWAIT), wenn du deinen Audiopuffer vergrößerst?
Wie kann das denn sein? Ich würde ja verstehen, wenn die Sleeps auftreten, wenn du den Puffer verkleinerst, aber wieso kann dein Code plötzlich keine TS-Pakete mehr annehmen, wenn er mehr Puffer zur Verfügung gestellt bekommt?
Irgendwie passt das doch nicht zusammen, oder übersehe ich da was?

Klaus

Zitat von Dr. Seltsam

Gibt es in der Praxis irgendwelche Probleme, wenn eine FF-Karte einen HD-Kanal abspielen soll?

das wird sicher primär auch von der HW abhängen. Ich hatte, wie oben erwähnt, mit der SD-FF Daten vom Sender "Einsfestival-HD" empfangen und diese dann per Streamdevice an einen Client geschickt um hier mit vaapi ohne neue Tuner zu testen. Problematisch war das auf Server wie auf Clientseite nicht (Client ist auch nicht ins Stocken geraten) Einsfestival hatte damals aber auch nur Demos mit mittlerer HD Datenrate gesendet. Bei ARD und ZDF mit jetziger VBR und über 12 Mbit kann das auch anders aussehen.

IMHO war das Limit der SD FF bei 15 Mbit über alles. Das heisst dann auch das eine "HD Aufnahme" die Karte soweit lahmlegt, das sie bei Anforderung einer weiteren Aufnahme auf demselben Transponder oder der Anfrage irgendeinen SD Sender eines anderen Tuners abzuspielen die um die Ohren fliegen wird.

Zitat von kls

Das verstehe ich jetzt aber nicht so ganz. Du sagst, es kommt (in cTransfer::Receive()) zu cCondWait::SleepMs(RETRYWAIT), wenn du deinen Audiopuffer vergrößerst?
Wie kann das denn sein? Ich würde ja verstehen, wenn die Sleeps auftreten, wenn du den Puffer verkleinerst, aber wieso kann dein Code plötzlich keine TS-Pakete mehr annehmen, wenn er mehr Puffer zur Verfügung gestellt bekommt?
Irgendwie passt das doch nicht zusammen, oder übersehe ich da was?

Diese Frage habe ich schon erwartet. deshalb habe ich extra "dies ist ein Problem in meinem Code" geschrieben.

Ich prüfe nur wie voll der Audiopuffer ist, wenn er "genug" voll ist, nehme ich keine Pakete mehr an.
Dies ist aber nur eine einfache Anzahl der Bytes Prüfung. Sind mehr als X Bytes im Puffer verweiger ich die Annahme von
Paketen. Bei 1s Puffer und noch 6 Kanal Ton ist der Wert gerade an der Grenze.
Richtig wäre an der Stelle zuprüfen ob mehr als die gewünschte Pufferzeit im Puffer ist.

Dies hat vorher nicht gestört, außer vielleicht Aufnahmen.

Johns

Zitat von Dr. Seltsam

m.E. geschieht genau das im av7110-Treiber

Die PES-Header werden untersucht, ob es sich um einen Video oder Audio-Stream handelt.
Daraus kann man aber den Codec oder die Auflösung nicht ableiten. Dazu müsste man nach MPEG2 Picture bzw. Sequence-Headern suchen.

Eine derartige Abfrage habe ich nicht gefunden, könnte aber auch sein, dass ich die übersehen habe.

Zitat von SHF

Die PES-Header werden untersucht, ob es sich um einen Video oder Audio-Stream handelt.
Daraus kann man aber den Codec oder die Auflösung nicht ableiten. Dazu müsste man nach MPEG2 Picture bzw. Sequence-Headern suchen.

Eine derartige Abfrage habe ich nicht gefunden, könnte aber auch sein, dass ich die übersehen habe.

Beim Starten einer Wiedergabe wird im Treiber nach einem Sequence-Header gescannt, um ggf. zwischen PAL und NTSC umzuschalten.

Falls mir jemand ein sicheres Kriterium zum Erkennen der MPEG-Version nennt, welches noch mit vertretbarem Aufwand abzufragen ist, baue ich das in den Treiber ein.

CU
Oliver

Es gibt seit geraumer Zeit den Full-TS-Mod! Wer immer noch eine FF-Karte mit Bandbreitenlimit einsetzt, ist selber schuld und muß mit den daraus resultierenden Problemen leben. Just my 2 cents.

Moin!

Zitat von geronimo

Auch wenn ich Dein Angebot toll finde, bin ich der Meinung, dass das der falsche Weg ist.

Das ist nicht der falsche Weg, sondern ein wichtiger Teil des gesamten Weges, denn dadurch profitieren auch andere Anwendungen.

Ich versuche mal, die passenden Infos zu finden (es darf mir auch jemand anderes zuvor kommen...).

Lars.

Zitat von UFO

Beim Starten einer Wiedergabe wird im Treiber nach einem Sequence-Header gescannt, um ggf. zwischen PAL und NTSC umzuschalten.

Falls mir jemand ein sicheres Kriterium zum Erkennen der MPEG-Version nennt, welches noch mit vertretbarem Aufwand abzufragen ist, baue ich das in den Treiber ein.

Es liegt hier an H264 vs MPEG.
H264 erkenne ich, daß am Anfang des PES Paket mehr als 3x 0 kommt, dann 9 für H264 NAL AUD, nächste kann ignoriert werden.
Also 0x00 0x00 ... 0x00 0x09 XX

Du könntest alles wegschmeissen bis wieder ein Paket ohne diesen Anfang kommt.

Johns

Zitat von johns

Es liegt hier an H264 vs MPEG.
H264 erkenne ich, daß am Anfang des PES Paket mehr als 3x 0 kommt, dann 9 für H264 NAL AUD, nächste kann ignoriert werden.
Also 0x00 0x00 ... 0x00 0x09 XX

Du könntest alles wegschmeissen bis wieder ein Paket ohne diesen Anfang kommt.

Na ja, ich brauche keinen Test auf H264/MPEG-4, sondern auf das, was die Karte kann: MPEG-2 bzw. MPEG-1 Video.
Andernfalls hat man eine ewige Baustelle, denn das, was die Karte nicht kann, wird mit der Zeit immer mehr...
(Falls der Test oben auch für zukünftige Standards gelten würde, wäre es ok - aber wer weiß das schon.)

Edit:
Hm - wenn ich es richtig sehe, gibt es bei H264 (u.a.) keine Sequence-Header (00 00 01 b3) mehr.
Es könnte also genügen, Daten zu verwerfen, bis ein Sequence-Header gefunden wird.

CU
Oliver

Sorum ist halt der Test sicherer, da es ja 0x00 0x00 0x01 0x09 auch bei mpeg gibt.

Mpeg ist mehr als 2x 0 dann 1 und als nächstes 0x00 (Picture) oder 0xb3 (Sequence start).
Also 0x00 .. 0x00 0x01 0x00 oder 0x00 .. 0x00 0x01 0xb3 im PES Paket mit Start Flag.

Wobei ich halt vorher H264 ausschliesse.

Johns