MagicYUV - a new fast lossless video codec

[kolak]

Do you have swap fields option ticked in huffyuv codec?

None of the lossless codecs will alter incoming video- it encodes what it gets and this will stay lossless.
In your case issues is before data hits codec. Problem is between app and codec, something goes wrong as there is even shift in the video. Yet again, this is not really magicyuv problem. Maybe huffyuv people made special work around it, so it works fine.

[Mick]

@Kolak
I used the Settings for HuffYuv as seen in the Screen Shot i posted, means, no "Swap Fields" Option enabled. I even tried VirtualDub-MPEG2 1.6.19 (ffcHandler) instead of VirtualDub 1.10.4, same Result. I agree, normally this should not happen but it does somehow and the only Software involved is VirtualDub, the Capture Devices and the Codecs, that's all i used for the Samples, no funny Codec Packs installed that could mess up something.

Win2K, XP, Win7, all with MagicYUV RC4 and UtVideo 13.3.1 along with VirtualDub gives the same results with NTSC and BFF Input, not just for me, for others too like my Friend in Florida who had the same Problem with MagicYUV. As i wrote earlier, i really don't know where the Problem could be and maybe Ben Roudiak Gould has a Routine in HuffYuv that takes care of this Situation when BFF is used on the Input.

So i ask you, where could be the Problem between VirtualDub, the different Capture Devices and the Codecs ? I practically grew up with VirtualDub but this is the first Time that i see a Codec behave like this. If it would be a Problem along with a exotic Software with funny Interfaces, yes, but VirtualDub ?

I did notice in VirtualDub 1.9/1.10 that some Filters handle the Field Order wrong. In the Manual it says for Example that "Field Order A" (Now TFF) handles the EVEN Field (Lower Field) under "Preview-Options", which is wrong, it handles the ODD Field (Upper Field) and "Field Order B" (now BFF) the ODD Field (Upper Field) but really is the EVEN Field (Bottom Field) for Interlaced Preview Mode.

VDub Manual "Field Order A" = Even Field, Truth: Odd Field (TFF)
VDub Manual "Field Order B" = Odd Field, Truth: Even Field (BFF)

This is also the case for the new Interlace Filter, Odd/Even Field is the other Way around. You can verify that easily with a proper DV Encoded Video which is always BFF for PAL and NTSC, for a long Time a reliable Standard. Load it in VirtualDub and select the Preview Option to "Weave TFF" and let it play in VirtualDub, afterwards to "Weave BFF" and you see the difference.

So, is it possible that there is a Error about the Fields in VirtualDub when using the Capture Mode ? And if so: For how long, if i get the same Result with Version 1.6.19 ? On the other hand, if there "is" a Error in the Field Order in VirtualDub, how come no one ever saw or noticed it before ? Millions of Users use VirtualDub since it came out and I'm the first one to discover this ? You must agree, that would be very strange, don't you think so ?

Going by Occam's Rule:
"The principle in philosophy and science that assumptions introduced to explain a thing must not be multiplied beyond necessity, and hence the simplest of several hypotheses is always the best in accounting for unexplained facts."

Or Occam's Razor:
"A rule in science and philosophy stating that entities should not be multiplied needlessly. This rule is interpreted to mean that the simplest of two or more competing theories is preferable and that an explanation for unknown phenomena should first be attempted in terms of what is already known. Occam's razor is named after the deviser of the rule, English philosopher and theologian William of Ockham (1285?-1349?)."

Source:
http://www.thefreedictionary.com/Occam%E2%80%99s+Rule

So, we all must ask ourselves at this point: Could it be that VirtualDub causes this Problem, that no one ever noticed before besides me, or the Codecs MagicYUV and UtVideo ? If it would be just me with this Problem, yes, could be something wrong with my Setup and VirtualDub and the Codecs are Innocent, but others too ? Same Problem with different OSes, Machines, Setup's and other Capture Devices ? Coincidence ?

Quote Kolak:
"None of the lossless codecs will alter incoming video- it encodes what it gets and this will stay lossless. In your case issues is before data hits codec. Problem is between app and codec, something goes wrong as there is even shift in the video."
Quote end

I agree with you and you're right, it should not happen, but somehow it does, can't explain why and how but you saw that yourself with the Samples i linked to the Forum.

Anyway, this whole thing is a Mystery for me as all the other captures I've done in all these Years with VirtualDub worked fine without any Problems and maybe it's because i mainly used HuffYuv the whole time. At this Point i really don't know what it could be and really puzzles me.

Cheers

Mick

[kolak]

Try this:

http://www.videohelp.com/tools/Stoik-Video-Capture

just to check something else.


I don't rate Vdub as a reliable capture tool. It's great tool, but Iam not sure about capture module.
My another simple advice is to capture DV as is ( no recompression) and than convert it to other codec. With todays PC it takes not much time. This way should be way more reliable.

[Ignus2]

Sorry being absent, was quite busy this week.

My suggestion would also be to try another capture program, anything else than VDub, and see what happens. I would also be interested in raw YUY2 capture.

About the compressed YUY2 being decoded as RGB always situation: do you have a sample which demonstrates this behaviour for you? I'd like to look at that as well.

About Win2k: The problem is that Win2k is missing a lot of Windows API functions that are needed to avoid the DLL shutdown deadlocks that was discovered after RC4, among other things. That OS is simply just too old.

Greets,
I.

[Mick]

@Kolak
I knew the Stoik Capture Tool and stopped using that a long time ago because it's not very reliable in keeping the Audio in Sync with the Video, but thanks anyway :)

@Ignus
About the RGB Output:
When i loaded a MagicYUV Capture in VirtualDub and selected the "Fast recompress" Mode with XviD as a Target Codec, no matter which VirtualDub Version (1.6.19 to 1.10.4), showed "RGB888" as a Target Format for XviD instead of YUY2. Same thing with a HuffYuv encoded File in VirtualDub, but shows "YUY2" as a target Format for XviD, not "RGB888".

By looking in the File Details Description of a XviD Video in the Windows Explorer, encoded with MagicYUV the XviD File says "24 Bit" while a HuffYuv/Lagarith encoded Video to XviD shows "16 Bit" under Color Depth.

I also tried the YUV Capture Module from MoviePack Pro using YUY2 for NTSC 4.43, saved in RAW YUY2 (!), opened that Capture in VirtualDub, used "Fast recompress", selected once the HuffYuv Codec, then the MagicYUV Codec. Result: Same distortion in the Image with MagicYUV while HuffYuv was clean.

The Capture Settings where:
Resolution: 720x480
Format: NTSC 4.43
Frame Rate: 29.97 Fps
Color Space: YUY2 4:2:2 16 Bit Uncompressed
Interlaced: Yes
Field Order: Bottom Field First (Lower Field / Even Field First)
Audio: 48.000 kHz, 16 Bit Stereo PCM
A/V Interleave: 1:1 (Every 1 Frame)

Same Settings with the simple Microsoft "Amcap" Tool, no difference. As soon as MagicYUV or UtVideo is used for Material that is NOT captured "TFF", then you get the Result that I made available where HuffYuv encodes the capture correct. I compared a direct re-compress with VirtualDub from the HuffYuv encoded Sample to YUY2, same as the Capture, no difference between RAW YUY2 and re-encoded from HuffYuv.

Note:
I tried the Multithreaded Version of HuffYuv (huffyuv_mt.dll), perfect, just like the HuffYuv CCESP Patch 0.2.5 that i use. Further: Lagarith (Version 1.3.23 for Win2K) also keeps track of the correct Field Order. Lagarith is one of the derivative Codecs of the HuffYuv Source Code.

About Win2K:
Yes, it's old, not the newest, but works fine and reliable for me what i can't say from the 2 Years I tried XP, nothing but Trouble and Problems with it. Booting Win2K is a matter of 20 seconds and my Machine is up and running, ready to go. With XP i went down to the Kitchen, made some fresh Coffee and when i came back after about 5 minutes it was just about done. No thanks, no need for a OS like that. BTW: The Win XP (SP2) came from the Dell Support, "optimized" for my Workstation and the later Dell update CD for SP3 made things even worse.

Further, Dell, who customized the Workstation for my needs, strongly recommended Win2K for being far more stable, faster and reliable. Guess what, they where right. Plus, for my kind of work i need something that does not hang every 5 Minutes. And yes, i even tried Win7, skipped the "fat" Vista and "Playtool" 8. A alternative ? Certainly not for me and takes even longer until everything is ready, far away from a RTOS like Win2K.

I refuse to work with a OS that takes several hours for a 1 Hour Documentation when Win2K does exactly the same thing in 12 Minutes. My Family would kill me if i spend my Time with watching for Hours the Screen until it's done. And my Clients would look for somebody else if i tell them that they get the Material back in 2 Weeks instead of a couple of Days.

Win2K works for me without any Problems, stable, reliable, fast, without Blue Screens or System hangs and nothing on this Planet will make me change to another Windows OS. If it works for you and all the others, that's fine with me, it did not work for me. But please, let's leave this excursus about OSes and hope you understand why i stick with Win2K, okay ?

Just to let you know: For the moment I uninstalled MagicYUV and UtVideo from my System because of this Problem. MagicYUV and UtVideo are real great Codecs, but still seem to have some Problems and HuffYuv served me reliably well over the Years without any Problems. I really hope you and the Author of UtVideo can find the Problem what's causing this.

So, there is nothing i can do any more from my end to help you solve this Problem, I wrote and described you everything that I know and observed. Still, don't give up, sometimes it's those small simple things that can cause a big Headache filled with Question marks ;)

Cheers

Mick

[Ignus2]

Now this is very interesting.
Could you send that raw YUY2 sample as well? I would be really interested and would like to try it on my machine to see the issue, and that would help a LOT, as I might have a chance to reproduce the problem on my machine.

Also, can you send the sample which reports RGB888 to xvid?

So, there is nothing i can do any more from my end to help you solve this Problem, I wrote and described you everything that I know and observed. Still, don't give up, sometimes it's those small simple things that can cause a big Headache filled with Question marks

You can :)
By sending the raw YUY2 sample and the other MagicYUV compressed sample which reports RGB888, that would allow me at least a chance to fix the problem.
I do not have any sort of capture hardware, so without those samples, it is simply impossible.

So, if you have a little more time, I would really appreciate those samples.

Greets,
I.

[kolak]

And another thing. Invest money into proper capture tool.
I would suggest GrassValley Edius.
There is 30 days fully working demo.

[Mick]

@Kolak
i have a very good Capture Module with my Movie Pack Pro from Aist Cinegy that keeps everything in perfect Sync, including the access to all the Settings for all TV Norms. Edius is nice but not that what I need for my Work. Thanks anyway for the Tip :)

Plus, I really don't think that it's a VirtualDub Capture Problem. I tried it again with the Stoik Capture Tool, the Microsoft WMV9 Amcap (original, not the commercial AMCAP), the Debut Capture Tool from NCH Software, the Logitech Capture Program and the NeroVision Capture Module (Nero Suite), all resulted with the same Field Order in NTSC 4.43 (BFF), no difference for I420, YUY2, YV12, UYVY or other Colorspaces.

I even tested Paul Glaga's "CaptureFlux" Tool without any difference what so ever:
http://paul.glagla.free.fr/index_en.htm

Other Tools tested: Grabshow, Video View, Syntech, Empia and QSonic Capture Tools, no difference, means from my point of view that VirtualDub works fine what capturing concerns. ;)

All Capture tests with the different Tools where done once with the native Windows YUV Codecs without the Drastic YCbCr Codecs and once again with the Drastic YCbCr Codecs installed, no difference, just to exclude that the Drastic YCbCr Codecs might be the Problem, but they are not. All NTSC 4.43 captures where BFF conforming to the norm with all Tools.

@Ignus
You already have a MagicYUV File that Reports RGB24 (RGB888) to XviD: The Sample you downloaded :) Since I tried MagicYUV, all Files reported RGB24 (RGB888) to XviD, never YUY2, regardless what Output Settings i used in the MagicYUV Config. Again, I left the Video Input at "Auto Detect" and the Video Output at "Same as Input", trying it with "Fast recompress" and "Normal recompress".

HuffYuv/HuffYuv_MT and Lagarith always reported in both recompress modes YUY2 to Xvid where MagicYUV and UtVideo always reported RGB24 (RGB888) to Xvid. A Win2K Issue ? No, because i tried the same thing with a small short Video on a Laptop with XP (SP3) using HuffYuv, Lagarith, MagicYUV and UtVideo, same result like under Win2K. HuffYuv/Lagarith reported YUY2 to Xvid, MagicYUV/UtVideo reported RGB24 (RGB888) to XviD.

And the RAW YUY2 ? It's really simple, open the HuffYuv Sample you downloaded in VirtualDub, select YUY2 for Output and use under Compression "Uncompressed YCbCr/RGB". This is the same as any other RAW YUY2 File that I would upload, verified with a uncompressed NTSC 4.43 Capture, both RAW YUY2 where exactly the same.

If you do really, really need another RAW YUY2 Sample, then I see when I get down to it and upload it via "Wetransfer", okay ? But this Time without Sound and in 640x480 instead of 720x480 to keep the Size down a bit. Would 10 seconds be enough ?

I really hope this helped you a bit further. BTW, did you or anybody else inform the Author of UtVideo about this Field Problem ?

Cheers

Mick

[Ignus2]

I don't see the problems you mention. The MagicYUV file gets correctly reported as YUV 4:2:2. I get the following log for Fast Recompress of the MagicYUV file you sent with 32 bit VirtualDub to XVID:


AVI: Opening file "E:\_vid\bugreport\MagyTest.avi"

Beginning dub operation.
[i] Dub: Fast recompress mode started with format: UYVY.

MagicYUV can decode compressed YUV 4:2:2 to both YUY2 or UYVY, whichever is requested.

For Normal Recompress with output set to "Same as decompression format" and input to "Autodetect" I get this for MagicYUV:

AVI: Opening file "E:\_vid\bugreport\MagyTest.avi"

Beginning dub operation.
[i] Dub: Recompressing using format: RGB888.

and this for HuffYUV:

AVI: Opening file "E:\_vid\bugreport\HfyuTest.avi"

Beginning dub operation.
[i] Dub: Recompressing using format: RGB888.

So in Normal Recompress BOTH report RGB. In Fast Recompress BOTH report YUV correctly.

I also tried to create the raw YUY2 file from HuffYUV. It looks correct. I then compressed the raw YUY2 file with MagicYUV: it also looks correct, moreover compared with Avisynth it is bit-by-bit identical to the HuffYUV encode.

Greets,
I.

[kolak]

Don't trust Vdub blindly.
Set color depth as desired instead of hoping it that everything will work as needed.

[ceth]

It seems there is a bug in your v1.0 codec install, I had to change my TMP folder to another or I get an access denied error (maybe due to non-english win7)

[Ignus2]

It seems there is a but in your v1.0 codec install, I had to change my TMP folder to another or I get an access denied error (maybe due to non-english win7)

Strange, what language? It should install on any language. I tried on various systems I had access to: English, Central-European, East-Asian OSes from Win XP to Win 8.1.

Greets,
I.

[ceth]

French

[Ignus2]

Anyone having any luck rendering 10-bit? I'm choosing the "UtVideo Pro YUV422 10bit VCM" option and have tried a few resolutions and frame rates but rendering in Vegas Pro it always tells me "The selected codec does not support the current render settings." In VirtualDub it says "Couldn't find compatible format. Possible reasons: *Codec may only support YUV *Codec might be locked *Codec might be decompression-only".

This is a reply to a post in the Ut Video codec thread, but I answer here, as the discussion would be off-topic there.

Hi!

I noticed your discussion on the Vegas Pro forums, and I'm facing the exact same problem with my codec's 10-bit variant. Basically what happens is that Vegas is presenting ONLY RGB32 for VFW codecs, period. It doesn't even ask anything about possible supported formats by the codec, I tried setting the project settings to 32-bit float, loaded an uncompressed v210 AVI, but still, the encoder gets RGB32 no matter what.

There are other problems as well, namely while Vegas can open uncompressed v210 AVIs, but if a codec reports that it can decode to v210, Vegas refuses to open it.
The Sony 10-bit YUV "codec" is actually what is doing v210 (hence the possibility to open uncompressed v210 AVI), but it isn't really a codec, all it does that it packs/unpacks the uncompressed data into v210, that is all.
However, the Sony 10-bit YUV codec is hard-coded into the avi output module of Vegas (you can verify this by looking into the avi output DLL file in the vegas folder - don't remember now where it is precisely - with Total Commander lister and search for Sony 10-bit, you'll find that, which means it is hard-coded), so it is probably able to get the native internal representation of Vegas, and not just RGB32.

So I have no idea how 10-bit or higher bit-depths can be supported by Vegas using VFW.
I asked Sony support about the issue, but they didn't answer, and I would be surprised if they did. Maybe you can try to convince them? ;)

EDIT: I also noticed some confusion on the Vegas forums about MagicYUV being a 422 codec, etc. MagicYUV can compress RGB, as well as various YUV formats, but in it's default mode, it compresses what it gets. In the next release I implemented a task-bar icon which will show exactly what the codec is doing (what input is it getting and how it is compressing it) to be clear what is happening. If you want to make sure you compress RGB, select RGB in the "Accepted colorspace" drop-down in the codec settings, this will make the codec accept only RGB and reject anything else. And if you want to be absolutely sure, press "Save as default" to save the settings to the registry. Note, that this will make the setting global for all apps, so remember that!

Greets,
I.

[nhope]

Ignus2, thank you for the very helpful explanation.

That's sad :( I will try to bring it to Sony's attention.

I wonder if Cineform's 10-bit VFW codec (in GoPro Studio Premium) is supported in Vegas Pro. I don't own it but I could download the trial to test.

[Mick]

@Ignus2
You have unread PN's :)

Cheers
Mick

[kolak]

Ignus2, thank you for the very helpful explanation.

That's sad :( I will try to bring it to Sony's attention.

I wonder if Cineform's 10-bit VFW codec (in GoPro Studio Premium) is supported in Vegas Pro. I don't own it but I could download the trial to test.
As far as I remember it does as Vegas has native support for CF (if you have license). Latest Adobe Media Encoder has native CF exporter included now, no need for seperate license (but MOV only).

[Mick]

@Ignus2
You still have unread important Pn's ;)

Cheers

Mickey

[Orivaa]

Soooo... what exactly is the point of this codec? I know it's fast and such, but what can one even use it for? You can't edit it because editing or re-encoding programs don't recognize it (At least when I tried), and you can't upload it to YouTube because it can't re-encode it.

[De-M-oN]

You can't edit it because editing or re-encoding programs don't recognize it

They do.

[Orivaa]

They do.

I couldn't get Handbrake nor Xmedia Recode to recognize it. If they couldn't, I don't see why editing programs would be able to.

[De-M-oN]

Handbrake uses ffmpeg for decoding only. Maybe XMR does the same.

Every program, which can access DirectShow will be able to decode this codec. Means there is a decoder in your system. But there is some software like VLC, Handbrake etc which ignore that and only use their internal decoder.
So of course Windows Media Player would be able to decode it.
MeGUI can decode it (better said avisynth)
Premiere, Vegas, etc can do as well, while the worst NLE camtasia cant though.

[zerowalker]

Ignus2 , how is it going with the ffmpeg implementation.
You started or is it not in the works?

Thanks

[Ignus2]

Ignus2 , how is it going with the ffmpeg implementation.
You started or is it not in the works?

Thanks

No, and it's unlikely in the near future. VLC plugin is more likely (I already have a working prototype). Also there are other very interesting stuffs in the pipe!

Greets,
I.

[zerowalker]

Ah ok, when it appears will Encoding be possible (why i ask is cause OBS will use ffmpeg which only supports UTVideo as a good Lossless Codec).
(What do you mean with VLC plugin, you mean a decoder inbuilt in it?)

Oh, can't wait to see those interesting things, you just got my anticipation up for more news;P

Thanks!

[Ignus2]

Not built-in, but as a dll/so binary plugin.

Greets,
I.

[zerowalker]

Yeah what supposed to say that.
Well that's great:)

[Orivaa]

So question. How well would this work for recording? I generally use Lagarith, then shrink the file size with Handbrake (A sad necessity).
So 1: Does this codec have less of a performance impact than Lagarith
And 2: How would one go about re-compressing it with h264 afterwards? Can't get it to work with Handbrake, after all.

[De-M-oN]

So 1: Does this codec have less of a performance impact than Lagarith

by far.
In my case a i7 3770k @ 4,1 ghz cpu, 1600 mhz cl7 RAM, RAID 0 with 352 mbyte/s - afterburner shows a frame compression time of about 19 to 22ms for Lagarith (2560x1600, yv12, multithreading) and for magicYUV about 8ms (2560x1600, 4:2:2 (same with YV12, maybe 1ms difference)

[zerowalker]

To answer the second, yes you do re-compress or rather Encode it with x264 afterwards.

Uploading Lossless is just impossible and not realistic in any scenario to Youtube.
MagicYUV works with x264 just as any codec should as long as you got a decoder.

[De-M-oN]

Uploading lossless is possible if you have the connection. Some not so complex videos I compressed with x264 via qp=0 which is by far smaller and was doable to upload with a 12 mbit uploadspeed.

[zerowalker]

Yeah it's possible, but it's not really something you should aim for:P
But i for that matter upload all Retro 2D games in x264 CRF=0 YV24 just for the heck of it.

[De-M-oN]

CRF 0 is not lossless. Use qp 0 (constant quantizer @ 0)

[zerowalker]

Wasn't both the same. Thought i read when CRF reached 0 it was the same thing.
Pretty sure i did some difference tests comparing Original Converted to YV24 with the x264 encoded version as well just to make sure.

[De-M-oN]

CRF 0 is not lossless. I assure you that. The encoder still writes b-frames and so on. All Lossy techniques are still used (which of course is also much slower than lossless)

[Information] [18.01.2015 20:18:00] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264_10b\avs4x264mod.exe" -L "C:\Program Files (x86)\MeGUI\tools\x264_10b\x264-10b_64.exe" --crf 0 --keyint infinite --min-keyint 1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1 --output "E:\Lets Play Blood\gzdoom_2015_01_14_12_19_11_653.264" "E:\Lets Play Blood\gzdoom_2015_01_14_12_19_11_653.avs"
[...]
[Information] [18.01.2015 20:18:00] Standard error stream
-[Information] [18.01.2015 20:18:00] raw [info]: 320x240p 1:1 @ 60/1 fps (cfr)
-[Information] [18.01.2015 20:18:00] x264 [info]: using SAR=1/1
-[Information] [18.01.2015 20:18:00] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
-[Information] [18.01.2015 20:18:00] x264 [info]: profile High 10, level 2.1, 4:2:0 10-bit
-[Information] [18.01.2015 20:18:08] x264 [info]: frame I:1 Avg QP:11.58 size: 60801
-[Information] [18.01.2015 20:18:08] x264 [info]: frame P:727 Avg QP:16.59 size: 25621
-[Information] [18.01.2015 20:18:08] x264 [info]: frame B:306 Avg QP:19.37 size: 16797
-[Information] [18.01.2015 20:18:08] x264 [info]: consecutive B-frames: 42.8% 52.6% 1.5% 3.1%
-[Information] [18.01.2015 20:18:08] x264 [info]: mb I I16..4: 0.0% 25.3% 74.7%
-[Information] [18.01.2015 20:18:08] x264 [info]: mb P I16..4: 0.2% 8.8% 15.5% P16..4: 15.7% 16.0% 20.8% 0.0% 0.0% skip:23.1%
-[Information] [18.01.2015 20:18:08] x264 [info]: mb B I16..4: 0.0% 2.0% 5.6% B16..8: 13.8% 17.8% 20.2% direct:19.2% skip:21.3% L0:30.4% L1:27.0% BI:42.6%
-[Information] [18.01.2015 20:18:08] x264 [info]: 8x8 transform intra:34.6% inter:23.9%
-[Information] [18.01.2015 20:18:08] x264 [info]: coded y,uvDC,uvAC intra: 99.7% 99.9% 99.8% inter: 63.6% 69.3% 66.1%
-[Information] [18.01.2015 20:18:08] x264 [info]: i16 v,h,dc,p: 8% 9% 62% 21%
-[Information] [18.01.2015 20:18:08] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 7% 38% 7% 7% 8% 7% 8% 9%
-[Information] [18.01.2015 20:18:08] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 8% 19% 9% 10% 11% 9% 11% 10%
-[Information] [18.01.2015 20:18:08] x264 [info]: i8c dc,h,v,p: 66% 10% 12% 11%
-[Information] [18.01.2015 20:18:08] x264 [info]: Weighted P-Frames: Y:16.9% UV:16.5%
-[Information] [18.01.2015 20:18:08] x264 [info]: ref P L0: 80.9% 10.4% 8.1% 0.6%
-[Information] [18.01.2015 20:18:08] x264 [info]: ref B L0: 87.9% 12.1%
-[Information] [18.01.2015 20:18:08] x264 [info]: ref B L1: 100.0% 0.0%
-[Information] [18.01.2015 20:18:08] x264 [info]: kb/s:11060.91
-[Information] [18.01.2015 20:18:08] encoded 1034 frames, 136.68 fps, 11060.91 kb/s

[zerowalker]

Remember 10bit is never lossless if the source is 8bit.
If it's the same still with the 8bit version, i am at a loss of words.

Doesn't make sense that the images are lossless in difference.
Really must look into it the next time i do that, was 100% sure it was lossless, i must have done something wrong with my tests.

Thanks for bringing it up.

EDIT:

I got a file recorded with CRF=0 as far as i can remember, it says 0 bframes and not even crf=0 with MediaInfo.

https://trac.ffmpeg.org/wiki/Encode/H.264 - here it says crf=0 is lossless :S

[De-M-oN]

With qp 0 the encoder doesnt use b-frames and the quantizer values stay at zero. qp 0 works with 10bit as well.

[zerowalker]

10bit can't be lossless on 8bit sources.
It's like YV12 to RGB isn't lossless.
It's just larger files for no use.

10bit lossy is a gain on 8bit, but lossless it should just get larger sizes as it must use 10bit instead of 8bit and can't do any clever compression.

[De-M-oN]

--[Information] [01.02.2015 21:43:05] resolution: 1920x1200
--[Information] [01.02.2015 21:43:05] frame rate: 60/1
--[Information] [01.02.2015 21:43:05] aspect ratio: 8:5 (1.600)
--[Information] [01.02.2015 21:43:05] custom command line: --output-csp i422
--[Warning] [01.02.2015 21:43:05] --min-keyint bigger as --keyint/2+1. Lowering --min-keyint to max value: 1
--[Information] [01.02.2015 21:43:05] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264_10b\avs4x264mod.exe" -L "C:\Program Files (x86)\MeGUI\tools\x264_10b\x264-10b_64.exe" --qp 0 --keyint infinite --min-keyint 1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --output-csp i422 --sar 1:1 --output "D:\XVideos\Lets Play Need For Speed SE\WT-NFSSE-Vertigo Ridge.264" "D:\XVideos\Lets Play Need For Speed SE\WT-NFSSE-Vertigo Ridge.avs"
--[Information] [01.02.2015 21:43:05] Process started
--[Information] [01.02.2015 21:43:05] Standard output stream
---[Information] [01.02.2015 22:06:43] avs [info]: AviSynth 2.60, build:Sep 28 2013 [15:09:12]
---[Information] [01.02.2015 22:06:43] avs [info]: Video colorspace: YV16
---[Information] [01.02.2015 22:06:43] avs [info]: Video resolution: 1920x1200
---[Information] [01.02.2015 22:06:43] avs [info]: Video framerate: 60/1
---[Information] [01.02.2015 22:06:43] avs [info]: Video framecount: 37550
---[Information] [01.02.2015 22:06:43] avs4x26x [info]: "C:\Program Files (x86)\MeGUI\tools\x264_10b\x264-10b_64.exe" - --qp 0 --keyint infinite --min-keyint 1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --output-csp i422 --sar 1:1 --output "D:\XVideos\Lets Play Need For Speed SE\WT-NFSSE-Vertigo Ridge.264" --frames 37550 --fps 60/1 --input-res 1920x1200 --input-csp i422
--[Information] [01.02.2015 21:43:05] Standard error stream
---[Information] [01.02.2015 21:43:05] raw [info]: 1920x1200p 1:1 @ 60/1 fps (cfr)
---[Information] [01.02.2015 21:43:05] x264 [info]: using SAR=1/1
---[Information] [01.02.2015 21:43:05] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [01.02.2015 21:43:05] x264 [info]: profile High 4:4:4 Predictive, level 5.0, 4:2:2 10-bit
---[Information] [01.02.2015 22:06:43] x264 [info]: frame I:94 Avg QP: 0.00 size:512519
---[Information] [01.02.2015 22:06:43] x264 [info]: frame P:37456 Avg QP: 0.00 size:338061
---[Information] [01.02.2015 22:06:43] x264 [info]: mb I I16..4..PCM: 58.1% 0.0% 41.9% 0.0%
---[Information] [01.02.2015 22:06:43] x264 [info]: mb P I16..4..PCM: 13.1% 0.0% 8.6% 0.0% P16..4: 2.5% 1.6% 1.6% 0.0% 0.0% skip:72.6%
---[Information] [01.02.2015 22:06:43] x264 [info]: 8x8 transform intra:0.0% inter:21.5%
---[Information] [01.02.2015 22:06:43] x264 [info]: coded y,uvDC,uvAC intra: 89.6% 89.4% 89.3% inter: 3.8% 5.7% 5.6%
---[Information] [01.02.2015 22:06:43] x264 [info]: i16 v,h,dc,p: 22% 78% 0% 0%
---[Information] [01.02.2015 22:06:43] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 51% 3% 3% 2% 1% 1% 1% 1%
---[Information] [01.02.2015 22:06:43] x264 [info]: i8c dc,h,v,p: 9% 30% 61% 0%
---[Information] [01.02.2015 22:06:43] x264 [info]: Weighted P-Frames: Y:0.9% UV:0.9%
---[Information] [01.02.2015 22:06:43] x264 [info]: ref P L0: 66.5% 11.9% 21.5% 0.0%
---[Information] [01.02.2015 22:06:43] x264 [info]: kb/s:162478.88
---[Information] [01.02.2015 22:06:43] encoded 37550 frames, 26.48 fps, 162478.88 kb/s

qp 0

I somehow doubt that 10bit changes the quality to negative at lossless.

[zerowalker]

Done some tests before, 8bit vs 10bit on 8bit sources.
10bit was always greatest in size, and it wasn't lossless (most likely as it has to be dithered down to 8bit, in 10bit it's probably identical if you have such gpu/monitor).

Do a fast recording on a 2D game, like just 1 sec.
Encode it with 8bit CRF=0 and compare original to encoded version (of course in same colorspace).
You can also try qp=0 and 10bit on both.

EDIT:

Interesting.

"Use of -qp is recommended over -crf for lossless because 8-bit and 10-bit x264 use different -crf values for lossless."

[De-M-oN]

Indeed interesting ^^

But 10bit has absolutely no loss to me compared to my 8 bit lossless capture.

But on the other hand if lossless mode is active the x264 8bit shouldnt produce banding if the lossless codecs dont either.
But if I use 10bit for x264 I thought I can be safe then.^^

[zerowalker]

Both of us seems to have been wrong.

10bit can do lossless on 8bit (still confused how it works. For me it's like storing YV12 in RGB), but it works it's just that i have failed using lossless (crf=0).

And you thought crf=0 wasn't lossless cause it wasn't in 10bit and i was using 8bit.

Quite funny, learned something. Must try 10bit and compare filesize sometime, if it's less then 8bit i am at a loss:P

[Orivaa]

by far.
In my case a i7 3770k @ 4,1 ghz cpu, 1600 mhz cl7 RAM, RAID 0 with 352 mbyte/s - afterburner shows a frame compression time of about 19 to 22ms for Lagarith (2560x1600, yv12, multithreading) and for magicYUV about 8ms (2560x1600, 4:2:2 (same with YV12, maybe 1ms difference)
So if used to record, the performance impact would be less, yes? Aaaaalso, whenever I use a recording program that supports External Codecs like MagicYUV, I can only use the 32 bit version. I imagine that would have different performance from the 64 version.

To answer the second, yes you do re-compress or rather Encode it with x264 afterwards.

Uploading Lossless is just impossible and not realistic in any scenario to Youtube.
MagicYUV works with x264 just as any codec should as long as you got a decoder.

I can't find a decoder, though. Neither Handbrake nor XMedia Recode recognizes it, and I was never able to render x264 with Sony Vegas. Know any programs (Preferably not editors, but programs like Handbrake) that supports both MagicYUV, and allows it to re-encode it as h264?

[Bloax]

10bit can do lossless on 8bit (still confused how it works. For me it's like storing YV12 in RGB)
Bits are not colorspaces; you can easily store 8 bits of information in 10 bits of information (the simplest thing to do would be leaving the excess two bits empty), but you can't store YUV values in RGB.

[Ignus2]

So if used to record, the performance impact would be less, yes? Aaaaalso, whenever I use a recording program that supports External Codecs like MagicYUV, I can only use the 32 bit version. I imagine that would have different performance from the 64 version.

That's because the program itself you use is 32 bit. If you use a 64 bit program, then it will use the 64 bit version.
And yes, the 64 bit version of the codec is much faster (especially for decoding).


I can't find a decoder, though. Neither Handbrake nor XMedia Recode recognizes it, and I was never able to render x264 with Sony Vegas. Know any programs (Preferably not editors, but programs like Handbrake) that supports both MagicYUV, and allows it to re-encode it as h264?
The reason why they don't "recognize" it is because they probably use ffmpeg, which is a monolithic collection of codecs, and obviously MagicYUV is not in it.
I might write a reference decoder sometime in the future for ffmpeg, though that sometimes could lead to confusion, like currently in the case of UT looking like it is slow, while in fact sometimes the installed inferior ffmpeg implementation (through Lav filter for example) does the decoding instead of the optimized official decoders.

In the meantime, you can use Avisynth with "AVISource()" to open MagicYUV encoded files and feed that to an h264 encoder.

Greets,
I.

[zerowalker]

Bits are not colorspaces; you can easily store 8 bits of information in 10 bits of information (the simplest thing to do would be leaving the excess two bits empty), but you can't store YUV values in RGB.

Yeah know. But thought those extra two bits would ruin things.
But if they can be empty then i guess the file is only larger by the address of that space or something, which should be next to nothing.

Thanks

[zerowalker]

And yes, the 64 bit version of the codec is much faster (especially for decoding).

Damn had no idea about this, knew it would be faster but thought like 1-5% at best. Guess it's more?

[De-M-oN]

Like said. Use MSI Afterburner and you can access the 64bit encoder.

http://www.abload.de/gallery.php?key=jRBPGPYE

with this settings (fps and codec of course your choice - the screen is older - but the rest of the options are still up to date.)

You'll still see MagicYUV's 32bit config, but Afterburner will use the 64bit encoder when you record. It does via the dedicated encoder server. An extra process for the encoding. This way it can use the 64bit encoder.

[zerowalker]

Thing i hate about MSI Afterburner is that the sync is off by a different way compared to Dxtory (non of them is good as both are unsync, Afterburner seems to be better though).
Other is that the record using 16bit audio which causes a bit of a noise floor which disturbs me. (Asked them to use float and convert to 16bit at the end to no avail, but well only i that care about it;P).

Other than that it's an excellent software, didn't really think about the 64bit option even though i have seen it.

[De-M-oN]

Afterburner is perfectly fine in sync - no asynch at all. Else story for dxtory over time :( And DXTory got so goddamn slow on OpenGL, while it was in the past fast there :/

There is only one thing you have really to take attention for: Afterburner closes Audio a lot milliseconds (up to 800ms) earlier than the video track. If you append several avi files without paying attention for that - of course it will get asynch.

Thats one of the reasons why we at letsplayforum use SSM. It can extract the audio while syncing it to the videotrack - if the track is too short it will fill up with silence and if its too long it will cut the rest.

This way you have a perfect synchronization with audio and video (if its not asynch within the track) and for me at Afterburner its perfectly accurate in sync.

The 16bit audio had never been an issue to me to be honest. (Rode NT2-A + PreSonus Audiobox 22VSL)

SSM : http://www.letsplayforum.de/index.php?page=Thread&threadID=110277 (its basically a avisynth script GUI with widened options for youtube videos compared to megui, allows an audio preview (and also for cutting) and has the said audio extracter - if you extract audio after making the trim entries it will even consider for the extraction that, means audio is directly cutted then. No clt list for megui necessary then.

And dont worry, you can choose english if you are not german.