Performance Test Procoder 3

  • Also ich habe jetzt im 209 seitigen englischen ProCoder 3 Handbuch nachgesehen - da steht kein einziges Wort von "Grid Encoding" drin.


    Ich suche weiter nach den Templates.


    Das ist auch aus meiner Sicht "Täuschung der Kunden" mit falschren Argumenten vor dem Kauf.

  • Mein Gott Leute jetzt lasst mich doch nicht so hängen (ich hab das Gerät doch erst ab Samstag) - wer kann mir mal Schrit für Schritt beschreiben wie ich auf diese ominösen Templates komme und woran ich erkennen kann, daß ich die richtigen habe.


    Schliesslich möchte ich auch diese Test noch machen, um beurteilen zu können was es mir bringt.

  • Hi,


    War auch kurz davor mir den Procoder 3 zu bestellen. Aber das habe ich mir nun aus dem Kopf geschlagen. Die Beiträge hier zeigen mir das der PC3 den gleichen Motor hat wie der PC2, und die zusätzlichen Features brauche ich nicht. Die Encodinggeschwindigkeit ist nicht verbessert worden was eigentlich dringend mal notwendig wäre. Scheint aber wohl für die Programmierer schwierig zu sein den PC3 an die neue CPU-Generation anzupassen. Über die vollmundigen Werbeversprechen seitens GV/Canopus sollte auch mal nachgedacht werden.


    bye, Haka


    PS. Gunnar du bist Samstag an der Reihe ;)

  • Hallo,


    auch ich stehe in "Kaufverhandlungen" mit meinem Händler bezüglich des PC3 und habe bis dato abgewartet.


    Bei den vielen Äußerungen hier im Forum...



    ... gehen mir zwei Dinge durch den Kopf:


    1. Gut, dass ich noch nicht zugegriffen habe.


    2. Wie sieht denn der Hersteller selbst die vorgen. Postings? Eine diesbezügliche Stellungnahme seitens Canopus respektive Grass Valley wäre für mich als "Noch-Unentschlossenen" durchaus hilfreich.

  • Zitat

    Original von Canope
    NEU: unterstützt "Grid-"Encoding für MPEG2 (DVD, HDV, usw) Formate und erreicht so bei Mehrkern- und Multiprozessorsysteme eine unglaubliche Renderleistung


    Unglaublich scheint sie doch zu sein. :D


    Hi


    Mich juckt´s ja nicht. Bin mit dem PC2 auf der sicheren Seite und den PC3 können sich gerne andere kaufen ;)
    Aber wenn man´s geanu nimmt ist dieses o.g. Werbeversprechen eine glatte Lüge.


    bye, Haka

  • So, ich habe mich jetzt mal im amerikanischen Forum umgesehen - da wird von Presets gesprochen z.B. "Preview DVD Target" die ich bei mir nicht finde.
    Ausserdem habe ich alle Targets durchgesehen - keiner ist gekennzeichnet als "Grid Encoding".
    Also bevor ich da weiter im Nebel rumstochere mache ich an der Front keinen weiteren Test - es sei denn jemand lüftet den Nebel ein wenig z.B. Canopus.


    Ein weiterer Grund für den ProCoder 3 war für mich das Estellen von MPEG Files für Blue Ray Authoring.
    Ich habe mir die Presets von Jerry aus dem amerikanischem Forum besorgt und installiert und eine neuen Test mit der gleichen Source File(siehe vorne) gestartet.


    Test Blue Ray Mastering:


    Categorie: DVDit Pro HD Blue Ray
    Presets: Blue Ray 1920x1080/50i -MPEG HD
    Target Parameters: MPEG2 Elementary Stream - Frame Rate 23976 - Non Interlaced - 16:9 - Mastering Quality - Closed GOP


    Ergebnis: CPU Auslastung 30% - alle Kerne "a weng beteiligt" Zeit: 24:50

  • Hallo Jürgen


    Hab selber den PC3 noch nicht.
    Was sich aber nicht verstehe
    Settings 50i,also interlaced
    Targed dann wieder -Non Interlaced ?(

    [SIZE=7]Digitalisierungen-Normwandlungen.
    Betamax incl.SuperBeta.
    Secam,Mesecam,NTSC,PAL-M,PAL-N.
    VCR LP,SP,SV ,alle Geräte.
    N8,Hi8,VHS-C,VHS,S-VHS,sämtliche Flagschiffe.
    D8,Mini-DV+grosse Bänder,NTSC LP+SP.
    [/SIZE]

  • Hallo Wendo,


    Du hast natürlich recht - habe ich auch gestutzt.


    Das erste(interlaced) ist der Preset Name (hat warscheinlich Jerry erfunden).
    Das zweite sind die wirklich verwendeten Parameter in diesem Preset.


  • Komm vorbei und schau es dir bis Mittwoch an. Dann geht der PC3 zurück.


    PS: Dafür aber wenigstens Frühschicht.

    PC2: E6600@3GHz, 2x512MB DDR Corsair, ASUS P5B-Deluxe, Powercolor x800GTO, 3x Samsung 250GB SATA, Edius v3.62, Procoder v2.04, Cinergy600, M-Audio Revolution 7.1, WinXP-SP1

  • Ein Wort noch zum Thema "Grid Encoding" des Informatikers in mir.
    Wenn das so funktioniert wie es Shadow Hunter beschrieben hat, dann würde ich meinem Programmierer sagen(wenn ich Entwicklungsmanager bei Canopus wäre) - das ist ein "quick and dirty" Design - was zu ständigen Kosten(bei Anpassung an neue Funktionen) führt. Das richtige Design wäre die "Datenschaufelstelle im Procoder zu suchen und ein parallelisierungs und load balancing Module einzufügen(muss bei neuen Funktionen nicht mehr geändert werden).
    Aber ich weiss dazu muss man mehr nachdenken und diesen Skill hat nicht jeder Programmierer.Aber ich kann mich errinnern, daß der Speed Encoder(der macht es richtig) auch durch den Zukauf von third party skill enstanden ist. Die Firma sass wohl um die Ecke der USA Canopus Niederlassung.

  • Wie weit reicht eigentlich die Datenratenberechnung eines Streams? Geht die weiter als eine GOP ? Wie weit? Weil, wenn ich GOPs habe mit einer definierten Länge z.B. 15, dann kann man die Datenrate auch einhalten, wenn man genau an den GOP-Grenzen schneidet und einzelne GOPs errechnet, um sie anschließend wieder zusammenzufügen.


    Oder wenn die Datenratenberechnung weiter geht, dann kann man einmalig eine Statistische Verteilung errechnen und auf dieser Basis die Parallelisierung und Datenrate festschreiben. Man legt sozusagen ein "Laufendes Fenster" über den Source-Stream. Diese Aufgabe ist teilbar. An den Schnittstellen, wo beide Streams aneinander stoßen berechnet man noch einmal die Schnittmengen (in Fenstergröße). Damit hat man die komplette Verteilung parallelisiert.


    Nun kann man die Berechnung basierend auf der Sourcedatenmenge optimieren. Mathematisch können Koeffizienten gebildet werden, die Aufschluss über die zu erwartende kodierte Datenmenge geben. Was anderes tut die MPEG-Kodierung ja auch nicht als eine Transformation errechnen.


    Wenn man nun einen Multicore-Rechner hat, dann können diese Berechnungen für einen Film übergreifend (in Intervallschachtelung/Rekursion) berechnet werden. Ab 4 Cores macht das dann erst richtig Sinn. Hinzu kommt ein erhöhter Speicheraufwand, der sofern der ProcoderX endlich 64bit-mäßig wäre, kein Problem mehr darstellen würde. Es wird dann weniger auf die Platte geschrieben. Im Hauptspeicher läuft das ganze dann sehr viel schneller (Faktor 100) ab.


    Das ganze macht dann allerdings nur bei der Kodierung eines einzelnen Films mit Multicore-Prozessor Sinn, da bei mehr Filmen die Filme natürlich, wie üblich auf die Cores verteilt werden können.


    Gruß
    Marcus


    P.S.: Leider sind die viele Programmierer keine Mathematiker.

  • Marcus,


    ja, das wäre ein möglicher Weg - es gibt aber bestimmt noch andere.
    Das kann man aber erst beurteilen wenn man den Code vorliegen hat.


    Warum kaufen die den Skill nicht wieder ein - bei den Leuten die den Speed Encoder gemacht haben(kann mich im Moment nicht mehr an den Namen errinnern) ?

  • Vielleicht fragt Canopus mal bei den Entwicklern des CC Encoders nach... da geht Multicore auch bei VBR und mehrfach-VBR, und alles ganz ohne lästiges File-Splitting ;)


    Allerdings hat man da bei Niedrigst-Bitraten nicht die selbe Qualität und der CC SP kostet halt auch fast 2000... Allerdings sollte der Preis ja kein Argument sein wenn man damit wirbt, für vernünftige Multicore-Unterstützung würde ich auch entsprechend mehr bezahlen.



    Ich erinnere mich noch an die Aussagen hier im Forum dass der Carbon Coder einen besseren Multicore-Support hat als der ProCoder 2, nun ist im ProCoder 3 laut Werbeaussage die Carbon Coder Multicoretechnik drin und man merkt keinen Unterschied, was im Umkehrschluss bedeutet dass der 10x teurere Carbon Coder das selbe Problem hat (inkl. fehlender VBR Unterstützung was übrigens beim Multi-CPU splitting in PC2 auch nicht ging) ... irgendwie eine ziemlich dumme Sache.

    • Offizieller Beitrag
    Zitat

    Original von ShadowHunter



    Notfalls direkt an Grass Valley wenden.


    :gruebel: Sind wir doch!

  • Zitat

    Original von Jürgen E
    Marcus,


    ja, das wäre ein möglicher Weg - es gibt aber bestimmt noch andere.
    Das kann man aber erst beurteilen wenn man den Code vorliegen hat.


    Warum kaufen die den Skill nicht wieder ein - bei den Leuten die den Speed Encoder gemacht haben(kann mich im Moment nicht mehr an den Namen errinnern) ?


    Wahrscheinlich, weil in den USA auch Software patentiert werden kann, wenn sie außergewöhnliche Verfahren verwendet. Wenn dann so ein "Patent pending" da dran steht, wartet man lieber erst einmal, ob das Patent erteilt wird oder nicht. Ansonsten kann das furchtbar teuer werden, wenn man unlizensiert Patente nutzt oder gar glaubt das Rad neu erfunden zu haben.


    Und wenn ich eine solche Firma wäre, die das Know-How hat, dann würde ich den Teufel tun und TGV fürn Appel und ein Ei patentfähige Software zu programmieren. Die dürften höchstens in Lizenz die als "Blackbox" programmierte Software nutzen.


    Gruß
    Marcus

  • Zitat

    Aber ich kann mich errinnern, daß der Speed Encoder(der macht es richtig) auch durch den Zukauf von third party skill enstanden ist. Die Firma sass wohl um die Ecke der USA Canopus Niederlassung.


    Um der Legendenbildung ein wenig Einhalt zu gebieten:


    Der ProCoder wurde ursprünglich bei Canopus entwickelt. Aus dem Entwicklerteam ging die eigenständige Firma Rhozet hervor, die eine zeitlang noch im gleichen Gebäude untergebracht war und jetzt an einer anderen Adresse sitzt. Rhozet ist ausgesprochen erfolgreich, die Referenzliste wird laufend beeindruckender:


    http://www.rhozet.com