Hallo,hm... *nachdenk*Zitat von monarc99
wurde dann vermutlich auf der HD-Pooling-Einheit aufgezeichnet, weil es nicht in den Top20 war, aber darüber noch in die HD-Aufnahmen gerutscht ist.
Egal, ich stelle die dann alle (sind ja nur 2 andere momentan) mal um.
Vor wenigen Tagen habe ich von der Umstellung der Kodiereinstellungen erfahren. Nun habe ich mir eine HQ-Aufnahme von Ard vom letzten Dienstag runtergeladen und musste leider feststellen, dass mein Smart-Tv LG 47LK950S sie (wie auch bisher bei vielen HQ-Aufnahmen) nicht richtig abspielt. Das Bild ruckelt leicht und das Bild ist verzerrt. Es ist möglicherweise das Gleiche wie bei der Playstation 3. Der Fernseher unterstützt aber laut Handuch H.264 (bis Level 4.1) bis HD-Auflösung. Ich hatte gehofft, dass es mit den neuen Einstellungen nun funktionieren würde, denn ich gucke überwiegend über OTR TV, muss mich aber auf die DivX-Dateien beschränken. Ich wäre froh, wenn die HQ-Dateien 50% größer wären und ich sie dafür richtig abspielen könnte, ohne jede Aufnahme extra konvertieren zu müssen. Schade!
firmware ist aktuell? auf die schnelle fand ich ein update von januar und märz 2012.
(version 05.01.10 und 05.11.08)
alternativ kannst du dir auch mal OTR-Lemminge von monarc99 anschauen. damit werden die Dateien schnell in andere Container kopiert und oft hilft das!
Weil es aktuell nur ein einziges Programm gibt, mit dem man framegenau und schnell schneiden kann: Virtualdub! und das unterstützt leider nur avi.. wenn irgendwann mal avidemux framegenauen schnellen Schnitt von h264 unterstützt, wird es denke ich nur sehr kurze Zeit zum testen benötigen, bevor OTR auf MKV umstellen wird(das hatte zumindest mal nen Admin gesagt). Die Vorteile sind enorm, wenn nur dieser eine Nachteil nicht wäre!
Ich habe Abenteuer_Forschung_12.06.05_23-00_zdf_30_TVOON_DE.mpg.HD.avi.otrkey runtergeladen. Diese Datei lässt sich in der Tat abspielen. Es ruckelt zwar noch leicht, aber man sieht es kaum. Erstaunlicherweise ist diese Datei gemessen an der Länge deutlich größer. Vielleicht liegt es daran, dass die erste Datei defekt war.
Mein Vorschlag zu den Containern: Man könnte HQ und HD jeweils in allen drei Containern anbieten, also AVI, MKV und MP4. Dazu müsste man eine HD/HQ-Aufnahme aber nicht dreimal speichern, sondern könnte den Container on-the-fly beim Download ändern. So würde man keinen zusätzlichen Speicherplatz benötigen. Und Lemminge zeigt ja, dass nicht unbedingt viel Rechenleistung benötigt wird.
Man könnte ein Skript schreiben, das die gleichen Tools wie Lemminge benutzt und den Ausgabedatenstrom auf die Standardausgabe schreibt. So müsste man das Ergebnis gar nicht zwischenspeichern, sondern könnte es direkt über das Netzwerk verschicken. Das Skript könnte man für verschiedene Arten des Abrufs wie den normalen Download, FTP-Push, ... nutzen.
da brauchst du aber vmtl. rel. viel mehr rechenpower.
ausserdem wäre ein verteilen auf die mirrorserver so natuerlich nicht moeglich.
es wäre dann eine sonderleistung rein von OTR und dadurch vmtl mit mehr kosten verbunden.
on-the-fly ist aber selbst bei vielen downloads direkt von OTR sicher ein problem. das muessten ja dann eigentlich die downloadserver machen. die brauchen aber eher wenig cpu leistung ?
(ich habe aber selber die lemminge nicht getestet!)
Wenn man eine Datei am Stück lädt, mag das noch funktionieren. Aber wenn man sich vorstellt, das man einen unvollständigen Download fortsetzen will und nur das letzte MB laden will, dann geht das on-the-fly schon nicht mehr.
Mir fällt noch ein anderer Ansatz ein, alle Container anzubieten, ohne viel mehr Speicherplatz als bisher zu verbrauchen. (Er würde auch ermöglichen, bei den werbefreien Dateien Speicherplatz zu sparen.) Man könnte beim Kodieren zunächst für jeden Container eine Datei erzeugen, also eine mit AVI, eine mit MKV und eine mit MP4. Man könnte z.B. zuerst die AVI-Datei wie bisher erzeugen und dann mit Lemminge in kurzer Zeit die MKV-Datei und die MP4-Datei. Dann dürfte man aber nicht alle Dateien separat speichern, sondern man müsste die gemeinsamen Teile der Dateien nur einmal speichern. Bei großer Ähnlichkeit der Dateien würde man im besten Fall nicht viel mehr Speicherplatz benötigen als für eine der Dateien.
Damit die auf die Video-Dateien zugreifenden Anwendungen (z.B. die Webserver auf den Downloadservern) nichts von dieser Art der Speicherung wissen müssen, wäre es gut, wenn die Speicherung als Dateisystem implementiert wäre.
Ich habe eine ganze Weile nach einer geeigneten Umsetzung dieser Idee gesucht und bin schließlich auf Cromfs gestoßen (http://bisqwit.iki.fi/source/cromfs.html). Dabei handelt es sich laut Beschreibung unter der genannten Adresse um ein Read-only-Dateisystem. Soweit ich es verstanden habe, greift es nicht direkt auf die Festplatte zu, sondern existiert selbst als Image in einer Datei. Mit einem Tool erzeugt man das Image einmalig mit den Dateien, die rein sollen, als Inhalt. Das wären in diesem Fall die drei Video-Dateien (AVI, MKV, MP4). Gemountet werden kann das Dateisystem über Fuse (http://fuse.sourceforge.net/). Wenn es gemountet ist, kann man ganz normal auf die Dateien darin zugreifen. Eine Besonderheit von Cromfs ist, dass es Komprimierung beinhaltet und dabei die Ähnlichkeiten unterschiedlicher Dateien berücksichtigt. Trotz Komprimierung unterstützt es selektiven Zugriff auf Ausschnitte einer Datei. Wenn also nach einem abgebrochenen Download das letzte Megabyte einer Datei separat geladen wird, ist davon auszugehen, dass auch nur auf einen Teil der Datei zugegriffen wird.
Hast du denn ausprobiert, ob das funktioniert?
Auch wenn eine AVI und eine MKV bzw. eine MP4 den gleichen Film beinhalten, sind sie intern komplett anders aufgebaut. Da wird sich ein Algorithmus schwer tun, Gemeinsamkeiten zu finden.
mfg
monarc
Berechtigungen
