MagicYUV - a new fast lossless video codec

[poisondeathray]

You should definitely test end to end what kind of results you are getting. For 10bit tests, using a gradient makes it easy to see the problem

I usually start on the ends (input and final output), and if something is wrong, work towards the middle tracing each step to find out where something went wrong. For some software / host applications there is no solution except to use their "preferred" uncompressed format (for some applications, they do not handle huffyuv, lagarith, ut video , magic yuv , etc... as lossless YUV ,or at the correct bit depth). That' s not really the codec developers fault IMO

I prefer the FourCC that was used ...

Maybe you missed, it but the point of my earlier "offtopic" statement was that some software handle certain fourcc's better than others. I would argue it matters less what you prefer - I would argue you should use what works better in that specific workflow or software title. In windows software , for YUV 4:2:2, UYVY is almost always the "preferred" format . YUY2 almost always gets converted to RGB internally. Similarly for 4:2:0 , IYUV (and sometimes I420) is usually the preferred format . YV12 almost always gets converted to RGB internally

[Ignus2]

I now have just a very little time to answer, but I write as the discussion begins to touch on too many subjects concerning various codecs and YUV formats in ingest systems, which does not directly concern codec development, but rather workflow and system setup, so I think it is getting slightly offtopic.

May I suggest to start a new thread in some other category on doom9 and continue the discussion there? That way maybe more people would be able to provide feedback as well!

I also would very much like to reflect upon the recent posts, but unfortunately I cannot do that now, as I'm not at home for a few weeks.

Thanks!

Greets,
I.

[easy2Bcheesy]

Hi,

Just bought a Blackmagic Intensity 4K for capturing PS4, Xbox One etc at 1080p60.

Annoyingly the only way to get a picture via DirectShow is using the r210 colourspace - which does not seem to be supported by any codec! Would it be possible to incorporate downsampling support for r210 into MagicYUV?

[raffriff42]

Originally Posted by easy2Bcheesy

r210 colourspace - which does not seem to be supported by any codec!

ffmpeg supports it -

C:\ffmpeg\bin>ffmpeg -codecs | find "r210"
ffmpeg version N-70664-ga47c2a1 Copyright (c) 2000-2015 the FFmpeg developers
[...]
 DEVI.S r210                 Uncompressed RGB 10-bit

C:\ffmpeg\bin>

(and therefore probably ffmpegsource for avisynth & ffmpeg input for virtualdub)

[easy2Bcheesy]

Would that work for real-time capture though?

[ChiDragon]

Originally Posted by easy2Bcheesy

Annoyingly the only way to get a picture via DirectShow is using the r210 colourspace

Sadly, a quote from Blackmagic support indicates that lack of any RGB -> YUV conversion is a deliberate part of the architecture, so it seems they will never support it. Sure would be nice if they added a note somewhere in the specs that they removed a popular feature (available with nearly every other HDMI capture device) as part of this "upgrade" from the Intensity Pro.

If you are capturing from HDMI, please note that the behaviour of the Intensity Pro 4K is a bit different to the Intensity Pro.
DeckLink 4K devices (which include the Intensity Pro 4K) require an application to explicitly set the pixel format for capture over HDMI that matches the video source. If you specified YUV for capture and the feed was RGB, the older Intensity Pro would automatically convert the pixel format.
However the Intensity Pro 4K does not. So if you have a RGB HDMI video source, you need to set capture for RGB (bmdFormat10BitRGB) with the Intensity Pro 4K, however you can get away with selecting 8-bit YUV (bmdFormat8BitYUV) or 10-bit YUV (bmdFormat10BitYUV) with the Intensity Pro.

The ridiculous thing about this is that the card actually does support conversion from RGB HDMI sources if the resolution is 480p/i! Probably 576p/i too though I haven't tested. Media Express lets you select every format with no problem when resolution is "NTSC", while the DirectShow interface actually forces you to capture "NTSC RGB" in YUV as there is no driver support for RGB capture at NTSC size.

However, there is good news. I discovered yesterday that the v10.4.1 driver/firmware update added support for "A RGB32" if you use the "Blackmagic WDM Capture" interface instead of "Decklink Video Capture" -- so thank goodness, we no longer have to use 10-bit RGB to capture 8-bit RGB sources... (v10.4.2 was released on Tuesday but I haven't tried it yet.)

It's still a bit of a pain in the ass to get the RGB32 capture working in VirtualDub. The Capture Pin for this driver version has a bug where the Frame Rate for HDYC, A RGB32, and r210 reverts to 25.000 no matter what you pick. The workaround is this:

1. Video -> Capture filter.
2. Video Format -> Override Video Mode.
3. Manually set Display Mode to the exact resolution/frame rate and Pixel Format to "8 bit BGRA".
4. Video -> Capture Pin.
5. Manually type in the exact frame rate and hit Apply or OK.
6. At this point, for me there is no often no image at all. Toggle from Video -> Overlay to Video -> Preview or vice-versa to restore the image.
7. Now you can set to Overlay or Preview mode, whichever you prefer, and capture with any codec that supports RGB32, including those that convert to YUV.
8. The overridden Video Mode is not saved, but all other settings are. When you close and reopen VirtualDub's capture mode, you will need to manually change the settings in Capture filter again, but you should then immediately get the image without any more steps.

I'm still trying to figure out which lossless codec and Disk I/O buffer settings might actually allow me to capture to my regular 5400RPM 4TB SATA drive without dropped frames when there are complex scenes.

[easy2Bcheesy]

Lossless 4:2:2 can hit a max (in my experience) 140MB/s, which may well be beyond your 5400rpm drive.

I am on Blackmagic 10.4.2 and alas I don't see any Blackmagic WDM capture interface in either VirtualDub or (my preferred tool), AmaRecTV.

I'm on Windows 8.1 if that makes any difference.

EDIT: 10.4.1 has the correct filter - giving it a go!

EDIT 2: Okay, so it works in VirtualDub, which is OK. I don't have to change the capture FPS either, it defaults to 59.94. However, turning on real-time audio preview kills the video preview in all modes. I don't suppose you could take a look at AmaRecTV?

[ChiDragon]

I seem to be averaging only 77MB/sec when capturing RGB -> lossless 4:2:2 but still getting random frame drops. Lossless RGB is more in the 90-100 range and giving me more "consistent" drops. The drive has been benchmarked with a min write speed of 83.2 and average 122 (it's actually 5900RPM, not that it makes a difference). It could understand if it was suddenly dropping off because it was hitting the far edge of the disk, but it's the random nature that confuses me.

AmaRecTV showed all the various pixel types so it seemed like it would be easier, but when I tried to capture it just failed with some error message. I didn't bother to troubleshoot.

They really removed it with 10.4.2? Ridiculous. That's like how RGB capture was broken completely with 10.4 after working okay with 10.3.7. Glad I didn't hop on the update bandwagon or I would have missed seeing this feature entirely.

Originally Posted by easy2Bcheesy

EDIT 2: Okay, so it works in VirtualDub, which is OK. I don't have to change the capture FPS either, it defaults to 59.94. However, turning on real-time audio preview kills the video preview in all modes.

Hmm, there is no difference for me when I "Enable audio playback" (they both display with a very poor frame rate for me when fed 1080p). Audio is set to "Capture device" and the format is 16-bit stereo. I'm way back at VirtualDub v1.9.10 but I doubt that gives me any advantage.

[Bloax]

Originally Posted by ChiDragon

IThe drive has been benchmarked with a min write speed of 83.2 and average 122 (it's actually 5900RPM, not that it makes a difference). I could understand if it was suddenly dropping off because it was hitting the far edge of the disk, but it's the random nature that confuses me.

The random nature is likely explained by the framedrops occuring when you hit a slow sector on the drive.
And yes, sectors are not equal on a drive - especially later in their life.

You can take a look at it by running a "read" surface test using HDDScan.

[benwaggoner]

This is definitely a job for RAID.

[kolak]

Originally Posted by easy2Bcheesy

Hi,

Just bought a Blackmagic Intensity 4K for capturing PS4, Xbox One etc at 1080p60.

Annoyingly the only way to get a picture via DirectShow is using the r210 colourspace - which does not seem to be supported by any codec! Would it be possible to incorporate downsampling support for r210 into MagicYUV?

Magicyuv has native support for r210 pixel format (and also AJA's R10k which is almost the same), but not in public/free version. This is one of the pro features which I convinced Ignus2 to implement.

You could try to force BM to output RGB 8bit instead of 10bit.

[ChiDragon]

Originally Posted by Ignus2

There is no need to read the docs, as I can read the source code as well. What I have said is:
"If there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not."
Which is verifiable by reading the HuffYUV sources. HuffYUV does no blending of fields whatsoever if you give it YUY2 and ask YUY2 back. It will give you back the same result if you encode and decode in the same colorspace whether interlaced encoding is turned on or not.

Going back a bit in the thread, but it occurred to me that since [the non-libavcodec versions of] Huffyuv only operate with YUY2 and RGB (no YV12), the presence of interlacing shouldn't even affect colorspace conversion for them.

[easy2Bcheesy]

Originally Posted by kolak

Magicyuv has native support for r210 pixel format (and also AJA's R10k which is almost the same), but not in public/free version. This is one of the pro features which I convinced Ignus2 to implement.

You could try to force BM to output RGB 8bit instead of 10bit.

Does the pro version offer the ability to process r210 input but capture in RGB24, YUY2 or YV12? The BM device is literally padding those two extra bits per channel as the consoles don't output 10-bit RGB.

ChiDragon's technique for forcing 8-bit RGB works, but it is not ideal.

[kolak]

No, there is no 10<->8bit conversion and this is done sort of on purpose. Decoder will decode r210 back to r210 or rbg64a/rgb48, so only to "better" pixel formats.

[pandy]

Originally Posted by raffriff42

ffmpeg supports it -

C:\ffmpeg\bin>ffmpeg -codecs | find "r210"
ffmpeg version N-70664-ga47c2a1 Copyright (c) 2000-2015 the FFmpeg developers
[...]
 DEVI.S r210                 Uncompressed RGB 10-bit

C:\ffmpeg\bin>

(and therefore probably ffmpegsource for avisynth & ffmpeg input for virtualdub)

And FFV1 can be used instead MagicYUV also ffmpeg can provide conversion from 10 to 8 bits (with dithering?) - so why not try to capture with ffmpeg ?

I've try few times and it works (capture)...

[ChiDragon]

FFV1 is much, much too slow for 1080p60 in realtime.

[kolak]

But new huffyuv in ffmpeg not

[ChiDragon]

It only converts to YUY2/YV12, not RGB. :\

[kolak]

Ffmpeg version supports up to 12bit RGB and with -vf pix_fmt you can convert between maaany pixel formats.
You probably talking about 'old' huffyuv in ffmpeg, not new one- 'ffvhuff'.

[ChiDragon]

[Sorry for all the OT, Ignus2.] How can you use that with VirtualDub or another capture app? The newest ffdshow-tryouts version that I found only offers those two formats for "FFVH".