GBWebmaster Posted September 21, 2016 Author Share Posted September 21, 2016 Bei der NVIDIA CUVID - Einstellung sind bei mir alle Felder ausgegraut ... Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 Dann solltest Du bei AMD auf DXVA wechseln und trotzdem das ROT eingerahmte Häkchen entfernen. Quote Link to comment
Derrick Posted September 21, 2016 Share Posted September 21, 2016 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 Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 Was machen eigentlich diese Einträge im svcdebug.log? Disk limit reached! total 805320679424 - free: 313606144 - Min: 314572800 Quote Link to comment
nuts Posted September 21, 2016 Share Posted September 21, 2016 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? Quote Link to comment
Tjod Posted September 21, 2016 Share Posted September 21, 2016 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 Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 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... Quote Link to comment
GBWebmaster Posted September 21, 2016 Author Share Posted September 21, 2016 (edited) 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 September 21, 2016 by GBWebmaster Quote Link to comment
nuts Posted September 21, 2016 Share Posted September 21, 2016 Intel, Nvidia, AMD? Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 Laut Support.zip: OS: Windows 10x86Aero enabled: TrueDirectX: 12.0d3dx9_33.dll: TrueMemory: 2027 MBCPU: Intel® Core2 Duo CPU E8400 @ 3.00GHzCPU Speed: 3000 MhzCPU Count: 2Videocard: AMD Radeon HD 6570Version: 15.201.1151.1008 Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 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... Quote Link to comment
Derrick Posted September 21, 2016 Share Posted September 21, 2016 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.. Quote Link to comment
MaxB Posted September 21, 2016 Share Posted September 21, 2016 Da es hier ja um Disconties beim RS ging hier noch die Logs von zwei gleichzeitigen Aufnahmen: Sky Emotion 22.09.2016WHS2011-BM\TV-Aufzeichnung\2016_09-22_00-22-16_Sky Emotion_Verlobung auf Umwegen - Liebeskomödie.tsDevice: Digital Devices DVB-C Tuner 5 (5)EventID: 36239Timer Name: Verlobung auf Umwegen - LiebeskomödieTimer Start: 21.09.2016 23:57:00Timer 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=0Timer Source: Web 00:22:16 / 00:00:00 (~ 0,00 MB) Start Recording00:22:16 / 00:00:00 (~ 0,00 MB) Drugstore Cowboy undefined | EventID: 36240 PDC: 0x0000000:22:17 / 00:00:00 (~ 0,09 MB) PID 511: H.264 Video, 16:9, 720x576, 25 fps00:22:17 / 00:00:00 (~ 0,09 MB) PID 512: MPEG Audio Stereo, 48 khz, 192 kbps00:22:17 / 00:00:00 (~ 0,09 MB) PID 513: MPEG Audio Stereo, 48 khz, 192 kbps00:22:17 / 00:00:00 (~ 0,09 MB) PID 515: AC3 Audio Stereo, 48 khz, 384 kbps00:22:17 / 00:00:01 (~ 0,09 MB) Verlobung auf Umwegen running | EventID: 36239 PDC: 0x0000000:35:26 / 00:13:10 (~ 278,25 MB) Stop Average Data Rate: 0,352 MB/sTotal Size: 278,2 MB (291764344 Bytes)Removed Filler Data: 0,4 MB (0,2%) Sky Nostalgie 22.09.2016WHS2011-BM\TV-Aufzeichnung\2016_09-22_00-22-30_Sky Nostalgie_Patton - Rebell in Uniform - Kriegsfilm.tsDevice: Digital Devices DVB-C Tuner 6 (6)EventID: 45378Timer Name: Patton - Rebell in Uniform - KriegsfilmTimer Start: 21.09.2016 21:47:00Timer 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=0Timer Source: Web 00:22:30 / 00:00:00 (~ 0,00 MB) Start Recording00:22:30 / 00:00:00 (~ 0,00 MB) Bruce Lee - Mein letzter Kampf undefined | EventID: 45379 PDC: 0x0000000:22:31 / 00:00:01 (~ 0,00 MB) Patton - Rebell in Uniform running | EventID: 45378 PDC: 0x0000000:22:47 / 00:00:17 (~ 0,21 MB) PID 767: H.264 Video, 16:9, 720x576, 25 fps00:22:47 / 00:00:17 (~ 0,21 MB) PID 768: MPEG Audio Stereo, 48 khz, 192 kbps00:22:47 / 00:00:17 (~ 0,21 MB) PID 769: MPEG Audio Stereo, 48 khz, 192 kbps00:32:29 / 00:09:59 (~ 132,35 MB) Patton - Rebell in Uniform running | EventID: 45378 PDC: 0x0000000:32:30 / 00:10:00 (~ 132,79 MB) Bruce Lee - Mein letzter Kampf starts in a few seconds | EventID: 45379 PDC: 0x0000000:33:00 / 00:10:29 (~ 144,47 MB) Bruce Lee - Mein letzter Kampf running | EventID: 45379 PDC: 0x0000000:33:01 / 00:10:30 (~ 144,73 MB) Madame und ihre Nichte undefined | EventID: 45380 PDC: 0x0000000:35:26 / 00:12:56 (~ 194,33 MB) Stop Average Data Rate: 0,250 MB/sTotal 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. Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 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 Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 Das CI ist unschuldig. Tauscht euch über das CAM aus. Da hat nicht nur ich sondern auch DD die ursache vermutet Quote Link to comment
GBWebmaster Posted September 22, 2016 Author Share Posted September 22, 2016 OK, dann machen wir hier zu - Danke an alle, die mitdiskutiert haben. Gruß GBWebmaster Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 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.. Quote Link to comment
nuts Posted September 22, 2016 Share Posted September 22, 2016 Ü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? Quote Link to comment
Griga Posted September 22, 2016 Share Posted September 22, 2016 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. Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 ..dafür gibt es tools, die TSC direkt anzeigen. Sowohl hex als auch binär Quote Link to comment
GBWebmaster Posted September 22, 2016 Author Share Posted September 22, 2016 Dann können wir hier zu machen 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? Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 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. Quote Link to comment
Griga Posted September 22, 2016 Share Posted September 22, 2016 Der von TransEdit aufgenommene entschlüsselte Videostream zeigt wie erwartet, was los ist. Periodisch tauchen Pakete der folgenden Machart auf: 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. Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 @Griga war schneller 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. Quote Link to comment
GBWebmaster Posted September 22, 2016 Author Share Posted September 22, 2016 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 Quote Link to comment
Griga Posted September 22, 2016 Share Posted September 22, 2016 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.... Quote Link to comment
Derrick Posted September 22, 2016 Share Posted September 22, 2016 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? Quote Link to comment
Griga Posted September 22, 2016 Share Posted September 22, 2016 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... Quote Link to comment
nuts Posted September 22, 2016 Share Posted September 22, 2016 Gute Arbeit Leute. Quote Link to comment
nuts Posted September 22, 2016 Share Posted September 22, 2016 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? 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 ... Quote Link to comment
GBWebmaster Posted September 23, 2016 Author Share Posted September 23, 2016 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? Quote Link to comment
Derrick Posted September 23, 2016 Share Posted September 23, 2016 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. Kein Ort ohne dich - Liebesdrama_Sky Emotion_2016-09-22_fixed.log Quote Link to comment
Derrick Posted September 23, 2016 Share Posted September 23, 2016 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. Quote Link to comment
Derrick Posted September 24, 2016 Share Posted September 24, 2016 Der TSDoctor "repariert" aufnahmen mit disconties dadurch, dass die continuity counter korrigiert werden. Quote Link to comment
Derrick Posted September 26, 2016 Share Posted September 26, 2016 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. Quote Link to comment
duddsig Posted September 28, 2016 Share Posted September 28, 2016 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. Quote Link to comment
nuts Posted September 28, 2016 Share Posted September 28, 2016 Griga's Maßnahmen für die Aufnahmen waren nach ersten Tests erfolgreich. Quote Link to comment
Derrick Posted September 28, 2016 Share Posted September 28, 2016 ..ich würde nach den tests trotzdem vermuten, dass es gar nichts ausmacht, ob diese pakete drin sind oder gedropt werden. Quote Link to comment
Griga Posted September 28, 2016 Share Posted September 28, 2016 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.