[ANKÜNDIGUNG] Sharemarks 0.1

Hallo liebe VDRler,

die Version 0.1 des Sharemarks-Projektes steht zum Download bereit. Wir glauben, dass das Projekt nun
für jedermann und den alltäglichen Gebrauch bereit ist

Das sharemarks Projekt ermöglicht den Austausch von Schnittmarken, so wie der
VDR sie erstellt, und zwar so einfach und angenehm wie möglich. Die Schnittmarken werden zentral in
einer Datenbank gespeichert und können von dort auch abgerufen werden.

Eine Kurzbeschreibung:

- Das Programm marks2pts sucht zu jeder Schnittmarke den passenden PTS
aus den Video-Daten, der bei allen Nutzern identisch sein sollte,
- speichert diese "PTSmarks" auf einem zentralen Web Server,
- erlaubt das Herunterladen von gespeicherten PTSmarks und die Konvertierung
zurück in
eine marks.vdr im VDR Format, und
- macht das ganze so einfach wie möglich.

Voraussetzungen:

Perl und das Modul LWP::Simple
Das Sharemarks-Paket:
http://vdrsync.vdr-portal.de/sharemarks/sharemarks-0.1.tgz

Benutzung:
- natürlich lässt sich das Programm von der Kommando-Zeile aus bedienen,
- es lässt sich auch via reccmds.conf mit der Fernbedienung steuern
- es lässt sich eine automatisches Upload nach jedem Schneidevorgang ausführen.

Details zur Installation, Benutzung und Integration in den VDR findet sich im Installations-Paket, und unter

http://vdrsync.vdr-portal.de/sharemarks

Viel Spass, viele Oster-Eier und vieleviele Schnittmarken

Peter

Zitat

Original von weak
"Es gibt Probleme mit dem AutoPID-Patch."

und zwar welche?
und wie gravierend?

Hallo weak,

wir verlassen uns bei der Senderkennung auf Video-PID, Audio-Pid, und Service-ID. Der Auto-Pid Patch scheint aber Video-Pid und Audio-Pid machmal zu überschreiben, oder auf ein "default"-Wert zu setzen. Mit so einem Eintrag wird der Sender nicht mehr eindeutig identifiziert, so dass weder manueller noch automatischer Up- und Download funktionieren können. Wann das passiert, und wie lange es dauert, bis wieder die korrekten Werte vorhanden sind kann ich nicht beantworten, da ich den Patch nicht benutze.

Cheers

Peter

Zitat

Original von weak
soweit so gut, thx.

dann is mir noch folgendes aufgefallen:
"Hier sollte man seine Signalquelle eingeben, momentan macht nur Astra S19.2E Sinn."
dh. mit kabel funktioniert das ganze sowieso nicht?

Hallo weak,

Ich empfange auch per Kabel, es ist aber alles identisch mit Astra, und Änliches haben auch andere Kanel-User berichtet.

Zitat

bin mir allerdings ziemlich sicher dass mein kabelnetzbetreiber (chello.at) einfach das astra signal 1:1 einspeisst. (behaupten sie zumindest; die pids sind allerdings anders)

Wenn alles andere identisch ist, dann können wir über eine "Übersetzungs-Tabelle" nachdenken, in der Du einfach eintragen kannst, welcher Kanal welchem Astra Mapping entspricht. Dann kannst Du mitmachen, egal wie die PIDs ausehen...

Cheers

Peter

Zitat

Original von Boergen
Hoi !

Tritt das AutoPid-Problem auch bei den aktuellen Developer-Versionen auf, die ja fest AutoPid-verdrahtet sind ?

Hallo Boergen,

da habe ich keine Ahnung, ändert die den Auch die Audio- und Video-Pids? Gibt es da auch 'ne Doku zu?

Cheers

Peter

Zitat

Original von Boergen

Hehe... Hast wohl in letzter Zeit nicht allzu viel mitbekommen, was ?

Mal im Ernst: Jau, die ändert auch die Audio- und Video-Pids, falls diese sich ändern. Es werden sogar selbständig neue Sender angelegt, falls diese auf bekannten Transpondern gefunden werden. Das ganze kann man stufenweise an- und abschalten.
Das weiss ich leider nicht. Lad' Dir doch einfach mal ne aktuelle Dev-Version runter. Vielleicht findet sich etwas in einer Readme.

Hi Boergen,

okok. da war ich mal wieder zu mundfaul:

Also, zur AutoPID Problematik:

Wenn die Audio- und Video-PIDs dynamisch angepasst werden, sei es durch den AutoPID Patch, oder durch einen ähnlichen Mechanismus im neuen VDR, dann ist das super, auch für das sharemarks Projekt. Astrein. Echt. Genau was wir wollen. Denn wenn die PIDs sich tatsächlich ändern, dann soll ja auch die channel-Kennung entsprechend geändert werden. Jeder, der eine Sendung aufnimmt, tut das schliesslich mit den gerade gültigen Kanal-Pids, sonst könnte er sie ja gar nicht aufnehmen. Also ist sowas 1a mit den sharemarks kompatibel.

Aber (aberaberaberaber):

Daer AutoPID Patch trägt gar nicht immer/sofort die tatsächlichen Audio- und Video PIDs ein! So was blödes Da tauchen so Platzhalter auf wie:

KABEL1:778:M64:C:6900:8191:0:0:0:899:133:33:16387
SAT.1:778:M64:C:6900:8191:0:0:0:46:133:33:16387
N24:778:M64:C:6900:8191:0:0:0:47:133:33:16387

Also stehen in der channels-conf temporär "falsche" Audio- und Video-PIDs.

Was heisst das nun für das sharemarks-Projekt:

Fall 1)
es machen gaaaaaaaanz viele User mit, mit und ohne Auto-PID Patch:
Dann ist es völlig egal, es gibt halt Schnittmarken für den Channel mit
8191-0-899 und Schnittmarken für den Channel 511-33-899, und alle sind zufrieden. Obwohl die channels natürlich identisch sind, und die Schnittmarken in einen Topf gehören, aber was solls.

Fall 2) Es sind nicht so viele Schnittmarken da, und die Chancen, welche zu bekommen erniedrigen sich rapide um den Faktor "Anzahl der unterschiedlichen Senderkennungen". Grumpf. Nicht schön.

Konkret lautet die Frage also: Setzt der VDR in seiner Entwicklungsversion 1.3.X auch temporär "falsche/dummy" Audio- oder Video-PIDs?

Und sollen wir nochmals das Format für die channel-Kennung ändern? Das würde ich allerdings ungern tun.

Zitat

Falls es Dir hilft: Die Einträge in der channels.conf sehen folgendermaßen aus:

Code

SAT.1:12480:vC34:S19.2E:27500:1791:1792;1795:34:0:46:133:33:0
RTL,RTL Television:12188:hC34:S19.2E:27500:163:104:105:0:12003:1:1089:0
ProSieben:12480:vC34:S19.2E:27500:255:256;257:32:0:898:133:33:0
VOX:12188:hC34:S19.2E:27500:167:136:71:0:12060:1:1089:0
RTL2:12188:hC34:S19.2E:27500:166:128:68:0:12020:1:1089:0

Wenn die Einträge immer so aussehen, dann ist ja alles in Butter Also kein Problem mit der Entwicklerversion des VDR.

Cheers

Peter

Zitat

Original von Boergen
Hi Peter !
<SNIP>

Ah. Das ist schick. Ich werde Sharemarks gleich mal auf ein paar Enterprise-Aufnahmen loslassen. Die Chancen, dass dafür schon Marks vorhanden sind, liegen ja glücklicherweise bei nahezu 100%.

Hi Boergen,

Neineinein, die Chance das 100te von Leuten auf Enterprise-Marks warten, liegt bei 100% :D. Die Chance, das jemand welche hochgeladen hat ist nicht so ganz genau definiert Es sei denn, die User veranlassen einen automatischen Upload beim Schneiden, so wie sich das gehört Andernfalls kannst Du viele Leute glücklich machen

Cheers

Peter

Hallo atl, Hallo xpix,

Ich befürchte, das Problem der richtigen "Strategie" bei mehrfach hochgeladenen Schnittmarken-Paketen wird uns noch eine Weile verfolgen, deshalb ein paar Gedanken zum Thema. Ich gehe jetzt einfach mal davon aus, dass in Zukunft Schnittmarken für jeden Film mehrfach vorhanden sein werden.

Der Ansatz, der momentan verfolgt wird, ist in meinen Augen der robusteste, und macht momentan am meisten Sinn.
Vorteil: Schnittmarken werden nach Häufigkeit gewichtet, dadurch wird vermieden, an jedem Schnitt 5-15 leicht versetzte Marken herunterzuladen, je nach Geschmack oder Genauigkeit des Users. Stattdessen gibt es eine einzige Schnittmarke mit einer hohen Wahrscheinlichkeit richtig zu liegen.
Nachteil: Die Marken werden nicht Film-genau geliefert, sondern einfach für einen Zeitabschnitt. Der Zeitabschnitt ist jedoch zu lang, da ja mangels VPS jede Sendung mit Vor- und Nachlauf aufgenommen wird. Ergebnis: Die Schlussmarke der vorhergehenden Sendung ist evt. noch drin (und "dreht alle marken um"), oder die erste Marke der nächsten Sendung ist noch drin (stört die ..?).

Fazit: Eine sehr gute Strategie, um möglichst akurate Marken zu bekommen, aber leider ist Handarbeit immer noch angesagt (BTW: Wir werden uns niemals einigen können, wann ein Film zuende ist, bei den kombinierten Abspann/Vorschau Dingern, die die Privaten ausstrahlen).

Alternativen gibt es sicher 100te, aber eine Vorschlag will ich mal zur Diskussion stellen: Vorneweg: Ich bin gegen die Verwendung von EPG-Daten, um den Beginn einer Sendung zu definieren. Das ist ein Krampf ohne Ende, je nach EPG-Quelle, Verschiebungen durch Sondersendungen o.ä. Wenn ich das richtig mitverfolgt habe, dann wird es ja sowas VPS ähnliches in der nächsten VDR Version geben, dann kann man das nochmal überdenken. Da könnte alles VIEL einfacher werden :).
Aber jetzt zum Vorschlag:
Schnittmarken werden in Paketen verwaltet, das heisst, alle Marken, die zusammen hochgeladen werden, bilden ein Paket, und bekommen auch eine gemeinsame Paket-ID. Wenn nun jemand eine Anfrage für den Zeitraum von 20:10 bis 22:05 stellt, dann will er wahrscheinlich alle Marken für den Spielfilm ab 20:15 (der in userem Beispiel mal bis 21:45 gehen soll).

Nun könnte man folgendes machen:

Alle Pakete, deren Start-Zeit nach 20:10 und deren Endzeit vor 22:05 liegt, werden herausgesucht. Diese Pakete sollten wirklich nur die marks für diese Sendung enthalten, sonst nichts. Aus diesen Paketen wird dann eine "Schnittmengen-Paket" berechnet, das heisst, die Schnittmarken werden so verrechnet, wie es bisher schon geschieht (es ginge auch Median o.ä).

Eventuelle Schnittmarken um 21:50 (Im Beispiel mal der Beginn des nächsten Films) werden ignoriert, weil sie in einem Paket übertragen wurden, dessen Ende nach 22:05 liegt.

Damit hätte man folgendes erreicht:
Statt EPG-Daten heranzuziehen, definieren die übermittelten Schnittmarken-Pakete den Start und das Ende einer Aufnahme. Wenn die Marken akurat gesetzt sind, dann sollte das sehr zufriedenstellend funktionieren.

Vorteil: kein Ärger mehr mit Marken, die zur Aufnahme davor oder danach gehören.
Nachteil: Es funktionieren keine Marken, wenn man etwas zu spät programmiert hat oder zu früh abgebrochen hat. Hierfür liesse sich allerdings als "fall-back" die bisherige Strategie verwenden. Konkret: Wenn kein vollständiges Schnittmarken-Paket innerhalb der Aufnahme liegt, dann gibt es eben die Marken wie bisher.

So, alles klar soweit? Was denkt Ihr?

Cheers

Peter

Hallo Boergen,

Zitat

Original von Boergen
Hi Peter,

was definiert denn ein "vollständiges Schnittmarkenpaket" ?

Einzig und allein, dass sie zusammen in einem Rutsch von einem User hochgeladen wurden. Schliesslich hat sich der User ja (hoffentlich) was dabei gedacht, die Marken so zu setzen. Wenn es ein automatischer Upload war, dann hat er ja sogar mit diesen Marken geschnitten, also sollte auch das Ergebnis Sinn machen

Zitat

Gehen wir mal vom worst-case aus: Es gibt nur zwei Schnitte: Am Anfang und am Ende der Aufnahme. Würde das ausreichen ?

Logo, siehe oben. Ist doch auch genau richtig für einen Film bei den Öffentlichen...

Zitat

Der zweite (noch schlimmere) Fall wäre, dass z.B. drei Sendungen aufeinander folgen, die wirklich direkt aneinander geschnitten werden (müssen). Sendung A, dann direkt Sendung B, dann direkt Sendung C. Das wären dann quasi nur 4 Schnittmarken im Zeitrahmen der 3 Sendungen. Würde das von Dir erdachte Prinzip da greifen ?

Ich kann Dir nicht ganz folgen.... Ich versuche es mal:
Erstmal vorneweg:
a) der Zeitraum, den ein Aufnahme-Timer definiert, ist der maximale Zeitraum für ein Paket (sollte logisch sein, länger ist ja die Aufnahme gar nicht).
b) Ein Paket kann aber durchaus einen kürzeren Zeitraum abdecken (und wird das wahrscheinlich auch tun), weil die erste Schnittmarke dieser Aufnahme NICHT direkt am Anfang der Aufnahme, sondern zu Beginn des Films liegen wird. Dasselbe gilt analog für das Ende, die letzte Schnittmarke wird NICHT ganz am Ende der Aufnahme liegen, sondern am Ende des Films. Das Paket definiert nun also genau den Film.

Wenn Du nun zu einer Aufnahme marken suchst, dann suchst allerdings von Aufnahmestart - Aufnahmeende, und nicht Filmstart - Filmende (die sind ja unbekannt). Alle Pakete, die vollständig zwischen Aufnahmestart und Aufnahmeende liegen sollten aber genau den Film definieren, den Du aufgenommen hast (wenn nur ein Film in der Aufnahme steckt). Sie können ja nicht zum Film davor oder danach gehören, weil ja sonst der Anfang und das Ende des Pakets nicht mehr im Aufnahmezeitraum liegen würde.

Ok, nun zu Deinem Beispiel:

Es gibt drei Sendungen, die wirklich und absolut zusammengehören, und auch so von normalen Usern geschnitten werden (also zum Beispiel Teil 1, 2 und 3 direkt nacheinander).

Nun gibt es aber dennoch User, die haben nur Teil 1 aufgenommen. Die laden die Schnittmarken hoch. Ebenso gibt es User nur für Teil 2 und Teil 3.

Dann gibt es noch die User, die alle Teile zusammen aufnehmen, und auch schneiden.

Wenn Du jetzt Marken für alle Folgen zusammen haben willst (und die auch in einem Rutsch aufgenommen hast), dann musst Du hoffen, dass jemand einen ebensolangen Timer definiert hatte wie Du. Wenn nicht, dann gibt es als fall-back Lösung einfach alle Marken, die in Deinen Aufnahme-Zeitraum Fallen so wie bisher. Soweit alles in bester Ordnung, oder?

Nochmal ein anderer Erklärungsversuch:

Wir gehen davon aus, dass Marken so gesetzt werden, dass beim Schneiden was sinnvolles rauskommt. Also steckt in den Schnittmarken nicht nur die Information zu den Werbepausen, sondern auch die Information "Wo fängt der Film an und wo hört er auf".

Wenn Du nun Infos für den Zeitraum von 20:05 bis 22:05 suchst, dann wäre es doch super, wenn man aus den übermittelten Schnittmarken schon wüsste: In der Zeit von 20:05 bis 22:05 haben XY User Schnittmarken-Pakete definiert, die um ca 20:15 anfangen und um ca 21:50 aufhören. Also kriegst Du ein "gemitteltes Paket" zurück, ohne störende Endmarken (der Sendung davor) oder Startmarken (der Sendung danach).

Zitat

Ich persönlich finde das bisherige Prinzip schon recht in Ordnung. Man muss zwar evtl. die erste und/oder letzte Marke löschen, aber das wird vielleicht so gerade noch zu verkraften sein.

Wie gesagt, ich denke auch, dass wir für den Anfang gut gerüstet sind, und mein Vorschlag ist ja mehr ein Gedanken-Experiment. Aber je länger ich darüber nachdenke, desto besser finde ich den Ansatz ...

Cheers

Peter

Hallo atl,

Zitat

Original von atl
Aber wie wäre es, wenn man zu jeder Marke den Typ (Startmarke oder Endmarke) mit speichert. Dann bräuchte man bei der Anforderungen von Schnittmarken für einen Zeitraum nur darauf achten, dass man immer Pärchen von Schnittmarken ausliefert - und somit immer komplette Start- und Endpunkte hat. Dann kann es z.B. auch nicht passieren, dass man die Startmarke der nachfolgenden Sendung mitgeliefert bekommt und das umständliche händische Nacharbeiten bzw. Löschen der überflüssigen Marken entfällt.

darüber hatten wir auch schon mal nachgedacht, und das würde sicher Sinn machen. Eigentlich sind die Infos schon vorhanden, wir müssten die Marken ja nur in "gerade" und "ungerade" einteilen (beim Hochladen), und die Kennung beim Runterladen entweder mitsenden, oder als erste Marke unbedingt eine "ungerade" senden, und als letzte eine "gerade".

Aber die Idee mit den Paketen würde das auch lösen ....

Cheers

Peter