Infoseite // Guter 4K Lossless Codec - "Magic YUV"

Frage von MLJ:


@All
Hier eine echte alternative zu anderen Lossless Codecs:

http://magicyuv.com/

"MagicYUV" ist kostenlos und stabil, hat mich sehr überrascht und für alle Windows Systeme verfügbar.

Andere Lossless Codecs:
ArithYUV Codec
Fast Codec
MLC Codec
YUVSoft Codec
MSU Codec (Sehr langsam)
ASL Codec

Meine eindeutigen Favoriten:
HuffYUV (Schnellster Codec, Echtzeit)
MagicYUV (Gute Performance, Echtzeit)
Lagarith (Langsam bei HD)
UtVideo (Manche NLE's zicken mit diesem Codec)

Anmerkung:
Manche NLE's verwenden ffmpeg und ffdshow als Engine, da hat HuffYUV die Nase vorne weil der Quell-Code von HuffYuV dort verwendet wurde. Andere Lossless Codecs basieren ebenfalls auf diesem Quell-Code aber mit HuffYUV konnte bisher jedes Windows NLE umgehen, was bei den anderen Codecs nicht immer funktioniert.

Cheers, Mickey



Antwort von hub19:

UtVideo (Manche NLE's zicken mit diesem Codec)Welche dir bekannten NLE haben Mühe mit UtVideo?



Antwort von MLJ:

@Roman Schön
"VideoPad" von NCH Software z.B. sowie viele Programme die mit "Intelli-Rendering" oder "Smart Rendering" arbeiten. Die "verschlucken" sich wenn man ein UtVideo Codec Video läd, etwas bearbeitet um es dann mit dem gleichen Codec wieder rauszugeben. "AviSynth" erkennt YUY2 Codierte Videos mit UtVideo nicht und wandelt es in RGB24 um.

Mit "VideoPad" entsteht ein Video mit 1 KiloByte größe wenn man den UtVideo Codec für die Ausgabe nimmt und das laden eines Videos mit UtVideo dauert ewig in VideoPad. In anderen Programmen mit Intelli/Smart Rendering ist die Vorschau in doppelter Geschwindigkeit und oft, nicht immer, asynchron mit dem enthaltenen Audio, egal bei welcher Samplerate.

"HuffYUV" ist z.B. in AviSynth, VirtualDub, ffmpeg und ffdshow integriert worden und HuffYUV Codierte Videos machen null Probleme. Echtzeit, Interlaced oder Progressiv, bis 16384x16384 (Workstation) und 8192x8192 bei PC's.

Getestet von XP (32 Bit) bis Win7 (64 Bit). Hat dir das weiter geholfen oder deine Frage beantwortet ? ;)

Cheers, Mickey.



Antwort von hub19:

Ja. vielen Dank für deine Auskunft!



Antwort von MLJ:

@Roman Schön
Keine Ursache :) Übrigens habe ich auch die Ursache gefunden, warum der UtVideo Codec in der Vorschau alles doppelt so schnell abspielt über Intelli/Smart Rendering: Im gegensatz zu HuffYUV verarbeitet der UtVideo Codec Interlaced nicht so gut wie es den Anschein hat. UtVideo spielt sie im Player richtig ab, aber gibt einen falschen Header an die Programme zurück wegen der Feldanordnung (Top/Bottom Field) und die gehen dann von einem 50 Fps PAL File aus obwohl es nur 25 Fps sind, genauso bei NTSC, 59.94 Fps statt 29.970.

Leider habe ich noch keine Möglichkeit gefunden den Autor von UtVideo zu kontaktieren, denn dieses Problem existiert seit längerem.

Cheers, Mickey.



Antwort von hub19:

Hallo Mickey

Das ist eine interessante Beobachtung. Mir ist ja auch aufgefallen, dass MAGIX Video Pro X die Art der Bildverarbeitung nicht erkennt und sie demnach auch nicht automatisch einstellt. So muss ich jeweils in den Objekteinstellungen definieren, ob es sich um TFF oder progressives Video handelt (BFF habe ich bisher noch nie verwendet).

Auf diese Weise konnte ich UtVideo-Clips allerdings immer problemlos verarbeiten (was ja logisch ist).

Gruss
Roman



Antwort von MLJ:

Hallo Roman
Wenn man die UtVideos manuell lädt, so wie du es eben beschrieben hast, dann funktioniert der Codec ja auch, nur eben nicht mehr richtig beim Ausgeben wenn Intelli/Smart Rendering genutzt wird, UtVideo ist ein guter Codec, hat aber noch kleine Macken und funktioniert sehr gut bei Progressiven Material, nur Interlaced ist nicht so gut.

HD Videos, egal ob PAL oder NTSC haben alle (!) TFF (Top Field first) was bei SD Videos anders ist, da geht es hin und her. Aber da gibt es auch Ausnahmen da manche Capture Karten/Sticks statt TFF auf BFF eingestellt sind, was aber sehr selten ist.

Cheers, Mickey.



Antwort von Spreeni:

@MLJ
Danke für die Info, der Codec ist ganz vielversprechend. Ich habe ihn mal unter After Effects (5.5) getestet und mit Lagarith verglichen. Beim Codieren sind die beiden gleich schnell, beim Decodieren ist MagicYUV schneller.

Leider war ist es z.Zt. scheinbar nicht möglich, Filme mit Alphakanal auszugeben. Zwar gibt es die RGBA Option bei MagicYUV, mein After Effects möchte aber mit diesem Codec keine RGB+Alphakanal erzeugen (Option erscheint nur ausgegraut). Hier mal ein Screenshot:

http://www.mir-studios.de/magicyuv.jpg

Ist Lagarith als Codec ausgewählt kann ich die Option auswählen. Liegt das an MagicYUV oder an meiner angestaubten After Effects Version?



Antwort von MLJ:

@Spreeni
Das hat mit deiner "verstaubten" After Effects Version nichts zu tun, das liegt scheinbar an MagicYUV denn ich hatte in verschiedenen Programmen das gleiche Problem, kein Alpha, nur nicht immer. Meine letzte Info vom Autor ist das er nach einer Lösung tüftelt. Du hast doch die letzte Version von "MagicYUV", oder ? Normalerweise unterstützt MagicYUV RGB32, also Alpha Channel. Hast du es mal mit einem anderen Programm probiert ?

Scheinbar liegt das aber daran, das nicht alle Programme wirklich mit Alpha arbeiten, nur eine Vermutung von mir.

Was du, zum vergewissern, probieren kannst:VirtualDub. Lade einfach ein kleines/kurzes Video in VirtualDub, dann unter "Video - Color Depth" einfach "RGB32 with Dummy Alpha Channel" als Ausgabe Format (Output to Codec) einstellen und MagicYUV als Codec wählen. Dann auf "Save AVI" gehen. Wenn VirtualDub jetzt meckert, dann liegt es definitiv am MagicYUV Codec.

Weitere Möglichkeit: Erstelle ein Testvideo mit VirtualDub. Das findest du unter "Tools", dort einfach "Levels" auswählen, KEINE Filter laden (!) und MagicYUV als Codec nehmen. VirtualDub erzeugt ein kurzes Testvideo im NTSC Format (640x480 @ 29.970 Fps) mit Alpha (32 Bit). Unter "Video - Color Depth" wählst du für Links und Rechts die oberste Option an. Dann "Save Video", fertig, sind 1000 Frames, also nichts riesiges und trotzdem ein guter Test um Unterschiede zwischen den einzelen Codecs zu prüfen.

Hier ist die Übersicht der Formate die MagicYUV unterstützt:
http://magicyuv.com/index.php/features

Ich hoffe das hat dir weiter geholfen ;)

Cheers, Mickey.






Antwort von TheBubble:

Normalerweise unterstützt MagicYUV RGB32, also Alpha Channel. Hast du es mal mit einem anderen Programm probiert ? 32 Bit pro RGB-Pixel bedeuten nicht unbedingt, dass ein Alpha-Channel vorhanden ist oder unterstützt wird. Häufig sind 8 Bit einfach ungenutzt, damit jedes Pixel an einer 4-Byte-Grenze beginnen kann. Manche Filter können in einem Alpha-Kanal eventuell vorhandene Werte auch nicht verarbeiten.

Noch eine Anmerkung: Man sollte auch immer darauf achten, ob man "pre multiplied alpha" oder nicht benötigt.



Antwort von Spreeni:

Hallo Mickey,

danke für die Tipps, ich werde mal bei Gelegenheit mit VDub testen, ob das Problem wirklich am Codec liegt. Laut Specs sollte ja RGBA funktionieren, nur kriegt AfterFX das nicht mit. Sieht mir nach einem typischen 1.0-Bug aus.



Antwort von Ignus:

Hi!

Sorry for replying in English, but my German is read-only.

I am the developer of the MagicYUV codec and I noticed you had some problems with RGBA. RGBA was never fully tested and as such it is possible that it might not work correctly.
After reading about RGBA support for Adobe products, I think I know what the problem might be, I just need to test it in After Effects. I hope to get it corrected in the next release.

-- In german by Google:

Es tut mir leid für die Beantwortung in Englisch, aber mein Deutsch ist schreibgeschützt.

Ich bin der Entwickler des MagicYUV Codec und ich bemerkt, dass Sie einige Probleme mit RGBA hatte. RGBA wurde nie vollständig getestet und als solches ist es möglich, dass es nicht korrekt funktionieren könnten.
Nach der Lektüre über RGBA-Unterstützung für Adobe-Produkte, ich glaube, ich weiß, was das Problem sein könnte, ich muss nur um es zu testen in After Effects. Ich hoffe, dass es in der nächsten Version korrigiert zu werden.

Greets,
I.



Antwort von MLJ:

@Ignus
first, welcome to SlashCam :) Second: Very good Codec, fast, stable and guess what, it even runs with Windows 2K Pro (SP4) in Realtime. In my "Hitlist" MagiYUV ranks on second Place.

My Hitlist:
1. HuffYUV (The "Original" 2.1.1 CCESP 0.2.5 Patch)
2. MagicYUV
3. Lagarith
4. UtVideo (Only because it handles Interlaced not well)

The other Lossless Codecs that are out there can not compete with the 4 in my List.

FYI: The HuffYUV Codec in ffdshow with YV12 is much slower than the Original stand alone Version. The original HuffYUV is way faster and clearer in the Picture when it comes to Interlaced Material.

MagicYUV compaired to HuffYUV is only a very small difference when it comes to Performance and compression. The CPU Load with HuffYUV is between 12 to 28 percent while MagicYUV is only a bit higher at 17 to 32 percent.

So keep it up, great Codec and let us know if there are any News or Updates available.

Cheers, Mickey.

P.S.: Don't worry too much about "English", that should be no Problem ;)



Antwort von Ignus:

Hi!

Thanks! I hope to get RGBA sorted out soon.

BTW, HuffYUV being faster is odd.
Can you tell me where can I download the HuffYUV version you mentioned? I tried the original HuffYUV 2.1.1, also looked at the sources of CCESP patch, but it doesn't support YV12 at all. To my knowledge, only ffdshow variant supports YV12.
Also, HuffYUV is single threaded AFAIK.

Can you tell me some details how you measured?
- OS
- 32/64 bit
- CPU (multicore or single core)
- Resolution
- Color space
- Program to do the measurement
- Codec settings for HuffYUV (prediction, etc.)
- Codec settings for MagicYUV
- Resulting file size/compression ratio for both compressed videos

Would really be interested, as in all my measurements, HuffYUV was always much slower :)

Greets,
I.



Antwort von MLJ:

Hi Ignus,
the original HuffYUV 2.1.1 is NOT the CCESP 0.2.5, it's the last Release before 2.2.0 came out, but was hardly used because it was buggy. The CCESP Version is stable and can cope with all HuffYUV Versions and has more options than the original Source.

I use Win 2K Pro (SP4) with 2 CPU's and Hyperthreading. I used VirtualDub 1.10.4 for Capture and noted there the CPU Load, same Sequence of course.

The Capture Settings:
PAL 768x576 @ 25 Fps (Interlaced, Top Field First)
Colorspace was "YUY2" 4:2:2 16 Bit
Audio was 48.000 kHz, 16 Bit, Stereo, PCM

In MagicYUV (rc2) i left everthing as default except "Interlaced" was enabled. With HuffYUV i also left the default Settings (Predict Left) and changed the Compression to "Convert to YUY2", thats all.

Playback was smooth and fluent without dropping Frames in both Videos, Sync with Audio and the Filesize was comparable, varied by about 500 KB between the two.

One thing you should look into: MagicYUV can not be loaded in Programs that use "ffmpeg/ffdshow" as a Import Engine, "VideoPad" from NCH Soft is one of those candidates.

It loads the Video but the Screen remains blank, not even the Audio. I could not find out why but somehow MagicYUV get's blocked. Other NLE's worked fine with MagicYUV.

Saving a RAW YUY2 Video (Uncompressed, Duration:5 Minutes) with MagicYUV took 00:43:34 and HuffYUV needed 00:38:22 for the same File in VirtualDub without any Filters loaded.

My "Wishlist": As you included "I420", could you include "IYUV" as well ? There are some "stupid" Capture Tools out there that state "I420" but use in realty "IYUV" because both Colorspaces are the same. And another thing would be great, if there was a Option for the Field Order for processing Interlaced Material (Top/Bottom Field).

All in all, great Codec, well done and keep it up :) I hope this helped you a little bit with your Codec.

Cheers, Mickey.



Antwort von Ignus:

Hi!

First of all sorry for the late reply.

MagicYUV 1.0rc3 is out.
Download: http://magicyuv.com

This release should hopefully fix the RGBA encoding issues, it should now work in After Effects. A new option was needed however to make it work, as it is non-trivial, the tooltip in the encoder settings dialog explains how it works.
I also added support for the IYUV fourcc.

And back to subject: can you provide a link to the HuffYUV 2.1.1 CCESP patch that you are using?

As for ffmpeg/ffdshow: that is a monolithic library of a whole lot of codecs implemented by a lot of people. MagicYUV however is currently a VFW (Video for Windows) codec. These are two very separate things, MagicYUV is not part of ffmpeg. The codec will not work with programs that don't support the VFW interface.

About benchmarks: MagicYUV's advantage should come out at FullHD and higher (4K, 8K) resolutions, especially when decoding. At least by my measurements, it should be way faster than HuffYUV and UTVideo for decoding. Though I used HuffYUV from ffmpeg, so that's why I'd like to try out the version you used.

About the interlaced setting: as MagicYUV is a lossless codec, the interlaced setting only affects file size (and YUV<->RGB conversions, but conversion is lossy anyhow). However, if you compress/decompress from/to the same colorspace, the interlaced setting simply might make the file smaller if the source was truly interlaced (or bigger if it wasn't).
Field order also doesn't matter for the codec, it always gives you back exactly what you compressed with it.

Thanks for your suggestions and time, let me know if you encounter bugs or have an idea for some other features.

Greets,
I.



Antwort von sgywalka:

@ Ignus!!!

Thank you, for YOUR greate Work.
You are one of my silent Mega-heros out
in cold space. Go on.
Works well and i like it.

Good Summer and many ideas in the
next 120 Years!!

sgywalka



Antwort von CameraRick:

"MagicYUV supports the following colorspaces: RGB32, RGB24, RGBA, AYUV (4:4:4 with alpha), YV24(4:4:4), YUY2 (4:2:2), UYVY (4:2:2), YV12 (4:2:0), I420 (4:2:0), Y8 (4:0:0) all at 8 bit depth per channel."

Hätte ja so schön sein können.






Antwort von MLJ:

@Ignus
Thanks Man, great piece of Work ;) I just downloaded it and try it out tomorrow and let you know about the results. Also thanks for implementing IYUV ;) About my HuffYUV Version, at the Moment it only installs and works fine with Windows from 9x to XP (32 Bit only). Is that still any help for you ? If so, i pack it in a zip-file and leave it here in the Forum so you can download it here, okay ? Just let me know beforehand. Say, do you know why Doom is still down ?

@CameraRick
Zitat:
"Hätte ja so schön sein können." (Wegen 8 Bit)
Zitat ende.

Du wartest auf 10 Bit, richtig ? Wie wäre es, wenn du Ignus mal ein wenig Anerkennung zollst für seine Arbeit denn er verlangt kein Geld oder irgendwelche Lizenzgebühren. Und 8 Bit haben bisher sehr gut funktioniert, also was willst du, ausser es vielleicht selber besser machen ?

UT-Video hat zwar mittlerweile einen v210 10 Bit jetzt an Board, aber den kannst du getrost im Moment vergessen, denn der funktioniert auf keiner 10 Bit Workstation, wurde getestet. Das gleiche bei VirtualDub und dem v210 10 Bit internen Codec, funktioniert nur richtig in VirtualDub aber auf keinem Professionellem System mit entsprechenden Karten. (AJA/Kona, DVS etc.) Die können mit diesen v210 Codecs null anfangen.

Lediglich der Drastic Codec funktioniert auf professionellen Workstations, in 8 und 10 bit, alle anderen kannst du getrost erstmal einpacken. Weiterhin ist der neue v210 von UT-Video verdammt langsam, ich meine SEHR langsam, da macht das Arbeiten null Spaß.

@sgywalka
WORD ;)

Cheers, Mickey.



Antwort von Spreeni:

@Ignus
Thank you for fixing the After Effects RGBA export. It's working very good. Can't wait to use and test it in 4K projects. Thanks for your work!



Antwort von CameraRick:

@CameraRick
Zitat:
"Hätte ja so schön sein können." (Wegen 8 Bit)
Zitat ende.

Du wartest auf 10 Bit, richtig ? Wie wäre es, wenn du Ignus mal ein wenig Anerkennung zollst für seine Arbeit denn er verlangt kein Geld oder irgendwelche Lizenzgebühren. Ich weiß nicht was Respekt mit der Nutzung von Codecs zu tun haben soll. Natürlich verdient jeder Programmierer Respekt wenn er Dinge einfach so kostenlos zur Verfügung stellt und Leute damit glücklich macht.

Aber für mich ist ein 8bit Intermediate halt irgendwie totaler Käse, für so manche Endausspielung ist das total Ok und toll aber sicher nicht während da Arbeit. Da schmeißt ja elendig viel Information weg, und das macht es für mich derzeit nicht brauchbar.
Und 8 Bit haben bisher sehr gut funktioniert, also was willst du, ausser es vielleicht selber besser machen ? 8bit mögen Dir reichen, aber halt nicht jedem. "Bisher" ist nun auch die Frage, wo sie so gut funktioniert haben; für manche Anwendungen halt nicht.

Ich kanns tatsächlich nicht besser machen, das tut mir leid. Aber ich verstehe auch die Logik dahinter nicht - kritisieren darf man offenbar also nicht, wenn man es nicht sofort besser macht?
Ich dachte halt dass ist ein Foren-Diskussion und kein Circle-Jerk



Antwort von TheBubble:

8bit mögen Dir reichen, aber halt nicht jedem. "Bisher" ist nun auch die Frage, wo sie so gut funktioniert haben; für manche Anwendungen halt nicht.

Ich kanns tatsächlich nicht besser machen, das tut mir leid. Aber ich verstehe auch die Logik dahinter nicht - kritisieren darf man offenbar also nicht, wenn man es nicht sofort besser macht? Sein Codec ist ein VfW Codec fuer den VCM. Da gehen ohnehin nicht mehr als 8 Bit pro Farbkanal bei der Ein- und Ausgabe.



Antwort von Ignus:

Sein Codec ist ein VfW Codec fuer den VCM. Da gehen ohnehin nicht mehr als 8 Bit pro Farbkanal bei der Ein- und Ausgabe. VFW/VCM can easily support any bit depth. For example V210, R10k, r210 and others all can work inside VCM, it all depends on other parts of the pipeline and software using VFW. VFW codecs can also be inserted into DirectShow (through a wrapper filter), and if you have filters that can accept the above formats (BlackMagic for example), then it will work.
10 bit support is already underway BTW (though it will probably not be included in the free edition), I just want to get 1.0 final out first.

Greets,
I.



Antwort von Ignus:

@Ignus
Thanks Man, great piece of Work ;) I just downloaded it and try it out tomorrow and let you know about the results. Also thanks for implementing IYUV ;) About my HuffYUV Version, at the Moment it only installs and works fine with Windows from 9x to XP (32 Bit only). Is that still any help for you ? If so, i pack it in a zip-file and leave it here in the Forum so you can download it here, okay ? Just let me know beforehand. Say, do you know why Doom is still down ? Thanks :)

Well, I do have a WinXP machine to test my codec too from time-to-time. If you have it, then upload it, so I can make some measurements.

Greets,
I.



Antwort von MLJ:

@CameraRick
Zitat:
" Aber ich verstehe auch die Logik dahinter nicht - kritisieren darf man offenbar also nicht, wenn man es nicht sofort besser macht?
Ich dachte halt dass ist ein Foren-Diskussion und kein Circle-Jerk"
Zitat ende.

Was ich meinte war etwas anderes. Dein Beitrag kam für mich (!) so rüber als wenn "Ignus" keine Anerkennung für seinen Codec verdient hätte, weil alles in 8 Bit abläuft und nicht in 10 Bit. Ich fand das, vorsichtig ausgedrückt, "abfällig" denn Ignus hat da wirklich verdammt gute Arbeit geleistet. Ich habe schon einige Programme geschrieben und kenne alle Tücken.

Natürlich ist das ein Forum in dem man diskutieren soll, aber dann doch bitte mit dem nötigen Respekt, meinst du nicht ? Sachlich bleiben ohne sich an den Kragen zu gehen, Informationen und Erfahrungen austauschen, aber das hat mit einem, wie hast du geschrieben "Circle-Jerk" absolut nichts zu tun. Klar kannst und sollst du kritisieren, keine Frage, aber dann zumindest mit dem nötigen Respekt vor der erbrachten Leistung, okay ? ;)

Also nichts für Ungut und mein Beitrag an dich habe ich auch nicht böse gemeint. Also, ist zwischen uns jetzt wieder aller klar ? :)

@Ignus
I have both, the Source Code and compiled HuffYUV Codec. I'm busy this Weekend but Monday evening i upload it to the Forum, okay ? Again, i'm deligthed with the "rc3", fantastic work, very stable. Say, why do do only give out RGB24 when the Source is YUY2 for example. UtVideo uses UYVY and HuffYUV uses YUY2 without going up to RGB24. Is there a certain Reason for this ?

To be exact: In VirtualDub you load a MagicYUV Capture, select "Fast Recompress" and MagicYUV uses RGB24 to any Codec instead of YUY2 while UtVideo and HuffYuV use UYVY and YUY2. Any Color conversion costs Quality, even with Lossles Codecs, depending on the Generation, that's why i ask.

Cheers, Mickey.



Antwort von Ignus:

@Ignus
I have both, the Source Code and compiled HuffYUV Codec. I'm busy this Weekend but Monday evening i upload it to the Forum, okay ? Again, i'm deligthed with the "rc3", fantastic work, very stable. Say, why do do only give out RGB24 when the Source is YUY2 for example. UtVideo uses UYVY and HuffYUV uses YUY2 without going up to RGB24. Is there a certain Reason for this ?

To be exact: In VirtualDub you load a MagicYUV Capture, select "Fast Recompress" and MagicYUV uses RGB24 to any Codec instead of YUY2 while UtVideo and HuffYuV use UYVY and YUY2. Any Color conversion costs Quality, even with Lossles Codecs, depending on the Generation, that's why i ask.

Cheers, Mickey. Thanks!

That shouldn't happen!
It should give native format first, especially in fast recompress. RGB24 conversion is optional, there are settings in the global codec config dialog (from the Start menu) controlling conversion (in "Decompression settings..."). The checkboxes on top tell which conversions the codec is allowed to do (if asked by a program). On the bottom "Suggest RGB for output first" can be used to tell the codec to always propose RGB24 if asked about it's native format. This was requested by someone, who wanted to compress as YUV but make it look like as RGB on output, because other programs didn't handle YUV output correctly (even though they accepted it).

So if you turn off "Suggest RGB on output first", then it should give native output format first.

This setting is disabled by default BTW. If you get RGB24 on fast recompress, then that surely means, that either the other Codec doesn't accept the native output (YUY2/YV12, whatever) or the compressed file was actually RGB24 to begin with.

Greets,
I.



Antwort von TheBubble:

VFW/VCM can easily support any bit depth. For example V210, R10k, r210 and others all can work inside VCM, it all depends on other parts of the pipeline and software using VFW. VfW is old, it dates back to 16-bit Windows. Programs can support arbitrary formats, but a lot of them probably don't. The most reliable common denominator for VCM codec input/output is probably RGB with 24 or 32 bits per pixel and (nowadays) an implicitly assumed sRGB color space (and transfer function), although a lot of RGB video data uses BT.709 or one of the BT.601 variants for sure. This ambiguity leaves the burden to keep track of accurate color reproduction with the user, unfortunately. (Newer version of DirectShow and Media Foundation can handle predefined nominal ranges, transfer functions, and so on.)

The encodings you mentioned are custom encodings, not documented in the Windows SDK, and most likely not supported by many programs. (There are documented FOURCCs with 10 bit per channel YUV data though. How well they are supported by editing/color correction packages is unknown to me.)






Antwort von MLJ:

@Ignus
I'm a bit in a hurry but here is the HuffYUV Codec CCESP Patch that i use (0.2.5). The Zip-File contains everything you need. The Folder Binary is the installable Codec (32 Bit Systems ONLY !) and the Folder Source contains the Source Code. Have fun Testing and hope this helps you. I check the Settings in MagicYUV about the RGB24 issue, okay ?

Cheers, Mickey.

P.S.: You need to log in to the Forum to access the Zip-File.



Antwort von CameraRick:

Was ich meinte war etwas anderes. Dein Beitrag kam für mich (!) so rüber als wenn "Ignus" keine Anerkennung für seinen Codec verdient hätte, weil alles in 8 Bit abläuft und nicht in 10 Bit. Ich fand das, vorsichtig ausgedrückt, "abfällig" denn Ignus hat da wirklich verdammt gute Arbeit geleistet. Ich habe schon einige Programme geschrieben und kenne alle Tücken.

Natürlich ist das ein Forum in dem man diskutieren soll, aber dann doch bitte mit dem nötigen Respekt, meinst du nicht ? Sachlich bleiben ohne sich an den Kragen zu gehen, Informationen und Erfahrungen austauschen, aber das hat mit einem, wie hast du geschrieben "Circle-Jerk" absolut nichts zu tun. Klar kannst und sollst du kritisieren, keine Frage, aber dann zumindest mit dem nötigen Respekt vor der erbrachten Leistung, okay ? ;)

Also nichts für Ungut und mein Beitrag an dich habe ich auch nicht böse gemeint. Also, ist zwischen uns jetzt wieder aller klar ? :)
Sorry wenn das so rüber kam. Es ist zwar ein Forum in Schrift und nicht Sprache, aber man muss ja auch nicht immer sofort in der negativsten aller Interpretationen deuten.

Ich meinte einfach nur: hätte schön sein können, aber für mich nicht nutzbar. Hätte schön sein können, aber so kann ich es nicht verwenden.
Wo Du da genau die fehlende Anerkennung rausliest weiß ich nicht.

Kleine Anekdote: ich arbeite in den VFX. Was meinst wie oft ich höre, "Der FIlm ist voll schlecht, keine Handlung und nur Effekte". DAS klingt abfällig. Auf eine Nachfrage hin versichert Dir aber auch jeder, die Effekte sein gut aber der Film halt nicht.
Daher habe ich aufgehört das wörtlich zu nehmen - nicht immer gleich alles schlecht sehen :)



Antwort von Ignus:

Thanks. I did some measurements using avibench (can be found on my website), which can measure codec speed separately, taking out all file I/O and whatnot from the equation.

The test was done on an AMD Phenom II X4 (4-core), 3.2 GHz in performance mode (3.2 GHz constant), 8 GB RAM, Window 7 64 bit. I created a 4GB RAMDisk, and used the first 500 frames of Big Buck Bunny in YUY2 format, FullHD (1920 x 1080), which is 2GB as raw YUY2.
As HuffYUV CCESP can use only 1 thread and runs in 32-bit mode only, I setup MagicYUV to use 1 thread too apart from using all threads and both 32/64 bit mode (other MagicYUV settings were defaults, ie. "Dynamic" prediction and "Adaptive coding" on). I also measured compression ratio.

For HuffYUV, I set interlaced threshold to 3000 (as the video is not interlaced), and disabled the Always Suggest RGB on decoding option and made sure it decodes in native format (YUY2) without conversion to RGB.

Here are the results:
Encode FPS Decode FPS Compression Ratio HuffYUV CCESP Left (32 bit, 1 threads) 57,0 25,4 2,39 HuffYUV CCESP Gradient (32 bit, 1 threads) 53,2 25,0 2,72 HuffYUV CCESP Median (32 bit, 1 threads) 61,7 16,6 2,91 MagicYUV 1.0rc3 (32 bit, 1 threads) 56,8 95,0 3,19 MagicYUV 1.0rc3 (64 bit, 1 threads) 79,5 131,0 3,19 MagicYUV 1.0rc3 (32 bit, 4 threads) 171,1 335,8 3,19 MagicYUV 1.0rc3 (64 bit, 4 threads) 215,0 433,6 3,19 So the only case where HuffYUV was a little faster is 32 bit single threaded mode encoding. In all other aspects, it was both slower and worse in compression ratio.
I note again, that the above is codec performance only, disk (ramdisk) I/O was taken out (avibench does separate timings for disk I/O).

Greets,
I.



Antwort von MLJ:

@Ignus
a bit under Time Pressure because of quite a bit of work today. About the comparison with HuffYUV and MagicYUV: With HuffYUV you only need to set the Interlaced Threshold to 1080, not to 3000 because anything below 1080 would be interpreted as Interlaced. One thing is certainly clear: MagicYUV is really fast, no doubt. I measured the Encoding and Decoding including the CPU Load with the Taskmanager during both operations.

My Test-Setup was like this:
Windows 2000 Pro (SP4)
One 500 GB SATA Drive for Capture Video
One 500 GB SATA Drive for Final Video
(Note: The SATA Drives are Identical (Seagate))
1 Typhoon Capture Card (768x576 PAL at 25 Fps, 4:3, Interlaced, TFF)
1 Creative Sound Card at 48.000 Hz, 16 Bit, Stereo PCM
1 Panasonic NV Series S-VHS VCR as a Source for Capture (S-Video)
Source: A 45 Minute Documentary

VirtualDub 1.10.4 in YUY2 Mode with Multithreading enabled.
Once selected HuffYUV and once MagicYUV as a Codec. No Filters or RGB Conversions, Preview Mode, Preview Acceleration set to "Interlaced", no Overlay Mode. Audio uncompressed PCM.

HuffYUV was set to "Predict Left" and "Convert to YUY2", Threshold at "288" and "Always suggest RGB" off.
MagicYUV was left to the Defaults except with "Interlaced" enabled.

Result in the right Window of VirtualDub was, that HuffYUV needed about 9-19 percent CPU Load on BOTH of my CPU's (Verified with the Windows Taskmanager) and MagicYUV 21-32 Percent, also both CPU's, no Frame Drops or Inserts. So, here i don't understand, that HuffYUV only ran in one Thread when it runs on my Pentiums in 2 Threads. I use the same Version that i uploaded here for you.

Compression to XviD 1.3.2 in "Fast Recompress" Mode was about Identical, except that MagicYUV uses "RGB24" and HuffYUV "YUY2". In "Normal Recompress" Mode HuffYUV uses RGB and MagicYUV RGB888.
I changed the Settings for MagicYUV but still the Output to XviD was RGB24/RGB888 in VirtualDub. Compression the whole 45 Minute Capture to XviD was done in 8 Minutes with HuffYUV and 30 Seconds longer with MagicYUV, i guess because of the RGB conversation. Again, both CPU's where used all the Time, monitored and checked with the Windows Taskmanager.

Playback with Windows Mediaplayer 6 (mplayer):
The HuffYUV Capture consumes about 3-7 Percent for Playback on both (!) CPU's and MagicYUV varies between 9 to 12 Percent on both CPU's at solid 25 Fps perfectly in Sync with the Audio with both Captures. The File Size with HuffYUV was about 1.2 GB higher than the MagicYUV Capture.

Conclusion:
Using a RAM-Disk does seem to make a Difference, even if it should not. Maybe you should try a similar Setup with longer Material for a long term Measurement instead of a short one to fully use the System. By the Way, i made the same Capture again with the same Setup at 1024x576 (16:9) with very little differences on the CPU Load which increased about 2-4 Percent with both Codecs, HuffYUV and MagicYUV for capturing, recompressing to XviD and Playback.

Please don't worry too much about the Speed of MagicYUV because everybody knows that your Codec is fast and produces a great Quality. Just try a different Setup for "Real Life" Measurements to get reliable Results. Many Bench-Tools produce different Results and the best is the one how hard the System and Machine gets really used, not a Program that tells you so.

Again, fantastic Work and thanks for MagicYUV. ;)

@CameraRick
Dann ist doch alles klar zwischen uns und ich habe deinen Beitrag nur falsch aufgenommen, nichts anderes. Also reichen wir uns die Hände und vergessen das ganze, okay ? :)

Cheers, Mickey.



Antwort von Ignus:

Thanks for the detailed report!

I tried fast recompress to XVID from compressed YUY2 and for me VirtualDub uses UYVY correctly. Could you try setting up MagicYUV when capturing, to set "Accepted colorspace" option to "YUV 4:2:2"?
If this refuses to capture, try setting "Mode (conversion)" to YUV 4:2:2 (just like HuffYUV).
If this works, but there is still RGB on output, try to disable the YUV 4:2:2 -> RGB conversion on the "Decompression settings..." page globally in the codec config dialog (rightmost column of check-boxes).

HuffYUV is single-threaded, the CPU load showing 2 cores being used is VirtualDub and the capture card and HuffYUV together, these together use multiple threads and the OS schedules them like that.

Actually, 768x576 is a rather small resolution, I don't know if the difference would come out at that resolution.

Also, a good test about encoding/decoding speed would be to re-encode the captured material (using a fast SSD or RamDisk) and see how long it takes.

Thanks, I don't worry too much, I just like to know why things happen the way they do :)

EDIT: One more thing about benchmarking. Video encoding involves a pipeline with many parts involved. If we look at the whole process, that doesn't tell us the speed of specific parts. I benchmark codec-only performance. Actually avibench is a tool I wrote to do just that, the source is included on my website, it measures disk I/O separately from the actual time the codec uses to finish compressing/decompressing a frame.
Also, when compressing to XVID, then the process is probably bound either by disk I/O or the XVID codec itself. In that case, the process won't be faster.
Also, RGB conversion takes a lot of resources, both from XVID side and MagicYUV side. Actually, this is what bugs me, why does it use RGB, and I'd like to know that.

Greets,
I.



Antwort von MLJ:

Hi Ignus,
Quote:
"Also, RGB conversion takes a lot of resources, both from XVID side and MagicYUV side. Actually, this is what bugs me, why does it use RGB, and I'd like to know that."
Quote end.

You find the Answer in the free Microsoft Sample Code of "msyuv.dll" that VirtualDub, HuffYUV and other Lossless Codecs use and modified. Plain Example: You make a Capture with UYVY or YUY2, no Compression, means 4:2:2 16 Bit. The Capture Card/Box/Stick saves it this Way and now you play it back. Guess what happens, right, it's NOT 16 Bit 4:2:2 anymore, it's RGB24 on the Output with a 16 Bit Header ! The Microsoft msyuv.dll decodes it this Way. The Background for this is easy: At the Time the Code was written and the first NLE's came out for Windows Microsoft faced a big Problem: The Drivers for the Graphics/Video Cards are for RGB, not YCbCr. The Chipsets refused in 24/32 Bit Mode any 12/16 Bit YUV Video, even in 16 Bit RGB so Microsoft wrote the Code in a Manner that 12 Bit I420/IYUV and 16 Bit UYVY/YUY2 and YVYU is converted to RGB24 on Playback so every Graphics/Video Card could play it.

Ulead, MGI, Adobe and all the others adopted that because Microsoft rules if you want to sell your Software. You can capture in 12/16 Bit but Playback is always in RGB24 Bit with a 12/16 Bit Header. You can try that yourself, just run the good old "Amcap" from Microsoft with any DirectShow Capture Card/Box/Stick and make a short Testcapture. Load it in VirtualDub and select "Fast Recompress" to any Codec that supports directly YUY2 on the Input for example. Which Decompressor is used ? "msyuv.dll" and what do you see in the Status Windows under "Log" ? RGB24.

At this point you should also deactivate the "Directly Decode Uncompressed YCbCr (YUV) Sources" through the "Options - Preferences - AVI" Settings so the Internal Codecs are bypassed from VirtualDub, they are still buggy and cause Color Shifts.

Why do you think Microsoft still holds on to the 32-Bit Codecs in a 64 Bit System like Vista/7/8 ? Compatibility ! The Intel Indeo IYUV (1997 !) Codec was modified for Vista/7/8 to support I420 as well, not just IYUV and what does this Codec do ? It takes 12 Bit and converts it to 24 Bit so the Playback is in RGB24, and NOT in 12 Bit like the Original. To directly compress a Video with Intel's IYUV you need 24 Bit RGB on the Output and the IYUV Codec converts this down to 12 Bit. The Logitech Codecs for some Cameras, that use UYVY, YUY2, I420 and IYUV stay in 12/16 Bit and that's why you get a "Green Screen" when you play them back because they don't convert to RGB24.

Speaking of Intel Indeo 2,3,4 and 5, same thing or Radius CinePak, this is part of the Video for Windows, ActiveMovie and DirectShow Interfaces that Microsoft provides. Why do you think some Videoboards only work with their own Codecs they install ? Because the native Windows Codecs don't work with them :)

There you have it, seek in the Archives from Microsoft and you stop wondering about a lot of things. But Microsoft is not alone in this Field, Apple too because QuickTime for Windows works the same Way, 12/16 Bit on Input but 24/32 Bit on the Output except RGB24/32 on the Input, but that is simply insane.

And XviD ? It does not (!) convert to RGB24, only if the Source comes this way in RGB24/32. You feed XviD with 12 Bit I420, IYUV or YV12 and XviD will use this Color Space without conversation. You give XviD UYVY or YUY2 and it will stay in 16 Bit without converting to RGB24, all tested and verified with the XviD Team because i know some of them.

You see, you're looking into a deep hole without a end and we all should be glad that Programs like VirtualDub exists to prevent all this Up/Down Conversation.

Cheers, Mickey.



Antwort von Ignus:

Actually with that question I was mostly interested in your case, why does VDub pass RGB to XVID? I know of course that XVID uses YUY2 input natively, it doesn't need to convert to RGB, I am interested in why during codec negotiation in VDub for fast recompress does MagicYUV end up outputting RGB for XVID in your machine, when it should use YUY2/UYVY (provided the compressed input really is YUY2/UYVY).

Greets,
I.



Antwort von MLJ:

Hi Ignus,
believe me, i tried the RGB Options in MagicYUV, all set to off but without a change. I'm using the 32-Bit Version (rc3), could it be that ? And yes, I'm sure, i used YUY2 4:2:2 16 Bit as a Source Format. HuffYUV and Lagarith send YUY2 to XviD, UtVideo sends UYVY to XviD and MagicYUV sends RGB24 (Fast Recompress) and RGB888 (Normal Recompress) to XviD.

Even if i recompress a HuffYUV or Lagarith Video with "Fast recompress" to MagicYUV, the Status Window from VirtualDub shows "YUY2" and when i open the MagicYUV Video that i compressed from HuffYUV or Lagarith in YUY2, same thing, RGB24 or RGB888 on the Output to HuffYUV, Lagarith or XviD. And yes, i pressed the "Apply" Button when i changed the Settings for MagicYUV with your Configuration Program :)

Don't panic, UtVideo uses UYVY instead of YUY2 on the Output, not perfect either ;) Speaking about UtVideo: The last release with v210 10 Bit is real slow and can not be used with AJA/Kona, Optibase and DVS Systems, just blank Video with 1 White Frame, that's all. Same with the v210 10 Bit in VirtualDub, not useable on these Systems. As you wanted to implement 10 Bit Codecs like v210 as well, maybe you should check into that first. ;)

Cheers, Mickey.

P.S.: I even tried older VirtualDub Versions back to 1.6.19 from "fccHandler", same thing and everytime the "Directly Decode YUV Sources" Option disabled and "Video - Color Depth" set to "Decompression Format - Autoselect" and "Output Format to compressor/display - same as decompression format".



Antwort von Ignus:

If all RGB decompression options are off but fast recompress sends RGB24 to XVID that definitely means, that the compressed material is RGB, not YUY2, I cannot see any other way. Or there is a bug somewhere.

Can you send me a few frames of the compressed material which is sent as RGB24 to XVID/other codecs?

I don't panic, but there may be either a bug or setup problem here, and if it's a bug, it definitely needs to be hunted down.

Thanks in advance, and sorry for taking your time!

EDIT: Thanks for the comments about 10 bit. Actually it's already well past the point of a wish to do it, but don't want to announce anything yet :)

Greets,
I.