Probleme beim Verarbeiten einzelner 192er-m2ts-Streams

Begonnen von tsduser, April 16, 2021, 11:44:19

« vorheriges - nächstes »

tsduser

Moin,
nach Jahren der TSDoctor-Nutzung in diversen Versionen ist auch mir nun ein kleineres Problem aufgefallen. Entdeckt habe ich es in der aus bereits erwaehnten Gruenden weiterhin verwendeten Version 2.1.44; es existiert aber identisch noch immer in der momentan aktuellen 3.1.11 (zumindest bei der Trial in einer VM; ich habe aber nicht den geringsten Zweifel, dass eine lizensierte Version die gleichen Falschmeldungen produzieren wuerde).

Betroffen sind einzelne m2ts-Aufnahmen (entgegen dem Namen sowohl SD wie auch HD) mit 192 Byte Packet Size:

Wenn die vier zusaetzlichen m2ts-Bytes am Anfang der ersten Pakete in der Datei mit 0x47 (eigentlich ja der Hinweis auf einen Paketstart) beginnen, kommt der Doctor komplett aus dem Tritt, und mit ihm ebenso die enthaltenen Raw Cutter und Packet Viewer.

Der Doctor meint zu einer solchen Datei beispielsweise, dass die PMT fehle, und eine neue nicht erstellt werden koenne, oder bleibt bei 99% PCR-Check "ohne Rueckmeldung" haengen.
Der Packet Viewer in 2.1.44 bricht beim Laden mit der Meldung ab, dass nicht ausreichend Hauptspeicher zur Verfuegung sei.
Der Packet Viewer in 3.1.11 laedt die Datei, aber mit 188 Byte Packet Size, und damit sind natuerlich alle Pakete "rot" (bis er sich irgendwo irgendwie auf 192 Bytes synchronisiert).
Der Raw Cutter meint, dass die Datei nicht "mir" (dieser Tippfehler in der 2.1.44 ist auch in der 3.1.11 noch nicht korrigiert) gueltigen TS-Daten beginnen wuerde, und will auf TS-Packetgroesse von 188 Bytes zu"recht"schneiden.

Der Doctor an sich verhaelt sich leider auch noch unterschiedlich; je nach dem, was sonst in der Datei so vorhanden ist. Die Packet Viewer und Raw Cutter sind dagegen verhaltens-konsistent.

Wenn man (wie es ja auch im Wikipedia-Artikel zum TS-Datenstrom beschrieben steht) in den ersten 5 Paketen der Datei die 0x47 in z.B. 0x46 aendert, ist die Datei ploetzlich komplett fehlerlos. (Die restlichen 0x47-Anfaenge duerfen dann gerne drinbleiben, und verursachen keine Probleme.)
Auf demselben Wege laesst sich selbstverstaendlich auch eine "fehlerbehaftete" Testdatei erstellen: Einfach ein paar 192er-m2ts-Pakete am Anfang mit 0x47 beginnen lassen -> Bumm!

Vielleicht verhalten sich ja auch meine Billig-Xoro-Receiver falsch, und die 30 Timer-Bits in 192er-m2ts-Packets duerften laut Spezifikation ueberhaupt nicht mit 0x47 beginnen. Dazu habe ich allerdings bisher nix gefunden.

OK, ich sehe ein, dass das Problem wahrscheinlich VU+-Verwender (fuer die der Doc zumindest in letzter Zeit leider hauptsaechlich entwickelt zu werden scheint) nicht betrifft, aber so einer bin ich halt nicht.
Ebenso betrifft es nur Aufnahmen, die aus mehreren Teilen bestehen, denn sonst beginnen die vier zusaetzlichen Timer-Bytes in den 192er-Packets ja immer mit "00 00 00 00", und wenn irgendwann spaeter im Verlauf laengerer Aufnahmen dann doch mal 0x47-Packets auftreten, sind die Entscheidungen zum erkannten Format lange schon in Stein gemeisselt.

Mir ist auch klar, dass eine Korrektur, so sie denn vorgenommen wuerde, nicht in den Code von 2.1.44 einfliessen wuerde, aber wenn ich bedenke, wie viele Dateien ich in der Vergangenheit als defekt verworfen habe, obwohl nur der Doc ueber so eine winzige Lappalie gestolpert ist, wollte ich's zumindest mal berichten.
Und jetzt habe ich ja auch eine "Q&D"-Loesung.

Danke fuer's Lesen bis hierher.

Cypheros


tsduser

#2
Beobachtet habe ich es sowohl auf HRK8772Twin wie auf HRK7672Twin; die verwenden beide dasselbe Aufzeichnungsformat (5-stellige numerische Ordnernamen in Vaterordner "REC", 4GiB-Dateien .ts, .ts1, .ts2, ... und ein paar kleinere weitere inkl. Beschreibungs-.txt).
Ein HRK8750 speichert zwar auch 4GiB-Dateien, aber im 188-Byte-Format (ALi3).
Ein HRK7520 duerfte ebenfalls nicht betroffen sein; der speichert auf NTFS Dateien auch groesser als 4GiB.
Ein HRK8910 (oder so; ich habe zwei entsprechende Techwood-"Clones") verwendet ganz andere Formate (und kein NTFS).
Mein Samsung-Fernseher legt ebenfalls 188er-Dateien groesser 4GiB "en bloc" auf NTFS ab.

Kiraly-Cutter

Der HRK8772Twin wird bei https://www.xoro.de/downloads nicht angegeben.
Soll das vielleicht der HRT 8772 TWIN sein ?
Dreambox DM920 UHD 4K
VU+ Duo 4K SE

tsduser

Jepp, stimmt, sorry, ein Tippfehler.
Beide (der HRT8772 und der HRK7672) sind sozusagen "Zwitter": Sie verwenden dieselbe (aktuelle) Firmware-Version, und lassen sich zwischen Kabel-Empfang und DVB-T2 umschalten. Ich verwende aber die "Kabel"-Einstellung. Es waere zwar moeglich, dass die je nach Einstellung unterschiedliche Aufzeichnungsformate fuer die abgelegten Dateien verwenden, aber ich vermute: eher wohl nicht.

Und mit dem Verhalten des Doc hat die exakte und korrekte Bezeichnung des verwendeten Receivers doch auch nicht soooo viel zu tun, nahm ich an, und hatte es in meinem Eingangspost nicht explizit erwaehnt ;-)
Selbstverstaendlich kann ich auf Anfrage auch gerne noch weitere Details liefern.

Cypheros

Wollte nur grob wissen um welchen Typ es sich handelt.

Erstmal ist das Format mit 192 Byte ein künstliches Format, da per Sat, Kabel oder Antenne immer 188 Byte Packete übertragen werden. Die zusätzlichen 4 Byte werden also vom Receiver drangebastelt. Es wird hauptsächlich bei HD+ und FreenetTV Receivern verwendet, da man 192 Byte besser verschlüsseln kann (3 x 64 Byte).

Der TS-Doctor versucht am Anfang der Analyse das Format zu erkennen, also ob 188 Byte oder 192 Byte. Dazu sucht er drei aufeinanderfolgende Start-Bytes 0x47 und misst den Abstand and mehreren Stellen.

Hab testweise mal so eine Aufnahme genommen bei der die ersten Pakete den Startcode im M2TS-Header haben. Wird trotzdem immer richtig erkannt.

tsduser

Meine letzte Antwort war auch mehr an Kiraly-Cutter gerichtet ;-)

Aber weil ich mir auch die Nicht-Reproduzierbarkeit nicht erklaeren konnte, habe ich es einfach mal auf meinem Notebook-Zweitrechner probiert. Schliesslich wird auf meinen Rechnern ja auch schon mal die Info-.txt-Datei in unerwarteten Verzeichnissen abgelegt, und nicht im Verzeichnis der geprueften Datei (die Meldung von vor Jahren "Fehler beim Schreiben auf Root von C:", aufgrund deren leider die Info-Erstellung beim Pruefen abgeschafft wurde)...

Und ich konnte es erst nicht glauben, und war zumindest verbluefft: Auch hier wurde die Datei ohne Fehler geoeffnet.

Jedoch nur, wenn ich die Datei per Dialog Datei -> Öffnen (O) einlese. Droppe ich die Datei dagegen in das offene Doctor-Fenster (meine "normale" Vorgehensweise), dann kommt auch hier verlaesslich eine Fehlermeldung.
Ein weiteres Beispiel dafuer, wo sich der Doc unterschiedlich (um nicht zu schreiben inkonsistent) verhaelt.

Der Raw Cutter produziert uebrigens bei mir IMMER die Fehlermeldungen, auf beiden Rechnern. Eigentlich ist das Problem beim Raw Cutter ja schlimmer, weil hier im Folgenden mit einer falschen Packetgroesse gearbeitet wird, die ich auch nicht von Hand veraendern kann. Ich kann mir nicht vorstellen, dass dies ebenfalls zur Reproduktion ausprobiert wurde, und der Fehler dabei NICHT auftrat... Nichtsdestotrotz wuerde ich mich da auf die getroffene Aussage verlassen, denn schliesslich kann ich sie von hier aus nicht widerlegen.

Ich kann, falls gewünscht, gerne morgen mal zwei 20MB-Schnipsel vom Anfang der 4GiB-Datei irgendwo ablegen, die sich lediglich in drei Bytes 0x46 bzw. 0x47 an den Hex-Positionen 0x0, 0xC0, 0x180 unterscheiden. Bei 0x46 alles OK, bei 0x47 kommt beim Drop der Datei in das Doc-Fenster "Keine PIDs gefunden. Dies ist kein gültiger Transportstream!" (was auch unter Annahme der Kuenstlichkeit definitiv falsch ist...).

Das mit den drei Startbytes ist m.E. so eine Sache...
Wenn 0x47 nirgendwo in den Daten vorkommen duerfte, waere das sicher ein probates Mittel. Der eingangs erwaehnte Wikipedia-Artikel schlaegt 5 Pruefungen vor, aber wo es ja eigentlich nur die zwei Moeglichkeiten 188 und 192 gibt, muesste man ja nur ermitteln, welche der beiden bei den gegebenen Daten die wahrscheinlichere ausmacht. Dass sich das Format innerhalb einer einzelnen Datei aendert, ist dann ja doch eher unwahrscheinlich.

Und beim Oeffnen per Dialog fuehrt der bestehende Test offenbar auch bereits zum korrekten Ergebnis. Aber moeglicherweise wird ja diese Absicherung beim Drop und, fuer mich viel schlimmer, beim Raw Cutter nicht (oder anders) angewandt...

Aber wie schon erwaehnt: Ich hatte fuer mich ja bereits eine Umgehung gefunden; mit dem Oeffnen der Datei per Dialog (ausser beim Raw Cutter) kommt eine weitere hinzu. Danke dafuer.

Cypheros

Ja, schick mir mal so ein Beispiel, mit dem ich das reproduzieren kann. 20MB sollten auch per E-Mail möglich sein.
Einfach an support(ät)cypheros.de schicken.

tsduser

Mail ist versendet. Viel Erfolg; ich bin gespannt.


www.cypheros.de