Jump to content

Errors und Klötzchenbildung bei SD-Sendern in DVB-S2


GBWebmaster

Recommended Posts

  • Replies 96
  • Created
  • Last Reply

Top Posters In This Topic

  • Derrick

    33

  • GBWebmaster

    22

  • Griga

    13

  • nuts

    12

Top Posters In This Topic

Posted Images

also wie sollen häkchen bei der dekodierung einfluss auf disconties in aufnahmen haben?

 

Macht ruhig weiter, ich ziehe mich erst mal zurück. Ach ja, kauft Sky hardware kann man da nur sagen ;)

Link to post

Interessant in dem Zusammenhang wäre erstmal nur ob es mit den mutmaßliche fehlerfreien Transedit Aufnahmen auch zu den Bildstörungen kommt.

An den Decoder Einstellungen rumzubasteln macht für die Suche der Ursache keinen Sinn, ggf. können so aber die Symptome später bekämpft werden.

 

@GBWebmaster: Welche GPU verwendest du zur Wiedergabe?

Link to post

Was machen eigentlich diese Einträge im svcdebug.log?

Disk limit reached! total 805320679424 - free: 313606144 - Min: 314572800

Das sagt das eine Aufnahme abgebrochen oder nicht gestartet wurde da weniger Festplatten platz frei war (free) als angegeben wurde das der immer mindestens frei bleiben soll (Min).

In dem Fall steht dass auf 300 MB, dem Standard Wert. Der so gesetzt ist für den Fall das auf der System Platte aufgenommen wird und Windows mag es nicht so wenn da 0 Byte frei sind ;)

Link to post

Das sagt das eine Aufnahme abgebrochen oder nicht gestartet wurde da weniger Festplatten platz frei war (free) als angegeben wurde das der immer mindestens frei bleiben soll (Min).

In dem Fall steht dass auf 300 MB, dem Standard Wert. Der so gesetzt ist für den Fall das auf der System Platte aufgenommen wird und Windows mag es nicht so wenn da 0 Byte frei sind ;)

Danke Tjod, das war mir schon klar, nur der User GBWebmaster hat trotz voller Systemplatte immer weiter versucht aufzunehmen...

Link to post

Nein, hab ich nicht, da ich die volle Platte bemerkt und anschl. Platz geschaffen habe ... ;)

 

@nuts

GPU ist DXVA2 (copy-back) - oder hab ich da was falsch verstanden??

Edited by GBWebmaster
Link to post

Laut Support.zip:

OS: Windows 10x86
Aero enabled: True
DirectX: 12.0
d3dx9_33.dll: True
Memory: 2027 MB
CPU: Intel® Core2 Duo CPU E8400 @ 3.00GHz
CPU Speed: 3000 Mhz
CPU Count: 2
Videocard: AMD Radeon HD 6570
Version: 15.201.1151.1008

Link to post

Eine theorie: Sky hat das ECM_timing auf 12032H so gestaltet, dass die nichtzertifizierte anordnung zur entschlüsselung damit nicht zurecht kommt.

 

In meinem privaten Kabelnetz werden die sky TS 1:1 von DVB-S2 in DCV-C/QAM256 umgesetzt und selbst mit der guten alten TT CT3650 und einem CI können 2 Sender gleichzeitig vom TS4 ohne Aussetzer im DVBViewer entschlüsselt werden:

21.09.16 23:56:49.433 Hbbtv.StartTV IsTV: 1 Name: Sky Nostalgie

21.09.16 23:56:52.836 TDVBPreview AllocateHardware USB 2.0 BDA DVB-C Tuner (1)

21.09.16 23:56:52.836 TBDATechnoTrend SetTuner TType: 0, Freq: 426000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 768, VPID: 767, PMT: 98, SID: 516, TID: 4, NID: 133, SatMod: 0, DiseqCVal: 0, Flags: 25

21.09.16 23:56:52.836 TBDACITTModule EvalPMT Set multiple Tuner Count: 1

21.09.16 23:57:00.312 Hbbtv.LoadInBrowser Set transparent Colorkey

21.09.16 23:57:00.357 TfrmMain SetTuner Start

21.09.16 23:57:00.357 TfrmMain AllocateHardware USB 2.0 BDA DVB-C Tuner (1)

21.09.16 23:57:00.357 TfrmMain SetTuner Found usable hardware

21.09.16 23:57:00.357 Hbbtv.LoadInBrowser Set transparent Colorkey

21.09.16 23:57:00.357 TfrmMain Release USB 2.0 BDA DVB-C Tuner (1)

21.09.16 23:57:00.357 TBDATechnoTrend SetTuner TType: 0, Freq: 426000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 512, VPID: 511, PMT: 97, SID: 20, TID: 4, NID: 133, SatMod: 0, DiseqCVal: 0, Flags: 25

21.09.16 23:57:00.357 TBDACITTModule EvalPMT Set multiple Tuner Count: 2

21.09.16 23:57:00.615 TfrmMain SetTuner End

21.09.16 23:57:00.643 Hbbtv.StartTV IsTV: 1 Name: Sky Emotion

21.09.16 23:57:00.643 Hbbtv.StartTV IsTV: 1 Name: Sky Emotion

21.09.16 23:57:00.648 Hbbtv.StartTV IsTV: 1 Name: Sky Emotion

 

=> meiner Meinung nach liegt das Problem also nicht bei der ECM-Theorie... Beim CI-Modul könnte @Derrick aber vielleicht doch Recht haben, da die "Grauzone" natürlich keine Garantie für Stabilität ist...

 

Link to post

 

meiner Meinung nach liegt das Problem also nicht bei der ECM-Theorie... Beim CI-Modul könnte @Derrick aber vielleicht doch Recht haben

das eine gilt natürlich nur im zusammenhang mit dem anderen ;), aber solange keine belastbaren testresultate verfügbar sind, lohnt es nicht darüber weiter zu diskutieren..

Link to post

Da es hier ja um Disconties beim RS ging hier noch die Logs von zwei gleichzeitigen Aufnahmen:

 

Sky Emotion 22.09.2016
WHS2011-BM\TV-Aufzeichnung\2016_09-22_00-22-16_Sky Emotion_Verlobung auf Umwegen - Liebeskomödie.ts
Device: Digital Devices DVB-C Tuner 5 (5)
EventID: 36239
Timer Name: Verlobung auf Umwegen - Liebeskomödie
Timer Start: 21.09.2016 23:57:00
Timer Duration: 01:58:00 (118 min. incl. 3 min. lead time, 15 min. follow-up time)
Timer Options: Teletext=0, DVB Subtitles=0, All Audio Tracks=1, Adjust PAT/PMT=1, EIT EPG Data=1, Transponder Dump=0
Timer Source: Web

00:22:16 / 00:00:00 (~ 0,00 MB) Start Recording
00:22:16 / 00:00:00 (~ 0,00 MB) Drugstore Cowboy undefined | EventID: 36240 PDC: 0x00000
00:22:17 / 00:00:00 (~ 0,09 MB) PID 511: H.264 Video, 16:9, 720x576, 25 fps
00:22:17 / 00:00:00 (~ 0,09 MB) PID 512: MPEG Audio Stereo, 48 khz, 192 kbps
00:22:17 / 00:00:00 (~ 0,09 MB) PID 513: MPEG Audio Stereo, 48 khz, 192 kbps
00:22:17 / 00:00:00 (~ 0,09 MB) PID 515: AC3 Audio Stereo, 48 khz, 384 kbps
00:22:17 / 00:00:01 (~ 0,09 MB) Verlobung auf Umwegen running | EventID: 36239 PDC: 0x00000
00:35:26 / 00:13:10 (~ 278,25 MB) Stop

Average Data Rate: 0,352 MB/s
Total Size: 278,2 MB (291764344 Bytes)
Removed Filler Data: 0,4 MB (0,2%)

 

Sky Nostalgie 22.09.2016
WHS2011-BM\TV-Aufzeichnung\2016_09-22_00-22-30_Sky Nostalgie_Patton - Rebell in Uniform - Kriegsfilm.ts
Device: Digital Devices DVB-C Tuner 6 (6)
EventID: 45378
Timer Name: Patton - Rebell in Uniform - Kriegsfilm
Timer Start: 21.09.2016 21:47:00
Timer Duration: 03:08:00 (188 min. incl. 3 min. lead time, 15 min. follow-up time)
Timer Options: Teletext=0, DVB Subtitles=0, All Audio Tracks=1, Adjust PAT/PMT=1, EIT EPG Data=1, Transponder Dump=0
Timer Source: Web

00:22:30 / 00:00:00 (~ 0,00 MB) Start Recording
00:22:30 / 00:00:00 (~ 0,00 MB) Bruce Lee - Mein letzter Kampf undefined | EventID: 45379 PDC: 0x00000
00:22:31 / 00:00:01 (~ 0,00 MB) Patton - Rebell in Uniform running | EventID: 45378 PDC: 0x00000
00:22:47 / 00:00:17 (~ 0,21 MB) PID 767: H.264 Video, 16:9, 720x576, 25 fps
00:22:47 / 00:00:17 (~ 0,21 MB) PID 768: MPEG Audio Stereo, 48 khz, 192 kbps
00:22:47 / 00:00:17 (~ 0,21 MB) PID 769: MPEG Audio Stereo, 48 khz, 192 kbps
00:32:29 / 00:09:59 (~ 132,35 MB) Patton - Rebell in Uniform running | EventID: 45378 PDC: 0x00000
00:32:30 / 00:10:00 (~ 132,79 MB) Bruce Lee - Mein letzter Kampf starts in a few seconds | EventID: 45379 PDC: 0x00000
00:33:00 / 00:10:29 (~ 144,47 MB) Bruce Lee - Mein letzter Kampf running | EventID: 45379 PDC: 0x00000
00:33:01 / 00:10:30 (~ 144,73 MB) Madame und ihre Nichte undefined | EventID: 45380 PDC: 0x00000
00:35:26 / 00:12:56 (~ 194,33 MB) Stop

Average Data Rate: 0,250 MB/s
Total Size: 194,3 MB (203769252 Bytes)
Removed Filler Data: 0,8 MB (0,5%)

 

=> Bei beiden Aufnahmen vom selben TS sind keine Diskontinuitäten aufgetreten.

Link to post

 

Bei beiden Aufnahmen vom selben TS sind keine Diskontinuitäten aufgetreten.

So sollte es sein. Allerdings bringt es keine erhellung bezüglich des topics (der titel muss sicher später geändert werden ;) ) Bei 2 leuten lässt sich das problem reproduzieren, aber keiner hat seine entschlüsselung offengelegt. Du kannst ja @nuts und @GBWebmaster deine methode per pn mitteilen. Dann können wir hier zu machen :D

Link to post

An einer qualitativen feststellung der fehler scheint niemand interessiert zu sein, ausser mir vielleicht, aber ich kann es ohne Sky unmöglich reproduzieren ;) Was es nicht sein kann, habe ich eingangs beschrieben. Bleibt nur die entschlüsselung und dazu haben @Griga und ich wege beschrieben, wie man mit einfachen testaufnahmen zumindest etwas licht ins dunkel bringen kann. Aber das scheint zu viel gefragt..

Link to post

Über das CAM brauchen wir uns nicht austauschen ...

 

Interessant wäre nur ob die Errors wirklich durch fälschlicherweise als verschlüsselt geflaggte Pakete bedingt sind und ob das wegfiltern im RS die richtige Strategie für solche Pakete ist.

Ich schau am Wochenende die files mal mit dem TS-Doctor an. Vielleicht erkennt der ja was?

Link to post

Solche falsch markierten Pakete lassen sich im Prinzip mit der Suchfunktion im Hex Viewer des TransEdit Analyzers finden. Ist nur etwas Bitklauberei ;)

 

Zunächst brauchst du irgendeinen TS Packet Header (die 4 ersten Bytes) eines verschlüsselten Pakets als Suchbegriff. Beim Videostream von Sky Cinema wäre das z.B. 47 00 FF D5. Da sind im letzten Byte die beiden Scambled-Flags gesetzt (die beiden höchstwertigen Bits).

 

Dann musst du dir im Hex Viewer den entschlüsselten Live-Stream anschauen und dort viele Pakete auflaufen lassen (also Packets auf einen hohen Wert setzen). Weiterhin musst du eine Suchmaske verwenden, die die beim Vergleich zu berückssichtigenden Bits im Header angibt (der sich ständig ändernde Continuity Counter darf z.B. nicht verglichen werden). Passend wäre für alle Sender FF 3F FF C0.

 

Und dann schaust du, ob die Suche irgendeinen Treffer am Anfang eines Pakets (nicht mittendrin) ergibt.

Link to post

Dann können wir hier zu machen :D

 

 

An einer qualitativen feststellung der fehler scheint niemand interessiert zu sein, ausser mir vielleicht, aber ich kann es ohne Sky unmöglich reproduzieren ;)

 

Ich hab das Topic deshalb für mich beendet, da ich aufgrund Deiner Aussagen (u.a. auch "Ach ja, kauft Sky hardware") davon ausgegangen bin, dass Du mit uns Noobs fertig bist ...

 

Ich hab Euch beiden mal per PN die HeaderInfo sowie die HexView in Dateiform zukommen lassen.

Hilft dies weiter?

Link to post

Mit den dateien kann ich nichts anfangen. Die PES Header interessieren mich nicht und mich durch einen PID_hex_dump zu wühlen tue ich mir auch nicht an. Das ist vielleicht was für @Griga, der diese methode vorgeschlagen hat ;) Sind ja auch nur 10 pakete. Beim video hier mit knapp 2mbps rauschen über 1000 ts_packets/s vorbei. In deinen log gibt es alle paar sekunden eine discontie. Also bräuchte man auch mindesten ein paar 1000 pakete, um so einen fehler einfangen zu können.

 

Es kann doch nicht so schwierig sein, eine kurze aufnahme ins netz hoch zu laden. Stell einen der sender im DVBViewer ein und starte auch transedits analyzer mit einem RTSP-device. Im analyzer müssten die PIDs vom sender schwarz sein. Wenn das der fall ist, nimm diese PIDs auf und starte zeitgleich eine sofortaufnahme im DVBViewer. Wenn per aufnahme einige zig MBs erreicht sind, kannst du die aufnahmen stoppen. Im log vom DVBViewer müssten disconties verzeichnet sein. Aufnahmen und logs bitte hochladen und hier den link posten bzw. an mich und Griga per pn.

 

Fülldatenentfernung im DVBViewer bitte abschalten. Falls das RTSP device nicht vom DD tuner gespeist wird (PIDs bleiben rot), alle anderen tuner (dvb2ip) deaktivieren.

Link to post

Der von TransEdit aufgenommene entschlüsselte Videostream zeigt wie erwartet, was los ist. Periodisch tauchen Pakete der folgenden Machart auf:

 

Zwischenablage01.png

 

Man sieht im TS Header das Syncbyte (47), die Video PID (01 FF = 511). Dann folgt das Byte F0, in dem verschiedene Informationen bitweise codiert sind: Beide Scrambling-Flags sind gesetzt - die Quelle des Übels. Zwei weitere Flags zeigen an, dass das Paket sowohl ein Adaptation Field (eine Art Header-Erweiterung) als auch Nutzdaten (Payload) enthält.

 

Die Länge des Adaptation Field ist B6 = 182 Bytes, bis auf das erste nur Fülldaten-Bytes FF. Plus 4 Header-Bytes am Anfang plus 1 Byte für besagte Längenangabe macht 187. Da die Gesamtgröße von TS Paketen immer 188 ist, steht am Ende also genau ein Byte, das zu den Videodaten gehört (hier E6). Und genau das fehlt dann in RS-Aufnahmen, weil der Recorder solche Pakete wegen der gesetzten Scrambling Flags eliminiert. Damit ist der Videostream an der Stelle kaputt. Ignoriert man die Scrambling Flags, ist der Videostream dem Augenschein nach fehlerfrei.

 

Ich würde sagen, das CAM kriegt bei der speziellen Machart dieser Pakete (nach Adaptation Field Stuffing nur ein Byte Payload) irgendwie die Kurve nicht und lässt die Scrambling Flags stehen.

Link to post

@Griga war schneller :)

 

Snap102.png

 

Es liegt eindeutig am CAM

 

Allerdings sehe ich in der DVBViewer-aufnahme, bei der diese pakete fehlen, keine artefakte und ruckeln tut es auch nicht.

Link to post

Ich danke Euch für den Aufwand, den ihr auf Euch genommen habt.

In diesem Fall werde ich wohl nur noch HD gucken ... ;)

 

 

Gruß GBWebmaster

Link to post

Ich habe mal in unser internes Archiv durchsucht. Vor ein paar Jahren (2012) gab es den Fall bereits, und damals hatte ich das Problem im DVBViewer Filter gelöst - er toleriert unter bestimmten Bedingungen die Scrambling Flags. Deshalb lässt sich die TransEdit-Aufnahme des entschlüsselten Streams im DVBViewer ohne Bildfehler abspielen.

 

Jetzt müsste man mal schauen, ob das Verfahren auch im Recorder anwendbar ist....

Link to post

ETSI TS 103 127

 

 

6.2.1 TS level scrambling

The basic unit of scrambling (or descrambling) is an MPEG-2 transport stream packet (TS). Each packet is scrambled

independently from all others, allowing random access. A packet consists of a header and optional adaptation field that

are left in the clear followed by a payload that is processed as described below.

AES-128, as defined in NIST FIPS 197 [1], is used to encrypt blocks of 16 bytes of the data payload of a given

TS packet. The payload, in general, is not an integer multiple of 16 bytes. Only a part that is made up of a multiple of 16

bytes, is encrypted by the scrambling process. If there is a remaining part (up to 15 bytes), it stays in the clear. If the

payload is less than 16 bytes, it is left in the clear.

..und das gilt natürlich auch für 2 bytes ;) Das paket wird durch den algo nicht angefasst, muss aber nichtsdestotrotz als clear gekennzeichnet werden

 

Muss die applikation schlechte programmierung von CAMs kompensieren? :rolleyes:

Link to post

Danke. Ich hatte in Erinnerung, dass es eine solche Spezifikation gibt, aber nicht mehr parat, wie sie genau aussieht.

 

Muss die applikation schlechte programmierung von CAMs kompensieren?

 

Muss nicht, aber kann, wenn es keine Nachteile mit sich bringt...

Link to post

ETSI TS 103 127 ..und das gilt natürlich auch für 2 bytes ;) Das paket wird durch den algo nicht angefasst, muss aber nichtsdestotrotz als clear gekennzeichnet werdenMuss die applikation schlechte programmierung von CAMs kompensieren? :rolleyes:

In dem Zusammenhang wäre noch interessant: Dürfen solche Pakete überhaupt als verschlüsselt gekennzeichnet werden?

In dem Fall läge das CAM ja richtig und Sky würde Mist machen ...

Link to post

Würde dies bedeuten, dass nur die Errors nicht mehr gezählt werden?

Oder hieße dies, dass die Bildfehler auch nicht mehr vorhanden wären?

Link to post

In dem Zusammenhang wäre noch interessant: Dürfen solche Pakete überhaupt als verschlüsselt gekennzeichnet werden?

In dem Fall läge das CAM ja richtig und Sky würde Mist machen ...

Ich glaube, es ist nicht so, wie das zitat sagt. Nicht dass da unsinn steht, aber die ETSI TS 103 127 bezieht sich auf DVB-IPTV. Den common scrambling algo gibt es nicht frei verfügbar. Aber wenn ich mich richtig erinnere, gibt es zumindest eine analogie zu dem zitat. Der CS verwendet 2 algos und zwar einen block cipher und einen stream cipher. Wenn der rest zu klein für den block cipher ist (sog. residuum) wird nur der stream cipher angewendet, was eine gewisse schwachstelle sein könnte. Also wären die 2 restbytes auch nicht in clear.

 

Sky macht also keine mist, hat aber im H.264_SD_encoder zumindest eine merkwürdigkeit, was diese restpakete betrifft. Wenn man die aufnahme durch den TSDoctor jagt, verschwinden die disconties. Das finde ich auch bemerkenswert. Ich werde Cypheros mal drauf hinweisen.

 

Snap103.png

 

Kein Ort ohne dich - Liebesdrama_Sky Emotion_2016-09-22_fixed.log

Link to post

Zum vergleich wäre ein aufnahmeschnipsel von @MaxB noch ganz interessant. Sein CAM macht es ja anscheinend richtig.

 

,

Bei beiden Aufnahmen vom selben TS sind keine Diskontinuitäten aufgetreten.

Link to post

Ich habe jetzt noch 2 test samples von @MaxB gecheckt. Einmal mit und einmal ohne CI. Alle pakete mit nur einem byte payload (adaptation field length = 182) sind im entschlüsselten stream als nicht verschlüsselt gekennzeichnet und bis auf das scrambling control field identisch mit den verschlüsselten paketen. Anscheinend braucht der videodekoder das singuläre byte überhaupt nicht, denn bei mir waren in den stream mit gedropten paketen keine störungen sichbar.

Link to post

Interressantes Thema, welches mich dazu bewegt hat ein paar getätigte Aufnahmen mal zu kontrollieren.

Mir ist diese Klötzchenbildung beim Abspielen von laufenden Aufnahmen aufgefallen, und ich habe dieser deshalb keine weitere Bedeutung zukommen lassen. Bei Timeshift ist mir nichts aufgefallen. Die Fehler sind definitiv im aufgenommenen File vorhanden. Wenn ich allerdings Timeshift mache, und die laufende Timeshiftdatei wegkopiere so ist diese sauber! Nicht ein Fehler. Habe beides gerade noch mal ausprobiert und mit dem Doctor verifiziert und es ist reproduzierbar.

Eventuell konnte ich damit für noch etwas Ver- oder Entwirrung sorgen.

 

Übrigens:

Die haben doch schon vor einem knappen Jahr auf S2 und H.264 umgestellt. Damals hatte ich noch ein anderes CAM, bei welchem mir keine Fehler aufgefallen sind.

Link to post
Anscheinend braucht der videodekoder das singuläre byte überhaupt nicht,

 

Er braucht es, selbst wenn er es nicht braucht, weil sonst Längenangaben in den Videodaten nicht mehr zutreffen. Das fängt schon beim PES-Header an. Eine sehr gute Fehlerbehandlung könnte allerdings einiges von den Folgen unsichtbar machen.

 

Wenn ich allerdings Timeshift mache, und die laufende Timeshiftdatei wegkopiere so ist diese sauber!

 

Im Gegensatz zu Aufnahmen wirft der der DVBViewer bei Timeshift Pakete mit gesetzten Scrambling Flags nicht raus und speichert den vollständigen Stream. Das dürfte es erklären.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...