Kritik an WMV

[Starrr]

Der Grund für wmv ist (wenn ich mich recht zurückerinnere) das die Aufnahmeeinheiten bereits in Hardware dazu fähig waren das zu kodieren. Oder wieso sind viele der Files so schnell nach Sendungsende fertig ?
Erst die neuen Einheiten könnten auch avi.
Und was die Sender betrifft, da kommt es auf die Aufnahmehäufigkeit der User an. Je mehr Sendungen eines Senders angefordert werden umso mehr wird entsprechend auch mal umgelagert (mei, was war das für ne überraschung als ich ne Usermeldung kam, ob ich ne Sendung ned mehr spiegel. Die war auf die avi-Einheit gewechselt worden. Erst diesen Monat passiert.)
Alle anderen Formate (ausser die angebotenen) gehen via Softwarekodierung.
Aber die Prozzessoren der Server sind am Limit, zuletzt wurde mal um ne serverseitige hash-Summe gebeten ... *rest kann man sich denken *

Es ist alles ein abwägen der prioritäten, aber die Sendungen werden wirklich per hand programmiert. Vielleicht lässt da etwas die sorgfalt zu wünschen übrig . Nur sollte auch da beachtet werden, der Ton macht die Musik

In diesem Sinne

P.S. ... und lasst endlich diese §$%&&"-OS-Diskussion, das ist wirklich Sinnfrei ...

[Starrr]

Achje
@SH
zu 1. ja, wieso ?
zu 2. siehe meine Beitrag, womit wir wieder bei den aufnahmeeinheiten wären.
zu 3. Schon mal geschaut was Traffic kostet ? Da brauch man die Turnschuh-Netzwerker, die sind billiger Mal abgesehen davon, das es stimmt.

Gruss

[Starrr]

Achja, einen noch:
Badfiles entstehen nicht nur dadurch das sie ned schnell genug kopiert werden können. Aber es ist mit einer der Gründe.

Gruss

[falcon_]

1. :-) also Du glaubst an den Weihnachtsmann und Version eins?

Ich glaube, dass wir als user nicht wissen, wie OTR funktioniert, auch wenn du so tust, als hättest du OTR selbst erfunden.

2. H.264-Aufnahmen? Was hat das mit wmv zu tun??? Da hat aber einer den Durchblick.
Wenn alle Files in xvid, divx oder H.264 wären, gäbe es kein Problem mit wmv.

Gut, dann können wir FLV auch gleich in die Tonne treten.

3. Du meinst sicher, wenn der Turnschuh-Netzwerker beim Transport der 50 bis 1000 Disketten vom einen zum anderen Rechner stolpert?

Ne, ganz so einfach geht das nicht, leider stehen die Aufnahmeeinheiten in Antigua, da müsste der ganz schön weit rennen. Und angeblich sollen ja auch noch OTR-FTP (Mirror) und User versorgt werden. Aber mich würde deine Version der Story wirklich interessieren. Was ist mit den 'pending bads', die nach ein paar Stunden da sind? Wenns nicht die Zeit ist, die die Server fürs encoden + auf die Downloadserver schieben brauchen, was dann? Natürlich, ich hab vergessen, dass die bei OTR jedes File per hand in den encoder jagen und nicht immer nachkommen
Außerdem habe ich dich nur aufgefordert, uns zu zeigen, wie toll FLV ist. Momentan hab ich noch kein einziges Argument gesehen, das für die Einführung desselben sprechen würde

[Starrr]

<...snipp...>
Und angeblich sollen ja auch noch OTR-FTP (Mirror) ...
<...snapp...>

... hin und wieder aber wirklich nur angeblich *tiefseufz*
Da wären die Netzwerker auf Turnschuhen schneller

Gruss

[Eos]

Hi!

Es glaubt hier doch wohl niemand, dass explizit eine Sendung aufgenommen wird.
also: start(10min vor Anfang) - Sendung - (Nachlauf) ende

Was gemacht wird ist:
Sender A: 0:00 Uhr start ----- 24:00 Ende
Dann wird die Sendung herausgeschnitten.

Offensichtlich ist es sogar so, daß für eine Sendung mehrere Dateien nacheinander aufgenommen werden!
Kurz vor der Startzeit laut EPG wird die Aufnahme gestoppt und eine neue Datei angelegt. Dasselbe passiert kurz nach der EPG-Zeit. Dieses kurze Stück (normalerweise 9:55 lang) bildet den Overlap.
Nach einer Sendung wird die endgültige Datei aus dem vorderen Overlap, der eigentlichen Sendung und dem hinteren Overlap zusammengebaut. Der hintere Overlap ist dann der vordere Overlap der Folgesendung.

Beweis: Bei den WMV-Einheiten (analog) gibt es an der Schnittstelle einen (in der Regel kurzen) Sprung - den sogenannten Overlap-Ruckler. Das Ende einer Sendung und der vordere Overlap-Ruckler der Folgesendung stimmen überein, ebenso der Anfang einer Sendung und der hintere Overlap-Ruckler der Vorsendung.
Ausnahme: Bei Sendungen unter 10 Minuten ist der Overlap vergrößert, 2 kurze Sendungen in Folge ergeben für die nachfolgende Sendung Müll (es fehlt ein Stück), wohl weil die Zeitberechnung durcheinander kommt.

Die DivX-Einheiten arbeiten digital, da wird der Datenstrom beim Datei-Wechsel zwischengespeichert und es gibt keinen Overlap-Ruckler. Die Probleme mit Kurzsendungen treten aber auch hier auf.

Eos

[Nobbi2509]

Wenn jemand wie ich in Chile lebt, dann ist er für jede Möglichkeit dankbar am deutschen TV teilzuhaben. Die Qualität tritt da in den Hintergrund, der Inhalt ist wichtig. Da ist es zwar unschön wenn Filme fehlerhaft sind und nicht wieder hergestellt werden (können) oder das Ende fehlt. Aber was ist schon perfekt? Ich benutze OTR seit Okt.06 und bin zufrieden. Mit Schwund muss man halt rechnen und solange der sich, wie ich finde, in einem erträglichen Masze bewegt ist die OTR-Welt in Ordnung. Die leichte Nutzbarkeit und die Kompalibilität sollten im Vordergrund stehen.

Mit freundlichen Grüssen aus dem sonnigen Santiago (ca +30° Celsius)

Nobbi

[Sledge Hammer]

Sorry, hab da wohl was verpasst. Wen habe ich beleidigt?

[worfroz]

Die Bildanzeige funktioniert hier nicht! Hier sollte das Bild angezeigt werden und nicht der Link!

Ich konnte vorhin das Bild anstelle des Links sehen! Evtl. Browser-Probs bei dir?

[mschafhuber]

Es ist kostenlos!