Beiträge von Sagaras

Das hängt mit deinem Schnittprogramm zusamm. Musste mal schauen ob du in deinem Schnittprogramm irgendwo in den Optionen oder Encodiersettings einen Haken findest das das Abspielen nach dem "Rendern" erfolgt.

Das kommt wie gesagt auf das Material und dem Resizer an was der Denoiser dann als Ergebnis bietet.

Zitat von RealLiVe

Sind sie das tatsächlich, oder ist die Angabe dazu "nur" wünschenswert, um dem Decoder möglichst viele Informationen bereitzustellen? I.d.R. müsste das auch ohne die Angabe der Parameter zufriedenstellend funktionieren.

Dann bekommste ein BT.601 Video. Knallhart. x264 bei MeGUI arbeitet ganz anders. Der würde BT.709 nutzen. FFmpeg hat aber nicht nur x264 enthalten, sondern das ganze Spektrum. Und da wird auf BT.601 zurückgegriffen. Also ja, die Angabe ist sehr wichtig.

Zitat von RealLiVe

War die gängige Empfehlung nicht, das bei höheren CRF-Werten auf den Standardwert zu belassen?

Bei einem CRF unter 20 könnte man es rauslassen. Aber es schadet auch nix wenn es drin steht. Und wenn es drin steht, macht euch die Arbeit damit eh leichter. Weil die Faulheit von Usern ist meist so, das sie es dann eh nicht wieder entfernen und dann einfach mal mit CRF 24 oder so encodieren.

Lass es drin.

Zitat von strohi

Ist für mich irgendwie logischer, das so zu machen, dass ich das alles nach Kategorie aufteile, aber ich kann es auch so machen, dass ich die Mappings mit den Kodiersettings mische.

Mach das mal am besten so wie ich vorgeschlagen haben. Weil sonst kommste irgendwann mit FFmpeg durcheinander und suchst dich dumm und dämlich, wenn irgendwas nicht hinhauen sollte.

Mit map selektierst den Stream den du mit den Filtern danach bearbeiten willst.

Bei dir ist das jetzt noch nicht schlimm. Weil du hast du ein Video Stream und ein Audio Stream was du selektierst. Wenn du aber mehrere hast, kommst du damit durcheinander. Weil dann zwei Audiospuren so anzugeben:

-map 0:1 map 0:2 -c:a vorbis -c:a pcm_s16le

geht nicht Aber das hier würde dann gehen:
-map 0:1 -c:a vorbis map 0:2 -c:a pcm_s16le

Weil dann weiß FFmpeg welchen Stream er wie kodieren soll. Das gilt auch für Filter.

Zitat von strohi

ffmpeg_64 -f dshow -video_size 720x480 -rtbufsize 702000k -i video="AVerMedia GC550 Video Capture":audio="AVerMedia GC550 Video Capture" -map 0:0 -map 0:1 -vcodec copy -acodec copy FRTest4.avi

Jetzt haste das Deinterlacing wieder vergessen

Und am besten ist es, wenn du map nutzt, das auch korrekt einzuordnen. FFmpeg hat eine schlichte lineare Anweisungskette und sollte am besten auch so ausgeführt werden.

Sprich so:

ffmpeg_64 -f dshow -video_size 720x480 -rtbufsize 702000k -i video="AVerMedia GC550 Video Capture":audio="AVerMedia GC550 Video Capture" -map 0:0 -vf yadif -vcodec copy -map 0:1 -acodec copy FRTest4.avi

Und dann liegt das Video in BT.601 TV Range vor. Also anhand deiner Roh Aufnahme. Wenn, dann würde ich da vllt. ein leichten Level Filter drauf anwenden.

Levels(4, 1.0, 252, 0, 255, coring=false)

Sowas ungefähr.

So, und in der AVI Datei stehts schon was für die Warnung in FFmpeg verantwortlich ist.

Das sollte dich aber nicht weiter stören.

In der AVI ist ein Fakeansatz der VFW Schnittstelle enthalten. Daher steht da auch bei Video x264 mit allen Angaben. ABER das Ding, also der Video Stream in der AVI ist ja komplett leer, weil du das ja als h264 via x264vfw von der AVI entkoppelt hast. Sprich ein Extra File angelegt.

Und weil FFmpeg nun dieses leere Video dekodieren will, meldet er Warnungen aus, weil das halt nicht geht. Wo nix ist, kann nix gemacht werden.
Da bekommste Warnungen von wegen das der Video Index nicht hinhaut oder der Chuck nicht stimmt.

Aber du willst ja aus der AVI auch nur die Audiodatei haben. Und das ist das wichtige. Und das macht er ja anscheinend ja auch wie vorgesehen.

Lass dich da also nicht irritieren. Das hat seine Richtigkeit so.

Zitat von strohi

Das stimmt allerdings. Die Ausgabe vom reinen SCART-Kabel sieht extrem nice aus.
Wenn nur das Capturen von SCART nicht so teuer wäre..

Volle PIN Belegung eines SCART Anschlusses entspricht S-Video Qualität.
FBAS braucht nur ca. die Hälfte der PIN Belegung bei SCART. Kann man z.B. bei PS1 oder PS2 SCART Kabeln sehen

Zitat von strohi

Was wären denn jetzt die nächsten Schritte?

Die Schritte sind immer gleich:

• Input
• Deinterlacing
• Bild-Zuschnitt (Cropping)
• Skalierung (Resize)
• Entrauschen (Denoise)

Bzw. kann man noch überlegen 4 und 5 zu tauschen. Kommt auf das Material und Skalierung an.

Zitat von strohi

Danach Änderung an den Farben (Irgendwie sind die Farben zu matt.. Echt sehen sie erst aus, wenn ich zwei mal von TV- auf PC-Range konvertiert habe)?

Komponenten Kabel Übertragung als auch S-Video, SCART oder FBAS Y/C übertragen das was die Konsole vorgibt. Und da die Konsolen meist auf ein Standard geeicht sind, sind sie zum einen auf TV Range und BT.601 geeicht. Bzw. Smpte240m, was ja ungefähr BT.601 entspricht.

Das heißt:
Du nimmst in PC Range auf und dein Video liegt in TV vor. Da ich aber keine festen Werte für deine TV Range habe, weil es gibt ja noch mehr Varianten als nur 16 - 235. TV kann auch sein 16 - 240

Und dann wird es böse.
Am besten du versuchst mal statt utvideo, einfach nur den Copy Befehl zu nutzen. Damit du eine 1:1 des Rohmaterials hast.

Wenn du das hast, lad das mal hoch und dann schau ich mal an was du da hast.

Zitat von strohi

Echt? Geht da nicht mehr? Ich dachte, dass Komponente zumindest 4:2:2 kann.
Na sowas..

Macht allerdings keinen großen Unterschied, die LGX sendet immer 4:2:2..

Komponenten Kabel macht meist nicht mehr als YUV4:2:0

Blöd ist es wenn das dein Aufnahmeprogramm auf ein Standard stellt wie YUV4:2:2

Zitat von strohi

Das Pixelformat überschreibt da nix am Codec, ich hab nur die Aufnahme kürzen wollen, dabei total verkackt und dadurch kam dieser Schrott bei raus.

Die Angabe "-pix_fmt:v yuv422p" am besten komplett raus lassen. Sehe keinen Sinn dahinter. Wenn du nicht grad den Farbraum beeinflussen willst damit, lass es weg. Weil dann nimmt sich FFmpeg immer den Farbraum der auch ankommt vom Input.

Zitat von SasZ_wtf

EDIT: MediaInfo von der h264 Datei? Funktioniert ja nicht, oder?

Doch von dieser Datei und eine Mediainfo der AVI Datei.

Erst mal eine Mediainfo von dem Video das du auf die Batch Datei ziehst.

Und dann am besten postest du den Inhalt der Batchdatei. Aber bitte mit in ein Code Fenster kopieren den Inhalt.

Müsste ich sehen was du da tust. Sonst wird das ein blindes Unterfangen

Wie war denn der FFmpeg Befehl?

@RealLiVe

Und hier noch ein paar weitere Settings die man bei Shotcut unter Sonstiges treffen kann:

movflags=+faststart
preset=medium
x264opts=crf=18:aq-strength=1,25:colorprim=bt709:transfer=bt709:colormatrix=bt709:keyint=infinite:min-keyint=1

Da FFmpeg nur den 8Bit Encoder enthält aq-strength beachten. Den mov-atom flag in der ersten Zeile bitte belassen. Bei MeGUI muss man das nicht angeben, wenn MP4 ausgewählt ist. Das ist speziell für den Container gedacht, damit Videos beim Streaming sofort weiterverarbeitet werden können. Sprich auf YT hochladen und YT kann schon während des Uploads encodieren. Bei FFmpeg muss man das aber mit angeben.

Des weiteren hier mal ein paar Angaben von wegen Qualitätsbasierend (VBR)

100%       = CRF 1
 66% - 67% = CRF 18
 60% - 61% = CRF 21
 56% - 57% = CRF 23 (x264 Default)
  0%       = CRF 51

Das kann auch unter dem Punkt Sonstiges getroffen werden.

Und dann muss man noch die richtigen B-Frames angeben. Die macht das Teil nämlich nicht nach Angabe des Presets.
B-Frames für:
ultrafast = 0
superfast = 3
veryfast = 3
faster = 3
fast = 3
medium = 3
slow = 3
slower = 3
veryslow = 8
placebo = 16

Bei der GOP Angabe bitte die FPS * 100 angeben. Das ist euer Keyint Wert. Der min-keyint bestimmt shotcut automatisch und nimmt exakt den keyint Wert / 100

PS:
Oben in der Liste mit den x264 Angaben, habe ich auch noch mal das mit keyint infinite mal mit angegeben. Sprich wer das nicht braucht, muss die Einträge von keyint und min-keyint unter Sonstiges entfernen.

Auch habe ich Spaßenshalber mal den CRF Wert angeben unter Sonstiges. Klappt auch Wunderbar und ignoriert den Qualitäts % Wert unter dem Punkt Codec.

Sehr Wichtig sind aber die Colormatrix, Transfer und Charakteristika Werte. Auch die lassen sich via Sonstiges einfügen.

Und da FFmpeg einen 8Bit Encoder für x264 benutzt, bitte aq-strength auf 1.25 stellen wie oben angegeben.

Der Rest sollte dem Standard Preset entnommen werden, sofern keine anderen Angaben in Shotcut diese überschreiben.

Edit:
Sind dann die gleichen Settings dann die wir alle auch bei MeGUI nutzen oder x264vfw. ;D

Zitat von RealLiVe

Das wird bei mir auch nicht übernommen ... scheint wohl ein Bug zu sein. Sowas wird noch häufiger vorkommen - wie gesagt, fertig ist das Ding noch lange nicht.

CRF kennt kein QP=0, da CRF ein verfahren ist das sich QP Werte für I, P und B Frames selbst ermittelt. Ansonsten ist es ja Schwachsinn von wegen gleichbleibender Qualität

Bei Shortcut Lossless mit x264 ober besser gesagt libx264 hinzubekommen muss man entweder AVR oder CBR anwenden und erst dann greift auch QP=0. Weil QP=0 ein fester Wert ist.

Wieso nicht viel einstellen? Unter Sonstiges kannste das gesammte Spektrum nutzen was das FFmpeg Plugin erlaubt.

Zitat von De-M-oN

Naja und anscheinend ja auch weniger fps..

Hatte ich ja schon genannt. PAL 50Hz und NTSC mit 60Hz

Und dann gabs bei einigen Nintendo Konsolen als auch anderen Konsolen die Variante PAL_60
Sprich PAL mit 60Hz

Gegenstück gibt es dann auch und ist ganz klar NTSC_50. Nimmt man meist nur nie. Sieht schrecklich aus ;D

Warum das so Konzipiert wurde hing zum größten Teil mit den Geräten zusammen wie Fernseher, Reciver.

Für uns in Deutschland ist eigentlich nur gut zu wissen:

• PAL 50Hz = PAL_B = für die meisten europäische Länder, darunter auch Deutschland, England, Frankreich
  B steht für (Alt: IV) CCIR-Norm (Bei Farbübertragung ist die Bildübertragung exakt 25Hz)
• NTSC 60Hz = NTSC_M = US Länder (Wird meist auf den Verpackungen sogar noch spezifiziert mit NTSC U, NTSC C etc.)
  M steht für (Alt: II) Amerikanische FCC-Norm, seit der Farbübertragung ist die Bildrate 30/1,001 ≈ 29,97 Hz.
• NTSC 60Hz = NTSC_J = Ost Asiatische Länder. Japan, China, etc. pp.
  J unterscheidet sich von der Amerikanischen Norm im IRE Signal Level. USA hat einen mit 7.5 und J mit 0

Je nach Gerät und Spiel müssen diese abgestimmt werden. Und das gilt für das Endgerät natürlich auch. Sonst gibt es lustige Bildverzerrungen und Farbspinnerein. Zum einen Weil sich PAL und NTSC von den Zeilen schon unterscheiden, zum zweiten von der Norm der Signalübertragung und zu guter letzt von der Hertz Zahl.

z.B. Wenn eine Konsole nur für PAL ausgelegt ist und keine NTSC Spiele unterstützt, dann kann das Spiel A) nicht abgespielt werden, weil es erkannt wird das es sich um ein NTSC Spiel handelt ODER das Spiel wird langsamer auf einmal. Weil von 29.97 FPS auf 25 FPS, macht sich schon bemerkbar auf der Konsole

Die meisten Konsolen werden aber mittlerweile alle Länderübergreifend Kompatibel gemacht.

Die einzigen Konsolen die diesen Blödsinn noch verzapfen sind Konsolen vor der PS3 Ära.

Wenn ich jetzt z.B. Resident Evil 4 aufnehmen würde von der PS2, dann habe ich die Auswahl zwischen 50Hz und 60Hz.

ABER.... die PAL Version die dies erlaubt hat daher kein NTSC Material. Sprich, es kann immer noch Interlaced sein. Weil dann haben wir den Fall PAL_B oder PAL_60

Und ja, deutsche Spiele für alte Konsolen sind meist ganz mies auf Grund dessen das sie Interlaced Material haben.

Trifft jetzt nicht auf alle alten Konsolen zu wie SNES oder NES. Da wird das RGB Signal regelrecht vergewaltigt am Output der Konsole um es für FBAS oder SCART Übertragung auf ein Niveau unterhalb der YUV4:2:0 Marke zu bringen.

Daher gibt es ja auch für SNES oder NES auch die Möglichkeit das Signal durch Eigenbau an der Konsole so zu modifizieren das man das Signal z.B. auf ein HDMI umpolen kann. RGB -> HDMI = Sauberes Bild. ;D Nicht nur für die Glotze dann, sondern auch für die Aufnahme.

Aber wen das dann interessiert, der sollte sich mal nach Modifikationen umschauen im Netz.

@De-M-oN
Ist bei den meisten PAL Spielen so gelaufen. Die Amerikanischen und Japanischen Versionen waren meist alle Progressiv Titel. Europa bildet da mal wieder ne Ausnahme. Diese Länder haben dann meist den Interlaced Mist bekommen.

Nagut, andere Zeiten.
Ich finde es viel trauriger wenn Puplisher heutzutage BluRays erstellen mit Interlaced Material und dann noch so doof sind das falsch zu Encodieren und daraus ein Augenkrebs Video auf den Markt bringen.
http://forum.gleitz.info/showt…BAFF-richtig-deinterlacen

@strohi
Ob das FFmpeg überhaupt kann bei utvideo ist Fraglich. Die werden da vermutlich nur Progressiv reingeballert haben.

Aber das ist ja nicht so schlimm. Musste es halt vorher Deinterlacen und dann kann man ja auch progressiv aufnehmen. Weil dein Material von der Konsole. (gerade GameCube) Interlaced sendet.

Das kann Spielabhängig sein, aber auch Konsolenabhängig.

Als Vergleich: Final Fantasy 12 für die PS2
PAL Version (Sprich die Europäische) hat 50Hz und liegt samt Videos in Interlaced vor.
US und JAP Version haben 60Hz und Spiel, als auch die Videos liegen in Progressiv vor.

Und die Game Cube gibt sogar meines Wissens in PAL_60 aus mit samt Interlaced.

Da haste dir mit FFmpeg eines der schwierigsten Sachen rausgefischt um eine Capture Card bzw. Capture Box anzusprechen.

Und deine Aufnahme war ja nicht mal UTVideo gewesen die ich letztens von dir gezogen habe, sondern reines unkomprimiertes YUV4:2:2, weil du das pix_fmt nach UTVideo angibst. Wieso? Entweder davor, oder gar nicht. xD

Weil wenn deine Konsole nur FBAS hat oder Komponenten Kabel oder SCART, dann ist YUV4:2:2 schon viel zu hoch. Weil über diese Leitungen geht höchstens YUV4:1:1 oder mit Komponenten Kabel YUV4:2:0 maximal. Odern wenn du S-Video nutzen solltest und die PIN Belegung komplett genutzt wurde bei SCART, dann kommst du dem Komponenten Kabel sehr nahe.

Aber YUV4:2:2 wird es mit Sicherheit nicht.

Heißt: Zeile 9 komplett rauslassen.

Weil wie gesagt, so habe ich es exakt runtergeladen von deinem Link:

Video
ID                                       : 0
Format                                   : YUV
Codec-ID                                 : YUY2
Codec-ID/Info                            : YUV 4:2:2 as for UYVY but with different component ordering within the u_int32 macropixel
Dauer                                    : 10s 20ms
Bitrate                                  : 276 Mbps
Breite                                   : 720 Pixel
Höhe                                     : 480 Pixel
Bildseitenverhältnis                     : 3:2
Bildwiederholungsrate                    : 50,000 FPS
ColorSpace                               : YUV
ChromaSubsampling/String                 : 4:2:2
Bits/(Pixel*Frame)                       : 16.000
Stream-Größe                             : 330 MiB (99%)

Und da steht nix von UTVideo ;D Da steht reines unkomprimiertes YUY2

Und dann wie gesagt vorher Deinterlacen, bevor du aufnimmst.

ffmpeg_64.exe ^
  -f dshow ^
  -video_size 720x480 ^
  -rtbufsize 702000k ^
  -i video="AVerMedia GC550 Video Capture":audio="AVerMedia GC550 Video Capture" ^
  -map 0:0 ^
  -vf yadif ^
  -c:v utvideo ^
  -map 0:1 ^
  -c:a:0 pcm_s16le ^
output.avi

So z.B.
Jetzt müsste der Deinterlacer Yadif dafür sorgen das der Video-Input von map 0:0 deinterlaced wird, bevor er überhaupt mit dem Codec encodiert wird. Und das ist wesentlich besser. Lieber die originale Quelle deinterlacen, als es bei einem Codec zu versuchen wo man es vllt. nicht mehr kann.

Interlacing so früh wie möglich immer entfernen. Das macht man immer als erstes.

Das ist auch so ein Bug von Bandicam.

Versuche die Aufnahme am besten via VirtualDub zu retten. Bandicam wird das nicht richtig geschlossen haben oder hat falsche Index Daten reingeballert.

Und du hast bei Audio als auch bei den Videoeinstellungen geschlafen.

Bandicam kann lediglich über die VFW Schnittstelle NUR YUV4:2:0. Das heißt das du mit 4:2:2 ein 4:2:0 aufgenommen hast und das ist Witzlos Mehr gemacht als nötig bzw. gar vorhanden war.

Und bei Audio genau das gegenteil. Statt Verlustfrei haste den übelsten Verlustcodec seit es Windows 3.11 gab genommen. Mpeg 1

So ziemlich eine Katastrophen Aufnahme

Schau hier mal rein sofern du die Aufnahme noch irgendwie retten willst:
Fehlerhafte Aufnahmen reparieren
Ungeschlossene AVI (fehlender Header, index, keyframes) reparieren

Der Fehler besagt das mit deinem Video was nicht stimmt.

AVISynth kann ihn nicht laden, der hängt sich schon am Ladefilter auf. Oder besser gesagt am UTVideo Codec.

Überprüfe ob das Video im MPC-HC funktioniert und poste mal eine Mediainfo zu dieser Aufnahme.

Zitat von GrandFiredust

2 Pass VBR ist auf DVDs und Blu-Rays ausgelegt.

Ja.... Nein. Dafür ist das auch nicht. Das kann ich auch mit 1pass machen
VCDs kann ich ja auch mit 2pass machen. Blu-Rays kann ich auch via CRF machen (1pass)
Das ist der DVD oder der Blu-Ray völlig Wumpe

Je mehr Durchgänge er machen kann, desto mehr Referenz Material kann er sammeln um z.B. Bitrate und Kompression besser nutzen zu können ohne die Qualität stark zu beeinträchtigen die mit der gewünschten Bitrate angegeben wurde oder halt die Dateigröße nicht zu sehr Variable zu machen.
Weil 1pass VBR bei einer Bitratenangabe wo 200MB nachher rauskommen soll, kann stark variieren. z.B. zwischen 180MB und 220MB
Auch die Qualität kann so drunter leiden bei einigen Szenen
Bei 2pass VBR wird das besser genutzt und die Zielgröße kann besser angestrebt werden. z.B. zwischen 198MB und 202MB
Und das Video hat die Bitrate besser genutzt, weil vorher mit 1pass die Daten analysiert worden sind die der 2pass besser nutzen kann.

Das kann man beliebig weiterführen zu n-Pass. Hat in der Regel nur keinen Sinn mehr als 2-pass zu machen. Weil was will man aus den gesammelten Daten noch mehr großartig rausholen?

x264 macht via MeGUI gar 3pass. Der Nutzen dessen fällt aber ins Bodenlose und ist daher für den normalen Gebrauch ungeeignet.

1pass und 2pass müssen Qualitätsmäßig nicht mal unterschiedlich sein. Siehe CRF was ja ein 1pass VBR durchführt.

Der Sinn hinter dem 2pass Verfahren bei Angabe einer Bitrate ist die, das man so effektiv auf Dateigrößen hinarbeiten kann.

Und das lässt sich ja errechnen.

Wichtig ist zu wissen, welcher Farbraum, Auflösung und FPS das Video hat. Und dann könnte man entweder anhand der Bitrate die Dateigröße oder anhand der Dateigröße die Bitrate ermitteln.

Was da dann als Rechenfaktor verwendet wird ist dann die bpp (bit per pixel) und diese werden limitiert bei einer Bitraten Encodierung. Die liegen meist immer unterhalb dem Lossless Bitratenwert für den jeweiligen Farbraum.

Das hatte ich mal woanders angesprochen gehabt: Richtige Einstellungen für Recording in Open Brodcaster Studio

So kann man die Qualität sogar noch etwas begutachten mit dem Wert wie ich es dort gerechnet habe bei Bitraten Encodierungen.

Jede Rechnung aber basiert auf ABR. Also der durchschnittlichen Bitrate. Bei VBR wird das ja noch effizient verteilt. Man weiß also nicht zu 100% was raus kommt.

Und da kommt dann 2pass ins Spiel um die gewünschte Dateigröße anzustreben. Und das ist bei einem 2ten Durchlauf ja auch kein großes Problem mehr, wenn der Encoder weiß wie die Datei genau beschaffen ist und wo er die Bitraten effizient reinstecken soll (verteilen soll).

PS: VP9 kann CRF sogar in 2pass anwenden. Ist ein riesen Aufwand und langsam, aber total Effizient in Sachen Dateigröße und Qualität.