Raten und Taten

Apps, Downloadmanager, und Plugins für Save.TV
z80
Beiträge: 25
Registriert: Fr 14. Okt 2016, 00:18
bevorzugter Onlinevideorecorder: safe.tv

Raten und Taten

Beitrag von z80 » Mo 18. Mär 2019, 00:01

Raten und Taten


Hallo an die Mitkunden bei safetv.
Ich plage mich seit Jahren mit einer Reihe Problemen im Zusammenhang mit meiner safetv Nutzung herum.
Primaer gehts mir da um fehlenden Komfort aufgrund meiner Ansprueche / Nutzungsweise und reicht von Aufnahmeprogrammierung, Metadatenbeschaffung und -verwaltung bis zu Verwaltung beim und Zugriff zum Konsum.
Das alles im Detail jetzt auszufuehren wuerde sicher den Aufmerksamkeitsrahmen jedes noch so geneigten Lesers sprengen, daher muss ich das vertagen.

Ein konkretes Problem mit dem ich mich aktuell beschaeftige:
Nicht alle runtergeladenen Aufnahmen sind astrein. Manche sind technisch kaputt, in dem Sinne das Ton aussetzt, Bildartefakte auftreten etc.
Andere sind schlecht geschnitten, haben fehlende Enden/Anfaenge oder (primaer bei privaten Sendern) stoerende Bild-/Toneinblendungen.
Bisher loese ich das so, dass ich interessierende Sendunge so oft wie moeglich aufnehme, und sobald ich wenigstens drei Aufzeichnungen habe die von Hand mit VLC vergleiche und die beste aufhebe.

Das kostet aber ewig viel Zeit, so dass mein Plattenstapel nicht kleiner sondern groesser wird (mittlerweile ca + 1x 8TB USB HD / 2 Monate).

Um zumindest schonmal technisch kaputte Aufzeichnungen auszufiltern (was mir auf Anhieb leichter erscheint) wollte ich dafuer also einen Automatismus bauen.

Im ersten Schritt habe ich ffmpeg.exe benutzt um die Files zu pruefen.
Leider geht das (fuer meine Ansprueche) viel zu langsam.

Hier mal die Messwerte fuer meine zwei Systeme (die Namen leiten sich von den Gehaeusefarben ab):
https://www.technikaffe.de/cpu_vergleic ... _g1820-330
Blacky
AMD A8 5500 quadcore (2phyische, 4logische CPU's) 3.2 GHz
4GB RAM
Win10 64bit)
Whity:
Intel Celeron G1820 dualcore (1phyische, 2logische CPU's) 2.7GHz
8GB RAM,
Win7 prof 64bit
Whity [min:s]Blacky [min:s]filesizeHD/SDplaylengthErrorsDetectedErrorsPresent
00:0400:0419871770SD01:37nono
00:0500:0629249989SD02:24nono
04:4104:171036837721HD44:23yesyes
05:1104:431041796630HD44:21yesyes
10:1309:322036024882HD1:27:01noyes
Dabei faellt auf das in einem Fall die Fehler nicht erkannt wurden (Blockartefakte in einer BR-Aufzeichnung wo sowas haeufiger vorkommt).

Ob die Dateien von lokaler SSD oder mit max ca 100MByte/s ueber SAMBA kamen hat keinen Einfluss gehabt.
Auf beiden Systemen waren alle(!) CPU's waerend ffmpeg permanent maximal ausgelastet, d.h. CPU ist der Flaschenhals.

Ich habe jetzt mehere Moeglichkeiten das zu beschleunigen:
a) neuen Rechner/CPU
b) ffmpeg hoeher-optimiert (fuer meinen jeweiligen Prozessor) compilieren
c) nicht ffmpeg.exe nutzen sondern die lib in einer eigenen Applikation, da ich z.B. das lange errorlog nicht brauche sondern nur die info wo (also offet zum beginn des videos in min:s) fuer wie lange fehler auftreten
d1) mp4 dekodierung intels quick-video ueberlassen
d2) mp4 dekodierung auf dedizierte GPU auf dem AMD-System verlagern

Um fuer a) eine Entscheidungsbasis zu schaffen braeuchte ich Messwerte von neueren/potenteren CPU's (ich kann nur so um die 100EU ausgeben, frage ist ob 200EU fuer diesen Anwendungsfall auch x2 Leistung bringen).

Ich stelle daher unter
https://1drv.ms/f/s!AuIgbkjwWdC5iGhFMAcljRNXGCeW
meine batch-Dateien zur Verfuegung so das jeder der moechte das auf seinem Win-System nachvollziehen kann.
An dem Ort liegen zwei Archive:
- meine Batches + das von mir genutzte ffmpeg
- nur meine Batches

Da die Laufzeiten erheblich sind mein Tip: erstmal
checkfile [irgendwas.mp4]
ausprobieren um die Leistungsfaehigkeit des eigenen Systems einschaetzen zu koennen.

Spaeter (um z.B. das ganze eigene Archiv zu testen):
checkdir [Path]
bzw.
checkdir [Path] /S
fuer rekursives abarbeiten.

Wuerde mich freuen wenn wer Messwerte teilt, zumindest ist das aber ein Werkzeug fuer Euch um Eure archivierten Aufnahmen 'schnell mal' zu checken.


[EDIT]
1)
Hab gerade rausgefunden wie ich hier Dateianhaenge dranpappe, d.h. muss keiner auf meinen (uU irgendwann nichtmher verfuegbaren) onedrive-account zugreifen um die batches zu benuzen
batches.zip
(658 Bytes) 27-mal heruntergeladen

2)
Die batches fahren vermutlich gegen die Wand wenn man Pfade mit Leerzeichen benutzt, bzw. verschlucken sich an Anfuehrungszeichen.
Wer will kann das gerne robuster gestalten, ich steh auf dem Standpunkt:
Wer Umlaute und Leerzeichen in Dateinamen/-pfaden verwendet, hat saemtliche denkbaren Schmerzen verdient.
[/EDIT]
Zuletzt geändert von z80 am Mo 18. Mär 2019, 23:28, insgesamt 2-mal geändert.



Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
sv00010
Beiträge: 473
Registriert: Sa 20. Feb 2016, 16:41
bevorzugter Onlinevideorecorder: onlinetvrecorder.com
Kontaktdaten:

Raten und Taten

Beitrag von sv00010 » Mo 18. Mär 2019, 17:43

z80 hat geschrieben:
Mo 18. Mär 2019, 00:01
Nicht alle runtergeladenen Aufnahmen sind astrein. Manche sind technisch kaputt, in dem Sinne das Ton aussetzt, Bildartefakte auftreten etc.
Andere sind schlecht geschnitten, haben fehlende Enden/Anfaenge oder (primaer bei privaten Sendern) stoerende Bild-/Toneinblendungen.
Aus diesem Grund bin ich kein Save.tv-Kunde mehr.
Ich wüsste nicht was ich gegen solche Sachen tun kann.

Link:
BBcode:
HTML:
Hide post links
Show post links

Fredel
Beiträge: 830
Registriert: So 21. Feb 2016, 20:45
bevorzugter Onlinevideorecorder: Save.TV

Raten und Taten

Beitrag von Fredel » Di 19. Mär 2019, 21:30

z80 hat geschrieben:
Mo 18. Mär 2019, 00:01
[...]Das kostet aber ewig viel Zeit, so dass mein Plattenstapel nicht kleiner sondern groesser wird [...]Blockartefakte in einer BR-Aufzeichnung wo sowas haeufiger vorkommt).[...]
Kommt mir bekannt vor. Ich kombiniere Dubletten Archivierung, gezielte manuelle Vergleiche (Anfang, Ende, 5 min Sprünge von Hinten nach Vorne, je nach Wichtigkeit 2,5 min Versetzt von Vorne nach hinten) , plus Wichtigkeit (pro Sprung nur 0,5 Sek abspielen, oder 1+ Sprung mit wenigen Sekunden) und Erfahrungswerte (BR kann ich bestätigen). Beim ungeprüft Dubletten ramsch spare ich mir das Raid, beim Langzeitarchiv Gespiegelt. Downloads erfolgen Plattenschonend auf eine SSD. Im Prinzip ein monetärer Kompromiss aus Hardware- und Arbeitszeit.

Ein Programm, welches mindestens die Fehler erkennt, nur eben zuverlässiger, welche ich manuell Erkenne, würde ich verwenden. Am besten alle Dateien in einem Verzeichnis.

Ein kurzer Blick schadet ja nicht. Man sollte immer kurz checken: Qualität (neuer = nicht immer besser, häufig aber schon), Formatverbesserungen oder Verschlechterungen (ehemals 4:3 in 16:9 manchmal mit „weniger+hochwertig“ / mit „weniger + gleiche Qual“ / mit „mehr + gleiche Qual“ / und kaum zu glauben manchmal „mit mehr + besser“). Ich hab da manche Serien – ja ist wirklich so - 20 fach. Und Ihr glaubt es kaum, mit allen Staffeln plötzlich in 16:9 mit mehr Content in besserer Qualität (ÖR), aber nur 1 mal. Verrückt. Ohne meine heftigen Materialeinsatz hätte ich die wohl nicht.

Zensur, „Werbewdh.“ (+20-60 Sekunden Wiederholung nach jeder Werbung) ausfiltern, sowie Sender Querschläger (manchmal landet eine Aufzeichnung X und der Aufnahme Y … *kotz*). Auf eine solche „intelligente“ Erkennung, welche ich bislang mache ohne mich lange aufzuhalten, würde ich dann öfter mal verzichten.
jDownloader & Save.TV: 1. Schritte - automatischer Download <--> Save.TV Manager Version 3 Update: Favoriten retten

Link:
BBcode:
HTML:
Hide post links
Show post links

z80
Beiträge: 25
Registriert: Fr 14. Okt 2016, 00:18
bevorzugter Onlinevideorecorder: safe.tv

Raten und Taten

Beitrag von z80 » Mo 25. Mär 2019, 00:52

Zunaechst mal Dank fuer 0 Messwerte nach 1Woche :/

Wenigstens haben zwei Foristen bewiesen dass das Forum nicht total tot ist und meine geschilderten Aergernisse real sind.

Ich habe einen ordentlichen Performance-Schub erreicht indem ich ffmpeg bei dem check der Files den codec nutzen lasse, der Intels QuickSyncVideo (QSV) nutzt.
Zum Glueck musste ich ffmpeg dafuer nicht selbst compilen, sondern das ist im downloadbaren Windows-Build schon drin.
Insgesamt sind da alle Optimierungen fuer alle Prozessor-Befehlszaetze drin, und beim Start wird der passende Codepfad zu den Faehigkeiten der ausfuehrenden CPU gewaehlt.

Das zu recherchieren hat viel Zeit gekostet, daher hier die Primaerresourcen die ich genutzt habe, falls wer das nachvollziehen will:
https://stackoverflow.com/questions/433 ... chitecture
-> mit gcc kann man besser auf eine konkrete CPU optimeren als mit VisualStudio, aber fuer so konkrete Sachen wie Cachesize oder CPU-Cycles/Command optimiert der GCC auch nicht sondern eben nur fuer Befehlssaetze.

Man koennte also bestenfalls ein bissel was an Codesize einsparen, wenn man nur die Codepfade fuer die eigene CPU in der LIB laesst..

Meine Bauversuche mit cygwin fuer ffmpeg waren also unnoetig. Geklappt hats trotzdem:
http://www.mediaentertainmentinfo.com/2 ... gwin.html/
https://www.intel.com/content/dam/www/p ... -valid.pdf

Nicht unwichtig für den weiteren Fortgang des Projektes, da ich mit Visual Studio entwickeln, aber mit gcc (im Zweifel ueber MinGW) compilen will, da ich parallel fuer Windows und Linux entwickeln moechte.
D.h. ich will am Ende aus dem selben Quellcode Binaries fuer Win und Linux bauen koennen.
GUI wird ueber einen embedded Webserver plattformunabhaengig gehalten:
https://www.codeproject.com/Articles/29 ... Web-Server

Aber zurueck zum Thema:
Ueber die angepassten Skripte am Ende dieses Posts kann man nun (so man eine Intel-CPU mit QSV hat) also auch mit diesem CPU-schonendern Codec seine Dateien pruefen.

Ausserdem habe ich den Output fuers Logfile angepasst, so dass man den jetzt direkt in LibreOffice/calc reinpasten kann um sich die Dauern (=Differenzen zwischen Ende und Start) ausrechnen zu lassen.

Dabei faellt fuer meine Gen4 Celeron CPU auf das fuer die QSV garnicht offiziell unterstuetzt wird:
https://trac.ffmpeg.org/wiki/Hardware/QuickSync

und das die Ergebnisse unbestaendig sind (d.h. bei mehreren Durchlaeufen kriege ich unterschiedlich Werte [sichtbar an der Laenge des Errorlogs] bei identischem Input).

Hier jedenfalls die Messwerte auf meinem Intel-System ('Whity') fuer die drei Durchlaeufe
IDCommandlineComment
STDcheckDir.bat e:\coding\ZNAP\CLI\testfiles\ohne QSV: Dateien von lokaler SATA-SSD
QSV1checkDirQSV.bat z:mit QSV: Dateien ueber GigaBit SAMBA
QSV2checkDirQSV.bat e:\coding\ZNAP\CLI\testfiles\mit QSV: Dateien von lokaler SATA-SSD
Dabei meint das HD/SD im Dateinamen die Aufloesung und OK/defekt sind meine subjektiven Einschaetzungen nach meinem bisherigen manuellen Verfahren (hatte dafuer extra ein paar defekt-Samples aufgehoben).

FileFilesizeResultErrorSizeDurationResultErrorSizeDurationResultErrorSizeDuration
STDSTDSTDQSV1QSV1QSV1QSV2QSV2QSV2
01_SD_OK198717701000:00:04114500:00:02114500:00:01
02_SD_OK292499891000:00:05114500:00:020376200:00:03
03_SD_OK2117119541000:00:4302193300:00:140227600:00:15
04_HD_OK2142567211000:01:0401992000:00:2805522500:00:20
05_HD_OK5123765371000:02:3505998600:00:5106813700:00:51
06_HD_OK10001624221000:04:54035685800:03:11013803800:01:46
07_HD_defekt10368377210512240000:04:510294199400:01:410306084700:01:47
08_HD_defekt1041796630093458300:05:23052833500:01:34053266300:01:36
09_HD_OK20021531441000:09:22040656400:04:09029627500:03:00
10_HD_defekt20360248821000:10:38035646700:03:43028464500:03:27
11_HD_defekt20519591481000:06:11011155300:01:3407761900:01:29
12_HD_defekt2357389123097667900:11:26053268000:05:07052805600:03:37
Total12513790041703366200:57:16533658000:22:38504768800:18:13
Bild

Hier noch die Lastanzeigen des Taskmanagers fuer
STD
Bild
QSV1
Bild
QSV2
Bild


Kann das mal wer auf anderen/moderneren/schnelleren Intel-CPU's nachmessen ?

Hier die noetigen batches:
batches.zip
(1.09 KiB) 31-mal heruntergeladen

Und das zip mit allen Messwerten und errorLogs:
measurement.zip
(515.52 KiB) 27-mal heruntergeladen

Link:
BBcode:
HTML:
Hide post links
Show post links

Fredel
Beiträge: 830
Registriert: So 21. Feb 2016, 20:45
bevorzugter Onlinevideorecorder: Save.TV

Raten und Taten

Beitrag von Fredel » Mo 25. Mär 2019, 20:37

Ich werd auch mal eine fehlerhafte Datei messen, so ich bei neuen Downloads eine finde, auf die Schnelle hier eine fehlerfreie HD. Allerdings bin ich mir nicht so sicher, ob der Test überhaupt funktioniert hat. Da die Auswertung nicht so aussieht, wie in Deinem Beitrag. Offensichtlich hast Du die Tabelle selbst erstellt. (Intel i3-4160 3,1GHz, w7x64) Verwendet wurde scheinbar nur 1 CPU.

Code: Alles auswählen

OK;Filename;Filesize;start;end;errorsSize
0;M:\Neu\MP4\Die_Bruecke_I_Transit_in_den_Tod_S01E01_ZDF_HD_180921.mp4;2195685185;20:31:21,77;20:33:46,47;145
20:31:21,74 .. 20:33:46,65 checked with QuickSyncVideo dir   

Code: Alles auswählen

[NULL @ 000000000043f640] non-existing SPS 0 referenced in buffering period
[NULL @ 000000000043f640] SPS unavailable in decode_picture_timing

Code: Alles auswählen

OK;Filename;Filesize;start;end;errorsSize
0;M:\Neu\MP4\Undercover_in_Nordkorea_Im_Reich_des_K_2019-03-08_2350_792036.mp4;698927722;20:43:25,20;20:44:54,27;155840
20:43:25,16 .. 20:44:54,44 checked with QuickSyncVideo dir   

Code: Alles auswählen

[NULL @ 0000000002e3e200] non-existing SPS 0 referenced in buffering period
[NULL @ 0000000002e3e200] SPS unavailable in decode_picture_timing
[h264_qsv @ 0000000000632740] Error during QSV decoding.: unknown error (-1)
Error while decoding stream #0:0: Unknown error occurred
ff. Zeile 3-4 bis 2249
[null @ 0000000002cf14c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 171048 >= 171026
ff. bis 2271
jDownloader & Save.TV: 1. Schritte - automatischer Download <--> Save.TV Manager Version 3 Update: Favoriten retten

Link:
BBcode:
HTML:
Hide post links
Show post links

z80
Beiträge: 25
Registriert: Fr 14. Okt 2016, 00:18
bevorzugter Onlinevideorecorder: safe.tv

Raten und Taten

Beitrag von z80 » Mo 25. Mär 2019, 22:35

Vielen Dank @ fredel fuer die Messung!

Die Zeiten liegen ungefaehr in der Dimension meiner CPU.
Das mit dem nur einen Kern kann ich bestaetigen, aber das ist gut:
Auf meinem Dualcore wurde dadurch im Batchbetrieb (test aller 12 files hintereinander) immer abwechselnd eine CPU zu knapp 95% und die andere zu 10-50% belaster.
Ohne QSV (also mit standard mp4-decoder) waren alle Cores voll ausgelastet (2/2 auf dem Dualcore inter, 4/4 auf dem AMD Quadcore).
Das wird wohl zwangslaeufig irgendwann in thermische Probleme/Drosselung fuehren.
Ich hab heute auf Arbeit mal einen 6th Gen Intel (mit 3 von 4 nutzbaren cores) vermessen. Die Differenz zu meinem System wuerde auf jeden Fall keine CPU-Aufruestung rechtfertigen.
Ich hab ausserdem mal kurz zu ffmpeg nachgelesen ob man das auch irgendwie auf AMD beschleunigen kann.
Hab aber unter der Woche aber kaum Zeit mich damit auseinanderzusetzen da die Coderei auf Arbeit (realtime unter Windows) mir wenig Luft laesst + mich bis unter die Dusche verfolgt.
Aber am Wochenende mach ich weiter in Bezug auf den MediaChecker.

Aber zurueck zum Thema andere hardwarebeschleunigte codecs:
https://trac.ffmpeg.org/wiki/HWAccelIntro
AMD scheint nur beim encoden von mp4 beschleunigt zu werden, nicht beim decoden.
Interessant waeren die nvidia Werte.
Ich hab nur leider keine entsprechende Graphikkarte, aber vielleicht lohnt sich eine ensprechende Anschaffung eher denn neue CPU.
Insbesondere da die Ergebnisse des QSV-runs in Sachen Verwertbarkeit (in der aktuellen Form) eher witzlos sind:
Wenn da verschiedene errorlogs bei wiederholten Laeufen mit den selben Daten rauskommen kann ich auch gleich wuerfeln.
Aber vielleicht lassen sich da mit wenig Aufwand auch 'Scheinfehler' ausfiltern..

Zur Auswertung:
Ich habe die Batches immer ueber ein Verzeichnis mit den 12 testfiles laufen lassen.
Die resultierenden workDir.log habe ich in libreoffice/calc reingepastet (jeweils auf ein neues Tabellenblatt), jeweils eine Spalte drangehaengt die '=E1-D1' die die Dauern berechnet und die resultierenden Spalten der Einzeltabellen in eine gemeinsame kopiert (die calc-datei ist im verlinkten 'measurements' meines vorherigen Beitrages enthalten).

Fuers Forum hier hab ich dann die markdown/ASCII-art Tabelle mit Notepad++ bearbeitet (das vertikale editieren mit ALT+rightmouse-drag ist dafuer schwer hilfreich).

Die Forensoftware zaubert dann aus '--|--' etc. eine schoene Tabelle, musste ich mich mit der Vorschaufunktion des Editors hier aber selbst rantasten.

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
Fox   
Administrator
Beiträge: 878
Registriert: Do 3. Mär 2016, 13:29
bevorzugter Onlinevideorecorder: (Eigenbau)
Kontaktdaten:

Raten und Taten

Beitrag von Fox    » Di 26. Mär 2019, 17:39

Ich habe es mir auch einmal angesehen ;)

ffmpeg Batch-Skript
Also auf meinem System (i7-3632qm) benötigt eine SaveTV 1h 7min HD-Aufnahme 5 min 3s (DXVA) und 4 min 4s (CPU). Intel Quick Sync spuckt hingegen nur Fehler aus. Theoretisch kann man über DirectX Video Acceleration (DXVA) (FFMPEG-Flag: -hwaccel dxva2) unter Windows die Hardwarebeschleunigung nutzen. Defacto hängt es aber stark vom DirectX Grafikkartentreiber ab, wie viel dies bringt.

Die Hardwarebeschleunigung führt allerdings dazu, dass nicht mehr der reine Software-Decoder genutzt wird. Meistens enthält man als Entwickler wesentlich weniger Rückgaben und Informationen, weswegen dies für gezielt diese Aufgabe ungeeignet ist. Darüber hinaus wird mit dem gegebenen -loglevel error nur ein aufgetretener schwerwiegender Fehler gemeldet werden. Bereits auf dem -loglevel warning wird ein Fehler nicht mehr gemeldet, falls der Decoder in der Lage war, diesen zu kaschieren.

Code: Alles auswählen

ffmpeg -loglevel level+info -err_detect crccheck+bitstream+buffer+careful+compliant+aggressive -i %1 -map 0 -f null -

Der konkrete Decoder 'h264' ist so fair und meldet auf dem Info-LogLevel, wenn er eine Error Concealment Strategy einsetzt um ein Bitstream-Problem zu kaschieren, welches ich (als Beispiel) durch einen Bit-Flip im Hex-Editor künstlich erzeugt habe.

Code: Alles auswählen

[h264 @ 0000028b549762c0] [info] concealing 498 DC, 498 AC, 498 MV errors in I frame

Decoder mit irgendeiner Hardwarebeschleunigung werden wohl kaum derartige Information liefern, da dies zu tief in Details des Hardware-Decoders gehen würde. Nutzer geizen gerne bei Hardware und Entwicklungskosten und würden Sturm laufen, wenn man ihnen nicht immer eine schöne Heile Welt vorgaukeln würde. In der Praxis ist Software deswegen daraus ausgelegt mit Fehlern zu arbeiten und sie zu vertuschen oder zu umgehen.

Erläuterung des FFMPEG-Befehls
Ich bin mit Batch noch nicht wirklich warm geworden, weswegen ich dir den Part überlassen würde.
  • -loglevel level+info (äquivalent zu -v): Legt das LogLevel fest und das angegeben werden soll, auf welchem Level eine Ausgabe erfolgt.
  • -err_detect: Flags um Informationen wir CRC-Prüfsummen überprüfen zu lassen und Fehler zu melden.
  • -map 0: Dekodiere alle Streams (nicht nur die Vorausgewählten) - hilfreich falls bspw. mehrere Audiospuren verwendet werden.
Das Speichern der Ausgabe in einer Log-Datei kann mittels -report erfolgen. ;)

Off-Topic aber vielleicht auch interessant
Bei der Übertragung von Dateien via OpenVPN zwischen Amsterdam (Shadow.Tech Cloud-PC - Save.TV hat ein Rechenzentrum in Amsterdam) und Karlsruhe sind 2 von 26 Übertragenen Dateien anschließend defekt gewesen, was ich anhand der CRC32-Prüfsumme feststellen konnte. Auch bei der Dateiübertragung zwischen Karlsruhe und Heidelberg gehen gelegentlich Dateien kaputt (Bei der heutigen Größenordnung von Datenströmen ist eine TCP-Prüfsumme offenbar unterdimensioniert. Dieses Protokoll wäre zumindest für die fehlerfreie Übertragung zuständig gewesen.). Ich dränge SaveTV schon seit Jahren für seine Download/Streamingserver TLS einzusetzen (darüber wird Datenschutz & Datenintegrität gewährleistet, auf einem höheren Level als es TCP möglich ist) allerdings werden die Aufnahmen bis dato unverschlüsselt und ohne jegliche Prüfsumme angeboten.

Bei mir sind auch bereits 2x WD RED innerhalb der Garantie abgeraucht und es gab sowohl Bad Sectors als auch unerkannte Fehler in "Clean Sectors" in denen die ECC-Hadwarefehlerkorrektur versagte, die unsichtbar auf HDDs Speicher/Lesefehler korrigiert. Dateisysteme wie BTRFS setzen Prüfsummen für Dateistrukturen ein und im LINUX/UNIX-Umfeld werden SHA1/MD5-Prüfsummen bei Downloads als die reinste selbstverständlichkeit mitangeboten. Im Usenet hat man sich dazu entschieden Paritäts-Korrekturdaten einzusetzen, hingegen sind im Warez Prüfsummen (CRC32, SHA1, MD%) verbreitet und DAU-freundlich innerhalb durch WinRAR-Container gekapselt sowie das Matroska (MKV) Containerformat für die enthaltenen Datenströme Prüfsummen unterstützt. Zu guter letzt werden im Serverbereich Serienmäßig ECC-Fehlerkorrigierende Arbeitsspeicher eingesetzt.

Ich setze CRC32-Prüfsummen mit RapidCRC ein und migriere diese zurzeit zu BLAKE2, ein Algorithmus der auch in WinRAR genutzt wird, um Fehler bei der Übertragung und Speicherung zu erkennen. Das Problem bei SaveTV ist allerdings dass bei der Aufnahme Artefakte auftreten. Eine anschließende Überprüfung mittels ffmpeg wird allerdings den Datenstrom auf Codec-Probleme prüfen und derartige Störungen nicht erkennen können. Man muss sich das vorstellen, als würde man ein Screenshot von Artefakten anfertigen und das Screenshot selbst wird fehlerfrei kodiert sein (aber nunmal Artefakte vorweisen). In solchen Fällen schiebt SaveTV die Artefakte gerne auf das TV-Signal des Senders und ich habe gekündigt, weil es mir damit zu bunt wurde und immer wieder auftrat.

XvId, H264, H265, usw. sind alles verlustbehaftete Kodierungsverfahren für Videos. Ähnlich wie wenn man im Drucker eine Kopie von der Kopie ausdruckt: Es enstehen Generationenverluste. Verschiedene Filter wie Deblock, Denoise und Deband versuchen das Originalbild wiederherzustellen oder künstlerisch aufzubereiten mit bspw. Dithering. Allerdings bedeutet dies Rechenaufwand und damit schlechtere Benchmark-Ergebnisse. ;)
Erkennen - Verstehen - Nutzen
Es gibt immer schlechte Beispiele - aber sollte man nicht versuchen, besser zu sein?

Link:
BBcode:
HTML:
Hide post links
Show post links

Fredel
Beiträge: 830
Registriert: So 21. Feb 2016, 20:45
bevorzugter Onlinevideorecorder: Save.TV

Raten und Taten

Beitrag von Fredel » Mi 27. Mär 2019, 15:48

Eine nicht erkannte fehlerhafte Übertragung digitaler Daten bei unzureichenden Prüfsummen.

Dass im Netzwerkverkehr also auch im Internet fehlerhafte Übertragungen entstehen, war mir nicht neu. Dass diese Fehler jedoch absichtlich nicht korrigiert und korrekte Daten angefragt werden, ist mir neu. Danke für die ausführliche Information, hab ich mit großem Interesse gelesen.
jDownloader & Save.TV: 1. Schritte - automatischer Download <--> Save.TV Manager Version 3 Update: Favoriten retten

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
Fox   
Administrator
Beiträge: 878
Registriert: Do 3. Mär 2016, 13:29
bevorzugter Onlinevideorecorder: (Eigenbau)
Kontaktdaten:

Raten und Taten

Beitrag von Fox    » Mi 27. Mär 2019, 16:57

Wird ein TCP-Prüfsummenfehler erkannt, wird das Segment verworfen und neu angefordert. Die TCP-Prüfsumme ist allerdings lediglich die Summe aus 16-bit Einerkomplementen und kann damit 16-Bit-Burst-Fehler erkennen. Bereits 3-Bit-Random-Fehler, symmetrische Fehler als auch Vertauschungen bleiben unerkannt. http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf & http://einstein.informatik.uni-oldenbur ... lement.htm - zum Glück sind das aber nicht die einzige Prüfsumme auf die es ankommt und aus dem IPv6-Protokoll wurden die Prüfsummen wieder entfernt. Dennoch traue ich der schwachen TCP/IP-Prüfsummen nicht und setze lieber auf MACs im TLS-Protokoll, welches immer bei der verschlüsselten Variante bekannter Protokoll (FTPS, HTTPS, etc.) zum Einsatz kommt.
Erkennen - Verstehen - Nutzen
Es gibt immer schlechte Beispiele - aber sollte man nicht versuchen, besser zu sein?

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
Fox   
Administrator
Beiträge: 878
Registriert: Do 3. Mär 2016, 13:29
bevorzugter Onlinevideorecorder: (Eigenbau)
Kontaktdaten:

Raten und Taten

Beitrag von Fox    » Mi 27. Mär 2019, 17:12

Fox    hat geschrieben:
Di 26. Mär 2019, 17:39
Eine anschließende Überprüfung mittels ffmpeg wird allerdings den Datenstrom auf Codec-Probleme prüfen und derartige Störungen nicht erkennen können.
Ich bin euch noch den Nachweis dafür schuldig, dass eine Überprüfung mittels ffmpeg die Aufnahme-Artefakte bei SaveTV nicht erkennen wird. Ich hoffe ihr glaubt mir es, wenn ich euch dieses Artefakt in einer mit Artefakten übersähten SaveTV-Aufnahme zeigen, in der ffmpeg fehlerfrei ohne geringste Anmerkungen durchläuft:
Deswegen würde ich dazu Raten nach anderen Möglichkeiten zu suchen, um den leiden mit defekten SaveTV-Aufnahmen ein Ende zu setzen.
2019-03-27_17h10_02.png
2019-03-27_17h10_02.png (696.07 KiB) 816 mal betrachtet
Erkennen - Verstehen - Nutzen
Es gibt immer schlechte Beispiele - aber sollte man nicht versuchen, besser zu sein?

Link:
BBcode:
HTML:
Hide post links
Show post links

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste