Beiträge von -TiLT-

    Ich vermute die ivtc-algos kommen mit diesen Doppellines nicht klar und sortieren die Fields falsch. Wenn ich die passenden Fields per Hand raussuche kommen diese broken outlines nicht vor.
    Wie entsteht sowas eigentlich? Mieses Upscaling vor der Telecine? Jedenfalls ist das irgendwie kein natives HD oder zumindest ein sehr sonderbarer Effektfilter.

    Nimm mal folgendes Script:


    Code
    assumetff()
    tfm(mode=4,pp=0,slow=2).decimate()
    Crop(2,4,-2,-4)
    LanczosResize(1280,720)

    Das sieht vom Sample her schon optimal aus.

    warum machen die dann überhaupt diese pseude 50fps ? ist ja bei arteHD, 1festHD das gleiche.nur um es uns "rekordisten" schwerer zu machen ?

    TV in Europa hat eben 50fps, in den USA 59,94fps (Ursprünglich 60fps).

    In Zusammenhang steht das mit der Hz-Zahl des vorhandenen Stromnetzes zum Zeitpunkt der Entwicklung der Fernsehnormen NTSC und PAL.

    Aufgrund nicht ausreichender Bandbreite um 50 Vollbilder übertragen zu können, entschied man sich für 50 Halbbilder, eingepackt in 25 Vollbilder, in Zeilenwechselsprungsverfahren. Respektive 60/30 für NTSC.
    So war eine flüssige Bewegungsdarstellung möglich, auf Kosten der horizontalen Zeilenanzahl, oder auch Auflösung heutzutage genannt.

    Progressive 25fps, respektive 23.976fps stammen aus der Art und Weise wie sich das Kinosystem auf die TV-Normen übertragen lässt. Um keine neuen Bilder errechnen zu müssen, werden die 24fps des Kinos für PAL-Normen auf 25fps beschleunigt, für NTSC-Normen auf 23.976fps verlangsamt und per 2:3 Pulldown auf 29.97fps aufgeblasen. Jede 5-Frame-Sequenz beinhaltet dabei nur 4 reale Frames, 2 Frames sind vollständig erhalten, 2 Frames werden im Zeilensprungverfahren auf 3 Frames verteilt, existieren also nicht mehr Progressiv. 2 Halbbilder sind Waisen. Das Verfahren soll vermeiden, dass das Ruckeln, welches entstehen würde, wenn einfach pro 5 Frames 1 Frame verdoppelt wird, verringert wird, durch die Aufteilung auf 2 nicht zeitgleiche Halbbilder.

    1 2 3 4 5
    1 2 2 3 4
    1 2 3 4 1

    Grün: Vollständig progressive Bilder
    Gelb: Rekonstruiertbar progressive Bilder
    Rot: Verwaiste Halbbilder

    Tja, und deshalb ist TV eben eigentlich 50fps und 60fps, und auch alle Studiokameras arbeiten mit entsprechender fps-Zahl.

    Natürlich ist das eigentlich nicht mehr zeitgemäß, und variable Framerate wäre die sinnvollste Implementierung gewesen, durch die jedwede Framerate erzeugt werden könnte, aber soweit war man wohl nicht, und deshalb leben wir weiter mit der Krux. Das hat also nichts damit zu tun, dass man es den Aufnehmern schwer machen will, sondern lediglich, dass man geistig nicht flexibel genug war, gleich Nägel mit Köpfen zu machen, und althergebrachtes über Board zu werfen.

    Der RB encodiert so, um die Kapitel 1:1 übernehmen zu können.
    Er verlässt sich darauf, dass der Encoder der DVD-Produktion bereits die benötigte Bitrate der Cell genau eingeschätzt hat, und reduziert einfach alle Cells um den gleichen Faktor um die gewünschte Zielgröße zu erreichen. Eine erneute Beurteilung ist also nicht notwendig.

    Mit ffvideosource kann ich den Stream tatsächlich lesen, aber ungefähr ab 54000 Frames gibt auch ffms2 auf und geht in einen "Festplattenratterdauermodus".

    Irgendwie komm ich mir grad echt doof vor, ich hab noch nie solche Probleme mit einem Stream gehabt, dass ich es wirklich gar nicht geschafft hab ihn weiterzuverarbeiten.

    Edit: Ich versuchs jetzt auch mal mit DSS2.
    Ist das normal, dass die avss.dll nicht per autoload funktioniert?

    Edit2: DSS2 und Directshowsource verursachen nach einiger Zeit einen Absturz von Virtualdub. Die genaue Ursache konnte ich nicht herausfinden, ich versuche nun mal den Weg über megui.

    Edit3: Ok, Fehler gefunden, war ein Speicherüberlauf durch einen zu großen Prebuffer von Haali. Directshowsource läuft nun wie gewohnt durch. Staxrip in der aktuellen Beta war ebenfalls ein Fehler, bin zurück auf die 1.1.1.4.

    Hallo LigH und Selur,

    ArteHD sendet 720p50, da liegt also kein PAFF/MBAFF Problem vor.

    TS-Doctor hat an dem Stream "leider" nichts auszusetzen.

    Ich habe übrigens noch zwei Fehlerfenster direkt vor dem Crash, die ich zuerst übersehen hatte.

    [Blockierte Grafik: http://img5.imagebanana.com/img/dqf798sv/dgavcdec3.png]

    [Blockierte Grafik: http://img5.imagebanana.com/img/3fg9ky2b/dgavcdec4.png]

    Sehe ich das richtig, dass dgavcindex eingestampft, und durch diese cuda-Version ersetzt wurde?
    Fände ich schade, aber entspräche der allgemeinen Entwicklung bei h264-Software. Nur gegen Geld und nur auf bestimmter Hardware. H264tscutter ist ja ein ähnlicher Fall :(

    Hallo,

    ich habe ein Problem mit einer Aufnahme von arte HD.

    Starte ich das Playback in dgavcindex erscheint gleich dieser Fehler und wiederholt sich mehrmals:

    [Blockierte Grafik: http://img5.imagebanana.com/img/bo9l7g4t/dgavcdec1.png]

    Unterdrücke ich den Fehler läuft das Playback einige Sekunden, dann erscheint dieser Fehler:

    [Blockierte Grafik: http://img5.imagebanana.com/img/0xz0ay4f/dgavcdec2.png]

    Die dga zu erstellen ist allerdings kein Problem, jedoch lassen sich dann auch nur wenige Sekunden nutzen, bevor es zu Abstürzen kommt.

    Coreavc meckert bei dem Stream nicht, daher kann ich mit directshowsource einiges machen, aber etwas ärgerlich ist es schon.

    Vielleicht mag sich jemand den Stream mal anschauen, der mehr Ahnung davon hat als ich, und das Problem präzisieren kann.

    http://rapidshare.com/files/327696964/arteHD.264 Grösse: 29575 KB

    cabac=1 / ref=3 / deblock=1:-1:-2 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.0:0.3 / mixed_ref=1 / me_range=12 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / chroma_qp_offset=-4 / threads=6 / nr=0 / decimate=0 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5169 / ratetol=1.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=9000 / ip_ratio=1.10 / aq=2:0.50

    Ich bin mir nicht 100%ig sicher, aber ich meine das lief auf ner PS3 vom Bekannten.
    Geändert habe ich seitdem nur die keys ggf. da min1 und max24 einsetzen.

    knopper: Das ist möglich, allerdings musst du dafür die komplette Automatik von Staxrip ausschalten.

    Erstmal unter View-Options-Advanced-Image "Auto correct crop values" und "Auto crop borders..." ausschalten.

    Nun kannst du haargenau so selbst croppen wie du es selbst benötigst.

    Den Rest musst du nun zu Fuss gehen, ergo die neue Auflösung berechnen inklusive der Borders die du einfügen willst, oder aber du benutzt das gute alte fit2disc, dem du lediglich die crop-werte aus Stax übergibst, die Zielauflösung eintippst und dann das zu enthaltende Bild verkleinst. Dann werden die entsprechenden Avisynth Zeilen ausgegeben.

    z.B.:

    LanczosResize(688,368,2,8,710,554)
    AddBorders(16,16,16,16)

    Durch einen Doppelklick auf die Resize-Zeile kannst du den dort stehenden Befehl einfach mit deinen neuen Zeilen ersetzen, den Crop-Befehl von Staxrip schaltest du aus, der ist bei fit2disc in den Resize Befehl eingebettet.

    Obiges Beispiel erzeugt übrigens aus einer anamorph-codierten DVD ein Video-Frame von 720x400 non anamprph mit einem 16 px Rahmen. Du solltest die Rahmengröße immer aus einem ganzzahligen Vielfachen der Makroblock-Größe des Zielcodecs ermitteln.

    An deinem TV ist dann das Bild insgesamt kleiner aber es wird weniger durch den TV-Overscan abgeschnitten. (Der TV-Overscan ist afar bei 720px in der Breite bis 24px im Safe-Bereich, aber das wäre kein Makroblock. Teste mit 16px und 32px was bei deinem Gerät noch ok ist. Jeder RöhrenTV ist anders eingestellt.)