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.

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.

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.

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.

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

I will test it and let you know

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.