I do have a video source in YUV 4:4:4 8 bit that I intend to capture directly if possible also to YUV 444 8 bit lossless. My capture card is able to deliver in several YUV 444 8 bit formats namely V308, IYU2, V408 and I have been trying without success to capture directly to magicyuv 444 8 bit lossless with virtualdub. However if I capture to v308 uncompressed for instance ,after it´s easy to convert with virtualdub to lossless magic yuv 444. The only way I found to capture directly to YUV 444 lossless has been to force the capture card to deliver RGB24 or 32 and in this case the magicyuv codec does capture directly to YUV 444. However it´s an additional color space conversion and I am queen to limit the color space conversion to the minimum. V308 and IYU2 are packed versions and v408 is 8-bit 4:4:4:4 with alfa. Which YUV 444 formats are accepted by the codec ? YV24 planar only? is there any possibility to capture directly to lossless yuv 444 using any of the three formats indicated ( V308, IYU2, V408) ?
Thanks in advance
Interesting, thanks!
MadVR has a pretty extensive list of pixel format support.
Though in the case of DirectShow things are a whole lot easier, as you have explicit stride (byte difference between rows of pixels) in the DShow API, whereas in VFW there is no such thing unfortunately.
OK, I implemented v308/v408 support, I'll make a build during the weekend and send it to you for testing.
Ok. Thank you.
As I will be obliged to test it in my main equipment where the magewell is installed and to avoid problems what will be better? to install directy over the official rc2 or unintall the rc2 and install the beta. I will do the standard tests, if you do need some specific tests please do ask it will be my pleasure to do them if I can.
The installer in general is pretty fool-proof, meaning you can install one over the other (even older ones) and it will automatically uninstall the old version (the same way as you would do it manually), so it should be pretty hard to screw up 🙂
So you can just simply go back and forth as you like, no need to waste time with uninstalling first.
Also, file format compatibility is also maintained in general, so compressed v308/v408 (ie. YUV 4:4:4) will decode perfectly fine with v1.2 even.
I've shared the installer with you, check your email.
Thank you, just received the file.
I will test it and let you know
Preliminary test, first impressions
It seems to be working fine and the codecs seem to be functional.
V308
Very light, cpu load between 1-3% no lost or inserted frames so far so good. Works with any width values, even not multiple of two.
I can read ( In this PC with the codec installed) in VDFM (internal or caching input driver), VLC, MPC-HC and Premiere. They accept records made with any width and do show the image correctly.
It does work with any width even if not multiple of 2. However in this case let’s say for instance 717x576 only two compressor show up 4.0.0 and 4.4.4 ( 4.2.0 and 4.2.2 don´t show up).
The select video compressor still says YV24 as the only pixel format accepted probably need to be updated to the new pixel formats.
These two situations apply also to v408
V408
It seems to be working also fine. Very light, cpu load between 1-4% no lost or inserted frames .
I case of v408 the records are incorrectly reproduced by VLC, VDFM ( both methods ), MPC-HC and premiere all do reproduce ok.
YUV4444 is also identified as M8Y4 not sure if it should be like that.
As far as I have other info I will let you know
Regards
Thanks for the detailed testing.
It does work with any width even if not multiple of 2. However in this case let’s say for instance 717x576 only two compressor show up 4.0.0 and 4.4.4 ( 4.2.0 and 4.2.2 don´t show up).
That is correct. 4:2:2 must have even width, 4:2:0 must have even width and even height. Anything that supports otherwise does so through some sort of non-standard hackery.
The select video compressor still says YV24 as the only pixel format accepted probably need to be updated to the new pixel formats.
I assume VDFM, right? That doesn't know about v308/v408 explicitly, so it tests for YV24 only.
I case of v408 the records are incorrectly reproduced by VLC, VDFM ( both methods ), MPC-HC and premiere all do reproduce ok.
What do you mean by "incorrectly"? I tried with VLC and VDFM and both decode just fine for me.
YUV4444 is also identified as M8Y4 not sure if it should be like that.
What do you mean?
EDIT: As an additional remark, I see you're using Rec.601 parameters. Keep in mind, that most apps (like premiere, etc.) usually request RGB from the codec, so it doesn't matter in that case (as the codec does YUV->RGB conversion internally), however if an app decodes as YUV directly, they must know how to "interpret" the YUV (Rec.601 vs Rec.709). This can be specified in VDFM in Video -> Decode format menu (on the right in the dialog). You must be careful here. I don't know how or if VLC can be instructed to interpret it in a different way.
VLC playing incorrectly v408.
Sorry my mistake, I wanted to say media player but it's probably about normal with YUV4444 , however in my pc media player reads v308 correctly. VLC does read correctly v308 and v408 without problems, sorry by the confusion.
Related to the fourCC code it was only a note as I was unsure if
MagicYUV - YUVA 4:4:4:4 and
MagicYUV - YUV 4:4:4 can have the same fourCC=M8YA or should have a different one
"I assume VDFM, right? That doesn't know about v308/v408 explicitly, so it tests for YV24 only."
Yes VDFM doesn´t recognize internally v308 or v408 so it´s about normal for now
Related to Bt.601 I was using it because I was using an SD stream and also because the capture card identified the stream as 720x576i 50 hz, 16:9, BT.601 , limited range(16-235).
Related to premiere as far as I know it can handle YUV video data natively. If the project uses clips that are in YUV format (like DV AVIs) and effects transitions also and only in yuv then Premiere processes them in the same colour space wherever possible. Also I do use debugmode frame server and the FrameServer plugin asks Premiere for YUV data first and if not found asks for RGB data. So in theory and I hope in practice clips and effects in YUV space will be processed by Premiere in YUV space and given in this case to the frameserver, which gives the data in the same colour space to the target application.
OK.
M8YA is for MagicYUV 4:4:4:4 (ie. with alpha), M8Y4 is for MagicYUV 4:4:4 (ie. without alpha). v408 can be compressed both ways, as v408 is actually 4 channel and might contain valid alpha. If you don't need alpha, just compress as M8Y4 and the "alpha" (or dummy channel) will be dropped.
To be absolutely sure regarding the decoding format, hover over the green "M" icon in the notification area (or click on it) while decoding to see what is the actual format the codec delivers. I doubt premiere supports YUV 4:4:4 directly, I'm pretty sure it requests RGB from the codec.
Also, be very careful with Rec.601/709 conversion issues. The codec has no way of communicating that information towards applications, so the apps must be set up correctly how to interpret YUV data coming from the codec. VLC for example doesn't seem to have any way to set this, and if you make one encode using Rec.709 and another one using Rec.601 of the same footage and play back them both with VLC you should most definitely see some color shift issues (especially in the reds and greens being brighter/darker). This also depends on a lot of factors how VLC is set up, whether it passes YUV data to the video card directly and leaves YUV->RGB conversion up to the video card (in which case global driver settings also kick in), or whether it does the conversion itself, etc.
Yes , You were right . Premiere does ask in RGB32 the data to the magicyuv codec.
This calls into question all the information I had about the native support of yuv in premiere from adobe and also from debug mode frame server.
Is this situation widespread or does it happens only with some codecs.? at this moment I would like to confirm for example what happens with DV files or other,s but I do not see an easy way to confirm if there was a change of color space or not.
As for the v308 / v408 codec, it seems to me that everything is correct, I made several additional captures, and all of them have gone well, only in 1080p and up formats, sometimes I have some frames inserted in the beginning but this do not seems specific to this codec, I have the same situation with others codecs sometimes too.
