5min-Blöcke statt EPG + cutlist

[dreamer]

Zur Vermeidung von fehlendem Anfang/Ende:
Einfach den Tag in 288 Stücke à 5min unterteilen mit Überlap bis zum nächsten Keyframe. Dann eine auf dem EPG basierende cutlist (die via cutlist.de werberfrei und auf den wahren Anfang (bzw. Ende) modifiziert werden kann), die die Informationen darüber enthält, welche Teile runtergeladen und aneinandergereiht werden müssen. Dann noch die Dekodierberechtigungen (sobald 10 User Anfang/Ende bestätigt haben) anpassen und alles sind happy :D

Ok, jetzt zum Haken: Freiwillige vor, die das dann mirror- und downloadmanager-tauglich machen :( sorry, würd ich gern selbst machen, aber an GUIs und APIs scheitern meine hobby-programmierkenntnisse leider...
Ich weiß, dass FDM eine allgemeine mirrorsuche hat, evtl. kann man da eine modifikation auf otr-search.com & co machen...

und dass jetzt keiner denkt ich will lob einheimsen, die idee war schon:

Ich währe dafür, Aufnahmen in 15 Min Schritte zu machen.(kleiner geht auch)
Und dann haste eben die Möglichkeit die Entsprechenden Teile zu Dekodieren, und dann muss das ganze nur als gemeinsames Video zusammen gefügt werden.

An dieser Stelle wird es aber schwerer, dieses zusammenfügen müsste Automatisiert werden, dafür müssten die Aufnahmen aber auch so sein, das es keine Überlappungen gibt.
Am schönsten währe es halt, wenn mann eine Reihe von Datein in ein Verzeichnis packen könnte, und der Dekoder aus diesen Einzelteilen eine gemeinsame Filmdate macht.

Oder die Einfachere Variante, wer sich die Dateien am Rechner anschaut, der hat halt 6-8 Einzeldatein zum Ansehen, in WMP oder Winamp als Playlist, und mann bekommt fast nicht mit, wenn von einer Datei auf die andere gesprungen wird.
Somit würde sogar der Server entlastet werden, da es nur 24 Sdt Aufnahmen gibt, und nicht wie im Moment geschätzte 25-26 Sdt durch den Overlap

[...]

wobei da dann noch der Vorschlag war, statt zu programmieren statusabhängig eine bestimmte zahl von segmenten pro monat dekodieren zu dürfen

[PeGu]

... jedem, der das GWP-System für userunfreundlich kompliziert und zu komplex hält, rate ich, sich mit der Umsetzung dieses Vorschlags auseinanderzusetzen. Man denke ihn mal in die Umsetzung. Jeder OTR-User würde gezwungen, mit cutlists zu arbeiten, jeder müsste immer zwangsweise schneiden und neu speichern. Laden - gucken - löschen wäre passé für lange Zeit. ...

Kurz und knapp: PeGu ist schonmal dagegen.

[anatol.at]

wenn, dann müsste man das decoding-prizip auch erweitern wie ich es bereits im ursprünglichen thread beschrieben hatte.


der server müsste als zusätzliche information die wechsel-keyframes mitsenden und der decoder die streams an diesen zusammenfügen. somit könnte man den overlap zumindest auf wenige sekunden beschränken und könnte trotzdem ohne neukodierung auskommen...

ABER: man müsste hierfür auch eine eigene aufnahmesoftware schreiben... (oder ein modul schaffen, dass den ersten keyframe, der in beiden dateien vorhanden ist findet und in die datenbank schreibt...)
UND: den mirrors erschwert dieses prinzip das leben... (ein bisschen)

unter diesen voraussetztungen halte ich diese lösung für denkbar, jedoch habe ich bedenken bezüglich einer leistbaren realisierung...

[Cineatic]

Eine solche Lösung halte ich für äußerst ungünstig!

Zum einen müsste das System für alle hier unterstützten Betriebssystem umgesetzt werden, dann wäre man als User gezwungen, mit einem Downloadmanager zu arbeiten, man läuft 288 Mal am Tag Gefahr, das eine Aufnahme nicht klappt, die OTR-Rechner müssten 288 Einzelaufnahmen erstellen ...

Praktisch ist so etwas nicht umsetzbar.

[dreamer]

Eine solche Lösung halte ich für äußerst ungünstig!

Zum einen müsste das System für alle hier unterstützten Betriebssystem umgesetzt werden, dann wäre man als User gezwungen, mit einem Downloadmanager zu arbeiten, man läuft 288 Mal am Tag Gefahr, das eine Aufnahme nicht klappt, die OTR-Rechner müssten 288 Einzelaufnahmen erstellen ...

Praktisch ist so etwas nicht umsetzbar.

Ist das nicht sogar einfacher? Die Rechner müssten nur im festen Takt aufnehmen statt dynamisch über EPG, da kann doch viel weniger schiefgehen. Und die EPG-cutlist erstellen kann nebenher ein einzelner 386er für alle...

Die verschiedenen OSe sind IMHO das größere Probelm, und downloadmanager ist ja kein Zwang. Wie gesagt, wenn ich's könnte würde ich gerne ein Proggy basteln dem man nur die cutlist gibt und das dann wahlweise downloaded und schneidet oder streamt, aber bei meinem Talent würde das ne pothässliche Konsolenanwendung geben :-/

Wäre es nicht zumindest einen Test wert?

[DerCamperHB]

Cineatik im Gegensatz es gibt eine Höhere Chance einen Film doch noch sehen zu können, da es dann nur zu 5 Min Ausfällen kommt, wenn eine Datei verhunzt wird:D

Pegu sehe ich anders, wie im Zitat schon erwähnt, es muss nicht geschnitten werden, du kannst ja als Playlist alle Teile hintereinander vorspielen lassen.
Zugegeben, wer das ganze auf CD/DVD Brennt, hat evtl Mehraufwand, kenne jetzt da nicht den Aufwand, wenn mehrere Teile hintereinander überspielt/gesetzt und geschnitten werden.

Der Größte Aufwand kommt halt auf Mirror Betreiber zu, wenn die Einzeldateien als Kompremierte Datei angeboten werden will, da dann die Entsprechenden Teile erstmal zusammen gesucht werden muss

[anatol.at]

es muss nicht geschnitten werden, du kannst ja als Playlist alle Teile hintereinander vorspielen lassen.

dies würde nur zustreffen, wenn die aufnahmen EXAKT frame an frame passen... das halte ich für kaum realisierbar, also müsste man 2*2 sekunden overlap einbauen, um sicher zu stellen, dass die schnittpositionen vorhanden sind.
somit ist ein einfaches aneinanderreihen und abspielen vermutlich nicht machbar... im endeffekt läuft alles auf einen schnitt-decoder hinaus, der die parts korrekt zusammenfügt.

[thsths]

Zur Vermeidung von fehlendem Anfang/Ende:
Einfach den Tag in 288 Stücke à 5min unterteilen mit Überlap bis zum nächsten Keyframe.Im Prinzip ist das eine gute Idee. Am besten wuerde man genau an einem Keyframe schneiden, dann kann man die Stueck ohne Lueck und ohne Ueberlapp einfach zusammensetzen. Das geht vielleicht sogar durch einfaches aneinanderhaengen, oder mit einer Playlist.

Aber: ganz einfach ist das nicht, und ich wuerde gerne erst einmal eine Demonstration sehen. Schliesslich kann dabei eine ganze Menge schief gehen, und deshalb ist es vielleicht gar nicht praktisch machbar.


Ok, jetzt zum Haken: Freiwillige vor, die das dann mirror- und downloadmanager-tauglich machen :(Ohne einen Client wird das wohl nicht besonders nutzerfreundlich. Aber da man sowieso schon den Dekoder braucht, ist das eigentlich kein Problem.


wobei da dann noch der Vorschlag war, statt zu programmieren statusabhängig eine bestimmte zahl von segmenten pro monat dekodieren zu dürfenJa, das ist ueberfaellig. Man koennte sich natuerlich auch an der Dateigroesse orientieren, das ginge auch jetzt schon.

[DerCamperHB]

Es kommt halt drauf an, was die Server mit den Rohdaten anfangen.
Aber Vermutungen helfen wirklich nicht weiter, es muss ein Entsprechender Admin mit dem entsprechenden Fachwissen dazu Äußern, ob es möglich ist, Dateien zu erstellen, die Framgenau zueinander passen

[RocknRolf]

Bin auch dagegen. Ich stell mir grad vor 90 minuten in 5 min blöcken = 18 Dekodierungen...

[DerCamperHB]

R.Rolf was stellst du dir da so schlecht vor?

Du darfst die aktuelle Anzahl der Dekodierungsberechtigungen nicht Gleichsetzen, die muss dann angepast werden, sagen wir 20:1, das wahre dann 100Min für 1 alte Dekodierung.
Somit hättest du bei 2Std Filme zwar Weniger, bei kurzen aber mehr Dekodierungen.

Leecher 17 Dekodierungen /1700Min.

30Min = 56,67 Dek
60Min = 28,33 Dek.
90Min = 18,88 Dek
120Min = 14,17 Dek

Ist jetzt nur ein Beispiel, aber in der Größenordnung stell ich mir das vor

[DerCamperHB]

worfroz wer sagt den, das Overlap nötig ist, das ist eine Vermuttung, die aufgestellt wurde.

Wir brauchen erstmal eine Aussage, wie das Technisch möglich ist, dann können wir uns über das Konzept der Verbreitung unterhalten, leider Äussern sich die Admins nie dazu

[worfroz]

leider Äussern sich die Admins nie dazu

Dieser Thread wurde gestern Mittag gestartet, da würde ich innerhalb eines Tages (also bis Sonntag Mittag) auch nicht unbedingt eine Antwort erwarten... ;)

[DerCamperHB]

Worfoz die Idee ist schon 1 oder 2 Monate alt:D

Aber Recht hast du im Prinzip, wir warten noch bis MO, und erwarten erstmal eine Antwort bezüglich der technischen Umsetzung der Idee ab.
Kannst du den Entsprechenden Admin die Anfrage zukommen lassen? Wenn ich allgemein an den Admin Maile ist ja die Frage, ob das beim Richtigen Landet

[worfroz]

Kannst du den Entsprechenden Admin die Anfrage zukommen lassen?

Die Admins schauen mehr oder minder regelmäßig in dieses Forum, deswegen wurde es ja eingerichtet, damit Vorschläge nicht in anderen Threads untergehen. Ein Weiterleiten ist also nicht notwendig... ;)

[OTR.TH]

Hallo,
[...]Overlap nötig [...]

Wir brauchen erstmal eine Aussage, wie das Technisch möglich ist
zum technischen:
auf analogen treten dann bei Aufnahmebeginn/-ende die bekannten Lücken von 1-2 Sekunden auf.
Bei den digitalen kann je nach Auslastung nicht garantiert werden, dass die Aufnahme exakt sekundengenau startet, mal ganz von Keyframes etc. abgesehen. Sekundengenaue Start/Stop-Programmierung klappt nicht, nur minutengenau. Also wäre ein Overlap von einer Minute sicherheitshalber nötig (nur vorne oder hinten würde ja reichen).
Und die Arbeit, z.B. 24 5/6-Minuten-Blöcke für 120 Minuten schnittgerecht aufzubereiten, will sich glaub ich regelmäßig niemand antun, ganz abgesehen davon, dass das ganze für Neu-User ein KO-Kriterium sein dürfte.

Und von wegen Pooling-Sendern fang ich gar nicht erst an :D

[DerCamperHB]

Polling ist klar, da müsste mann sich noch etwas einfallen lassen.

Also werden einzelne Aufnahmen gestartet sprich es gibt mehrere Empfangsgeräte für 1 Sender, die die Einzelnen Aufnahmen tätigen.

Das ist doch mal eine Aussage.
Währe es nur 1 Empfänger, der Rohdaten zur Verfügung stellt, wo draus dann die Aufnahmen geschnitten werden, hätte die Geschichte ja anders aussehn können.

[anatol.at]

Danke für das Statement des Admin!

Ich fühle mich darin bestätigt, dass die Lösung zwar technisch realisierbar wäre, der Aufwand jedoch in keiner Relation zum Nutzen stünde...

[DerCamperHB]

Ich lese zwar eher draus, das die Grundidee eben NICHT realisierbar ist, Dateien zu erstellen, die ohne Overlap laufen, das war die Grundbedingung dabei, aber komme ansonsten zum gleichen Ergebnis.

Es gäbe eine technische Möglichkeit, die aber vom Umfang und Umständlichkeit die Änderung nicht Rechtfertigt:mad:

[OTR.TH]

Hallo,
Gibt es da noch kein tool das einen gemeinsamen Szenenwechsel sucht und passend schneidet? (Bzw. falls tatsächlich eine ganze Minute kein Wechsel kommt halt wirklich nach einem identischen Frame sucht).
keine Ahnung?

Aber wenn ich mir das Umfrageergebnis soweit ansehe, lohnt es sich nicht wirklich, da so viel Arbeit reinzustecken, sorry.

[dreamer]

Aber wenn ich mir das Umfrageergebnis soweit ansehe, lohnt es sich nicht wirklich, da so viel Arbeit reinzustecken, sorry.

Schade. Naja, vielleicht findet sich ja ne andere Lösung zum Dekodieren von fehlenden Anfängen/Enden...
(Ja ich weiß vorher/nachher mitprogrammieren, ist aber bei Serien doch bissl lästig, und wishlist ist dank 200 bannerklick grad echt nicht drin, und neu-user blicken da leider erst recht nicht durch)

[Gifhorn]

... jedem, der das GWP-System für userunfreundlich kompliziert und zu komplex hält, rate ich, sich mit der Umsetzung dieses Vorschlags auseinanderzusetzen. Man denke ihn mal in die Umsetzung. Jeder OTR-User würde gezwungen, mit cutlists zu arbeiten, jeder müsste immer zwangsweise schneiden und neu speichern. Laden - gucken - löschen wäre passé für lange Zeit. ...

Kurz und knapp: PeGu ist schonmal dagegen.

Nicht wenn die Dateien anhand der Aufnahme-Programmierung schon auf dem Server zu eine Datei zusammengesetzt wird

[Cineatic]

Nicht wenn die Dateien anhand der Aufnahme-Programmierung schon auf dem Server zu eine Datei zusammengesetzt wird

Wo kommt denn die Recheneinheit für diese Aufgabe her? Und vor allem, wer verrät dem Programm, das diese Aufgabe übernehmen müsste, welche Blöcke es alle für eine komplette Aufnahme benötigt?

[Gifhorn]

Der Größte Aufwand kommt halt auf Mirror Betreiber zu, wenn die Einzeldateien als Kompremierte Datei angeboten werden will, da dann die Entsprechenden Teile erstmal zusammen gesucht werden muss

Nicht unbedingt, wenn auf den den Mirror-Servern dieselbe Software läuft die die Aufnahmen anhand der Programmierung automatisch zu eine Datei zusammensetzt. Welche einzelnen Dateien zusammengestzt werden müßen kann dabei schon im Dateinamen für die jeweilige Programmierung stehen

[Cineatic]

Sorry, aber entweder verstehe ich gerade nur Bahnhof, oder du. :D

Das was du da vorhast, würde doch an der jetzigen Problematik überhaupt nichts ändern. Dadurch käme es dann immer noch zu unvollständigen Aufnahmen, wenn ein Sender mal wieder eine größere Zeitverschiebung im Programm hat.

Denn die Blöcke nach der offiziellen Sendezeit hätten doch dann den falschen Namen und würden dementsprechend nicht mehr verwendet, obwohl sie die gewünschte Sendung beinhalten.

[Gifhorn]

trotzdem notwendiges Overlap von einigen Sekunden,

Was für ein Overlap, wenn die Datei Byte-genau getrennt wird wird und später wieder Byte-genau zusammengesetzt wird auf dem Server. Auf diese Weise Dateien zu behandeln ist ein Kinderspiel im PC-Bereich


Sorry, aber entweder verstehe ich gerade nur Bahnhof, oder du. :D

Das was du da vorhast, würde doch an der jetzigen Problematik überhaupt nichts ändern. Dadurch käme es dann immer noch zu unvollständigen Aufnahmen, wenn ein Sender mal wieder eine größere Zeitverschiebung im Programm hat.


Das könnte man ja mit der manuellen programmierung auffangen


Denn die Blöcke nach der offiziellen Sendezeit hätten doch dann den falschen Namen und würden dementsprechend nicht mehr verwendet, obwohl sie die gewünschte Sendung beinhalten.

Dann müßten die einzelnen Blöcke nicht nach der Sendung benannt werden sondern nach Aufnahmezeit und Sender. Der Name kann bei eine EPG-Programmierung nach den Zusammensetzen der Dateien nachträglich hinzugefügt werden

[Grüner Drache]

Ich find die Idee nicht schlecht, ich werde wohl mal meinen alten Rechner mit der TV-Karte aus dem Sysoloschen Keller holen.

@ Administratoren, ge ich rcht in der annhme, das die Aufzeichnungseinheiten auf Linux laufen?

Ich werde mal ein paar Tests durchführen und das ergebniss hier Posten.

Falls Typos drin sin bitte entschuldigen, es ist mal wieder ein Overlay drübergewesen.

[dreamer]

Danke, wäre sehr interesannt zu wissen, ob's geht!

[DerCamperHB]

Leider werden deine Test wenig bringen.

Wir müssen dabei das Gesamtkonzept betrachten.
Wenn ich das Richtig verstehe, wird das Programm nicht einmal aufgenommen, sondern es gibt wohl 2 oder mehrere Empfangseinheiten Pro Sender/Aufnahmeeinheit.

Jetzt läuft Einheit 1 von 8.00-8.45
Einheit 2 läuft von 8.29-9.10
Einheit 3/1? läuft von 8.54-9.35
usw

Es sind dann schon im Vorfeld fertige Abschnitte von Aufnahmen, die nicht weiter geschnitten, sondern nur noch umgewandelt werden müssen.

Wenn die Aufnahmen so Wirklich Arbeiten, ist es leider nicht möglich, Frame/Bitgenaue Dateien zu erstellen, da du 2 getrennte Aufnahmen vergleichen und Synchronisieren müsstest.
Machbar währe es halt nur, wenn die Daten nur von einer Einheit kommen, und diese als Dauer-Datenstrom verarbeitet werden.
Dann könnte eine Software evtl was machen, wie StreamaufnahmeProgramme.
Evtl könntest du mal in der Richtung was testen.
Bin mir nur nicht sicher, ob die Verlustfrei arbeiten, oder ob es da Fehlzeiten zwischen Aufnahmen gibt.