HEVC + ProRes + XAVC-L Vegas Plug In

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich versuche weiterhin die 10 Bit Farbauflösung zu implementieren. Die 4:2:2 sind ja kein Problem und die werden auch mit den 24 Bit RGB BitMaps übergeben. Bei der 10 Bit Unterstützung muß zwangsläufig auf YUV FrameFormat gegangen werden.Da nur bei den XAVC-L Files aus der X70 eindeutig 10Bit aus den Media-Informationen hervor gehen, nutze ich im Moment ausschließlich diese als Input für meine Entwicklung.

      XAVC-L_VideoInfo.png ProRes_VideoInfo.png

      Bei den ProRes scheint mir das nicht so ganz eindeutig, wie hier zu sehen ist.

      Nun noch mal zu der vom LAV Decoder erstellten Buffer Größe bei FHD. Bei RGB ist das ganz klar und auch richtig. Da muß der Buffer 3 * 1920 x 1080 groß sein und das ist auch der Fall. Bei UYVY, ein 8Bit 4:2:2 Format mit 16 Bit pro Pixel ist der Buffer auch 2 * 1920 *1080 groß.

      Bei 10 Bit bietet der LAV Decoder P210 oder v210. Dabei nutzt P210 32 BitproPixel und der Decoder kommt mit einem 8294400 Byte Buffer. Das ist 4 * 1920 *1080 und somit wie erwartet. Bei v210 nun ist der Buffer nur 5529600 Bytes groß obwohl 24 Bit pro Pixel genutzt werden also 3 * 1920 x1080 = 6220800. Somit liegt ganz offenbar in diesem Mode ein Fehler im LAV Decoder vor. Leider scheint auch der 10Bit P210 Mode noch nicht richtig im LAV Decoder implementiert zu sein, zumindest ist es mir da noch nicht gelungen die passenden Pitch Werte zu setzen. Ich werde mich noch ein wenig damit beschäftigen, glaube aber, daß der 10 Bit Pfad im LAV Decoder noch nicht ganz sauber unterstützt wird.
      LG
      Peter
    • elCutty schrieb:

      Da nur bei den XAVC-L Files aus der X70 eindeutig 10Bit aus den Media-Informationen hervor gehen, nutze ich im Moment ausschließlich diese als Input für meine Entwicklung.

      Bei den ProRes scheint mir das nicht so ganz eindeutig, wie hier zu sehen ist.


      Bei ProRes ist es so, dass es gar kein ProRes Material aus dem Shogun gibt welches nicht 10bit hat. Ich glaube nicht einmal dass es ProRes mit nur 8bit gibt (aber da müßte man im white paper nachsehen).

      Was Media Infor gerade im Zusammenhang mit ProRes und unter Windows anzeigt ist ziemlich irrelevant bis falsch - und hängt wohl eher mit der miesen Implmentierung von ProRes in die Windows-Umgebung zusammen. Du kannst also davon ausgehen dass die verfügbaren ProRes Muster aus dem Shogun definitiv echtes 10bit Material sind.

      Freilich, was der LAV Decoder damit macht weiß ich gegenwärtig nicht.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Eigentlich haben die Renderer/Player meist keine andere Wahl, als den MediaInformationen aus den Headern zu vertrauen und das Material entsprechend zu verarbeiten. Davon unbenommen, habe ich bisher noch keinen DirectX Renderer, der nimmt die Frames zum Abspielen und Darstellen entgegen, der mit 10 Bit Frames umgehen kann finden können. Das macht die Prüfung des LAV Decoders für mich etwas schwierig.

      Ich werde mir mal ansehen, was da in den Buffern liegt. Bei P210 müsste dann in den 16Bit Worten auch im Y-Bereich mal ein Wert mit >8 Bit auftauchen.
      LG
      Peter
    • Dass es auch anders geht zeigt Edius. Das erkennt das ProRes Material sehr wohl als 10bit. Dafür wird dort stur Cineform als 8bit erkannt.

      Frag mich aber nicht wie die das machen.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Diese ganze 10Bit Geschichte ist noch recht unreif, noch unreifer als UHD im Allgemeinen. Um einen Nutzen aus solchen 10Bit Files ziehen zu können, muß man Vp13 im 32 Bit Floating Point Mode betreiben und das kostet extreme Rechenzeit. So komme ich auf meinem System mit UHDp25 Material aus der AX100E nur noch auf 0,7 bis 0,9 fps in der Vorschau. Das ist noch deutlich weniger als derzeit mit meinem PlugIn (0.2.5) und einer 8Bit Vegas Einstellung. ;)

      Ich werde mich heute noch etwas mit der 10 Bit Unterstützung beschäftigen, mich dann aber auf die integrierte Video-Proxy-Lösung konzentrieren.
      LG
      Peter
    • elCutty schrieb:

      Ich werde mir mal ansehen, was da in den Buffern liegt. Bei P210 müsste dann in den 16Bit Worten auch im Y-Bereich mal ein Wert mit >8 Bit auftauchen.


      Gesagt - getan. Hier mal die Bufferinhalte, die anders als bei BitMaps in umgekehrter Zeilenreihenfolge geliefert werden und umgedreht werden müssen. So zeigen meine Bilder des Frames 0 aus dem ProRes SLT Video hier jeweils den Anfang des Buffers in 16Bit Worten, wie es die Spec beschreibt.

      ProRes_SLT_P210_inBuffer.png ProRes_SLT_P210_inBuffer_Reversed.png ProRes_SLT_Frame0_HD.jpg

      Es sind also nicht nur 10Bit sondern volle 16Bit Werte in der Übergabe. Dabei besteht die erste Hälfte des aus jeweils einem 16Bit Wort für den Wert der Luminanz jedes Pixels und daran anschließend liegen je ein U und V 16 Bit Wort für jedes zweite Pixel.

      Ich bin mir da nun nicht sicher, ob Vegas da eigentlich nur Werte im Bereich von 0 bis 0x400 (1024) erwartet, wie in P210 als 'Planar, 4:2:2, 10Bit' angegeben und hier aber 16 Bit übergeben werden.
      LG
      Peter
    • elCutty schrieb:

      Diese ganze 10Bit Geschichte ist noch recht unreif, noch unreifer als UHD im Allgemeinen. Um einen Nutzen aus solchen 10Bit Files ziehen zu können, muß man Vp13 im 32 Bit Floating Point Mode betreiben und das kostet extreme Rechenzeit. So komme ich auf meinem System mit UHDp25 Material aus der AX100E nur noch auf 0,7 bis 0,9 fps in der Vorschau.


      Ja beim Abspielen des 32bit floating point modus hat Vegas seine Vorschauprobleme. Cineform ist hier deutlich performater als dein AX100 Material, weil halt doch vermutlich als i-frame only Material leichter dekodierbar. Aber der Einbruch in der Vorschau ist in Vegas ein bekanntes Problem.

      Entwickelt ist der Modus tatsächlich nicht gut - ich schneide auf meiner alten Maschine daher im 8bit Modus, und schalter erst für das finale Rendern auf 32bit um. Und wehe man vergißt dabei den CUDA-Support für die Vorschau abzustellen - dann hat man Abschnitte im Material die nur noch schwarz sind. Hier hat Vegas Grenzen. Im Vergleich dazu ist der 10bit Modus in Edius zwar weniger genau in der Rechenpräzission, aber deutlich performater bei der Vorschau und beim Rendern.


      elCutty schrieb:

      Es sind also nicht nur 10Bit sondern volle 16Bit Werte in der Übergabe.


      Finde ich eigentlich logisch, den der 32bit Modus ist ja nicht nur für 10bit ausgelegt sondern soll alles abdecken.

      elCutty schrieb:

      Ich bin mir da nun nicht sicher, ob Vegas da eigentlich nur Werte im Bereich von 0 bis 0x400 (1024) erwartet, wie in P210 als 'Planar, 4:2:2, 10Bit' angegeben und hier aber 16 Bit übergeben werden.


      Das kann ich dir auch nicht beantworten.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • wolfgang schrieb:

      Finde ich eigentlich logisch, den der 32bit Modus ist ja nicht nur für 10bit ausgelegt sondern soll alles abdecken.

      Der Vegas 32 Bit Mode ist ein Floating Point Mode. Hier handelt es sich aber um Integer Werte und die haben zunächst nichts mit Vegas oder einem anderen NLE zu tun.

      Um in der 10Bit Problematik weiter zu kommen, bin ich nun zurück gegangen auf ein 8Bit 4:2:2 Frameformat : 'UYVY'. Hier werden die YUV Werte für zwei aufeinander folgende Pixel in 4 Bytes U0,Y0,V0,Y1 gespeichert. Es ist also ein Format mit 16 Bit/pixel. Dieses Format wird vom LAV Decoder sauber ausgegeben und nach einigen Anpassungen auch über mein PlugIn in Vp13 ausgegeben:

      HEVC_PlugIn_XAVC-L_UYVY_8Bit_422.png

      Man beachte auch die Angabe unter dem grünen Pfeil. Bei der letzten Version mit RGB Übergabe steht an dieser Stelle 24, wie es für 3*8 auch richtig ist.

      Um nun zu Prüfen, ob da zwischen der RGB- und UYVY- Übergabe ein Unterschied besteht, habe ich jeweils den ersten Frame eines X70 XAVC-L Clips aus Vp13 über das Clipboard an PhotoShop übergeben :

      XAVC-L_RGB_Frame0.jpg XAVC-L_UYVY_Frame0.jpg

      und mit der Ebenen-Funktion EbenenDifferenz.jpg die Differenz gebildet. Das Ergebnis ist ein schwarzer Frame, da also keine Differenzen enthalten sind.

      Morgen schaue ich mir noch einmal das P210 Format an.
      LG
      Peter
    • elCutty schrieb:

      Bei v210 nun ist der Buffer nur 5529600 Bytes groß obwohl 24 Bit pro Pixel genutzt werden also 3 * 1920 x1080 = 6220800. Somit liegt ganz offenbar in diesem Mode ein Fehler im LAV Decoder vor.

      Da bin ich offenbar von einer falschen Voraussetzung ausgegangen. Da bei v210 die 10Bit Werte für 6 Pixel in 4*4 Bytes gespeichert werden, kann die BitCount-Angabe von 24 nicht zur Berechnung der Buffergröße genutzt werden. Die vom LAV Decoder 0.65 bei v210 übergebene Buffergröße ist also korrekt.
      LG
      Peter
    • So, nun habe ich endlich auch die so begehrte 10 Bit 4:2:2 Unterstützung implementiert.

      HEVC_PlugIn_XAVC-L_v210_10Bit_422.jpg

      In der Vegas Anzeige wird da zwar, wie bei der ersten auf RGB-Buffer basierenden Version, für das FHD Video aus der X70 '1920x1080x24' angezeigt. In der aktuellen Version 0.2.7 werden die Daten aber in einem gepackten YUV 'v210' Format übergeben, das jeweils 10Bit Werte für die drei Komponenten nutzt. Ich habe mir die Werte in den Buffern angesehen und das überprüft. Da ich als Zwischenschritt eine YUV Version mit dem 8Bit 4:2:2 Format 'UYVY' erstellt hatte, lagen mir die 8 Bit YUV Werte zum Verglich vor.

      Mich würde nun brennend interessieren, ob diese 10 Bit unter Vegas im 32 Bit Mode auch 'spürbar' sind.
      LG
      Peter
    • Das ist was für dieses (vermutlich verregnte) Wochenende... danke schon mal.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • If the File type is unknown you must leave Vegas and rename or delete the file
      “FFCache_x64_1033.ini” at “C:\Users\{username}\AppData\Local\Sony\Vegas Pro\13.0” to
      force Vegas to make a rescan to find the new -config file.


      @Peter, bei mir wird zwar die “FFCache_x64_1033.ini” neu geschrieben mit dem Eintrag
      [HEVC_FileIOPlugin]
      Path=C:\VegasPlugIns\HEVC_FileIOPlugin.dll
      und trotzdem funktioniert es nach erneutem Sart von Vegas nicht.
    • Ich habe es gerade noch einmal auf meinem System, auf dem das Plug In zunächst auch nicht erkannt wurde probiert. Hier habe ich die FFF.....ini nur in .ini.sav umbenannt und dein Handbrake Vegas Clip geladen.

      Kann es sein, daß ein anderes FIO_Plugin mit einem höheren Merit bei dir installiert ist bzw. hast du in dem Vegas pro 13 Ordner noch andere *.fio2007-config Files?
      LG
      Peter
    • Was für Files hast du denn benutzt? Hast du mal ein HEVC aus der NX1 probiert?


      ja, dieses "yvid_SAM_0231-HQQuality.MP4"!

      hast du in dem Vegas pro 13 Ordner noch andere *.fio2007-config Files?


      Nein!
    • Ich habe bewußt ein recht hohes Merit (0x8001) in die Config-Datei geschrieben. Gibt es in deiner .ini noch ein Plug In mit einem höheren Merit?

      Sonst habe ich zunächst mal keine weitere Idee. Vielleicht probierst du es bitte noch mal auf einem anderen System.
      LG
      Peter
    • Hallo Günter,

      wuff schrieb:

      hast du in dem Vegas pro 13 Ordner noch andere *.fio2007-config Files?

      Nein!


      hast du auf dem System nicht auch den FrameServer installiert? Der müßte dann da eigentlich auch auftauchen. Falls er drauf ist und kein *.fio2007-config File zu sehen ist, deinstalliere ihn doch bitte mal temporär.
      LG
      Peter
    • Hallo Peter,

      verstehe ich das richtig, daß Deine Arbeit auch das zum Rendern nach UHD/HEVC 24-60p möglich macht ?

      (In Deiner Ausgangsbeschreibung heißt es ja lediglich "um Vegas pro 13 den direkten Import von HEVC/H.265 Videos zu ermöglichen")