Resolve 15 Final ist verfügbar

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

  • Resolve 15 Final ist verfügbar

    Resolve 15 Final (Studio und Light) ist verfügbar.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10 Pro/I7-5930K/GTX 780/SSD-RAID/Intel X550 10GbE/BMD 4K Extreme 6G/32 GB RAM/

    Triple Boot:Win10 Pro/I7-6950X/GTX 1080/SSD-RAID/HDD-RAID/BMD 4K Extreme 12G/2 x 10GbE/64 GB RAM

    both on:10Gbps Media sharing Network, 10Gbps NAS
  • So,

    neue Runde, neues Glück - ab heute gibt es Resolve 15.1 als Download.

    Neben weiteren Überarbeitungen und Verbesserungen wird jetzt eben auch das hauseigene Blackmagic RAW unterstützt.

    Gruß
    Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9
  • BM zeigt, wie man einen Codec populär macht und bietet das kostenlose SDK zum Codec an, auf dass ihn implementieren kann, wer will!
    Das Gegenteil von dem, was GV mit seinem Codec jemals anzustellen wusste! Traurig ist, noch immer ist der GV Codec für andere Tools weitesr gehend unbekannt.

    Jim
  • Leider gibt es den RAW Player bisher nur für den Mac.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10 Pro/I7-5930K/GTX 780/SSD-RAID/Intel X550 10GbE/BMD 4K Extreme 6G/32 GB RAM/

    Triple Boot:Win10 Pro/I7-6950X/GTX 1080/SSD-RAID/HDD-RAID/BMD 4K Extreme 12G/2 x 10GbE/64 GB RAM

    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Jim_Pansen schrieb:

    BM zeigt, wie man einen Codec populär macht und bietet das kostenlose SDK zum Codec an, auf dass ihn implementieren kann, wer will!
    Das Gegenteil von dem, was GV mit seinem Codec jemals anzustellen wusste! Traurig ist, noch immer ist der GV Codec für andere Tools weitesr gehend unbekannt.

    Jim
    Korrekt ist: BM versucht einen Codec populär zu machen - ob das gelingt, istjedoch nicht sicher. Wir haben auf der IBC mit allen Kameraherstellerngesprochen, keiner wollte den Codec integrieren. Die meisten haben ja ohnehinschon ihren eigenen Raw Codec. Wobei ohnehin zu diskutieren ist, ob ein auf DCTbasierender Codec überhaupt Raw ist - DCT ist ja so ziemlich das Gegenteil vonRaw. BMD hätte sicher gerne den Apple ProResRaw Codec bekommen - haben sie aberaus politischen Gründen nicht. Das die BMD aber als letzter Kameraherstellereinen eigenen Raw Codec herausbringt war unvermeidlich - Cinema DNG ist totalveraltet und unhandlich und ineffizient und wurde seit langen nicht weiterentwickelt. Dazu unser Interview am BM Stand der IBC 2018:



    Blackmagic hat einen kostenlosen SDK für den Codec veröffentlicht, die Integrationund Support muss aber der NLE Hersteller selbst übernehmen. Ob die aber Lust darauf haben, wegen einemCodec, der bislang eine Kamera unterstützt das Format schnell zu integrierenmuss man abwarten. Adobe ist aktuell nicht gerade ein Fan von BMD. Avid dürfteauch mit SDK dazu nicht in der Lage sein. FCP wird es schlichtweg aus politischenGründen nicht machen. Also ich würde mit dem Urteil etwas abwarten. Und warumman ausgerechnet Grass Valley als Gegenbeispiel anführt ist mir auch nichtklar. Gut, man hat den HQ/HQx Codec, lange der Kern der eigenen Software, nichtvon Anfang an verschenkt. Grass Valley hat das Ziel mit seinen Produkten Geldzu verdienen und seine Mitarbeiter zu bezahlen. BMD ist im Marketing Modus undkämpft für Marktanteile, daher gibt es hier einiges umsonst...

    Grass Valley hat den HQx Codec seit vielen Jahren jedem Anwender als AVI undMXF und MOV Codec zur freien Verwendung für Encoding und Decoding auf Mac undWin zur Verfügung gestellt (Welcher andere Codec macht das eigentlich möglich? In 10bit mit Alpha? Antwort: Es gibt keinen). Praktisch jede Editing Software kann ihn kostenlosnutzen. Zudem haben zahlreiche Partner wie (darunter auch Microsoft für Azureund BMD für Resolve, aber vor allem viele High-End Broadcast Partner) den Codeclizensiert - und dafür bezahlt.

    Wenn man die eigene Technik nur durchsetzen kann, wenn man diese verschenktist der Ansatz sicher korrekt. In Sachen Codecs muss sich Grass Valley aberwirklich nicht verstecken. Kein anderer Hersteller im Markt hat einvergleichbares Codec Knowhow wie Grass Valley und zudem viele eigene Codecs(DV, HQ, HQx, MPEG2, H.264, H.265, ...) während praktisch alle anderen NLEHersteller diese von z.B. MainConcept/Rovi zukaufen und integrieren müssen.Grass Valley hat auch zusammen mit Sony und Panasonic deren Codecs mitentwickeltund Canon stellt auf der IBC eine Kamera vor, deren Material aktuell nur vonEDIUS 9.30 bearbeitet werden kann. Die Messefilme der Kamera wurden alle mitEDIUS bearbeitet. Es handelt sich um die Canon XF705 mit H.265 10bit 422 XF-HEVC,Videoreport unter:



    Zum Vergleich: Wer in der Vergangenheit einmal eine BMD Schnittkarte gekaufthatte konnte in einem ca. 20 Jahre alten M-JPEG Codecs arbeiten oderuncompressed. In Verbindung mit EDIUS können diese Karten dann plötzlich indiversen Codecs, darunter auch nativen Kameraformaten wie XDCamHD, AVC-Intraoder auch MPEG2 für DVD usw. aufnehmen.

    Weitgehend unbekannt ist, dass der MPEG2 Decoder, den Microsoft in einigen seiner Betriebssystemversionen von Grass Valley stammt. Auch hier hat Grass Valley diesen nicht verschenkt. Der Verbreitung von Windows hat das meinen Wissens nicht geschadet.
    Mit freundlichen Grüßen,

    Michael Lehmann-Horn
    magic multi media GmbH
    Grass Valley Distributor

    digitalschnitt.de
  • Das ist mir dann doch ein wenig zu viel Whitewashing und Cheerleading.
    Mit einem Codec allein lässt sich kein Geld verdienen. Allein Apple ist in der Situation, diesen als Zünglein an der Waage für eine Kaufentscheidung für einige FCP sozialisierte Cutter und die, die diesen Codec unbedingt benötigen zu positionieren.

    Als NLE-Hersteller steht man doch vor der Frage, ob man einen eigenen Codec propritär nur für das eigene Universum designt und die Handhabung damit von vornherein limitiert oder damit vielleicht auch Aufmerksamkeit auf die eigene Produktpalette zieht und vielleicht eine Interoperabilität zu anderen Tools fördert. Das hilft den eigene Usern deutlich mehr. Es gab in der Vergangenheit einige Hersteller, die ihre Codecs zur Nutzung frei gegeben haben. BM hat übrigens, wie AJA auch, lange auf den V210 Codec gesetzt. Auf einen alten MJPEG-Codec hatte doch eigentlich nur Matrox gesetzt. Na ich kann mich auch irren.

    Heutzutage werden Codecs von anderen NLEs mit eigenen Libraries häufig nativ gelesen. Das ist auch sinnvoll, denn die VfW- oder DirectShow-Implementationen sind oft nicht konsequent durchgeführt und limitieren manchmal auf 8 Bit Farbtiefe. Diese Schnittstellen verlieren auch langsam ihre Bedeutung, einige Tools setzen darauf gar nicht mehr. So führt z.B. das Laden eines HQ/HQX-Clips in Telestream Switch (x64-Anwendung) zur Fehlermeldung, weil Switch die Codecs nur aus der eigenen Library nativ liest. Während ProRes und DNxHD auf Grund ihrer Popularität natürlich supported werden, bleibe ich mit HQ/HQX im Austausch mit solchen Anwendungen einfach im Regen stehen.
    Die Freeware Implementation (decoding only) in die LibAV- und FFMPEG-Library hat den Usern mehr Flexibilität in der weiteren Verarbeitung gebracht als GVs halbherzige Versuche in der Vergangenheit, Interoperabilität herbei zu führen. Der V210 Codec ist unhandlich, die Dateien zu groß und wie der MXF DNxHD Codec auf bestimmte Auflösungen eingeschränkt. Auf hochkomprimierten Formate für den Austausch zu orientieren, kann ja eigentlich nicht des Rätsels Lösung sein.

    Die GV-Codec-Familie ist sicherlich interessant und qualitativ sehr gut, aber eigentlich nicht mal wirklich komplett. Es gibt keinen 4:4:4:4 Flavour (klar, das spielt in Edius keine Rolle, aber warum eigentlich nicht?) und nicht einmal eine Lossless-Variante die bei 10 Bit Farbtiefe verlustfrei komprimiert, quasi den Canopus Lossless als 10-Bit-Variante ohne große Auflösungseinschränkungen. Wer Lossless exportieren will muss leider mit den utopischen Datenmengen des V210 oder dem unkomprimierterten Standard-Codec umgehen.

    Die Eigenentwicklungen GVs von Standardcodecs mögen für einige Szenarien zweckmäßig sein. Aber sie sind auf Grund fehlender 2-pass Modi nur bedingt hilfreich. Ein 2-pass Modus ist einfach State-Of-The-Art und unerlässlich, wenn man mit Bitrate wirtschaftlich und genau gewichtet umgehen muss. Da wünschte ich manchmal, man hätte einfach auf externes Know how gesetzt. Die Entfernung des Procoder-Supports für den Export war damals ziemlich tragisch, weil es keinen adäquaten Ersatz gab. Der Export qualitativ hochwertiger MPEG2-Dateien war danach bei mittlerer Bitrate im 1-pass Modus im Grunde kaum mehr möglich. So sieht es auch beim MP4-Export aus. Es gibt ja gottseidank noch den Quicktime-Exporter, der zwar grottenlangsam ist, aber wenigsten sehr gute Qualität liefert. Ich liefere Electronic Press Kits als H264-QuicktTime mit eingebetteten PCM-Ton an TV-Sender aus. Das kann der Edius-interne Exporter gar nicht abbilden, weil nicht konsequent zuende gedacht wurde, die korrespondierenden Möglichkeiten mit abzudecken. Wenn die QuickTime-Schnittstelle irgendwann mal abgekoppelt wird, stehe ich mit Edius auf jeden Fall im Regen. Bei EPKs ist die einfache Handhabung des Clipmaterials einfach sehr wichtig, weil nicht nur technische Profis damit hantieren müssen.

    Dass andere Kamerahersteller den BM-Codec implementieren ist ausgesprochen unwahrscheinlich und auch egal. BM hat den richtigen Ansatz. Wenn man Kameras verkauft, die weit verbreitet sind, sorgt man mit dem freien SDK für den Support des eigenen Codecs in Fremdanwendungen und damit für ein funktionierendes Ecosystem. Man kann den Begriff 'Kamera' auch mit 'NLE' ersetzen und man begreift, dass ein gutes Ecosystem, das konsistent ist und Referenzen schafft wichtig für den Erfolg des eigenen Primärproduktes ist.
    Ich habe BM für diese Taktik gelobt, weil ich bei GV eigentlich viel Schnarchigkeit, Halbherzigkeit und Inkonsequenz auf diesem Gebiet erlebt habe.
    Meine Meinung!

    Jim

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Jim_Pansen ()

  • Hallo Jim,

    Danke für die Meinungsäußerung ich muss aber ein paar Dinge doch klarstellen.

    Jim_Pansen schrieb:

    Mit einem Codec allein lässt sich kein Geld verdienen.
    Nunja Grass Valley hat damit schon schöne Summer verdient. Weil man diese Technologien eben auch selbst hat, siehe mein obiges Posting.

    Jim_Pansen schrieb:

    Als NLE-Hersteller steht man doch vor der Frage, ob man einen eigenen Codec propritär nur für das eigene Universum designt und die Handhabung damit von vornherein limitiert oder damit vielleicht auch Aufmerksamkeit auf die eigene Produktpalette zieht und vielleicht eine Interoperabilität zu anderen Tools fördert. Das hilft den eigene Usern deutlich mehr. Es gab in der Vergangenheit einige Hersteller, die ihre Codecs zur Nutzung frei gegeben haben.
    EDIUS ist auch heute noch das Schnittprogramm mit der breitesten Codecunterstützung am Markt. Der HQx Codec hat bei einer schnellen Verarbeitung praktisch aller aktuellen Videoformate sicher nicht die größte Relevanz, andere Programme können oder konnten verschiedenste codecs nur konvertiert lesen. Grass Valley musste nicht den Markt missionieren, um kompatibel zu sein, es war bereits kompatibel. Nochmals: welches andere Schnittoprogramm kann denn direkt direkt in Kameraformaten aufzeichnen? Welches erlaubt die Ausgabe so, dass die Kameras denken, es wäre natives Material (AVCHD, XAVC, XDCam, AVC Ultra, usw.)

    Jim_Pansen schrieb:

    BM hat übrigens, wie AJA auch, lange auf den V210 Codec gesetzt. Auf einen alten MJPEG-Codec hatte doch eigentlich nur Matrox gesetzt. Na ich kann mich auch irren.
    Ja, Du irrst Dich. Der einzige eigene Codec von BMD war lange Zeit M-JPEG.

    Jim_Pansen schrieb:

    Heutzutage werden Codecs von anderen NLEs mit eigenen Libraries häufig nativ gelesen. Das ist auch sinnvoll, denn die VfW- oder DirectShow-Implementationen sind oft nicht konsequent durchgeführt und limitieren manchmal auf 8 Bit Farbtiefe. Diese Schnittstellen verlieren auch langsam ihre Bedeutung, einige Tools setzen darauf gar nicht mehr. So führt z.B. das Laden eines HQ/HQX-Clips in Telestream Switch (x64-Anwendung) zur Fehlermeldung, weil Switch die Codecs nur aus der eigenen Library nativ liest. Während ProRes und DNxHD auf Grund ihrer Popularität natürlich supported werden, bleibe ich mit HQ/HQX im Austausch mit solchen Anwendungen einfach im Regen stehen.
    Ok, telestream hat hier keine ordentliche Integration einer Standardschnittstelle gemacht - und das ist nun Grass Valley Fehler? Vielleicht einmal auf Telestream schimpfen, wenn die die Basics nicht machen? Die integration dieser Standard Komponenten in Windows ist absolut unkompliziert. Offenbar hat das ein Mac Programmierer die Windows Version gleich mit geschrieben...

    Jim_Pansen schrieb:


    Die GV-Codec-Familie ist sicherlich interessant und qualitativ sehr gut, aber eigentlich nicht mal wirklich komplett. Es gibt keinen 4:4:4:4 Flavour (klar, das spielt in Edius keine Rolle, aber warum eigentlich nicht?) und nicht einmal eine Lossless-Variante die bei 10 Bit Farbtiefe verlustfrei komprimiert, quasi den Canopus Lossless als 10-Bit-Variante ohne große Auflösungseinschränkungen. Wer Lossless exportieren will muss leider mit den utopischen Datenmengen des V210 oder dem unkomprimierterten Standard-Codec umgehen.
    Das verstehe ich nicht, man kann doch einfach im Grass Valley Lossless codec in 10bit exportieren? Der Unterstützt auch Alpha. Klar, er ist 4:2:2:4 - aber EDIUS ist das ja auch. Und für einen Videoeditor ist das meiner Meinung nach auch das beste und schnellste Format. Wer zeichnet denn 4:4:4:4 auf? Für Sonderanwendungen macht das sinn, aber will ich deshalb die Performance einschränken? Die YUV Optimierung von EDIUS kommt praktisch allen typischen Videokameraformaten zugute.


    Jim_Pansen schrieb:

    Die Eigenentwicklungen GVs von Standardcodecs mögen für einige Szenarien zweckmäßig sein. Aber sie sind auf Grund fehlender 2-pass Modi nur bedingt hilfreich. Ein 2-pass Modus ist einfach State-Of-The-Art und unerlässlich, wenn man mit Bitrate wirtschaftlich und genau gewichtet umgehen muss. Da wünschte ich manchmal, man hätte einfach auf externes Know how gesetzt. Die Entfernung des Procoder-Supports für den Export war damals ziemlich tragisch, weil es keinen adäquaten Ersatz gab. Der Export qualitativ hochwertiger MPEG2-Dateien war danach bei mittlerer Bitrate im 1-pass Modus im Grunde kaum mehr möglich. So sieht es auch beim MP4-Export aus.
    Ich wundere mich sehr über diese Aussage. Die Software Encoding Qualität wurde mit jeder EDIUS Version besser, gerade in EDIUS 9 sind sowhl MPEG2 als auch H.264 Encoder gerade wieder deutlich leistungsfähiger (besser und schneller) geworden, mit nahezu perfekter Multicore Auslastung. Noch nicht getestet? Es klingt für mich wie eine Kritik, die schon ein paar Jahre alt ist. EDIUS 9 hat hier absolut geliefert.

    Jim_Pansen schrieb:


    Es gibt ja gottseidank noch den Quicktime-Exporter, der zwar grottenlangsam ist, aber wenigsten sehr gute Qualität liefert. Ich liefere Electronic Press Kits als H264-QuicktTime mit eingebetteten PCM-Ton an TV-Sender aus. Das kann der Edius-interne Exporter gar nicht abbilden, weil nicht konsequent zuende gedacht wurde, die korrespondierenden Möglichkeiten mit abzudecken. Wenn die QuickTime-Schnittstelle irgendwann mal abgekoppelt wird, stehe ich mit Edius auf jeden Fall im Regen.
    Es ist mir neu, dass PCM in einem MP4 vorteile bieten soll. Damit wird doch die Datei nur wieder unnötig größer. Weiter oben wird die effiziente Kompression gelobt, aber es soll PCM im MP4 sein? Im Quitcktime Exporter ist das ein Relikt. Es wäre mit auch neu, dass es ein etablierter Standard ist, in eine MP4 Datei PCM Audio zu packen. Das ist ja wie ein Sportauto mit Anhänger. Wenn es ein zertifiziertes oder zumindest relevantes Format wäre, würde Grass Valley es sofort unterstützen, ich denke aber die sehen eher das Problem, dass so ein unübliches Format, wenn es integriert wird, von Anwendern eingesetzt wird und somit die Effizienz der MP4 zerstört.

    Jim_Pansen schrieb:


    Dass andere Kamerahersteller den BM-Codec implementieren ist ausgesprochen unwahrscheinlich und auch egal. BM hat den richtigen Ansatz. Wenn man Kameras verkauft, die weit verbreitet sind, sorgt man mit dem freien SDK für den Support des eigenen Codecs in Fremdanwendungen und damit für ein funktionierendes Ecosystem. Man kann den Begriff 'Kamera' auch mit 'NLE' ersetzen und man begreift, dass ein gutes Ecosystem, das konsistent ist und Referenzen schafft wichtig für den Erfolg des eigenen Primärproduktes ist.
    Ich habe BM für diese Taktik gelobt, weil ich bei GV eigentlich viel Schnarchigkeit, Halbherzigkeit und Inkonsequenz auf diesem Gebiet erlebt habe.
    Meine Meinung!
    Eine Meinung die ich akzeptiere, aber ich wundere mich schon über den Ton mit dem hier über das codec Knowhow von Grass Valley gesprochen wird und man ausgerechnet BMD als Gegenbeispiel nimmt, die in diesem Umfeld noch nichts geleistet haben (wenn man den veralteten M-JPEG codec mal außen vorlässt). Auch würde ich mich freuen, wenn man nicht allgemein schreibt, was alles schlecht ist, ohne vielleicht die Fakten geprüft zu haben... EDIUS 9 hat ja gerade in der Version 9.30 wieder zahlreiche Formaterweiterungen erhalten, darin auch für MP4 (Audio und Streaming), XF-HEVC H.265 Decoding (als erstes und einziges NLE am Markt) sowie im MXF XAVC, AVC Ultra und XDCam Bereich...

    Meine Meinung.
    Mit freundlichen Grüßen,

    Michael Lehmann-Horn
    magic multi media GmbH
    Grass Valley Distributor

    digitalschnitt.de