YUV 4:4:4 8 bit capture

Hi,

Sorry for the very late response, I had my hands full with various issues, my apologies.

I can look into those pixel formats, I don't think they are hard to implement support for.

Could you make a raw/uncompressed capture with each of them so I can test?

Thanks!

Ok. Thank you again .   I´m including three samples,  v308, v408 and IYU2,  5 seconds each  zipped together . Giving support to all of them it´s probably to much work with a limited return, one of them it´s probably  enough ,  from the three the most useful it´s perhaps the v308  in my opinion , but I think it will be up to you to decide which one if any will be interesting to eventual include in the codec.

https://we.tl/t9NivkG1am

the link will be active I think over the next 7 days

Best Regards

Thanks. v308 and IYU2 are similar, both are 3-byte packed formats, the only difference is the component order. v308 is "V,Y,U", while IYU2 is "U,Y,V". v408 is also a packed YUV format with alpha, having component order "U,Y,V,A".

Could you also make a test capture for v308 and IYU2 (v408 is not needed) having a width that is not a multiple of 4 (like 1022, 1018, etc.)?

I made two additional samples  v308 and IYU2 with 1018x576. I was not sure if you need only a width that was not a multiple of 4 or if you need  a height not multiple of 4 also. I made only with width equal to 1018 and used the same height 576. If you need a different height let me know.there is no problem as the card upscale and downscale to whatever value I want.

https://we.tl/x9PXzWzAvu

If you achieve support to a broader array of formats namely the more demanding ones ( 10 bit+ , 444, etc) I think  magicyuv can profit as being seen as more universal and probably the one supporting  the largest number of formats.

Thanks again for your time

Wonderful, we're almost there 🙂

I only needed the width to be non-4-multiple.

One last question: what program do you use to open these AVI files (either for editing or viewing)? Also what program did you use to capture these files? I'll get to my point after that 😉

I normally use to capture  VirtualDubFilterMod  . As the card does support direct show I have also used amarectv, Obs and others  applications and even ffmpeg directly ( works  fine), however 95% I use VirtualdubFilterMod. For edit or viewing I do use Avisynth and VirtualDubFilterMod, but usually I do compress after  capture( if uncompressed) to lossless with MagicYUY , Utvideo FFV1 or x264, usually are these files that I after open in avisynth /VirtualdubFM or Adobe with some exceptions sometimes to v210 that I use sometimes directly in Adobe. I tried and it also works capture directly with ffmpeg  and directly convert on the fly for whatever lossless format I want , but even if it seems to work fine is not practical.

The reason I asked about the latest captures specifically is that when I open the v308_1018x576.avi in VirtualDub_FilterMod_40639 the image is skewed as you can see in the attached image.

The reason for that is precisely what I was curious about, namely the rows of pixels are padded to 4-byte boundaries by something in the capture chain, but the ffmpeg v308 decoder in VDFM expects no padding, hence it decodes incorrectly. This of course does not affect "regular" resolutions like 1024 etc. which are multiples of four pixels wide, but does affect those which are not.

Were you able to open the 1018x576 v308 capture in any editing or playback software correctly? When you were using VDFM to do the capture, was the preview correct?

Yes weird indeed, but if you do open with MPC-HC for instance ,it does open normally. I thought first it was a virtualdub filtermod bug as they have had some bugs with specific formats. However if I do open with ffplayer  it does have the same problem apparently it does shows up with width´s that are not multiple of 4.However the workflow is the same capture card and virtualdub (filtermod or not) I only changed the target image size in the  capture pin .I also tried capturing with the standard virtualdub and the result is the same. No clues for now  

I tried also other  sizes , if they are multiple of four everything is ok if not they are skewed. ????

For me, MPC-HC doesn't open v308 at all. I assume the capture card installs the necessary DShow filters to "decode" (ie. convert to RGB for display) v308, and because it's making the capture as well, it's doing it correctly. Though graphstudionext would be needed to verify what kind of graph is built for playback.

Question: during capture, the preview is OK? If so, I assume that it's a different pin than the capture pin (preview pin), and that's probably RGB?

Anyway, this skewing is not weird at all, it can be expected. As I mentioned, v308 is a 3 byte per pixel format, so if your capture width is not a multiple of 4 you'll end up with a number of bytes per row which is also not a multiple of 4. For example a width of 1018 is 3054 bytes. Similarly to RGB24 (which is also a 3 byte per pixel format) under VFW it is expected of DIB formats rows to be padded to 4 byte boundaries, so the capture card pads to 3056 bytes with 2 bytes (which does not contain relevant data). However ffmpeg (which is used by VDFM to decode) doesn't expect this padding, so it treats those 2 bytes as data, hence the whole image gets skewed 2 bytes (ie. 2/3 pixels) with each row.

Obviously multiple of 4 widths are not affected, as those rows naturally end on 4 byte boundary sizes.

I'll try to ask the ffmpeg guys about it, can I share the clips you sent with them for testing? Could you provide the details of the capture: OS version, capture card brand and exact model, capture software name and exact version, etc.

Yes during capture, the preview is OK and Yes the card has three pins one for capture ,one for preview  and the last for cc  and I usually use rgb24 for the preview.

capture details

OS-  windows 7 professional with SP1

capture card- Magewell Pro capture HDMI

capture software- VirtualDubFilterMod(build 40640/release-AMD64) 

No problem you can share the clips, I forgot however to remove the sound to make them more compact .

Sorry my fault, the graph  was only to show the several pins. however at the preview pin I pressed render pin and it made this strange workflow .

OK, I got a bug report in the meantime from the VDFM dev which I had to fix first.

Now I'll be adding v308 support first, as that is the quickest and will make a private build for you to use/test. A dev from ffmpeg told v308 probably shouldn't have any 4 byte alignment/padding, but I'll make the codec to make an educated guess based on image size (given in bytes), so it should work in both cases. Though as it affects only non-4-pixel-width videos anyway, which isn't very common, it's gonna work either way.

Ok, no problem  I will wait for these special version.

Out of curiosity I tried to identify why MPC-HC is showing a v308 file and additional showing it correctly even with non-4-pixel-width videos. Using the context menu item in MPC-HC do shows the Directshow filters that are being used;  in this case for video only two , lav splitter source (internal) and madVR.

I have been able to also read the file without problems in graphstudionext using the lav splitter source and madVR. MadVR seems to be the only renderer that connects to the video pin all the other renders don’t connect to a pin with media subtype v308, 1118x576 . In a MPC-HC that doesn´t have madVR installed it doesn´t run v308 at all ,because it can not find a renderer that connects to the video pin. I tried also to connect to the functional playback from mpc-hc from graphstudionext  but I´m missing a proppage.dll file from windows sdk and I don’t want to install the windows sdk to avoid generate more problems in my pc that has already  to much .

I used also  DirectShowCaptureCapabilities utility to get detailed capture capabilities  of the magewell card and I´m including some references to v308.