Capturen klappt nicht

[Rooter]

Hi,

ich will noch ein paar uralte VHS-Aufnahmen digitalisieren bevor ich mich endgültig von dem Format verabschiede. Folgendes habe ich gemacht:

Videorekorder an die Soundkarte und die GeForce 6600 GT Vivo gehängt, aktueller nVidia WDM Treiber ist installiert
Capturen mit VDubMod weil das normale VDub beim aufrufen von "Capture AVI..." mit einer Exception in 'kernel32' abgesemmelt ist
Gecaptured wird in 720x576 mit 25 fps nach huffYUV und Wave, dabei schwankt die aktuelle Framerate immer leicht um 25 herum und es gab bei meiner 3-minütigen Testaufnahme 5 dropped frames
Die fertige Datei wird mit AviDemux (wegen der guten Filter) bearbeitet und nach XviD + MP3 umgewandelt. Weil AviDemux diese Datei mit komplett kaputten Farben anzeigt übergebe ich sie mit avsproxy_gui im Tab AVISource()

Nun habe ich zwei Probleme:

Obwohl das Orginalvideo im MPC-HC synchron läuft und mir MediaInfo auch eine Framerate von 25.000 bestätigt laufen Bild und Ton der encodierten Datei nach ca. 1 Minute schon deutlich auseinander
Die Personen im Video sind alle langestreckt, fast wie anamorph, nur nicht ganz so heftig. Ich vermute das liegt am Pixel Aspect Ratio aber wie kann ich das in AviDemux korrigieren? In den Einstellungen des XviD-Encoders gibt es den Punkt PAR sogar aber scheint sich gar nichts zu ändern wenn ich dort 1:1, 16:9 oder 4:3 einstelle. :confused: Oder muss ich das sogar schon in VDub machen?


Ich hoffe ihr könnt mir hier ein paar Tips geben was ich falsch mache. :(

MfG
Rooter

[Gast]

Es ist schon lange her, dass ich etwas derartiges gemacht habe.

Beim recoding bekommt man wohl fast immer Probleme mit der Synchronität von Bild und Ton.
Das Problem dürfte daran liegen, dass die Aufnahmeframerate nicht wirklich zu 100% konstant ist. Wenn du das Video bearbeitest und neu erstellst wird dies aber mit einer konstanten Framerate gemacht. Da Bild und Ton getrennt verarbeitet werden passt es danach nicht mehr zusammen.

Du könntest versuchen die Framerate entsprechend anzupassen. In VirtualDub gibt es dafür eine ganz praktische Option: "Change so video and audio durations match"

Bei AVIDemux gibt es diese soweit ich sehen kann leider nicht mehr, aber du kannst trotzdem einfach das Video in VirtualDub öffnen, die Framerate mit der genannten Option einstellen und die sich daraus ergebende Framerate notieren. Diese stellst du dann einfach in AVIDemux ein.

Das funktioniert zwar nicht immer, kann aber oft zu brauchbaren Ergebnissen führen. Bild und Ton sind zwar trotzdem nicht 100% synchron, allerdings verhinderst du damit dass die Lücke immer größer wird und in den meisten Fällen dürfte der Unterschied klein genug sein ohne aufzufallen.


Eventuell ist auch eine stabilere Aufnahmeframerate durch die Wahl eines anderen Codecs möglich. Es bieten sich für die Aufnahme natürlich codecs an, die Einzelbilder abspeichern. Ich würde mal MJPEG probieren, das ist zwar nicht verlustfrei, sollte aber keinen großen Einfluss haben, die reale Auflösung von VHS ist gegenüber der Aufnahmeauflösung so niedrig, dass kein Qualitätsverlust durch die JPEG-Komprimierung sichtbar wird.

Dein zweites Problem kann sehr einfach behoben werden, indem du einfach mit quadratischen Pixeln aufzeichnest. Ich nehme an es handelt sich um das 4:3-Format, also zeichnest du in 768x576 statt 720x576 auf.

[Rooter]

Hallo Gast, danke für die Tipps. Ich hatte vergessen zu erwähnen dass ich in VDubMod im kompatiblen Modus gecaptured habe. Wie ich jetzt aus der FAQ auf der Homepage erfuhr funktioniert das synchronisieren von Video und Audio nur im normalen Modus. :rolleyes:
Bei der Gelegenheit habe ich das normale VDub auch gleich mal aktualisiert (meine Version war um ein paar Minorversionen älter) und siehe da, keine Abstürze mehr! :up: Capturen läuft mit 24,99xx fps. Außerdem kann ich die von dieser Version erstellte AVI-Datei auch direkt in AviDemux öffnen, avsproxy brauche ich also nicht mehr. Schneller geworden ist das Umwandeln dadurch aber auch nicht...
Egal, Encoding meines zweiten Videos läuft gerade. =)

MfG
Rooter

[HeldImZelt]

Und wie sieht die genaue Verarbeitungskette nun aus?

[Rooter]

- Capuren mit Vdub in HuffYUV + WAV @ AVI
- Encoden mit AviDemux nach XviD (Qr=5) + MP3 @ AVI mit folgender Videofilterkette:- haßliche Ränder wegschneiden (8 oder 16 Pixel)
- Deinterlacen mit DGBob
- Entrauschen mit hqdn3d
- schwarze Ränder wieder hinzufügen


Für eine 38-minütige Aufnahme hat mein P4@3200 letzte Nacht 7 Stunden gebraucht :usad:

Seltsam ist noch dass die fertige Datei beim Springen im MPC-HC teilweise einige Sekunden braucht bis es weitergeht. Gibt es da einen Haken bei XviD den man setzen muss damit das schneller geht?

MfG
Rooter

[Gast]

Welchen Zweck hat der letzte Punkt?

Grundsätzlich wird das Springen im Video umso langsamer, je länger die GoPs (= Group of Pictures)

Ein GoP bezeichnet den Bereich zwischen 2 I-Frames.

Ein I-Frame ist ähnlich einem JPEG ein Frame das für sich existiert, die folgenden Frames hängen von diesem I-Frame ab (mit B-Frames wird es noch komplizierter, da Decodier- und Anzeigereihenfolge nicht mehr die selbe ist)

Wenn du also beispielsweise an das letzte Frame einer GoP springst, müssen alle Frames vom vorhergehenden I-Frame bis zum Zielframe dekodiert werden bevor es angezeigt werden kann.

In den Encodereinstellungen kannst du normalerweise einstellen wie groß eine GoP maximal sein darf bevor zwingend ein I-Frame gesetzt wird.

Wenn du den Wert verringerst beschleunigt sich das Springen im Video, allerdings leidet darunter auch die Effizienz.


BTW: Einige Player springen grundsätzlich nur auf I-Frames, in diesem Fall verlierst du mit längeren GoPs nur an Genauigkeit.

[Rooter]

Ich weis was eine GOP und I-Frames sind, mir war nur nicht klar dass die GOP-Länge die Lösung meines Problems ist.
Habe die max.GOP jetzt mal von 300 auf 100 reduziert, ist schon viel besser geworden. Gibt es denn einem empfohlenen Wert für XviD?

MfG
Rooter

[Gast]

Gibt es denn einem empfohlenen Wert für XviD?



Das hängt vom Einsatzgebiet hab. Ist das Spulen wichtiger, oder eine hohe Effizienz an Qualität/Byte.

Für Broadcasting wird man logischerweise eine niedrige GoP-Länge verwenden, für die Wiedergabe vom Datenträger eher eine höhere, da es dort weniger stört. Kapitelmarken kann man ja auf I-Frames setzen und ansonsten ist das Spulen eigentlich nicht wirklich wichtig.

Die 300 Frames Vorgabe kommt eigentlich von 10s bei 30fps. Wenn du 25fps-Material hast kannst du 250 Frames verwenden.

Wenn das Material auch rückwärts abgespielt werden soll ist auch eine kurze GoP-länge sinnvoll, wobei man da besser nur I-Frames verwendet.

Grundsätzlich stellst du ja auch nur die maximale GoP-länge ein, bei einem Szenenwechsel wird auch dann ein I-Frame gesetzt wenn die maximale Länge noch nicht erreicht ist.

[HeldImZelt]

Das Multiplexing ist nicht optimal. Lass es mit Virtualdub/DirectStreamCopy neu speichern. Dann sollten die Keyframes getroffen werden. Mit Avidemux gehts auch, da musst du 'rebuild i frames' auswählen und dann speichern, kommt aber auf die Version von Avidemux an. Die GOP Länge ist egal bei Keyframe Seeking (wird von mpc-hc unterstützt).

Ich nehme zum Capturen VirtualDub/HuffYUV (ffdshow/yv12/median/adaptive), Avisynth und MeGUI (ggf. VirtualDub). Avidemux ist langsam, fehleranfällig und nicht annähernd so leistungsfähig und umfangreich wie Avisynth. Als Filter würde ich nur einen leichten temporalen Rauschfilter nehmen und ggf. den Chrominanzkanal korrigieren, falls die Farben in eine Richtung ausbluten.

[Rooter]

Erstmal danke für die bisherigen Antworten! :wave2:

Welchen Zweck hat der letzte Punkt?War der Meinung dass das Benutzen einer prominenten Auflösung wie PAL die Kompatibilität mit manchen Geräten erhöht. Könnte aber auch Blödsinn sein diese Überlegung... Ob das TV (50" Samsung Plasma) den Overscan anzeigt muss ich morgen mal ausprobieren.

Das hängt vom Einsatzgebiet hab. Ist das Spulen wichtiger, oder eine hohe Effizienz an Qualität/Byte.Bei einem Sprung im Video sollte es nicht länger als ~2 Sek. dauern bis das Bild weiterläuft. Ansonsten ist es mir die Effizienz wichtig, wobei die bei entrauschtem Material eh nicht optimal werden kann. Das Schlechteste was ich bisher hier habe ist eine 36-minütige Reportage die zu einer 930MB großen Datei wurde. :-/ Eine andere Reportage - sogar 1 Minute länger - kommt nur auf 600MB.

Das Multiplexing ist nicht optimal. Lass es mit Virtualdub/DirectStreamCopy neu speichern.Habe das jetzt mal bei einer Datei probiert und bilde mir ein dass das Springen im Video wirklich ein bischen schneller geworden ist... Werde mir auch das morgen mal genauer ansehen. Zur Not kann ich ja alle Dateien nochmal durch VDub jagen, so viele sind es ja nicht, zwei Dutzend werden es wohl sein wenn ich fertig bin.

MfG
Rooter

[HeldImZelt]

War der Meinung dass das Benutzen einer prominenten Auflösung wie PAL die Kompatibilität mit manchen Geräten erhöht. Könnte aber auch Blödsinn sein diese Überlegung... Ob das TV (50" Samsung Plasma) den Overscan anzeigt muss ich morgen mal ausprobieren.
Die endgültige Zielauflösung ist beim Capturen erst mal Nebensache. Man versucht in erster Linie mit der nativen Auflösung des Capturechips zu arbeiten. Den Rest verwurschtelt sowieso nur der Treiber.

Normalerweise können die Capturechips intern nur eine Auflösung. Entweder 52µs bei 704 oder 53.33µs bei 720 Pixel. Manche machen es sogar falsch und legen die interne (feste) Zeilenlänge auf beide Auflösungen. Dann muss man wissen oder recherchieren welche Auflösung richtig ist, sonst ist das Pixelseitenverhältnis nicht ganz korrekt. Renommierte Chips (wie Philips saa713x) tasten mit entsprechenden Treibern beide Auflösungen korrekt ab. Erkennst du daran, dass bei VHS(720) schwarze Streifen rechts und links sind. Bei 704 sollten die deutlich kleiner oder gar verschwunden sein. Dann arbeiten Chip und Treiber richtig.

704 kannst du auf 768x576 (oder andere DAR4:3 Auflösung) umskalieren. Bei 720 schneidest du vorher 16 Pixel ab. Die eleganteste Form ist 720x576 beizubehalten und Metadaten in den Container/Stream zu legen (SAR12:11 für 4:3). Dann sollte das Abspielgerät den Rest in Echtzeit erledigen, machen aber die wenigsten Geräte bei XviD/Avi. Daher ist es aus Kompatibilitätsgründen empfehlenswert direkt auf PAR1:1 DAR4:3 zu skalieren, wie oben beschrieben.

Bei einem Sprung im Video sollte es nicht länger als ~2 Sek. dauern bis das Bild weiterläuft.
Normalerweise gibt es fast keine Wartezeit. Unter optimalen Bedingungen (korrektes Multiplexing, gute Renderkette) kommt das Bild sofort. Siehe hier: XviD Keyframe Seek (http://wildcopper.funpic.de/xvid.keyframe.seek.mp4)
Das Video wurde auf einem AthlonXP erstellt (inkl. Screencapture), was zeigt, dass es in erster Linie nicht auf Power ankommt.

Ansonsten ist mir die Effizienz wichtig, wobei die bei entrauschtem Material eh nicht optimal werden kann.
Glattbügeln verbessert die Kompression durchaus. Temporale Filter verlieren subjektiv kaum Details, stabilisieren das Bild aber enorm.

Habe das jetzt mal bei einer Datei probiert und bilde mir ein dass das Springen im Video wirklich ein bischen schneller geworden ist... Werde mir auch das morgen mal genauer ansehen. Zur Not kann ich ja alle Dateien nochmal durch VDub jagen, so viele sind es ja nicht, zwei Dutzend werden es wohl sein wenn ich fertig bin.
Der MPCHC, bzw. dessen Renderkette ist u.U. nicht immer die beste Wahl. Vielleicht solltest du auch mal andere Splitter/Decoder (z.B. Haali mit FFDShow) oder andere Player ausprobieren. Auch VirtualDub muss nicht immer den besten Multiplex produzieren. Ich kann mich an bestimmte Videos erinnern, die waren mit Avidemux besser. Ich bin mir nicht sicher, welchen Faktor 'Closed GOPs', 'Packed Bitstream' oder ähnliche Optionen in dieser Rolle spielen.

[Rooter]

Moin,

wenn ich die Videos via DLNA an den Fernseher streame werden die Ränder angezeigt. War ja eigentlich auch klar, ist ja kein TV-Material.
Werde das hinzufügen der schwarzen Ränder ab sofort wohl weglassen und nur zusehen dass ich nach dem croppen eine durch 16 teilbare Auflösung erhalte.

Auch die mitVDub neu gemuxte Datei habe ich mir nochmal angesehen aber abgesehen davon das sie 150KB kleiner ist gibt es keinen Unterschied beim spulen.

Erkennst du daran, dass bei VHS(720) schwarze Streifen rechts und links sind. Bei 704 sollten die deutlich kleiner oder gar verschwunden sein. Dann arbeiten Chip und Treiber richtig.Schwarze Balken rechts und links habe ich natürlich, die sind aber bei 704x576 wie bei 720x576 vorhanden, kommen also vom Overscan. Wenn ich zwischen 704 und 720 wechsle ändert die Vorschau in VDub auch ihre Breite, ich vermute also die GeForce 6600GT macht das richtig.

704 kannst du auf 768x576 (oder andere DAR4:3 Auflösung) umskalieren. Bei 720 schneidest du vorher 16 Pixel ab. Die eleganteste Form ist 720x576 beizubehalten und Metadaten in den Container/Stream zu legen (SAR12:11 für 4:3). Dann sollte das Abspielgerät den Rest in Echtzeit erledigen, machen aber die wenigsten Geräte bei XviD/Avi. Daher ist es aus Kompatibilitätsgründen empfehlenswert direkt auf PAR1:1 DAR4:3 zu skalieren, wie oben beschrieben.Aufgrund der bescheidenen horizontalen Auflösung von VHS hatte ich mir zuerst sogar überlegt in eine Halbauflösung wie 352x576 zu encoden! Bei MPEG-2 kein Problem - diese Auflösung steht ja sogar im DVD-Video Standard - habe ich noch nie ein AVI in dem Format gesehen so dass ich lieber die Finger davon gelassen habe. :-/

Normalerweise gibt es fast keine Wartezeit. Unter optimalen Bedingungen (korrektes Multiplexing, gute Renderkette) kommt das Bild sofort. Siehe hier: XviD Keyframe Seek (http://wildcopper.funpic.de/xvid.keyframe.seek.mp4)
Das Video wurde auf einem AthlonXP erstellt (inkl. Screencapture), was zeigt, dass es in erster Linie nicht auf Power ankommt.Tja, ich frage mich woran das liegt. Ich habe hier auch einige Videos (nicht von mir erstellte) bei denen das Bild sofort da ist.

Glattbügeln verbessert die Kompression durchaus. Temporale Filter verlieren subjektiv kaum Details, stabilisieren das Bild aber enorm.hqdn3d ist ein temporaler Filter. Ich finde die Ergebnisse ganz okay wenn man bedenkt dass es sich größtenteils um 10-15 Jahre alte Longplay-Aufnahmen handelt (Kassetten waren/sind teuer ;)). Werde nachher mal Vorher/Nacher-Bilder posten.

Zum Thema AviSynth, klar ist das erste Wahl aber da ist die Auswahl an Plugins so groß dass ich keine Lust hatte mich da ewig durch zu wurschteln. Ich hatte ja gehofft bei Doom9 oder ähnlichen Seiten ein fertiges Skript für VHS-Captures zu finden auf dem ich aufbauen kann, habe aber auch nach mehrfachem googeln nichts brauchbares gefunden.

MfG
Rooter

[Rooter]

http://img97.imageshack.us/img97/2338/st1z.png http://img854.imageshack.us/img854/7241/st2zw.png

MfG
Rooter

[HeldImZelt]

Schwarze Balken rechts und links habe ich natürlich, die sind aber bei 704x576 wie bei 720x576 vorhanden, kommen also vom Overscan. Wenn ich zwischen 704 und 720 wechsle ändert die Vorschau in VDub auch ihre Breite, ich vermute also die GeForce 6600GT macht das richtig.
Wenn sie das 720'er Bild (inkl Balken) auf 704 zusammenquetscht, macht sie es falsch. Sie muss es croppen, nicht skalieren. Sicherheitshalber würde ich auf 720x576 capturen (nicht 704x576). Dann bist du (in diesem Fall) auf der sicheren Seite.

Zum Thema AviSynth, klar ist das erste Wahl aber da ist die Auswahl an Plugins so groß dass ich keine Lust hatte mich da ewig durch zu wurschteln. Ich hatte ja gehofft bei Doom9 oder ähnlichen Seiten ein fertiges Skript für VHS-Captures zu finden auf dem ich aufbauen kann, habe aber auch nach mehrfachem googeln nichts brauchbares gefunden.

3rd Party Plugins brauchst du nicht, außer vielleicht adaptive Deinterlacer im Bedarfsfall.

Edit:
Das untere Script ist sehr schnell, weil der Filter keine zusätzliche Farbraumkonvertierung braucht. Wenn du von vornherein im YV12 Farbraum aufzeichnest, findet sogar gar keine statt und ergibt die optimale Renderkette.

Das avs File würde ich in MeGUI/Dev laden, XviD CQ Template auswählen und 10 Sekunden Testfiles (trim) erstellen mit mehreren Qualitätsstufen.


# DirectShowSource nur im Notfall benutzen, nicht frameakkurat.

#DirectShowSource("D:\Temp\capture-8.avi")

# FFMpeg Library (Die beste Quelle, falls es funktioniert. Erstellt Index. Erst Audio, dann Video angeben!)
#a=FFAudioSource("D:\Temp\capture-8.avi") # benötigt ffms2.dll plugin
#v=FFVideoSource("D:\Temp\capture-8.avi") # benötigt ffms2.dll plugin
#AudioDub(v,a) # Multiplex

AviSource("D:\Temp\capture-8.avi")
Crop(8,0,-8,-0) #Left, Top, Right, Down # 720x576 -> 704x576
LanczosResize(640,480)
TemporalSoften(2,4,8,15,2) # stärker=(2,8,16,15,2)

#Trim(250,500) # 10 Sekunden Test
#ConvertFPS(25)

ConvertToYV12 # Farbraumkonvertierung

[Rooter]

Hallo Held, danke für die Mühe,

aber so beeindruckend finde ich dein Skript eigentlich nicht. Oder ist TemporalSoften wirklich so ein überlegener Filter? Und deinterlacen tut das Skript auch nicht, da ich mir den Kram aber zu >90% am PC ansehen werde täte das schon Not...
Wann muss ich ConvertFPS aktivieren?

EDIT: In YV12 kann ich nicht capturen, kann die Karte wohl nicht. Habe bisher alles in UYVY aufgenommen.

MfG
Rooter

[HeldImZelt]

Die Masse der Filter musst du selbst entscheiden. Ich bevorzuge "weniger ist mehr".

Degrainmedian und HQDN3D werden auch oft genannt. Ich weiß aber nicht, ob die beide in YV12 arbeiten. YUY2 würde wieder mehr Zeit kosten.

ConvertFPS brauchst du hier nicht. Sollte eigentlich auch ChangeFPS hin... Crop war auch falsch, ist korrigiert.

Wenn die Karte nicht direkt YV12 liefert, stelle es einfach im Kompressor um, den Rest macht die Software. UYVY oder YUY2 für die Karte auswählen. Nimm u.U. nicht den alten HuffYUV, sondern den aktuellen in FFDShow ('median' ist stärkste Kompression, sollte die CPU aber locker schaffen).

Ein guter adaptiver Deinterlacer ist TDeint. Auf jeden Fall vor dem Resizer einsetzen.
http://forum.doom9.org/showthread.php?t=82264


Für Qualitätsprüfungen eignet sich sowas. Mit VirtualDub (oder entsprechendem Player) öffnen und via Framestep sichten (Interleaved/temporal verzahnt).
AviSource("original.avi")
interleave(subtitle("lossless"), AviSource("processed.avi"))
# Shows lossless frame first followed by compressed frame


Oder nebeneinander:
File1=AviSource("Original.avi")
File2=AviSource("Processed.avi")
StackHorizontal(File1, File2)

File1=AviSource("Original.avi")
File2=AviSource("Processed.avi")
BG=BlankClip(File1,width=File1.width*2)
File3=Overlay(BG,File1,x=0,y=0,mode="add",opacity=1)
Overlay(File3,File2,x=File1.width,y=0,mode="add",opacity=1)

[Rooter]

Habe jetzt mit TDeint und den stärkeren Parametern von TemporalSoften mal probiert. Das Skript sieht so aus:
LoadPlugin("c:\Programme\AviSynth2\plugins\TDeint.dll")

DirectShowSource("H:\ST_6.avi") # AviSource hat nach wenigen Frames einen Fehler ausgeworfen
Crop(0,16,-16,-16) #Top, Left, Down, Right
ConvertToYV12 # Farbraumkonvertierung wegen TDeint
TDeint()
TemporalSoften(2,8,16,15,2)

Mit DGBob und hqdn3d aus AviDemux sieht es so aus:
http://666kb.com/i/bvtrsnkrf0tjhpwab.png

Mit obigem Skript:
http://666kb.com/i/bvtrusnbwc009px2r.png


Ist jetzt kein so großer Unterschied dass es sinnvoll wäre alles nochmal neu zu machen.

Warum ist das Copping von AviSynth am oberen und linken Rand eigentlich anders? Ich wollte recht, links und unten jeweils 16 Pixel abschneiden, ist da Crop(0,16,-16,-16) nicht richtig? :confused:



Übrigens habe ich zum Spaß mit AviDemux auch mal in x264 encodiert. Abgesehen davon dass es zu meinem Erstaunen kaum länger gedauert hat als mit XviD wurde die Datei weniger als halb so groß (10,8 vs 5,1 MB)!! :O Dabei hatte ich in x264 sogar CABAC deaktiviert.

http://666kb.com/i/bvtrytm4a0euc0nub.png

MfG
Rooter

[HeldImZelt]

Warum ist das Cropping von AviSynth am oberen und linken Rand eigentlich anders? Ich wollte recht, links und unten jeweils 16 Pixel abschneiden, ist da Crop(0,16,-16,-16) nicht richtig? :confused:
War mein Fehler... hatte ich etwas später via edit korrigiert. Es ist nicht T,L,R,D sondern L,T,R,D, also Crop(16,0,-16,-16). Schau im Zweifel in die Avisynth Referenz Dokumentation im Startmenü.

Übrigens habe ich zum Spaß mit AviDemux auch mal in x264 encodiert. Abgesehen davon dass es zu meinem Erstaunen kaum länger gedauert hat als mit XviD wurde die Datei weniger als halb so groß (10,8 vs 5,1 MB)!! :O Dabei hatte ich in x264 sogar CABAC deaktiviert.
Warum deaktivierst du Cabac? Das ist nicht empfehlenswert.
Ohne genaue cmdline beider Encoder ist deine Aussage ziemlich nichtssagend. x264 mit crf und veryslow preset holen sicherlich mehr raus.

Bevor du DirectShowSource nimmst, probiere lieber FFVideoSource. DirectShow hat einen beschissenen Taktgeber und läuft mit hoher Wahrscheinlichkeit irgendwann aus dem Ruder, abgesehen davon, dass der Sync mit jedem Neuaufbau des Rendergraphen sowieso anders ist.

Bei AviSource kommt es drauf an, welchen VfW Dekompressor das System wählt. Wenn du FFDShow installiert hast, aber mit dem alten HuffYUV standalone Kompressor aufgezeichnet hast, könnte FFDShow den 4cc (http://de.wikipedia.org/wiki/FourCC) "klauen" und versuchen das Material zu dekodieren, was vermutlich nicht reibungslos geht. In FFDShow/VFW Konfiguration' kann man auch 'Huffyuv' abschalten, sofern man nur den alten Codec verwenden will.

Nimm für die Filter besser nicht meine Werte, sondern spiele selbst damit rum und passe es an dein Material an. HQ3DN gibt es auch als Plugin. Bei Doom9 gibt es Stimmen, die eher HQ3DN bevorzugen.

Standbilder (Screenshots) bei Temporalfilter sind trügerisch, weil sie bei Bewegungen ihre Wirkung verlieren. Der Betrachter sollte dieses Pulsieren nicht bemerken. Ein gewisses Grundrauschen sollte immer da sein. Der Filter verleitet förmlich dazu, stark aufgedreht zu werden, weil er das Rauschen bei Standbildern perfekt wegglühen kann ohne nennenswert Details zu verlieren. Bei Bewegungen wird es dann schlagartig "dreckig" mit Rauschen und Ghosting. Grundsätzlich ist es aber nicht verkehrt den Filter mal testweise ordentlich aufzudrehen, um die Nebeneffekte kennenzulernen.

Hast du mal probiert direkt in YV12 (YUY2->YV12) aufzunehmen?

[Rooter]

War mein Fehler... hatte ich etwas später via edit korrigiert. Es ist nicht T,L,R,D sondern L,T,R,D, also Crop(16,0,-16,-16). Schau im Zweifel in die Avisynth Referenz Dokumentation im Startmenü.Ah, okay. :D

Warum deaktivierst du Cabac? Das ist nicht empfehlenswert.Aus Kompatibilitätsgründen, ich dachte ich würde damit die Lauffähigkeit des Videos auf bestimmten Geräten einschränken. Aber ich habe es letzte Nacht nachmal mit CABAC encodiert und die Datei hat sich nochmal von 240 auf 195 MB verkleinert! Auf Handy und TV läuft sie aber trotzdem noch so dass ich das wohl zukünftig anlassen werde.

Ohne genaue cmdline beider Encoder ist deine Aussage ziemlich nichtssagend. x264 mit crf und veryslow preset holen sicherlich mehr raus.Ich will halt einen sinnvollen Kompromiss zwischen Qualität und Encodingzeit wobei die Qualität natürlich wichtiger ist. Hier der Auszug aus MediaInfo:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@3.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 25mn 34s
Bit rate : 922 Kbps
Width : 688 pixels
Height : 560 pixels
Display aspect ratio : 1.229
Frame rate mode : Variable
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.096
Stream size : 169 MiB (86%)
Writing library : x264 core 106 r1732 b20059a
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=26.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


Standbilder (Screenshots) bei Temporalfilter sind trügerisch, weil sie bei Bewegungen ihre Wirkung verlieren. Der Betrachter sollte dieses Pulsieren nicht bemerken. Ein gewisses Grundrauschen sollte immer da sein. Der Filter verleitet förmlich dazu, stark aufgedreht zu werden, weil er das Rauschen bei Standbildern perfekt wegglühen kann ohne nennenswert Details zu verlieren. Bei Bewegungen wird es dann schlagartig "dreckig" mit Rauschen und Ghosting. Grundsätzlich ist es aber nicht verkehrt den Filter mal testweise ordentlich aufzudrehen, um die Nebeneffekte kennenzulernen.Ich weis, gerade bei temporären Filtern kann das in Bewegung gruselig aussehen.

Hast du mal probiert direkt in YV12 (YUY2->YV12) aufzunehmen?Nein, es hat ja bisher so funktioniert. :ugly: Außerdem bin ich jetzt eh so gut wie fertig mit dieser Aktion.

Andere Sache, wieso kann ich eigentlich .avs Dateien nicht im MPC-HC öffnen? Das Fenster öffnet sich und dann lastet der einen Kern aus und es geht nix mehr weiter. Auch nach dem schließen des Fensters bleibt der Prozess im Speicher. Mit dem Windows Media Player laufen die Skripte problemlos? :confused:

MfG
Rooter

[HeldImZelt]

Aus Kompatibilitätsgründen, ich dachte ich würde damit die Lauffähigkeit des Videos auf bestimmten Geräten einschränken. Aber ich habe es letzte Nacht nachmal mit CABAC encodiert und die Datei hat sich nochmal von 240 auf 195 MB verkleinert! Auf Handy und TV läuft sie aber trotzdem noch so dass ich das wohl zukünftig anlassen werde.
Der H.264 Standard definiert Profile, die Konformität zu Hardwareklassen gewährleisten sollen.

Du benutzt derzeit high@3.0. Wenn du daraus base@3.0 machst, sollte es auch auf älteren Geräten laufen. Audiokompressor und Container müssen auch passen. Im Zweifelsfall öffne ein Video mit MediaInfo, das das Handy selbst erstellt hat.

wieso kann ich eigentlich .avs Dateien nicht im MPC-HC öffnen? Das Fenster öffnet sich und dann lastet der einen Kern aus und es geht nix mehr weiter. Auch nach dem schließen des Fensters bleibt der Prozess im Speicher. Mit dem Windows Media Player laufen die Skripte problemlos? :confused:
Ist bei mir derzeit auch so. Keine Ahnung, was da nicht stimmt. Ich benutze den mpc-hc kaum.

[Rooter]

Der H.264 Standard definiert Profile, die Konformität zu Hardwareklassen gewährleisten sollen.

Du benutzt derzeit high@3.0. Wenn du daraus base@3.0 machst, sollte es auch auf älteren Geräten laufen.
Audiokompressor und Container müssen auch passen. Im Zweifelsfall öffne ein Video mit MediaInfo, dass das Handy selbst erstellt hat.Das Handy (Samsung Wave GT-S8500) zeichnet in Baseline@L3.0 auf, was aber wohl daran liegt dass die Hardware für 720x480@29,97fps in Echtzeit zu schwach ist. Wiedergeben kann es auch High@L3.1 (1280x720@29,97fps). Ich weis noch dass bei meinem letzten Handy CABAC das Problem war, aber wenn das 20% kleinere Dateien bringt nehme ich darauf keine Rücksicht.

Welchen Container sollte ich eigentlich nutzen, MP4 oder MKV? Für MP4 gibt es ja z.B. YAMB (http://yamb.unite-video.com/features.html) aber mit welchem Programm kann man denn MKV muxen bzw. demuxen?

Ist bei mir derzeit auch so. Keine Ahnung, was da nicht stimmt. Ich benutze den mpc-hc kaum.Habe mich da heute Nachmittag mal dahinter geklemmt und das Problem gefunden: Nachdem ich die Datei ffavisynth.avsi aus dem plugins-Ordner von AviSynth entfernt hatte (bzw. ich habe die Dateiendung geändert) laufen die Skripte im MPC-HC.

MfG
Rooter

[HeldImZelt]

Das Handy (Samsung Wave GT-S8500) zeichnet in Baseline@L3.0 auf, was aber wohl daran liegt dass die Hardware für 720x480@29,97fps in Echtzeit zu schwach ist. Wiedergeben kann es auch High@L3.1 (1280x720@29,97fps). Ich weis noch dass bei meinem letzten Handy CABAC das Problem war, aber wenn das 20% kleinere Dateien bringt nehme ich darauf keine Rücksicht.
Es gibt noch einen weiteren Flaschenhals, der nicht von den Profilen abgedeckt wird, das wären Puffer und Datenbus des Zielgeräts. Wenn der Dekoder Daten generiert, die den Puffer unter- oder überfordern (oder den Datenbus überfordern), kommt es zu Störungen. Um das zu verhindern gibt es vbv-maxrate und vbv-bufsize (http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#VBV_Encoding) Settings in x264. Kurz gesagt ist das eine Art maximaler Datenstrom in kilobit/s (Streamingbandbreite), den der Dekoder nicht überschreiten soll. Das muss natürlich schon beim Encoden angegeben werden.

Die derzeitige Strategie des offiziellen x264 Frontend (MeGUI) sieht vor, nur noch das Zielgerät (Target Playback Device) anzugeben, das Encoderpreset (Fast<>Slow) und ggf. das Tuning (Film, Anime..), so dass der User keine weiteren Einstellungen mehr vornehmen braucht. Einige Geräte (Handys, Konsolen..) sind schon drin mit passenden VBV-Werten.

Du kannst ja einfach mal testweise die VBV Werte runter schrauben oder als CBR kodieren. Bei MeGUI wäre das im 'Misc' Tab unter 'Custom Command Line' (--vbv-bufsize 2500 --vbv-maxrate 2500). Eventuell kannst du mit dem Bitrateviewer (http://www.winhoros.de/docs/bitrate-viewer/) die VBV Datenrate anhand eines Originalvideos genauer ausloten.

Auf dem Bild sieht man die x264 Kommandozeile mit VBV Limits von 2.5MBit/s für Android G1 Handys, ausgelöst durch Auswahl des 'Target Playback Device'.
http://www.abload.de/thumb/meguisdlq.png (http://www.abload.de/img/meguisdlq.png)

Welchen Container sollte ich eigentlich nutzen, MP4 oder MKV? Für MP4 gibt es ja z.B. YAMB (http://yamb.unite-video.com/features.html) aber mit welchem Programm kann man denn MKV muxen bzw. demuxen?
Welches du nimmst ist an sich egal. MKV wird aber nicht von vielen Geräten unterstützt, so dass man auf MP4 ausweichen muss. Ansonsten würde ich immer MKV bevorzugen.
MeGUI kann alles muxen/demuxen. Standalones sind z.B. 'My MP4Box GUI (http://my-mp4box-gui.zymichost.com/index.html)' oder MKVToolnix (http://www.bunkus.org/videotools/mkvtoolnix/index.html)

Habe mich da heute Nachmittag mal dahinter geklemmt und das Problem gefunden: Nachdem ich die Datei ffavisynth.avsi aus dem plugins-Ordner von AviSynth entfernt hatte (bzw. ich habe die Dateiendung geändert) laufen die Skripte im MPC-HC.
Kurioserweise geht es bei mir gerade auch... Vorführeffekt. :)

[Rooter]

Habe mal rumprobiert und stelle fest dass die Datenrate für dieses Handy kein Problem darstellt. Selbst bei 7500kbps (CBR und vbv-maxrate) lief das 1280x720p Testvideo einwandfrei, wobei die Datenrate laut MediaInfo "nur" 5622kbps betrug. Erst als ich es mit 13000kbps übertrieb... -- kam kein Ton mehr, das Bild war immer noch okay. :D Was ich aber feststellen musste: Zumindest in dieser hohen Auflösung kommt es mit B-Frames nicht so recht klar, selbst bei CBR 1500 stockt das Video ganz minimal wenn B-Frames vorhanden sind. War mir vorher nie aufgefallen, bei ganz langsamen Schwenks sieht man es aber.
Interessant fand ich dass das Profil von XMediaRecode für dieses Handy eine vbv-maxrate von nur 1500 vorsieht und auch keine B-Frames, aber auch kein CABAC. :rolleyes:

Ich encode gerade noch ein Video mit nur 1 statt 3 B-Frames, mal sehen wie das läuft.
EDIT: Mit nur 1 B-Frame ist das Stocken weit weniger ausgeprägt aber immer noch vorhanden. Mal sehen wie es bei XviD ist...

MfG
Rooter