Beiträge von De-M-oN

    Ohje ich bin gar nicht mehr sicher was richtig und was falsch ist.


    Weil die 59,94 von ffms haben diesmal meine kuriosität nicht gelöst:


    Komischerweise hab ich diesma so'n Szenario:


    Habe Audio meines Spielsounds extern aufgenommen und habe dann in TMPGEnc 1 Frame vor meiner Soundstartmarkierung geschnitten und das gleiche mit dem externen Sound - auch 1 Frame vor der soundstartmarkierung (also 1 frame bevor der sound spielt)


    Dann natürlich zum Bereich gegangen wo mein Spiel beginnt und dort dann simultan die spuren geschnitten.


    Dann hätte es ja so eig. 100% synchron sein müssen. Und da kommt jetzt der Punkt wo ich das nicht verstehe.


    Egal ob ich mit L-Smash oder ffms2 in TMPGEnc 6 reingeh (ich geb allerdings 60,1 mit, damit es zu CFR 60 gemacht wird)


    ich muss dann den Sound in MPC-HC um 480ms nach rechts verschieben damit er synchron ist. Also demnach stolze fast 30 frames Abweichung. Wenn ich diese Anpassung mache, ist es allerdings durchweg synchron. Also die konstante framerate ist gegeben und in Avisynth hab ich auch die korrekte Framenummer die TMPGEnc mir genannt hat eingetragen (hab mit TMPGEnc nur synchronisiert und Audio in WAV exportiert, den richtigen Encode mach ich mit MeGUI dann).


    Von daher versteh ich nicht wie das sein kann. Timeline von TMPGEnc stand automatisch schon auf 60fps, weil er aus der Quelldatei einlesen kann wie die Timeline sein soll.


    Achja und bei 'nem vorigen Video mit gleichem Vorgehen hat es auch wunderbar geklappt.



    Und nochmal zurück zum Anfang:


    l-smash vs ffms2 indexierung


    Da bin ich auch verwirrt was da nun richtig ist.
    l-smash erkennt immer so 59,9xx die letzteren beiden zahlen ändern sich je nach video.
    bei ffms2 kommt immer 59,940 bei raus.


    Bei Mediainfo steht sowas:


    Code
    1. Frame rate mode : Variable
    2. Frame rate : 59.940 (59940/1000) FPS
    3. Minimum frame rate : 9.903 FPS
    4. Maximum frame rate : 63.830 FPS
    5. Original frame rate : 60.000 FPS


    Ich frag mich dann schon: Wer hat denn nun Recht? Gesamtframemenge kommt bei beiden Verfahren aber die gleiche Menge raus (also ausgehend von, wenn man nicht auf CFR wandelt via fpsnum und fpsden, sonst ist ja klar das es beides gleich ist)

    FFDShow und/oder Haali installieren, dann sollte es gehen.


    Die großen Entwickler haben scheinbar alle noch nichts von High 4:4:4 predictive gehört, nichts von höheren Chroma Subsamplings als 4:2:0 gehört, geschweige denn 10bit Encoding. Ich versteh echt nicht, warum die großen Timeline Softwares beispielsweise noch immer keine MKV Container öffnen können, kein 10bit de- und encodieren können, und all das was ich aufgezählt habe. Noch dazu fast keine Einstellungen für die Codecs.
    Ich versteh nicht, wie man immer noch solche beta h.264 decoder haben kann, wo der Standard schon weit mehr als 10 Jahre existiert. Warum einfach nur??


    ___


    Und in deinem Falle killt das 10bit Encoding dein WMP...

    Premiere hat kein x264. (als ob die mal was gut machen würden bei encoder oder decoder :hm:
    Von daher haste allerhöchstens dir x264vfw besorgt, ansonsten haste mainconcept..
    Und da gibts nur bitratefixed encoding.

    Hallo, was war eigentlich nochmal der Grund, warum bei ffms2 immer die Threads auf 1 gesetzt werden?


    Weil das ist echt blöd. Hab hier paar MP4s mit VFR und um die nach CFR zu kriegen, nutze ich ffms2. Nur dauert das sehr viel länger zu encoden als mit L-Smash, eben weil ffms2 auf nur 1 Thread läuft..


    L-Smash jedoch erkennt die FPS Rate sehr oft verkehrt. ffms2 erkennt 59,940, was richtig ist, und L-Smash erkennts als 59,928.


    Da hilft dann auch die Angabe von numerator und denominator nicht viel, wenn der aus 59,928 timing heraus auf CFR 60 geht. Dann stimmt das Timing nicht und mein extern vorliegender Audio ist dann asynchron.

    Zitat

    Wahrscheinlich Bicubic oder Bilinear


    Ich würde stark auf Bicubic tippen.


    Bilinear ist viel zu unscharf. Im Leben nicht benutzen die das. Dafür bleiben die Videos zu scharf. Bicubic könnte gut sein denk ich. Und Pointresize erstrecht nicht. Das wäre ja mega aliasing befallen und youtube will nun auch nicht das die Videos komplett scheiße aussehen. Seit VP9 sehen die sogar auf höheren Stufen als 1080p sogar schon verdammt gut aus.

    Warum ist der Interpolate when downsampling Haken nicht drin? ._.


    Glaub mir: Du möchtest den Chroma nicht via Nearest Neighbor konvertieren ... :x Dann ist nämlich jeder 2. Pixel farblos. Und bei PC Aufnahmen haste einen RGB32 Input. Also wird hier jeder 2. Pixel dir farblos gemacht, wenn auf YUV 4:2:2 gehst ohne interpolation.


    Der Haken ist standardmäßig drin und daher wunder ich mich, warum du den entfernt hast?


    Wenn du in YUY2 aufgenommen hast, würd ich diese auch behalten.


    Demnach würd ich in MeGUI auf NO drücken und bei x264 config in custom commandline:


    --output-csp i422


    eintragen. Dann behältste die Chroma Qualität von 4:2:2 bei. Wenn auch mit jedem 2. Pixel farblos. Würde ich vllt erneut aufnehmen..

    Zitat

    Der Standard-Wert von x264 (23) wird im CRF-Verfahren schon auffällige Verluste hinterlassen, mag aber für Web-Videos ausreichen, die man in angenehmer Zeit herunterladen können soll.


    Hängt aber auch sehr von der Auflösung ab.
    Während 1280x720 schon bei CRF20 mir etwas verlustig erscheint, kommt zb 3200x1800 selbst mit CRF25 noch ziemlich hervorragend davon.

    Zitat

    Unendliche GOPs sind auch nicht zu empfehlen, wenn die Videodaten auf störanfälligem Weg übermittelt werden. Ein falsches Bit, das einen Decodierfehler auslöst, und im schlimmsten Fall setzt der Bildfehler sich bis ans Ende des Videos fort, während YouTube das hochgeladene Video konvertiert. Sicher ist das Risiko gering, aber es wäre schon schade, wenn das Hochladen von Gigabytes nachträglich umsonst gewesen wäre.


    Einfach kein WLAN nehmen, dann passiert auch nix. Hat youtube noch nie gestört. Die encodierens ja auch eh um.


    Im Doom9 forum stand aber auch geschrieben das trotz CRF die schnelleren Presets weniger Qualität liefern^^ Glaub das stand sogar auch mal hier, hm ^^

    Doch Spline100 ist eher weich, warum auch immer, ist aber echt so.


    Spline144 ist aber wiederum ähnlich zu 64, also eher scharf. Aber 100 ist irgendwie sehr weich. Weicher als Spline16. Und am besten komprimierbar, wobei bilinear, bicubic, gauss hab ich noch nicht probiert. Aber bilinear hab ich als nicht sonderlich schön in erinnerung.


    Naja Auflösungsskalierung ggf mit äußerst sanftem motion blur ist eig. nicht so destruktiv fürs video. Weniger Sättigung wär mir glaub ich beispielsweise zu großer Angriff aufs Bild.


    Wie sieht denn fluxsmooth aus? Ghosting ala frameüberblendung wenn der sony vegas user mal wieder falsche fps rate in projekteinstellungen hatte, find ich zb sehr sehr hässlich :/

    Motion Blur macht das Video etwas komprimierbarer. Besser natürlich ingame motion blur verwenden. Ein leichtes reicht da ja schon.


    Gerade vegetationsstarke Spiele macht youtubes starke kompression zu schaffen.


    LigH: Was ahnst du denn? Und was gefällt dir nicht? Sprich dich aus :)


    Die Situation mit youtube ist halt, das sie allem anschein nach folgendes tun:


    CRF von ungefähr 30, kombiniert mit einer VBV-maxrate bei eher schlechten x264 einstellungen, so das selbst ihr CRF30 bitratenmäßig beim meisten material gebremst werden muss von der schwachen vbv-maxrate.
    Je besser die Auflösung, desto höher ist aber die vbv-maxrate angesetzt. z.B. bei 1080p,30fps gibts nur 4000 kbit vbv-max und bei 1440p schon ~10000 kbit vbv-maxrate. 1080p@60fps bekommt wenigstens 6000 kbit vbv-maxrate.


    Daher suchen wir halt Wege das Video so komprimierbar wie möglich zu kriegen via weichem Resizer ala Spline100, evtl ein bisschen Motion Blur zb. Sowas eben. Vllt habt ihr ja sonst auch noch tipps^^

    Zitat von Ligh

    Dass für alle Auflösungen AVC-Videostreams existieren, ist eine Sache; dass sie nicht ohne zusätzliche Hilfsmittel abrufbar sind, eine andere.


    Sie sind aber so zugreifbar.


    http://abload.de/img/unbenannt187l0afe.png


    Am Beispiel mit 360p. Läuft AVC.
    Auf 240p läuft noch immer AVC.
    usw.


    Falls es vp9 encodes gibt (manchmal macht youtube die ja ebenso je nach lust und laune) spielt er statt h.264 die vp9 encodes ab. Diese haben weniger Bitrate und sehen trotzdem noch besser aus als ihre h.264 encodes. Haben ihren vp9 wohl nicht ganz so mies eingestellt^^

    Zitat

    schon klar.Nur leider zeigt der beim DL nicht die Datengrösse an.


    Er bezog sich auf youtube und da wird die dateigröße auf alle fälle angezeigt.


    Zitat

    Ja...früher hiess es da.MKV käme aus der Schmuddelecke....


    Dann sollen die erstmal ihre eigenen Encoder und einlesbarkeit und einstellungsmöglichkeiten für encoder und wahl des encoders angucken xD die sollten daher lieber mal kleine brötchen backen, bevor sie gutes schlecht machen^^

    Die gibt es sogar alle in H.264.


    144p:


    Code
    1. VideoID : 1Format : AVCFormat/Info : Advanced Video CodecFormat-Profil : Baseline@L1.2Format-Einstellungen für CABAC : NeinFormat-Einstellungen für ReFrames : 1 frameCodec-ID : avc1Codec-ID/Info : Advanced Video CodingDauer : 23minBitrate : 108 KbpsBreite : 230 PixelHöhe : 144 PixelBildseitenverhältnis : 16:10Modus der Bildwiederholungsrate : konstantBildwiederholungsrate : 15,000 FPSColorSpace : YUVChromaSubsampling : 4:2:0BitDepth/String : 8 bitsScantyp : progressivBits/(Pixel*Frame) : 0.218Stream-Größe : 18,1 MiB (30%)


    240p:


    Code
    1. VideoID : 1Format : AVCFormat/Info : Advanced Video CodecFormat-Profil : Main@L1.3Format-Einstellungen für CABAC : JaFormat-Einstellungen für ReFrames : 3 framesCodec-ID : avc1Codec-ID/Info : Advanced Video CodingDauer : 23minBitrate : 243 KbpsBreite : 384 PixelHöhe : 240 PixelBildseitenverhältnis : 16:10Modus der Bildwiederholungsrate : konstantBildwiederholungsrate : 30,000 FPSColorSpace : YUVChromaSubsampling : 4:2:0BitDepth/String : 8 bitsScantyp : progressivBits/(Pixel*Frame) : 0.088Stream-Größe : 40,6 MiB (48%)


    360p:

    Code
    1. VideoID : 1Format : AVCFormat/Info : Advanced Video CodecFormat-Profil : Main@L3.0Format-Einstellungen für CABAC : JaFormat-Einstellungen für ReFrames : 3 framesCodec-ID : avc1Codec-ID/Info : Advanced Video CodingDauer : 23minBitrate : 597 KbpsBreite : 576 PixelHöhe : 360 PixelBildseitenverhältnis : 16:10Modus der Bildwiederholungsrate : konstantBildwiederholungsrate : 30,000 FPSColorSpace : YUVChromaSubsampling : 4:2:0BitDepth/String : 8 bitsScantyp : progressivBits/(Pixel*Frame) : 0.096Stream-Größe : 99,5 MiB (70%)


    480p


    Alles H.264 streams.

    Zitat

    mpc-hc kanns zwar abspielen.......in welchem Schnittprogramm willst Du dies denn bearbeiten ?


    MagicYUV kann eine NLE öffnen. Drache benutzt vegas und sendet via Frameserver an MeGUI.


    Ich persönlich bearbeite rein nur mit avisynth, falls ich denn mal bearbeiten muss. Meist sinds nur Auflösungsskalierungen, weil youtube^^


    Ich persönlich habe eine riesige Abneigung zu NLEs, weil sie in Decode und Encode einfach nur miserabel sind...

    Zitat

    Geduckt im Gras laufen ist der absolute Killer für alte Encoder wie H.263; da ist nix mehr zu erkennen, geschweige denn zu lesen.


    War ja auch Sinn und Zweck des Ganzen. Wir wollten in dem Fall ein massiv komplexes Video für youtube haben.


    Youtube benutzt aber x264 und kein h.263. Wo haste denn her das youtube noch h.263 benutzt? Das machen die höchstens auf 240p oder so, aber alles höhere ist definitiv h.264 video.


    Die Aufnahme ist von mir und liegt in RGB24,1280x720,60fps vor. Aufgenommen wurde mit MagicYUV Codec.