Beiträge von TomKeller

    Ohne Gewähr:


    WEB-CAP wird meines Wissens als Bezeichnung für Rips von (üblicherweise) zugangsbeschränkten Web-Streams genutzt (sprich: als Quelle dienen kostenpflichtige Streams, die nur im Browser laufen, und abgegriffen werden = mit speziellen Tools gedownloaded oder mit Screencapture-Software aufgezeichnet werden).
    WEB-DL bezeichnet hingegen Rips von (typischerweise) zugangsbeschränkten, regulär downloadbaren Web-Videos (sprich: kostenpflichtige Videos, die auf einer Seite - z.B. iTunes - zum Download angeboten werden, dienen hier als Quelle).


    Oder um es kurz zu machen:

    • WEB-DL = Quelle sind Videos, die vom Streaming-Anbieter zum Download (und Offline-Ansehen) angeboten werden
    • WEB-CAP = Quelle sind Videos, die vom Streaming-Anbieter nur als Web-Stream im Browser (ohne Offline-Betrachtung) angeboten werden

    Der Lernprozess bei solchen Sachen ist doch irgendwie NIE abgeschlossen.., gelle? ^^


    Also ich lerne nichts mehr. Nicht etwa, weil ich schon alles weiß, sondern weil ich mir nichts mehr merken kann/will (Kelly-Bundy-Effekt => neue Informationen könnten wichtige(!) alte verdrängen).


    Nicht mit Sicherheit..! Aber.., wenn ich mir vorstellen soll, dass so'n Dingens zwar DivX5, aber kein DivX4 abspielen sollte, hielte ich das eher für ein Gerücht. Umgekehrt wird allerdings schnell ein Schuh daraus.., gelle? :D


    Logisch wärs (denn ein offiziell(!) DivX-zertifizierter Player sollte eigentlich schon abwärtskompatibel sein) - aber die Praxis widerspricht leider gelegentlich der Logik.
    Aber ist ja auch egal: der Player vom TE (bzw. von dessen Freundin) ist scheinbar nicht DivX-zertifiziert... somit braucht man sich auch keine Gedanken darüber zu machen.


    Das mit dem FourCC ist schon Recht, aber wieso soll das/mein 'Jagen' durch den VirtualDub viel länger dauern?


    Vielleicht weil es länger dauert eine mehrere hundert Megabyte große Datei neu zu schreiben, als das Ersetzen von ein paar Bytes innerhalb der Datei ;) ??? Im Endeffekt bedeutet das aber nur: einstellige vs zweistellige Sekundenbereiche.


    Ist zwar nicht zu fassen und noch weniger zu glauben, aber viele Leute halten an ihren Uralt-Playern einfach fest, "weil die Dinger ja noch laufen"..!


    Ich hatte halt noch nie (so) einen Uralt-Player. Daher irritiert mich die Tatsache, dass die Dinger schon zum Erscheinen veraltet waren. Schließlich gab es die ersten DivX/XviD-tauglichen Hardware-Player ja erst nach der Jahrtausendwende... über ein halbes Jahrzehnt davor aber schon OpenDML-AVIs.


    Egal - dir auch noch einen schnönen (Rest-)Sonntag!

    Ich wollte dir ja auch bei nichts widersprechen, du alter Hausdrachen (bis auf die Sache mit dem "mit DivX erstellt" ;) ). Ich kann aber spontan nicht ausschließen, dass irgendwelche billigen China-Player vielleicht tatsächlich nur DivX 5 abspielen und mit DivX 4 (aus welchen Gründen auch immer) Probleme haben. Kannst du es?


    Mich hätte übrigens auch mal die Rückmeldung zum Vorschlag mit dem FourCC-Changer interessiert - aber der TE hat das vermutlich gar nicht ausprobiert. Dabei wäre es tatsächlich in Sekundenschnelle getestet... auch schneller als das "Jagen" durch VirtualDub (was ja durch das komplette Remuxen und damit verbundene Neuschreiben der Datei ein klein wenig länger dauert).


    Bist du dir eigentlich sicher, dass es tatsächlich Player gibt, die sich noch an AVI 2.0 stören und ZWINGEND AVI 1.0 verlangen? Immerhin gibt es ja die OpenDML-Erweiterungen des AVI 2.0 Containers schon seit fast 20 Jahren...

    Aber das der Player kein DivX abspielen soll, wäre fast ein Phänomen!


    DivX 4 und DivX 5 sind größtenteils nicht kompatibel zueinander! DivX-Unterstützung eines Hardware-Players bedeutet daher NICHT automatisch, dass DivX 5 und DivX 4 Dateien abgespielt werden können.


    DivX 4 basiert (genauso wie XviD) auf dem OpenDivX encore2-Sourcecode von Project Mayo. Durch die enge Verwandtschaft zwischen XviD und DivX 4, müsst man DivX 4 Videos EIGENTLICH(!) einem XviD-kompatiblen Hardware-Player auch als XviD Videos unterjubeln können (wie ich oben empfohlen hatte, müsste eine sekundenschnelle Änderung des FourCC schon reichen, um den Player glauben zu lassen, dass es sich um ein XviD Video handelt)...



    Zum Einen fällt bei den 'geht.., geht nicht'-Meldungen mit MediaInfo schon mal klar auf, dass die funktionierende Version mit VirtualDup, die 2. erstellte Version mit DivX erstellt wurden.


    Die zweite wurde eher mit ffmpeg erstellt ;) :



    Lavf = Libavformat:


    http://de.wikipedia.org/wiki/FFmpeg#Technische_Details

    Ist "srestore(frate=29.97)" alles, was ich für 'nen vernünftigen Aufruf des Skripts bräuchte?


    Nein. Vor Srestore muss noch ein Fullframe-Deinterlacer eingesetzt werden, der aus den 25 interlaced Frames je Sekunde (= 50 Halbbilder je Sekunde) 50 Vollbilder je Sekunde macht. Als Fullframe-Deinterlacer ist dabei von Yadif, über TDeint bis QTGMC alles erlaubt. Siehe auch:


    http://avisynth.org/mediawiki/Srestore#Examples


    Srestore ist hier nötig, weil Deinterlacing alleine nichts bringt. Das Problem sind die bei der Normwandlung entstandenen Blends, also die "Mischbilder" der ursprünglichen Frames. Siehe:


    http://home.arcor.de/scharfis_…tischesInterlacing/#2.3.3


    Srestore versucht die Blends rückgängig zu machen und die ursprünglichen Vollbilder (von VOR der PAL-Wandlung) wieder herzustellen.


    In diesem Fall ist das Ausgangsmaterial leider nicht besonders gut, so dass nach dem Deblending mit Srestore teils Artefakte beim Schwenk zu sehen sind - der Schwenk selbst wird mit srestore(frate=29.97) allerdings ruckelfrei.


    ABER NUR der Schwenk wird dadurch ruckelfrei. Die Szenen vor und nach dem Schwenk scheinen ursprünglich mit einer anderen Framerate als der Schwenk selbst vorgelegen zu haben. Ich würde vermuten:

    • vor und nach dem Kamera-Schwenk: mit 23,976fps gedreht => 3:2-Pulldown auf 29,97fps => Normwandlung mit Blendings zu 25fps interlaced
    • während des Schwenks: mit 29,97fps (interlaced) gedreht => Normwandlung mit Blendings zu 25fps interlaced


    Das bedeutet im Klartext: mit srestore(frate=29.97) wird der Schwenk ruckelfrei, aber davor und danach wirds ruckeln! Du müsstest das also getrennt bearbeiten - hättest dann aber als Ergebnis Schnippsel mit verschiedenen Frameraten!


    Daher mein Vorschlag, im Gleitz-Forum nachzufragen. Da sind auch die Leute aktiv, von denen z.B. Funktionen wie Srestore stammen - die haben vielleicht eine bessere Idee zu Umsetzung, und eventuell auch Vorschläge um die beschriebenen Artefakte zu beseitigen (bzw. zumindest zu verringern).

    Merkwürdige PAL-Wandlung. Im Schwenk über die Fahrzeugseite zähle ich 30 (respektive 29,97) Frames je Sekunde in den 50 Halbbildern - der Rest sind Blends (= Mischungen/Überlagerungen aus zwei Frames).


    Code
    1. srestore(frate=29.97)


    ... liefert dann zwar einen recht "sauberen" Schwenk (wobei "sauber" relativ ist: die miese Ausstrahlungsqualität mit unzähligen Kompressionsartefakten macht der Deblending-Funktion von Srestore das Leben schwer - aber zumindest ist der Schwenk ruckelfrei)... die paar Sekunden davor und danach enthalten nach dieser Behandlung aber scheinbar regelmäßig doppelte Frames. Wie's aussieht, sind dort nur 23,976fps(???) enthalten -> Mischmaterial???


    Ich würde vorschlagen, mal im Gleitz-Forum nachzufragen - da kann evtl. AviSynth-Pro "Didée" einen Blick drauf werfen und hat dann vielleicht einen zündenden Einfall! Ich als Laie würde behaupten: FALLS da abseits der Standard-Deinterlacer was zu machen ist, ist der Aufwand (allein schon wegen der schlechten Ausgangsqualität) den Nutzen kaum wert.

    Die Antwort lautet: es gibt keine Möglichkeit, das auf der Seite selbst zu erkennen. Das Upload-System bietet nämlich für die Upper keine wirkliche Möglichkeit zur Angabe des Containerformats... sondern eben nur zur Angabe des Videokompressionsformats.


    Ein Problem sehe ich da aber nicht - folge doch einfach dem Tipp von "MacLeod" und muxe zur Not den Inhalt der MP4 in eine MKV-Datei. Das dauert (je nach Dateigröße) nur Sekunden bis Minuten und ist ohne jeglichen Qualitätsverlust.

    Ich muss sagen: nach der überzeugenden ersten und starken zweiten Staffel hat mich bei "Luther" die dritte Staffel ein wenig enttäuscht. Die vierte ist hingegen wieder deutlich besser - rutscht aber teilweise etwas in Serien-Klischees ab, die einige (eigentlich als schockierend vorgesehene Ereignisse) vorhersehbar machen.

    Also bitte, bitte die aktuellen Sachen, soweit möglich und verfügbar, auch als XviD anbieten, sonst drehe ich demnächst durch und laufe Amok ...


    Ich hab den Eindruck, wir drehen uns immer weiter im Kreis! Nochmal zum Mitmeißeln:


    Ein Großteil der Releases auf Serienjunkies sind Scene-Releases(!!!) - und die Scene setzt jetzt nunmal verstärkt auf x264 und interessiert sich nicht die Bohne für Seiten wie serienjunkies.org! Wenn andere Seiten XviD-Versionen der selben Releases anbieten, dann nur, weil sich dort Leute rumtreiben, die die Scene-Releases nach eigenem Gusto in XviD umwandeln und dort anbieten... bzw. die selbst capturen/rippen und den Kram hochladen.
    Das ist auch auf Serienjunkies möglich - aber dazu müssen sich User finden und bereit erklären, sowas zu machen! Ich hab die letzten paar meiner eigenen Releases auch in verschiedenen Versionen hochgeladen - als XviD-AVI und als x264-MKV. Aber die Sachen, die ich für Serienjunkies anfertige sind üblicherweise eher alte/unbekannte Serien und TV-Filme... und ich mach das auch mehr oder weniger um nicht aus der Übung zu kommen und aus Experimentierfreude statt aus Nettigkeit ;) .


    Darum (und das wurde hier schon mehrfach vorgeschlagen):
    Wer auf XviD-Releases besteht, sollte sich vielleicht mit Gleichgesinnten (die ein wenig Ahnung vom Encoden haben) zusammentun und eine eigene P2P-Release-Group gründen, die aktuelle x264-Releases in XviD umkonvertiert und anbietet. Nur so ändert sich was - nicht durch Beschwerden hier auf dem Board.


    Ich habe einen neuen Sony-Fernseher und habe bisher die XviD-Dateien einfach vom PC auf einen USB-Stick kopiert, den ich dann direkt in das Fernsehgerät gesteckt habe. Hat bisher ohne Probleme funktioniert, doch nun klappt überhaupt nichts mehr, denn mein Fernseher kann zwar avi/XviD abspielen, aber keine mkv-Dateien. Meinen Kollegen geht's ohne Ausnahme genauso mit ihren Fernsehgeräten anderer Marken (Samsung, Philips etc.)


    Eventuell spielt der Fernseher aber von x264 erzeugtes Video in einer MP4-Datei ab??? Was sagt denn das Handbuch? Mich würde nicht wundern, wenn bei vielen, die sich beschweren, der Fernseher H.264-Video decodieren kann... aber eben mit dem MKV-Container Probleme hat.


    Nochmals der Hinweis: MKV ist ein Containerformat! Sprich: gewissermaßen die Verpackung! Und die kann man ändern = schnell und ohne Qualitätsverlust zu erledigen!


    Ich habe übrigens einen älteren(!) LG-Fernseher (42LM615S), weil der seinerzeit im Saturn für 469€ im Angebot war. Der kann z.B. (relativ) problemlos MKV-Dateien abspielen (solange kein DTS-Ton enthalten ist). Er ignoriert zwar reingemuxte Untertitel (die müssen als separate Datei vorliegen) und Kapitelmarken... und bei zwei Tonspuren spielt er nur die erste ab... ABER er spielt MKV-Dateien ab ;) !

    Besser: "Ansicht" => "Text" kopieren und hier posten - die Screenshots der einfachen Ansicht sind nämlich häufig nicht vollkommen aufschlussreich!


    Zumindest sieht man in diesem Fall, dass das Problem-Video DivX-4- und somit NICHT XviD-kompatibel erstellt wurde. Ich hab jetzt nicht genau im Kopf, wie genau es um die Kompatibilität zwischen XviD und DivX 4 bestellt war. Eventuell waren die gewissermaßen nahe Verwandte (denn beide gingen aus dem selben Quellcode hervor). Du könntest mal probieren, den FourCC der Problem-AVI hin zu XVID zu ändern (z.B. mit diesem Tool) - das dauert nur Sekunden und ist somit schnell getestet. Bestenfalls läuft dann die AVI... schlimmstenfalls läuft sie mit Bildfehlern oder halt gar nicht.


    Falls das nichts bringt, musst du halt bei deinem Konvertierungstool nachsehen, ob du irgendwo den Output so einstellen kannst, dass das WIRKLICH ein XviD-Video ausgespuckt wird.

    Mach mal zwei Analysen mit MediaInfo (einmal für das Video, welches läuft... und einmal für das Problem-Video) und setzte das erweiterte Analyseergebnis hier rein ("Ansicht" => "Text" kopieren und hier posten) bzw. vergleiche selbst beide Ergebnisse!


    EDIT: Da war ich zu langsam ;) !

    Es wird immer gern darauf verwiesen, dass mkv schon seit einigen Jahren der kommende Standard sei. Ich frag mich dann aber schon, warum wird es dann von relativ vielen Abspielgeräten nicht erkannt?


    Wirklich!? Eigentlich spielen die meisten Abspielgeräte mit H.264-Unterstützung auch Matroska-Dateien mit per x264 erzeugtem H.264-Video ab. Und in den wenigen Fällen, wo das nicht der Fall ist (z.B. bei der PS3), reicht üblicherweise das rasend schnelle Ummuxen der Inhalte so einer Matroska-Datei in ein vom Wiedergabegerät unterstütztes Container-Format - wofür es meist sehr benutzerfreundliche Tools gibt.


    H.264 ist schließlich der genutzte Videokompressionsstandard bei der HDTV-Ausstrahlung und der bevorzugt auf Blu-rays verwendete Standard... ganz zu schweigen von seiner breiten Anwendung für Streaming-Videos im Internet. Entsprechende Hardware-Decoder-Chips sind daher schon in Blu-ray-Playern, in Standalone-HDTV-Receivern und in bei Fernsehgeräten integrierten HDTV-Receivern (bzw. Fernsehgeräten mit Internet-Zugang und Unterstützung für diverse Streaming-Portale) verbaut.


    Wobei man aber sagen muss:
    KEIN Hardware-Player mit Matroska-Unterstützung bietet VOLLSTÄNDIGE Matroska-Unterstützung. Das ginge gar nicht, da das Matroska-Format zu viele Features hat, die unmöglich alle in Hardware "gegossen" werden können (man denke nur mal an sowas wie Menü-Unterstützung oder das Einbetten von Schriftarten für die Untertitelanzeige)... ganz zu schweigen von der breiten Format-Unterstützung (wo schon aufgrund von notwendigen Lizenzkosten für z.B. DTS & Co. ein Player niemals alle möglichen Formate decodieren kann) und der ständigen Weiterentwicklung des MKV-Containerformats.


    Trotzdem existiert das Matroska-Format schon eine gefühlte Ewigkeit. Ich war z.B. vor gut 8-9 Jahren das erste mal damit konfrontiert und wusste damals noch nicht so recht, was daran denn so viel besser als am guten alten AVI-Containerformat sein soll. Da musste ich erstmal "aufgeklärt" werden, was denn damit so alles möglich und machbar ist und weshalb es als Format der Zukunft angesehen wird.


    Trotzdem hat sich das MKV-Format anfangs nicht wirklich durchsetzen können - ganz besonders nicht bei der Hardware-Wiedergabe auf Standalone-Geräten. Es bestand halt einfach kein Bedarf dafür.
    Das änderte sich erst mit der Verbreitung von H.264-Video und der Frage danach, in welchem Containerformat denn derartige Videostreams am besten untergebracht werden sollten. AVI stand außer Frage - denn schon für die Unterstützung von AC3-Ton und XviD-Video musste der AVI-Container gewissermaßen "aufgebohrt" werden. Im Endeffekt kristallisierten sich MP4 und eben MKV als Archivierungs-Container heraus. Erst in DIESEM Moment fing das Matroska-Format an, auch für die Hersteller von Abspielgeräten interessant zu werden...


    Dem Otto-Normal-User wird es wie mir gehen, man beschäftigt sich nicht mit den Details der Szene, Codecs etc. sind für einem in der Regel böhmische Dörfer.


    Wie schon mehrfach erwähnt: die eigentlichen Scene-Releases waren nie, wirklich NIE(!), für den Otto-Normal-User gedacht. Dass jetzt gerade diese User von der Scene "Benutzerfreundlichkeit" fordern, ist daher schon irgendwie skurril ;) ! Das ist ein klein wenig so, als ob sich jemand ohne zu bezahlen in eine 3D-Kinovorstellung rein schleicht, und sich hinterher lautstark beim Kinobetreiber beschwert, dass er keine 3D-Brille bekommen hat, dass daher das Bild so unscharf war und dass er den Film deshalb nicht genießen konnte.


    Will damit nur sagen, bisschen mehr Verständnis für jene, die sich jetzt überrumpelt fühlen, wäre schon nett, als immer gleich von oben herab zu kommen und den Leuten zu unterstellen, ewig Gestrige zu sein, die sich dem Fortschritt verweigern.


    Das mit dem Verständnis sehe ich ein - aber manche fordern ja regelrecht Mitleid. Und da ist meiner Meinung nach Schluss! Schließlich gibt im Wesentlichen zwei Lösungen für das Dilemma:

    • geeigneten Media-Player kaufen (schließlich gibt es brauchbare Lösungen schon für unter(!) 50€) = Geld investieren
    • eigenhändig die Videos in XviD konvertieren (dafür gibt es auch simple One-Click-Software-Lösungen, die ohne großartiges Vorwissen auskommen - und selbst wenn es damit Probleme gibt, hilft die Community bestimmt gerne weiter) = Zeit (und Stromgeld) investieren


    Wer GAR NICHTS investieren will und sich einfach nur beschwert, hat in meinen Augen auch kein Verständnis verdient. Zum einen, weil "Meckerer" nie sympathisch rüber kommen, zum anderen, weil Beschwerden in diesem Fall unsinnig sind - denn (wie schon geschrieben): der Scene sind Otto-Normal-User schlicht und einfach scheißegal ;) .


    Wie hier auch schon wiederholt angesprochen, so richtig ist für mich auch nicht nachzuvollziehen, warum man sich hierzulande nun komplett dem xvid verweigert und nicht die Dinge noch ein Weilchen parallel laufen lässt wie andernorts, wo die Hardware-Situation ja nun sicher keine andere ist Die Wechsel innerhalb der Staffel fand ich schon sehr ärgerlich.


    Eigentlich lief es ja schon eine ganze Weile parallel: x264 wurde für HD(TV)-Rips benutzt und XviD für SD-Pendants. Mehr kann man von der Release-Scene nicht erwarten ;) . Dort geht es nunmal um Geschwindigkeit und darum, möglichst als erster einen Rip raus zu hauen. Da kann man eigentlich weder fordern, noch erwarten, dass eine Schiene mit "weicher Übergangsphase" und Doppel-Releases in zwei Formaten gefahren wird!


    Wie "Lil Fatima" schon schreibt:
    Den Scene-Releases der Vergangenheit ist es zu verdanken, dass sich XviD-AVIs auf breiter Front durchgesetzt haben. Jetzt geschieht halt das selbe mit x264 + MKV - das ist nunmal der Lauf der Dinge!

    Lustigmachen nützt keinem was... sich aufregen allerdings ebenfalls nicht! Tatsache ist und bleibt: Technik entwickelt sich weiter. Notwendige Neuanschaffungen von Geräten waren schon immer mit dieser Weiterentwicklung einhergehend und unvermeidlich. Das war beim Aussterben von Filmen auf VHS-Kassette so... beim Abschalten von analogen TV-Ausstrahlungen... und ist halt auch in diesem Fall nicht anders.


    Sich dann jammernd gegen diese Entwicklung querzustellen zeugt auch nicht selten von einer gewissen Scheinheiligkeit. Denn irgendwie wird da meist nur bekämpft/unterstützt, was einem persönlich gerade recht kommt. Dabei wird gerne vergessen, dass es gerade die Fortschritte bei hochkomprimierenden Videocodecs waren, die uns heute HQ-Videos bei minimalsten Download-Größen erlauben. Hätten sich damals Leute gegen diese Fortschritte durchsetzen können, müssten wir uns heutzutage mit gigantischen Videodateien in mieser Qualität rumschlagen. Aber anstelle die Tatsache zu begrüßen, dass sich Videos ohne sichtbare Qualitätsverluste noch wesentlich effektiver komprimieren lassen, wird auf die Weiterentwicklung geschimpft, weil einige mit der Hardware-Anschaffung nicht hinterher kommen. Realitäts-Check, Leute: ihr seid in der Minderheit - und... ja... daher heißt es für euch nun einmal tatsächlich "friss oder stirb"! Es war halt schon immer so, dass man nicht auf ALLE Rücksicht nehmen kann...


    Abgesehen davon, wird auch nicht daran gedacht, dass die ganzen Scene-Releases ja kostenlos verfügbar sind. Wir genießen also schon ein ziemliches Privileg, dass wir kein (mehr oder weniger) überteuertes Staffel-Set einer Serie kaufen müssen, ums sie zu jeder beliebigen Zeit sehen zu können. Aber vermutlich ist es auch typisch Deutsch, trotzdem einen Grund zum Schimpfen finden zu können ;) ...

    Wenn man einen Download-Manager für OCH (z.B. JDownloader) benutzt, kann man auch den Link zur Serienjunkies-Seite mit der kompletten Staffel (oder sogar der kompletten Serie) in den eingebauten Link-Decrypter eingeben - der "fischt" dann die ganzen Links aus der Seite.


    Allerdings muss man dann trotzdem noch die Captchas manuell je Folge lösen... oder halt einen Captcha-Exchange-Service nutzen!