Macroblocking artifact seen on a VC1 video file

[DaveBinM]

I'm seeing a very similar issue to intel/intel-vaapi-driver#13 in this driver as well, which I was able to replicate using the file linked here: https://docs.google.com/uc?id=0B9X316MN6HHvSlNWb1ZhSGo2X2M&export=download

This is on Ubuntu 18.04.3 (kernel 5.0.0-31-generic), with intel-media-driver/19.2.1 and a Kaby Lake G processor (https://ark.intel.com/content/www/us/en/ark/products/130411/intel-core-i7-8705g-processor-with-radeon-rx-vega-m-gl-graphics-8m-cache-up-to-4-10-ghz.html). @carpalis was able to resolve this last time.

[XinfengZhang]

@Tianhaol could you help to check it?

[DaveBinM]

Just following up on this one to see if there's any further news on this one?

[thorsteneb]

Confirmed that this issue is (still) present in 20.1.1 .

[DaveBinM]

@carpalis, I'm sorry to ask, but is there any chance the work here is similar to what you did to resolve intel/intel-vaapi-driver#13? 🙂 🤞

[mgutt]

Any updates? I saw the recent label "P3" means "no customer usage". I don't know what a "customer" means for intel, but there are hundreds of posts similar to this in other communities:
https://forums.plex.tv/t/movies-with-vc-1-vc1-codec-badly-pixelated-flashing/708200

[lqvnguyen]

Any chance this issue can be given some development cycles?

[XinfengZhang]

sorry for late response, @guowillyy could you help to check whether the patch intel/intel-vaapi-driver#234 is applicable for media-driver, from the discussion, similar issue already been fixed in intel-vaapi-driver repo by the PR

[lqvnguyen]

Please do what you can as this is a showstopper, pun intended, for all users of Comet Lake and newer.

[XuanJessica]

Hi @DaveBinM , the file link is out of date (https://docs.google.com/uc?id=0B9X316MN6HHvSlNWb1ZhSGo2X2M&export=download), could you please help to provide a valid file link that can replicate this issue? Thanks a lot.

[lqvnguyen]

@XuanJessica Several samples provided here for the VC-1 decoder failures

https://drive.google.com/drive/folders/1PJ0Gjs1mdJB01bxlhi6PmnMvzk8yFOmD

[XuanJessica]

Thanks @lqvnguyen , copy that.

[lqvnguyen]

Thanks @lqvnguyen , copy that.

Any progress?

[XuanJessica]

Thanks @lqvnguyen , copy that.

Any progress?

Hi, we are checking priority, WIP.

[Jexu]

Just check the '(1)-123.mkv' in provided bitstream.

I guess the artifact is not related to intel/intel-vaapi-driver#13 since the bitstream look more like an invalid stream. In this bitstream, first 4 decoded frame are I, B, B, P frame, as we known, B frame should have both forward and backward reference, so the bitstream should send I, P, B, B in decode order to umd at least.
So, you can simply modify the app behavior to skip decoding B frame if it doesn't have forward or backward reference, this is what ffmpeg doing at moment. You can have a try.

[Jexu]

Close this issue now, feel free to re-open it again if having any concerns or otherr issues.

[DaveBinM]

@Jexu Which release of the driver should we expect to see the fix in?

[mgutt]

@Jexu Which release of the driver should we expect to see the fix in?

He says, that it can't be fixed, because the source file is corrupt. I think this could be the root cause in Plex as well, as Plex splits the source file into evenly sized clips, before transcoding them. By that the main key frame could be randomly gone lost as it is part of the previous clip. So Plex should not split the clips in size/length, instead they need to respect the key frame order/position.

That is for example the reason why MKVToolnix does not respect the expect millisecond splitting video files. It inspects at first the key frame:
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/1628

[lqvnguyen]

Except PMS handles this just fine if using Nvidia or software decode.

[ChuckPa]

To remove segmentation from the argument, I allowed FFMPEG to transcode the entire file.

Input -> Output.

Run #1 - uses the default intel-media-driver with QSV

Observe the macro blocking at 1:52

Run #2 - Select i965 driver (export LIBVA_DRIVER_NAME=i965)

Observe no macroblocking at same 1:52 timestamp of same input file.

This is exactly the same failure we saw before Carpalis fixed it.

[lqvnguyen]

@Jexu Root cause is with iHD. Please reopen and continue investigating. If you need more samples, they will be provided.

[Jexu]

I just check first several frames before, except the invalid B frame decoding, it does have similar issue of intensity compensation.

Feel free to try above patch, let me know if it helps for your issue. Locally worked.

[ChuckPa]

@Jexu

I have not yet checked it, but should you wish it, here are the first 4 minutes of the video where the above screenshots were taken from.

Please feel free to use it for your testing. I will provide anything else if needed.

Intel-VC1-Input-sample.mkv

[Jexu]

Do you try above fix, if no other issues, I will get the PR merged and close this issue.

[ChuckPa]

@Jexu

I see no other issues at this time.
Please feel free to PR and merge

[Jexu]

I will get the PR merged and close the issue now.