[IVB/BYT/BSW] Macroblocking artifact seen on a VC1 video file

[seanvk]

migrated from Bugzilla #68492
status REOPENED severity major in component intel for ---
Reported in version unspecified on platform All
Assigned to: Focus.Luo

On 2013-08-23 23:01:04 +0000, wrote:

Macroblocking artifacts seen during playback of a WMV file with VC1 video using vaapi-decode. The macroblocks can be seen in the first 3-4 seconds of the clip. Also artifacts are more prominent around 02:31 timestamp in the playback.

Instructions to reproduce:

File:
http://download.microsoft.com/download/9/b/4/9b4535e2-f908-4785-97a5-ef360405e391/Elephant%27s%20Dream%20720p%202M.wmv

Playback command:
gst-launch-0.10 filesrc location=elephant_dream.wmv ! asfdemux ! vaapidecode ! queue ! vaapisink

Platform:
reproduced on Ivybridge 64-bit and Baytrail-M 32-bit with 13.10 Ubuntu and 3.11 kernel.

On 2013-08-23 23:03:05 +0000, wrote:

These macroblocking artifacts are not seen when playing the same file with software codec, or with windows media player on Windows.

On 2014-10-01 15:58:39 +0000, Kevin Mitchell wrote:

*** Bug 84552 has been marked as a duplicate of this bug. ***

On 2015-11-23 14:28:31 +0000, haihao wrote:

We fixed some VC1 related issues this year. Could you try the latest driver if you still experience this issue ?

On 2016-01-12 04:48:16 +0000, Kevin Mitchell wrote:

Problem persists unchanged for me with libva and intel-driver git master.

On 2016-02-05 20:04:27 +0000, wrote:

Gentlemen,

Seems like I'm having the same problem on ASRock Beebox Intel Celeron N3000. The file is coded VC-1, 1080p24. When I play the file with VAAPI enabled, I get the square artifacts on the screen. I experienced this problem with vaapi intel-driver 1.6.1 and 1.6.2. If VAAPI is disabled, the problem disappears, but the CPU load is too much.

You may get the file here: https://docs.google.com/uc?id=0B9X316MN6HHvSlNWb1ZhSGo2X2M&export=download (Second 3 till the end).

Reproduced on Braswell 64-bit, with OpenELEC 6.0.0, Linux Mint 17, kernel 4.3.3, vaapi intel-driver 1.6.1 and 1.6.2.

On 2016-12-07 02:50:26 +0000, haihao wrote:

Hi Focus,

Can you reproduce this issue on SKL or KBL?

Thanks
Haihao

[xhaihao]

Assign the bug Focus to check this issue on SKL+

[lqvnguyen]

I would like to see this long standing issue resolved. I can provide samples where the macro blocking artifacts are occurring with VC-1. Would like to see this issue resolved with Haswell, Braswell, Broadwell, and Skylake. Once I acquire an Apollo Lake and Kaby Lake NUC, I will test against those as well.

This is occurring with LibreELEC 8.0 Kernel 4.9.8 using Mesa 13.0.3, VAAPI Intel Driver 1.7.3

[ChuckPa]

I also would like this resolved. There are a lot of folks who are depending on this working cleanly, especially in Linux, so we can use the hardware directly and free up the processor to all the other things it needs to do.

[xhaihao]

@lqvnguyen, Please provide a sample, thanks

[lqvnguyen]

@xhaihao Samples provided here.

[LongChair]

I have to say that I also would like a fix for this.

[lqvnguyen]

@xhaihao Were you able to review the samples?

[lqvnguyen]

Updates?

[xhaihao]

@lqvnguyen Sorry for slow response. I can reproduce the issue with the samples you provided. We will look into the issue. but it is hard to say when we will fix the issue.

[DaveBinM]

I'd also like to have this resolved. This has been broken in linux for a long time, and I'd like to be able to use my CPU for things other than software decoding VC-1.

[lqvnguyen]

@xhaihao Now that you have reproduced it, do you have an idea of the root cause? This issue has plagued the Linux platform for years, yet functions properly under Windows. What can we do to get more support and traction on this issue?

[xhaihao]

@lqvnguyen Currently the root is unknown, we will check the pipeline setting for VC1 first.

[lqvnguyen]

This was just tested against the NUC7i3BNK. Same issue as all previous Intel CPU/iGPUs mentioned in my first post.

[lqvnguyen]

Additionally Windows has support for VC-1 1080i. Why is there no support for this under Linux? Do you need a new GHI for this?

[lqvnguyen]

Update please.

[DaveBinM]

Is there any update on this? I'm getting increasingly frustrated with needing to decode VC-1 in software.

[xhaihao]

@lqvnguyen @DaveBinM unfortunately, we still not root cause the issue.

[lqvnguyen]

Can we have the priority raised for this?

[DaveBinM]

I'd also like to see the priority of this increased, as it's an ongoing issue for me.

[DaveBinM]

Any chance someone could provide an update on this, please?

[lqvnguyen]

Bump

[cayars]

This is a problem for me as well as I can't migrate an app from Windows to my NAS or Linux machines where i need it to run due to this issue.

Is there an update or expected ETA on this? Can you tell us what progress is being made?

Thanks,
Carlo

[ChuckPa]

How about a big

BUMP

At this rate, I'll be old, retired, and won't give a rat's xxx before it makes progress.

[YuJiankang]

We did some analysis, checked all the input/output parameters and made many attempts, but unfortunately, we still can't root cause the issue.we will continue to work on this issue once some urgent tasks on hand are solved, Thanks a lot for your patience and understanding.

[lqvnguyen]

Update?

[carpalis]

Intel, please give this bug some more attention. I had a good look on a sample that shows the artifacts. The macroblock artifacts were only present in B-frames that referenced at least one P-frame that has Intensity Compensation (MVMODE='Intensity Compensation'). The source code already indicates a FIXME when using luma_scale. The artifacts may just be due to this FIXME and fixing/implementing Luma Scaling may just be solution.

*** UPDATE ***
The patch below solves the macroblocking issues for me on Haswell platform. I did not implement other platforms. The idea is to store the intensity compensation parameters on a P-frame and use them on subsequent B-frames.

vaapi-vc1.zip

Regards,
Jerome Borsboom

[lqvnguyen]

Jerome Borsboo--Thank you for contributing your knowledge. The community appreciates this.

[carpalis]

I have tried to implement a better integrated version of the patch for more platforms. Please build and try out the code at carpalis/intel-vaapi-driver.

[xhaihao]

@carpalis many thanks for the patch, I tried the patch on SKL and it works fine. Could you submit a PR?

[lqvnguyen]

@carpalis Thanks so much for this contribution!!! @xhaihao Are you looking to add this to the drivers for haswell and later generations?

[DaveBinM]

@carpalis Thank you so much for this contribution. I'm very glad to see this long standing issue resolved! 🙂

[carpalis]

As public documentation for SandyBridge graphics does not include the Command Reference, I could not implement the patch for SandyBridge platform. If someone from Intel could tell me which field in the MFX_VC1_PRED_PIPE_STATE command enables intensity scaling for the forward reference plane, I can implement the patch for SandyBridge. It should be either bit 0 or bit 2 in the last byte of the command.

[xhaihao]

It is bit2 @carpalis

[keithah]

@fritsch said he'll find the sample and report back, thanks!

[carpalis]

SNB is now also included in the patch set.