RecStripper - TAP zum Schrumpfen der Aufnahmen

[chris86]

So, hier ein kleiner Statusbericht:
Das PMT-Problem ist sowohl bei Twilight, wie auch bei wtuppa@ identisch.
Es ist auf eine "Eigenheit" des Österreichischen Fernsehens zurückzuführen, welche haarscharf an den Grenzen der DVB-Spezifikation schrammt, und die ich so nicht erwartet hätte:

Der Topf zeichnet normalerweise nur diejenigen PIDs auf, die zum gerade gewählten Sender gehören. Deshalb findet man in einer Topfield-Aufnahme üblicherweise auch nur genau EINE PMT.
Der ORF nutzt allerdings zur Übertragung seiner CAT eine PID, die gleichzeitig auch für eine PMT (eines anderen Senders) verwendet wird. (Ob das zulässig ist...? )
Wegen der CAT zeichnet der Topf nun auch diese PID mit auf, und somit eine zweite PMT, die eigentlich zu einem anderen Sender gehört.

Wenn RecStrip nun im Stream nach "der" PMT sucht, dann ist es Glückssache, ob er zuerst die "richtige" PMT findet, oder die "falsche".
Insofern verhält sich RecStrip hier - im Sinne des Erfinders - eigentlich "korrekt". Es war von mir halt nie vorgesehen, dass es Aufnahmen mit zwei unterschiedlichen PMTs geben kann.

Ich wüsste im Moment auch keinen Rat, wie ich (auf einfache Weise) ermitteln könnte, welche PMT-PID die richtige ist.
Auf Basis der gegebenen Beispiele (n=2), sehe ich folgende Unterscheidungsmerkmale:
- die "richtige" PMT enthält einen Video-Stream, die falsche nicht.
- die CAT scheint in beiden Fällen auf der höchsten PMT-PID übertragen zu werden.

Für die aktuellen Beispiele wäre es ein funktionierender Workaround, wenn ich - im Falle von mehreren PMT-PIDs in einer Aufnahme - grundsätzlich immer die niedrigste wählen würde. Allerdings wäre das wohl ein ziemlich schmutziger "Hack", ohne echte sachliche Begründung. Ob das in allen Fällen so funktionieren würde, kann ich nicht sagen. Dafür bräuchte es mehr Beispiele.

Vielen Dank euch beiden für die Bereitstellung von Aufnahmen! Es ist immer wieder interessant zu sehen, auf welche unvorhergesehenen Ideen die Fernsehsender so kommen!
Nur auf diese Weise können wir zunehmend mehr und mehr Eventualitäten berücksichtigen.

[wtuppa@]

die CAT müßte doch wesentlich weniger Daten haben als die "richtige" PMT. Reicht das als Unterscheidungsmerkmal?
Eventuell kann man auch in den Sourcen vom MediaInfo bzw. MKVToolNix nachschauen (ist aber sicher einiges an Aufwand).

---

ich habe noch 3 Aufnahmen von ARTE, die auch Probleme gemacht haben. Aber die muss ich mir mal ansehen, ob die am PC angeschaut werden können. dort findet sich im log immer

Code: Alles auswählen

 Duration calculation failed (missing PCR). Using 120 minutes.

bei einer vierten meint er "Invalid TS packet size".

[chris86]

die CAT müßte doch wesentlich weniger Daten haben als die "richtige" PMT. Reicht das als Unterscheidungsmerkmal?
Eventuell kann man auch in den Sourcen vom MediaInfo bzw. MKVToolNix nachschauen (ist aber sicher einiges an Aufwand).

Nein! Bzw. das stimmt halt gar nicht. Auf der PID mit der CAT wird ebenfalls eine komplette, "richtige" PMT übertragen, jedoch halt die eines anderen Senders.
Und in den Sourcen der anderen Tools nachschauen, wird nicht viel bringen. Es gibt verschiedene Möglichkeiten, die richtigen PIDs zu identifizieren. Man könnte z.B. auch einen PID-Zähler benutzen und somit ganz auf die PMT verzichten. Aber ich werde jetzt nicht das komplette Programm deswegen umschmeißen. Zumal RecStrip aufgrund der Einsatzmöglichkeit auf dem Topf auf möglichst gute Effizienz und sparsame Speichernutzung optimiert ist. Ein Tool für den PC kann sich da andere Ressourcen genehmigen.

ich habe noch 3 Aufnahmen von ARTE, die auch Probleme gemacht haben. Aber die muss ich mir mal ansehen, ob die am PC angeschaut werden können. dort findet sich im log immer

Code: Alles auswählen

 Duration calculation failed (missing PCR). Using 120 minutes.

bei einer vierten meint er "Invalid TS packet size".

Fände ich auch beides spannend! Wenn du die Möglichkeit hast, freue ich mich auch hier über eine Beispiel-Aufnahme.
(Ohne rec kann ich hier natürlich nur Kaffeesatzlesen, und sagen, "Irgendwas stimmt wohl mit der PCR nicht" )

[wtuppa@]

und wenn du in so einem Fall imer die Info aus der INF Datei verwendest, du sagt ja dort selbst:

Code: Alles auswählen

Inf file: /mnt/Die Croods - 2020-03-15 10-43.rec.inf
  Determine SystemType: DVBs = 0, DVBt = -4, DVBc = -5 Points
   -> SystemType=ST_TMSs
  INF: VideoStream=0x1b, VideoPID=1920, HD=1
  LoadInfFile() E0905: Inconsistant video PID: inf=1920, rec=-1.

natürlich nur wenn rec=-1 ist...

[chris86]

Das ist unzuverlässig.
Die inf kann leichter falsch liegen als die rec (siehe Twilights anderes Beispiel)
Und RecStrip arbeitet konservativ. Wenn schon die Informationen über die verwendeten PIDs nicht eindeutig ermittelt werden können, dann sollte der Strip-Vorgang lieber abgebrochen werden und die Dateien unverändert bleiben, als dass die Aufnahme dabei womöglich zerstört wird!

[wtuppa@]

das ist mehr als verständlich.

[chris86]

Korrigiere:
Es ist keine CAT, sondern

0x80 = DVB-CSA and DigiCipher II/ATSC CA message sections used in EMM and ECM streams.

Wie gesagt, es ist anscheinend nicht "verboten", aber doch sehr "ungewöhnlich":

While the MPEG-2 standard permits more than one PMT section to be transmitted on a single PID (Single Transport stream PID contains PMT information of more than one program), most MPEG-2 "users" such as ATSC and SCTE require each PMT to be transmitted on a separate PID that is not used for any other packets.

(PMT Descriptors table)
This table contains PID numbers of elementary streams associated with the program and it has information about the type of these elementary streams (video, audio, etc.). In addition it may also contain an ECM (entitlement control messages) stream for any other stream that is encrypted.

In einem anderen Dokument, was ich gerade aber nicht wiederfinde, habe ich gelesen, dass mehrere PSI-Tabellen MIT DERSELBEN TableID auf derselben PID übertragen werden dürfen.
(Dagegen wird hier verstoßen)

Allerdings knabbere ich gerade auch noch am EPG des ORF. Hier beginnen die Pakete irgendwie woanders als sie sollten
- Aber vielleicht habe ich auch nur gerade ein Brett vorm Kopf!

[chris86]

@wtuppa: Und arte hat keinen PCR, sagst du...?
Die SD oder die HD Version?
Immer? Oder nur bei speziellen Aufnahmen?

[wtuppa@]

komm erst am Abend dazu, war ARTE HD und nur ganz wenige Aufnahmen von vielen.
und ja, er sagt missing PCR.

[jkIT]

Ich wüsste im Moment auch keinen Rat, wie ich (auf einfache Weise) ermitteln könnte, welche PMT-PID die richtige ist.
Auf Basis der gegebenen Beispiele (n=2), sehe ich folgende Unterscheidungsmerkmale:
- die "richtige" PMT enthält einen Video-Stream, die falsche nicht.
- die CAT scheint in beiden Fällen auf der höchsten PMT-PID übertragen zu werden.

Du könntest doch den Video PID aus der PMT mit dem Video-Stream der Aufnahme vergleichen.

Steht die "falsche" PMT auch in der PAT?

[chris86]

Du könntest doch den Video PID aus der PMT mit dem Video-Stream der Aufnahme vergleichen.

Steht die "falsche" PMT auch in der PAT?

Ja, das wäre die "richtige" Methode.
Allerdings dient die PMT-Analyse ja dazu, den Video-Stream zu ermitteln!

Ja, sie steht auch in der PAT. So wie noch viele weitere PMTs, die zum Glück aber nicht mit aufgezeichnet werden!

[Homer]

"Richtig" wäre, alle Video Streams der Aufnahme zu schrumpfen, d. h. alle Video Streams aus allen PMTs zu verarbeiten.
Z. Zt. gibt es in einer Aufnahme maximal einen Video Stream( - vielleicht in Zukunft auch mehrere).

Z. Zt. wird also entweder auf mehrere Video Streams verwiesen, von denen nur einer tatsächlich vorhanden ist, oder es wird nur auf einen Video Stream verwiesen, der dann auch vorhanden ist.

Da eine PMT-PID spätestens alle 100 Millisekunden übertragen wird, sollten die PIDs der tatsächlich vorhandenen PMTs nach dem Lesen eines 100 ms-Bereichs bekannt sein.

Viele Grüße
Homer

[chris86]

"Richtig" wäre, alle Video Streams der Aufnahme zu schrumpfen, d. h. alle Video Streams aus allen PMTs zu verarbeiten.
Z. Zt. gibt es in einer Aufnahme maximal einen Video Stream( - vielleicht in Zukunft auch mehrere).

Kein Problem.
An dem Tag, an dem Topfield plötzlich wie ein Phönix aus der Asche aufersteht, und neue Receiver baut, die Aufnahmen mit mehr als einem Video-Stream erzeugen können, dazu ein völlig neues Format für inf und nav erfindet, welches diese Neuheit dann auch unterstützt, sowie dieses fiktive neue nav-Format dann von Debugging-Spezialisten wie Firebird oder jkIT entschlüsselt wurde, können wir gern darüber reden, ob ich mich ein paar Monate hinsetzen und RecStrip komplett neu strukturieren möchte, um eine solche Art von Aufnahmen zu unterstützen.
Bis dahin bleibe ich persönlich beim vorhandenen Format.
Aber der Source-Code ist ja öffentlich verfügbar, sodass jeder gerne Verbesserungen einbauen darf.

[Twilight]

twilight

[chris86]

So, liebe Leute... Es gibt Oster-Neuigkeiten!

Zuerst eine schlechte Nachricht:
Ich habe einen kleinen Bug in den RecStrip-Versionen 1.0 bis 2.4b festgestellt, der in sehr speziellen Konstellationen dafür sorgt, dass vereinzelte Pakete zu viel gefiltert werden.
In meinen Testaufnahmen kommt dieser Fall nur sehr selten vor, weshalb er bislang auch nie aufgefallen ist. Aber dennoch soll das nicht sein!
Ich empfehle allen, künftig nur noch die Version 2.5 (beta) oder höher einzusetzen!

Und jetzt die gute Nachricht:
Ich habe die derzeit etwas mehr verfügbare Zeit genutzt, um eine völlige Re-Strukturierung von RecStrip umzusetzen.
Die neue Version RecStrip 3 führt die Filterung von Filler-NALUs und Zero-Byte-Padding nicht mehr nur auf TS-Ebene durch, sondern sie arbeitet mit einem In-Memory-Demultiplexer, filtert auf PES-Ebene, und re-multiplext die Streams anschließend wieder.
Der Vorteil: Die starren Grenzen (188 Byte) der TS-Pakete können aufgebrochen werden!
Bisher konnten nur komplette TS-Pakete, die ausschließlich Fülldaten enthielten, entfernt werden. Dabei verblieb am Anfang und Ende jeder Filler-NALU je ein Rest-Paket, das noch teilweise aus Fülldaten bestand.
Mit der neuen Version kann der Video-Stream richtig schön sauber gefiltert werden, so dass keine Rückstände der Fülldaten mehr verbleiben.
Nach ersten Schätzungen können damit - selbst bei bereits gestrippten Dateien - nochmal 5 oder bis zu 10% herausgeholt werden!

Die neue Version ist bisher nur im Alpha-Stadium. Das bedeutet, es funktioniert bisher:

• In-Memory Demultiplexing und Re-Multiplexing
• Strippen von Filler-NALUs und Zero-Byte-Padding auf PES-Ebene
• Neu-Berechnung der PCRs und Arrival-Timestamps
• Strippen von Nullpaketen, EPG, Teletext, Adaptation-only-Packets auf TS-Ebene
• Anpassung der nav-Dateien

Noch un-optimiert und völlig ungetestet sind die folgenden Funktionen

• Anpassung von Bookmarks und Segment-Markern
• Schneiden und Teile kopieren
• Merging und Appending zweier Aufnahmen
• Konvertierung zwischen Receiver-Typen

bekannte Einschränkungen:

• Die neue Version setzt voraus, dass der PCR auf der Video-PID übertragen wird. (Eine Anpassung für separate PCR-PID wäre theoretisch möglich, aber recht aufwändig, und mir ist noch keine Test-Aufnahme untergekommen, wo das der Fall wäre. Wenn jemand eine findet, kann ich versuchen, das umzusetzen.)

Da die meisten Leute vermutlich eh hauptsächlich das "simple" Strippen einer rec-Datei nutzen, die letzte Version aufgrund des Bugs eher nicht mehr eingesetzt werden sollte, und die Bereitstellung bzw. der Test aller Kombinationen der obigen Features ewig dauern würde, stelle ich die neue Version dennoch bereits im alpha-Stadium zur Verfügung.

Meine Test-Aufnahmen lassen sich mit der neuen Version nach dem Strippen und einwandfrei abspielen, und zeigen in TSDoctor keine Fehler an.

Dennoch ist es wichtig, den neuen Algorithmus mit so vielen Aufnahmen von so vielen Sendern wie möglich auszutesten. Wie immer denkt sich jeder Sender seine eigenen Besonderheiten aus, für die teilweise eigene Anpassungen erforderlich sein werden...

Ich wünsche mir also zu Ostern ganz viele Tester, die den neuen Algorithmus mit ihren Aufnahmen ausprobieren

Bitte achtet besonders darauf, dass die gestrippten Aufnahmen - am Topf und am PC - wirklich einwandfrei wiedergegeben werden (selbst kleinste "Glitches" oder Verpixelungen, Tonaussetzer oder Aynchronität von Bild und Ton dürfen nicht passieren, und wären sehr wichtig zu wissen!)
Ebenfalls entscheidend ist, dass das Spulen, sowie Zeitlupe-Wiedergabe im Topf genauso reibungslos und "smooth" laufen muss, wie vor dem Strippen. Sollte das bei einer Aufnahme nicht der Fall sein, sagt bitte ebenfalls Bescheid!

Die neue Version steht wie immer zum Download bereit unter:
http://mc.tms-taps.net/RecStripper/

[Twilight]

sehr beeindruckend!! danke

die version gibt es bis jetzt für pc und srp, nicht für nas oder? und ich möchte da jetzt keinen druck erzeugen, nur wissen ob das so ist

twilight

[chris86]

Aktuell ja. Ich muss wahrscheinlich noch viel ändern.
Wenn alles gut läuft, dann mach ich irgendwann nochmal eine Linux-Kompilieraktion, wenn es sich dann auch lohnt...

[Twilight]

twilight

[db1]

Hallo, habe gerade einmal die win Version der 3alpha an einem ONE HD file getestet. Hat leider nicht geklappt. Ausgabe waren nur zwei2 0 Byte files (rec und nav). Mit der 2.5er läuft das Streaming gerade (ohne Probleme).

Code: Alles auswählen

C:\Program Files (x86)\RecStrip_3alpha>.\RecStrip_3alpha.exe -s -e "T:\DataFiles\MoveToNAS\Der Medicus.rec" "T:\DataFiles\MoveToNAS\windows3alpha\Der Medicus_stripe.rec"

RecStrip for Topfield PVR v3.0 alpha
(C) 2016-2020 Christian Wuensch
- based on Naludump 0.1.1 by Udo Richter -
- based on MovieCutter 3.6 -
- portions of Mpeg2cleaner (S. Poeschel), RebuildNav (Firebird) & TFTool (jkIT)

Parameters:
DoCut=0, DoMerge=0, DoStrip=yes, RmEPG=yes, RmTxt=no, RmScr=no, RbldNav=no, RbldInf=no, PkSize=0

Input file: T:\DataFiles\MoveToNAS\Der Medicus.rec
  File size: 9106008576, packet size: 192
  TS: PMTPID=5410, SID=10376, PCRPID=5411, Stream=0x1b, VPID=5411, HD=1
  TS: TeletxtPID=5414
  TS: SubtitlesPID=5415
  TS: EvtStart  = Tue Mar 31 00:25:00 2020
  TS: EventName = Der Medicus
  TS: EventDesc = Spielfilm Deutschland 2013 (The Physician I)
  TS: ExtEvent  = England, im fr³hen elften Jahrhundert. Trotz seiner magischen Vorahnung muss der junge Halbwaise Rob Cole hilflos mit ansehen, wie seine Mutter an einer unheilbaren Krankheit stirbt. Das Erlebnis prõgt ihn nachhaltig. Rob schlie▀t sich einem fahren
  TS: ExtEvent  = England, im fr³hen elften Jahrhundert. Trotz seiner magischen Vorahnung muss der junge Halbwaise Rob Cole hilflos mit ansehen, wie seine Mutter an einer unheilbaren Krankheit stirbt. Das Erlebnis prõgt ihn nachhaltig. Rob schlie▀t sich einem fahrenden Bader an, der ihn in das medizinische Halbwissen des Mittelalters einweiht. Da der Wanderheiler allmõhlich sein Augenlicht verliert, ³bernimmt sein Zauberlehrling bald die "Behandlungen" - f³r die Patienten eher schmerzhafte als heilsame Prozed
  TS: ExtEvent  = England, im fr³hen elften Jahrhundert. Trotz seiner magischen Vorahnung muss der junge Halbwaise Rob Cole hilflos mit ansehen, wie seine Mutter an einer unheilbaren Krankheit stirbt. Das Erlebnis prõgt ihn nachhaltig. Rob schlie▀t sich einem fahrenden Bader an, der ihn in das medizinische Halbwissen des Mittelalters einweiht. Da der Wanderheiler allmõhlich sein Augenlicht verliert, ³bernimmt sein Zauberlehrling bald die "Behandlungen" - f³r die Patienten eher schmerzhafte als heilsame Prozeduren.
  TS: SvcName   = ONE HD
  Failed to get start time from Teletext.
  TS: FirstPCR  = 1983578430374 (20:24:25,867), Last: 2268828720615 (23:20:30,693)
  TS: Duration  = 176 min 04 sec
  TS: StartTime = Mon Mar 30 20:04:00 2020
  PIDs to be checked for continuity: [0] [5411], [1] 5412, [2] 5413, [3] 5416, [4] 5414, [5] 18

Inf file: T:\DataFiles\MoveToNAS\Der Medicus.rec.inf
  Determine SystemType: DVBs = 0, DVBt = -4, DVBc = -5 Points
   -> SystemType=ST_TMSs
  INF: VideoStream=0x1b, VideoPID=5411, HD=1

Nav file: T:\DataFiles\MoveToNAS\Der Medicus.rec.nav

Cut file: T:\DataFiles\MoveToNAS\Der Medicus.cut


Output rec: T:\DataFiles\MoveToNAS\windows3alpha\Der Medicus_stripe.rec

Inf output: T:\DataFiles\MoveToNAS\windows3alpha\Der Medicus_stripe.rec.inf

Nav output: T:\DataFiles\MoveToNAS\windows3alpha\Der Medicus_stripe.rec.nav

Cut output: T:\DataFiles\MoveToNAS\windows3alpha\Der Medicus_stripe.cut



C:\Program Files (x86)\RecStrip_3alpha>

[db1]

Habe es mit 2 weiteren versucht. Es gehen alle nicht. Dürfte wohl eher ein generelles file Problem sein. Hier noch eine Ausgabe mit anderer Fehlermeldung:

Code: Alles auswählen

C:\Program Files (x86)\RecStrip_3alpha>.\RecStrip_3alpha.exe -s -e "T:\DataFiles\MoveToNAS\Impostor - Der Replikant.rec" "T:\DataFiles\MoveToNAS\windows3alpha\Impostor - Der Replikant_stripe.rec"

RecStrip for Topfield PVR v3.0 alpha
(C) 2016-2020 Christian Wuensch
- based on Naludump 0.1.1 by Udo Richter -
- based on MovieCutter 3.6 -
- portions of Mpeg2cleaner (S. Poeschel), RebuildNav (Firebird) & TFTool (jkIT)

Parameters:
DoCut=0, DoMerge=0, DoStrip=yes, RmEPG=yes, RmTxt=no, RmScr=no, RbldNav=no, RbldInf=no, PkSize=0

Input file: T:\DataFiles\MoveToNAS\Impostor - Der Replikant.rec
  File size: 2897585280, packet size: 192
  TS: PMTPID=99, SID=51, PCRPID=1535
  TS: TeletxtPID=38, Stream=0x2, VPID=1535, HD=0
  TS: Teletext Programme Identification Data: 'TELE5'
  TS: Teletext date: mjd=58927, 21:08:25
  TS: SvcName   = TELE 5
  TS: EvtStart  = Thu Mar 19 20:15:00 2020
  TS: EventName = Impostor - Der Replikant
  TS: EventDesc = Science-Fiction-Film, USA 2001
  TS: ExtEvent  = Regie: Gary Fleder. Darsteller: Gary Sinise, Madeleine Stowe, Vincent D'Onofrio. Spencer Olham ist Waffenspezialist. Im Auftrag der Regierung soll er die Erde gegen aggressive Aliens verteidigen, die die Menschheit seit Jahrzehnten immer wieder at
  TS: ExtEvent  = Regie: Gary Fleder. Darsteller: Gary Sinise, Madeleine Stowe, Vincent D'Onofrio. Spencer Olham ist Waffenspezialist. Im Auftrag der Regierung soll er die Erde gegen aggressive Aliens verteidigen, die die Menschheit seit Jahrzehnten immer wieder attackieren. Doch kurz bevor Olham den Prõsidenten trifft, wird der Forscher verhaftet. Ausgerechnet er soll ein mit einer Bombe ausgestatteter, auf die Erde geschleuster Android der Aliens sein. Ein dunkler Blick in die Zukunft.
  TS: FirstPCR  = 39194077002 (0:24:11,632), Last: 212224419767 (2:11:00,163)
  TS: Duration  = 106 min 48 sec
  TS: StartTime = Thu Mar 19 20:14:00 2020
  PIDs to be checked for continuity: [0] [1535], [1] 1536, [2] 38, [3] 18

Inf file: T:\DataFiles\MoveToNAS\Impostor - Der Replikant.rec.inf
  Determine SystemType: DVBs = 0, DVBt = 0, DVBc = -1 Points
   -> SystemType=ST_TMS?
   -> DEBUG! Assertion error: SystemType in inf (0) not consistent to filesize (5)!
  LoadInfFile() E0903: Incompatible system type.

ERROR: Cannot open input T:\DataFiles\MoveToNAS\Impostor - Der Replikant.rec.

C:\Program Files (x86)\RecStrip_3alpha>