1.2.90 - warum FTA Aufnahmen mit "verschlüsselten Transportpaketen" ?

[Hominidae]

Sorry falls das Thema nicht neu ist, aber ich habe den Doc nun endlich auf meiner neuen Workstation unter Win8 installiert
und mal garnix zum Dialog und Schnittverhalten "extra" angehakt , sodass er mit default-Werten läuft.

...mache gerade einen Batch-Lauf mit >300 Stck Aufnahmen aus KiKa-HD...die sind bestimmt FTA...aber bei gefühlt 30%
der Aufnahmen meckert der Doc dass verschlüsselte Transportpakete gefunden wurden.

Warum findet der Doc sowas?...KiKa-HD ist bestimmt *nicht* verschlüsselt.

Edit: und der Schnitt gelingt latuernich nur, wenn man den Dialog zum Überspringen mit *nein* beantwortet, also entgegen dem Standard (empfohlen) weitermacht 

Edit2: ..und manchmal findet es der Doc beim PID-Scan...dann wieder manchmal erst beim automagischen Schnitt im VPS-Mode

[Djfe]

auch wenn ich dazu nicht allzuviel sagen kann,
aber eventuell sind da einzelne Packete falsch geflagt oder dein Receiver nimmt verschlüsselt auf (-> welchen Receiver/Stick verwendest du?, laufen die Aufnahmen einwandfrei am PC (VLC, etc.)?, nimmst du über Satellite auf?)

und mal garnix zum Dialog und Schnittverhalten "extra" angehakt , sodass er mit default-Werten läuft.

für dieses Problem gibt's ja extra die Dialog Einstellungen
[attachimg=1]
solange die Aufnahmen noch einwandfrei nach dem Schneiden funktionieren und wirklich nichts sichtbar verschlüsselt ist (schwarzes Bild) -> ignorier die Meldung einfach und lass die Dialog Einstellung um es einfacher zu haben für den Batchlauf einfach auf Ja
(-> einige der Optionen durchzulesen kann definitiv nicht schaden)

[Mam]

Stömmt, KiKa ist nicht verschlüsselt, deshalb ist es richtig, dass Du stutzig wirst.

So richtig "verschlüsselt" erkennen kann der Doc ja auch gar nicht, er reagiert genauso, wenn er an der falschen Stelle "Matsche" vorfindet.

Könnte es also sein, dass Deine Aufnahmen ein paar hässliche Fehler enthalten, die der Doc fehlinterpretiert?

Lass doch mal eine von den angemeckerten Dateien "von Hand" durchlaufen und poste hier das Logfile.

[Hominidae]

auch wenn ich dazu nicht allzuviel sagen kann,
aber eventuell sind da einzelne Packete falsch geflagt oder dein Receiver nimmt verschlüsselt auf (-> welchen Receiver/Stick verwendest du?, laufen die Aufnahmen einwandfrei am PC (VLC, etc.)?, nimmst du über Satellite auf?)

SAT DVB-S2 mit einer Digital-Devices Quad....alles nur FTA...mit ARGUSTV (ForTheRecord).
Und die Aufnahmen sind auch ohne Behandlung durch den Doc stets einwandfrei...VLC, XBMC/Openelec spielt das alles.

für dieses Problem gibt's ja extra die Dialog Einstellungen
[attachimg=1]
solange die Aufnahmen noch einwandfrei nach dem Schneiden funktionieren und wirklich nichts sichtbar verschlüsselt ist (schwarzes Bild) -> ignorier die Meldung einfach und lass die Dialog Einstellung um es einfacher zu haben für den Batchlauf einfach auf Ja
(-> einige der Optionen durchzulesen kann definitiv nicht schaden)

...na eben *nicht*. wenn ich auf JA klicke, also "überspringe", dann sind die Schnitte Müll.
Deswegen hilt es leider nicht die Dialog-Optionen auch zu lesen...leider muss man auch wissen was man tut oder was diese im Konbtext auch bewirken.
Das empfohlene "default" macht es hier eben nicht.

[Hominidae]

Stömmt, KiKa ist nicht verschlüsselt, deshalb ist es richtig, dass Du stutzig wirst.

So richtig "verschlüsselt" erkennen kann der Doc ja auch gar nicht, er reagiert genauso, wenn er an der falschen Stelle "Matsche" vorfindet.

Könnte es also sein, dass Deine Aufnahmen ein paar hässliche Fehler enthalten, die der Doc fehlinterpretiert?

Lass doch mal eine von den angemeckerten Dateien "von Hand" durchlaufen und poste hier das Logfile.

Tja eben...Matsch ist Matsch, aber verschlüsselter Matsch ist besonderer Matsch. 
Wenn der Doc so gut ist, dass er normalen Matsch von verschlüsseltem Unterscheiden kann...warum behandelt er meinen normalen Matsch auf KiKa als Sonder-Matsch?
Der Punkt ist ja, das die Standard-Empfehlung lautet den verschlüsselten Bereich zu überspringen...damit klaut er aber mehr als wenn man den Matsch normal, we unverschlüsselt behandelt, was ja bei mir
das bessere Ergebnis bringt.

...ich muss nochmal gucken ob ich das Zeug nochmal anfass...waren 300 Folgen "Bernhard" und ich bin froh, dass die alle mal durch sind 

[Mam]

Tja eben...Matsch ist Matsch, aber verschlüsselter Matsch ist besonderer Matsch. 
Wenn der Doc so gut ist, dass er normalen Matsch von verschlüsseltem Unterscheiden kann...warum behandelt er meinen normalen Matsch auf KiKa als Sonder-Matsch?

Nee, was ich meine iss: "dumm gelaufen" 
Irgendwo in den Kopfdaten eines Paketes steht nun mal ein Flag "Ischh binn ein verschlüsselter Prinz...".

Und wenn der Matsch genau dieses Flag trifft, dann behandelt der Doc den Rest des Paketes falsch, da er glaubt, sie seien verschlüsselt.

Der Videostream enthält keine Prüfsummen usw, man kann also nicht berechnen, ob der Inhalt Matsch ist oder nicht.

Normalerweise betreffen Empfangsfehler mehrere Pakete, so dass sie bei den Tonspuren (die haben Prüfsummen) auffallen. Aber im ungünstigsten (Zu)Fall betrifftst halt nur den Videoteil, und da ist das Erkennen schwer möglich.

[Cypheros]

In der neuen Beta 1.2.92 ist die Geschicht mit den verschlüsselten Paketen geändert worden. Der Dialog kommt nicht mehr, da in 99% aller Fälle die Pakete nicht wirklich verschlüsselt sind, sondern nur "kaputt". Leider lässt sich bei der ersten Analyse nicht rausfinden ob ein Paket wirklich verschlüsselt ist oder nur durch Datenmüll (Tuning, Empfangsprobleme,etc.) das entsprechende Flag für "scrambled" gesetzt ist. Das funktioniert erst bei der Verarbeitung der Daten wenn eine neue Datei erzeugt wird und auch die Elementardaten analysiert werden.

[Djfe]

sry meinte eigentlich nicht default auf ja setzen sondern auf nein -> dann sollte er ja die "verschlüsselten" Bereiche einfach übernehmen, oder liege ich da falsch?
gibts eigentlich eine Möglichkeit solche unnötigen Scrambled Flags einfach aus den Streams zu entfernen?
und wenn du einen eigenen Decoder hättest: gäbe es die Möglichkeit die betroffenen Stellen auf tatsächliche Verschlüsselung zu untersuchen? (kurzes Rendering im Hintergrund zum Testen o.Ä.)

[Mam]

gäbe es die Möglichkeit die betroffenen Stellen auf tatsächliche Verschlüsselung zu untersuchen? (kurzes Rendering im Hintergrund zum Testen o.Ä.)

Erst denken, dann fragen 

So langsam solltest Du wissen, dass ein Dekodieren von H264 Videoströmen nur von einem sog. "I-Frame" ausgehend erfolgreich sein kann. Also müsste, damit Dein Renderingtest erfolgreich ist, jedes zu testende verschlüsselte Paket einen I-Frame enthalten, sonst gibts Pixelmatsche, obwohl die Daten "heile" sind.

Das ist nun wahrlich auf keinen Fall der Fall, womit Deine Idee sich als schnapsige erweist.... 

Auch die komplizierte Denkerweiterung, einen dekodierten V-Stream im Speicher mitzuführen und dann immer das verschlüsselte Paket testweise dranzuhängen, ist nicht von Erfolg gekrönt. Ist da dann wirklich ein Dekodierfehler (ob durch Verschlüsselung oder durch Matsche ist egal), dann kommt der ganze Stream aus dem Tritt und fängt sich erst wieder beim nächsten heilen I-Frame (der vielleicht niemals mehr kommt). (Ausserdem würde dadurch mal wieder das große Schnarchen einsetzen...)

Also: geht nich, gibbs nich 

[Cypheros]

sry meinte eigentlich nicht default auf ja setzen sondern auf nein -> dann sollte er ja die "verschlüsselten" Bereiche einfach übernehmen, oder liege ich da falsch?
gibts eigentlich eine Möglichkeit solche unnötigen Scrambled Flags einfach aus den Streams zu entfernen?
und wenn du einen eigenen Decoder hättest: gäbe es die Möglichkeit die betroffenen Stellen auf tatsächliche Verschlüsselung zu untersuchen? (kurzes Rendering im Hintergrund zum Testen o.Ä.)

Die Empfehlung für das Überspringen ist aus alten Zeiten, als kaputte Pakete den TS-Doctor noch leicht aus dem Tritt bringen konnten. Das ist aber bei der aktuellen Version nicht mehr so.
Da diese Fehler ohnehin meistens nur am Anfang und am Ende der Aufnahme auftauchen, in einem Bereich der sowieso entfernt wird, ist es eigendlich egal, was man wählt.
Es gibt aber auch Fälle, wo das überspringen der Pakete Probleme verursachen kann, wenn nämlich die Pakete nur falsch geflagt sind. Dann sollte das Scrambled-Flag besser ignoriert werden.
Deshalb wird nun das Scrambled-Flag immer ignoriert und bei der Verarbeitung gelöscht. Damit sollte es zukünftig keine Diskussionen mehr über diesen lästigen und inzwischen überflüssigen Dialog mehr geben.

Im Notfall kann das Ignorieren des Scrambled-Flags aber in den Korrektureinstellungen wieder deaktiviert werden.

[Djfe]

nur in der Theorie (also nicht zur praktischen Umsetzung, weil es schlichtweg zu lange dauert), möchte noch was dazu lernen :

So langsam solltest Du wissen, dass ein Dekodieren von H264 Videoströmen nur von einem sog. "I-Frame" ausgehend erfolgreich sein kann. Also müsste, damit Dein Renderingtest erfolgreich ist, jedes zu testende verschlüsselte Paket einen I-Frame enthalten, sonst gibts Pixelmatsche, obwohl die Daten "heile" sind.

soll heißen, es ist nicht möglich B und P-Frames als heile zu identifizieren, bloß weil sie zur Komprimierung nur Teile der Bildinformationen enthalten?
(es muss ja kein volles Bild zur Überprüfung erstellt werden, oder?
was ich weiß: wenn ein video nicht mit nem I-Frame anfängt fehlen, logischerweise Bildinformationen (haste ja schon gesagt),
dennoch schaffen Player wie der VLC ja doch hier einen Inhalt anzuzeigen -> auch wenn es nur die Unterschiede zum vorherigen Bild sind...es muss doch möglich sein zu erkennen, ob der Inhalt käse ist (keinen Sinn ergibt) oder tatsächliche Bildinformationen

oder gibt es keine wirklichen Fehler, da es Rohdaten ohne Struktur sind, die man auch Rendern könnte? (Struktur wäre in dieser Theorie dann nur in dem Container (TS-Stream))
soweit ich das kenne, ergeben verschlüsselte Videostreams ja ein schwarzes Bild, oder ist dies nur durch den Receiver/Player dahingekünstelt?

des Weiteren:

und wenn du einen eigenen Decoder hättest: gäbe es die Möglichkeit die betroffenen Stellen auf tatsächliche Verschlüsselung zu untersuchen? (kurzes Rendering im Hintergrund zum Testen o.Ä.)

hier ging es ja nicht darum den LAV Decoder o.Ä. zu verwenden, sondern mit 'nem eigenen Decoder an dieser Stelle zu untersuchen, in wie weit hier was lesbar ist (es soll ja kein Bild zur Anzeige vorbereitet werden)

[Mam]

soll heißen, es ist nicht möglich B und P-Frames als heile zu identifizieren, bloß weil sie zur Komprimierung nur Teile der Bildinformationen enthalten?

Yep 
Du solltest Dich vielleicht mal ein ganz kleines bißchen mit den Grundlagen von Komprimierungen beschäftigen :-)
z.B. der olle Ziff mit seinem Lempel. Der basiert auf der Idee eines Wörterbuches. Am Anfang kommt ne Tabelle mit Bitkombinationen, und hinten (in den wirklichen Daten) werden nur noch die Positionen dieser "Vokabeln" eingesetzt.
Beispiel:
Originaldatei: zweieinseinsviereinsdrei

gebildetes Wörterbuch: "eins"(0),"zwei"(1),"drei"(2),"vier"(3)
Komprimierte Datei: 100302

So, und nun hasse ein Datenpaket, da steht drin
"reivier100302".

Mach was draus 

So ein I-Frame kennzeichnet die Stelle, wo das Wörterbuch anfängt, B und P Frames enthalten nur die komprimierten Daten. Das eine macht ohne das andere keinen Sinn.
(Damit es nicht zu einfach wird: "B-Frames" sind die Daten, bilden aber gleichzeitig ein neues Wörterbuch, dessen Daten dann in den "P-Frames" (pyramidisch) stehen. Ist allso doppelt gepackt. Deshalb auch bei Störungen grobe und feine Klötzchen, je nachdem, wo die Störung trifft).

hier ging es ja nicht darum den LAV Decoder o.Ä. zu verwenden, sondern mit 'nem eigenen Decoder an dieser Stelle zu untersuchen, in wie weit hier was lesbar ist (es soll ja kein Bild zur Anzeige vorbereitet werden)

Öff Öff!
Hömma, ich krich' schon keine pisseligen bunten Umlaute, und Du willst einen eigenen Dekoder (sogar 2, einmal MPEG-2, einmal H.264 und bald dann auch H.265, wa?)
Ob Du das dekodierte Bild nun anzeigst, oder nicht, ist dem Dekoder Schnuppe. Die Arbeit ist vorher geleistet.
Außerdem sollte er immer irgendwas dekodieren können, egal wie Matsche die Ausgangdaten sind. Ob das ein sinnvolles Bild ergibt, kann nur der Betrachter (oder eine noch viel kompliziertere Bildanalyse) beurteilen.
Geh in ein Museum mit zeitgenössischer Kunst, dann siehst Du, was alles ein "heiles Bild" ist 

[Hominidae]

Die Empfehlung für das Überspringen ist aus alten Zeiten, als kaputte Pakete den TS-Doctor noch leicht aus dem Tritt bringen konnten. Das ist aber bei der aktuellen Version nicht mehr so.
Da diese Fehler ohnehin meistens nur am Anfang und am Ende der Aufnahme auftauchen, in einem Bereich der sowieso entfernt wird, ist es eigendlich egal, was man wählt.
Es gibt aber auch Fälle, wo das überspringen der Pakete Probleme verursachen kann, wenn nämlich die Pakete nur falsch geflagt sind. Dann sollte das Scrambled-Flag besser ignoriert werden.
Deshalb wird nun das Scrambled-Flag immer ignoriert und bei der Verarbeitung gelöscht. Damit sollte es zukünftig keine Diskussionen mehr über diesen lästigen und inzwischen überflüssigen Dialog mehr geben.

Im Notfall kann das Ignorieren des Scrambled-Flags aber in den Korrektureinstellungen wieder deaktiviert werden.

Ha...guuut...danke Meister.
P.S.: ...wollte eigentlich son' storm nicht lostreten, aber danke an alle für die gute Diskussion 

[Cypheros]

P.S.: ...wollte eigentlich son' storm nicht lostreten, aber danke an alle für die gute Diskussion 

Kein Problem, macht doch Spaß mit seinem Fachwissen um sich zu schmeißen 

Aber Spaß beiseite, solche Diskussion sind schon sehr hilfreich zu sehen wo "normale User" Probleme haben zu verstehen, was der TS-Doctor von Ihnen wissen will. Deshalb versuche ich immer so wenig Dialog wie möglich aber so viele wie nötig anzuzeigen.