+Pawel +Rob

Raising priority to P0 as this is affecting customers in the field and is a regression over previous behavior.

Adding Marcheu@ and ihf@. marcheu@/ihf@, can either of you please take a look a this one?

Why again is this P0?
Why PNacl?
Is this Elm specific?

In general, to finish decoding process of the current picture, an H.264 decoder needs to reach an access unit boundary. The H.264 specification has more details, but in general, picture boundary can be a slice of the following picture, or a non-slice NALU, such as SPS, PPS, or AUD.

From your description it's not fully clear if you are using any of these mechanisms to trigger access unit boundary detection (such as the usually used for this AUDs)? If other platforms are handling the same case correctly however, it's possible that you are, and elm has an issue with this, so we should confirm that.

I'm not sure if this is a regression though, as elm is a relatively new platform. Do we have a version in which this worked on it before?

Yes, we are using AUD to trigger the access unit boundary. 

The issue happens only in this platform "elm" that too only for "I" frame. 

After decoding the first frame (either by pushing NAL by NAL till the access unit or by pushing complete stream till access unit) the GetPicture callback should have been called with the corresponding picture, in this case "I" frame.
But the "I" frame and the first "P" frame picture retrieved only after we push the second "P" frame to the decoder.
It happens only in this platform "elm". The other platforms (intel, tegra etc) works fine, the "I" frame picture retrieved after the decode done. 

It can be experienced with the attached sample app. 

I could reproduce the issue on elm. I filed https://code.google.com/p/chrome-os-partner/issues/detail?id=62318 on MediaTek.

FYI. I also tested on peach pit and veyron minnie. I had to push one more P frames to retrieve the picture. It's still one frame later than software decode. Software decode retrieves the picture when I push I frame.

Did you see AUDs being inserted? This could be verified by enabling H264Parser/H264Decoder logs on minnie for example.

wuchengli@ can you please comment on this? This is currently a blocking bug for Citrix and other virtual desktop solutions. Customers are seeing a black screen while launching desktops/apps.

The bug is in VPU firmware and needs MediaTek to investigate. This week is Lunar Chinese Year and people will be back tomorrow or next Monday. We pinged MediaTek in https://code.google.com/p/chrome-os-partner/issues/detail?id=62318. Let's see what they say.

Note this bug is on elm only. So all other Intel and ARM devices should be fine. Is this still a blocking bug? Usually Bug-Regression means it is working on a device and it is broken on a later release on the same device. I believe elm has this bug since FSI.

As said in comment #5, the issue happens only for "I" frame. As "Wechengli" mentioned, there is one frame delay in arm platform. To overcome that we can push an AUD frame to get the picture without delay. 
But in case of "elm" after "I" frame even if we push an "AUD" or another "P" frame there is no picture. We need to push "I" frame than "P" and followed by an another "P" or "AUD" to get the picture.
We decode and render picture frame by frame. since after first "I" there is no picture retrieval the app appears no response in "elm" platform. 

I just pinged MTK in the partner bug.

I checked the kernel log. V4L2_CID_MIN_BUFFERS_FOR_CAPTURE (dpb size) is 1.

Here's the chrome v4l2vda log when running the test.

Deleted: chrome.txt 24.8 KB

chrome.txt 24.8 KB View Download

Here's kernel log with debug messages enabled.

Deleted: messages.txt 34.3 KB

messages.txt 34.3 KB View Download

From the kernel log, VPU firmware didn't return an output buffer when the first P frame was pushed.

2017-02-20T11:52:19.356984+08:00 INFO kernel: [  230.465868] [MTK_V4L2] level=3 get_display_buffer(),112: [7]
2017-02-20T11:52:19.356987+08:00 INFO kernel: [  230.465873] [MTK_VCODEC][7]: vdec_h264_get_fb() [FB] there is no disp fb
2017-02-20T11:52:19.356990+08:00 INFO kernel: [  230.465877] [MTK_V4L2] level=3 get_display_buffer(),122: No display frame buffer

Re #15: So the problem should be in VPU firmware.

Here's the log of H264Decoder and H264Parser on minnie.

Deleted: h264_decoder.txt 14.7 KB

h264_decoder.txt 14.7 KB View Download

From the log, max_num_reorder_frames is 0 so decoder should output picture as soon as one is decoded.

As for how we could test this with a unittest, in my understanding of the spec, to allow output of the oldest picture by POC in DPB, all conditions below should be met:

1) the picture is decoded
2) the number of not displayed decoded pictures in DPB >= max_num_reorder_frames (which is either explicitly specified in the stream or has predefined values based on profile, etc.)
3) we have reached the output time as defined per spec in C.2.2

To simplify, I think if we'd like to test one frame output in this case, we'd probably need to provide SPS + PPS + all frame slices + AUD to achieve 1), and specify max_num_reorder_frames=0 in the stream, and verify the decoder returns the frame until time 3), which we could set as a timeout on the current expected fps?

I'm removing videoshortlist because this looks like a P2 to me.

This needs MTK to fix and they are not responding.

If we can't come up with a fix, we should disable hw H264 decode on MTK, that would solve the problem.

This is fixed in 9775.0.0.
https://chromium-review.googlesource.com/c/572476
https://chromium-review.googlesource.com/c/573700
https://chrome-internal-review.googlesource.com/c/412550