Vorschlag zur Vermeidung von Bildsprüngen und zwar endgültig!

[Rude]

Es hieß vor einiger Zeit, dass OTR das Problem mit den Bildsprüngen bei Avi-Dateien scheinbar gelöst habe. Allerdings tritt es bis heute immer noch auf!
Die Bildsprünge, wie wir wissen, hängen nicht mit schlechtem Empfang in Gibraltar zusammen; nein! Sie werden durch Dekodierungsfehler bei Avi-Dateien verursacht.

Beispiel: Jede Avi-Datei hat genau 9:54 min Overlap.

Die Sendung dauert beispielsweise 1 h, also muss die Größe zum Schluss so aussehen: 1:09:54

Wenn die Bildsprünge allerdings schon bei der Orignalaufgenommenendatei auftreten, sagt es mir bitte.

Hier einmal der Weg der normalen Dateien:
Quailitativ sehr Hochwertige Aufnahme
Kompremierung
Kodierung
Bereitstellung

Die Fehler, durch die Bildsprünge verursacht werden, können bei allen Faktoren liegen. Hoffentlich nicht am obersten. Ich denke, es liegt an der Kodierung. Hier mein Vorschlag, wenn es an der Kodierung liegt, wenns an der Kompremierung liegt, einfach auch lesen. Das kann OTR bestimmt umsetzen.

Ein Film mit 2 Stunden Laufzeit wird aufgenommen, d.h. er braucht 9:54 min Overlap.

Zuerst wird also erst einmal die Zeit notiert. Danach wird kompremiert. Jetzt sollte OTR schon mit der ersten Kontrolle anfangen: Ist die unkompremierte Datei genau so lang wie die kompremierte. Wenn ja, gehts weiter zum nächsten Schritt. Wenn nein, wird die kompremierte Datei wieder gelöscht und die unkompremierte wird nochmal neu kompremiert. Dann wird, wenn das also geklappt hat die kompremierte Datei kodiert. Nun nimmt OTR die kodierte Datei, decodiert diese wieder und vergleicht nochmal die Länge mit der decodierten entstandenen Datei und der Ausgangsdatei, die codiert wurde. Stimmen sie überein, wird die kodierte Datei bereitgestellt. Wenn nicht, werden die kodierte und die daraus decodierte Datei gelöscht und die kompremierte Datei wird wieder kompremiert, solange bis alles klappt.

Nichts anderes als ein Ablauf von Checks!

[stonecoldcrazy]

Nunja.... also ich für meinen Teil muss schon sagen dass ich soetwas (Fehler in den Aufnahmen) herzlich wenig sehe.... wenn ich soetwas sehe muss ich schon sagen stört es mich recht wenig da diese Sprünge zwar an sich lästig sind aber nur sehr kurz andauern... Zu deiner Checkliste... man müsste aber zuersteinmal wirklich wissen woran das liegt... OTR ist ein Projekt einer Firma und die Firma hat so oder so sehr viel zu tun... Wenn man jetzt bei diesem Prozedere etwas ändern würde, dann würde man das ganze System nochmals umschmeißen.... wahrscheinlich würde dann erstmal ein chaos ausbrechjen... abgesehen davon, dass die Aufnahme-Einheit ja auch noch nebenbei weiter aufzeichnet und so ein Prozedere ziemlich CPU-aufwendig ist gibt es noch das problem, dass wenn der Fehler doch in der Aufnhame an sich liegt weil ein Lag oder so drinne ist sich das ganze in eine Endlosschleife einfädeln würde und man diese Aufnhameeinheit fürs erste vergessen könne... wenn die kaputt ist kannst du dir vorstellen wie schwer es ist diese mal eben schnell in Gibraltar zu reparieren^^.... du musst bedenken dass die einheit evtl ganz kaputt ist und neu angeschafft werden müsste...
So, habe hoffentlich keinen meiner Gründe vergessen^^....
Gruß
StoneColdCrazy

[Rude]

Also mich regen die Sprünge schon auf. Zumal kommen sie zwar nicht mehr so oft vor, aber sie kommen derzeit IMMER bei den Simpsons-Folgen am Sonntag vor. Passt da mal auf.

[mercury202]

@Rude:
Ich habe zwar keine Ahnung, wie viel Rechenleistung OTR im Keller hat, aber ich kann mir kaum vorstellen, dass sich das realisieren lässt: Da bräuchte man - bei der Menge an Daten, die OTR verarbeitet: c. 1 Dutzend Sender, 24 h am Tag, und das z.T. in mehrere Formaten - wohl ne Weile.

[Feckon]

kleine Sprünge wären ok, aber bei den Simpsons-Folgen am Sonntag fehelen grundsätzlich mittendrin 2 Minuten dank des Sprunges.

Woran liegt das???

Und klar hat OTR viel zu tun, aber die Vollständigkeit der Aufnahme ist fundamental für das Selbstverständnis und das Funktionieren des Dienstes.

Dieser Bug sollte als aller erstes analysiert und behoben werden!

[Luke321]

Nunja.... also ich für meinen Teil muss schon sagen dass ich soetwas (Fehler in den Aufnahmen) herzlich wenig sehe....

Da kann ich mich nur anschließen. Bei mir sind solche Sprünge noch nie vorgekommen...

[sw2005]

was ich bei dem Vorgehen nicht verstehe: wieso sollte ein Schritt mit denselben Ursprungsdaten nochmal wiederholt werden? Wenn die Codierung einmal einen Sprung produziert, tut sie es beim nächsten Mal doch erneut. Determinismus nennt man das, IIRC.

[ashcan]

Keine schlechte Idee, so könnte man auch feststellen ob bei Aufnahmen, von denen es eine HQ Variante gibt, in beiden Versionen zu den Sprüngen kommt. Wenn ja, dann muss der Sprung wohl schon bei der Aufnahme entstanden sein.

[george]

das problem mit sprüngen hatte ich schon lange nicht mehr, bis auf eine ausnahme:
Mission__Impossible_2_07.01.21_20-15_pro7_140_TVOON_DE.mpg.HQ.avi
es gibt in den ersten 15-20 min ein paar kleine sprünge - dann nicht mehr.
schreib ich trotzdem in der liste mit rein.

also:


Zeugin_der_Anklage_07.02.07_00-00_sw3_110_TVOON_DE.mpg.avi.otrkey
Mission__Impossible_2_07.01.21_20-15_pro7_140_TVOON_DE.mpg.HQ.avi


ps. hab die [LIST]-form weggelassen, da es für copy-paste nicht so gut geeignet ist...

[Raus]

Ich fange auch gerne mit der Liste an (die sollte jeder weitere Listenposter kopieren und durch seine Angaben ergänzen, dann bliebe alles zusammen und würde nicht auf 100 Posts verteilt):

Wenn jetzt jeder die Liste um ein File ergänzt, dann wären es bei 100 Usern trotzdem 100 weitere Postings!

Was haltet ihr davon, wenn sich einer von euch bereit erklären würde, per PN alles zu sammeln und nach einem gewissen Zeitraum, dann die komplette Liste veröffentlichen würde?