The testcase is too big to be uploaded in bugzilla.
You can download it at this url:

http://pan.baidu.com/s/1kTsjBoF

Which version of libva/libva-intel-driver is used in the testing?

Thanks.
   Yakui

The version is 2013,Q4 release on 01.org. Thanks. --Clear

Hi, Long/Clear

    Thanks for the version info. 
    I download the test case. But it fails in building.
    Will you please double check the test case so that we can run the test case?

Thanks.
   Yakui

Just update here, ykzhao/Yakui can build the test program successfully. Thanks. --Clear

I download the test case and can build it. 
Yes. The issue of GPU hang can be reproduced after running the test case.
But after some analysis I don't think that this is the driver issue. Instead it is caused by the wrong usage scenario.

From the test case I get the following info:
   1. Three videos are decoded.
   2. But only one decode context is created to decode the three video streams.

This is not correct usage scenario as the driver needs to keep some info required by the hardware during decoding. When it switches the different video stream in one context, the hardware info will be lost/mixed and trigger some unexpected behaviour.

The better solution is that one decode context is created for each video stream.

Will you please let the customer create one decode context for every decoded video stream and see whether the issue still can be reproduced?

Thanks.
     Yakui

Put information in mail here.

Hi Yakui,

There is stream switch in demo application and only one stream is decoding at the same time. Stream will be switched per 50 frames. When swith, va-context will be destroied and created again,  just the va-context value is same according to log informatoin. So every stream has its own context. 

Thanks,
Clear 

"GPU hung 问题，demo中有码流的切换，每次只有1路解码，没50帧切换码流，切换码流时会切换va-context 
每次destroy 再 create之后，打印出的va-context是同一值

三段不同码流在每次切换时context都会销毁后重新创建，使用层面看不出有什么问题。但通过买文豪gdb查到的信息，每次重新创建后的context id与前次相同，这可能是导致yakui.zhao以为三段视频均使用同一id的原因。综上所述，该bug更像是libva库本身实现的问题。"

Away for two days at conference.  Expect delays in response.

(In reply to comment #7)
> Put information in mail here.
> 
> Hi Yakui,
> 
> There is stream switch in demo application and only one stream is decoding
> at the same time. Stream will be switched per 50 frames. When swith,
> va-context will be destroied and created again,

This is the wrong usage of libva. The APP should only create a VA context for each stream,  and the life cycle of the VA context should be from the first frame to the last frame.

(In reply to comment #9)
> (In reply to comment #7)
> Put information in mail here.
> 
> Hi Yakui,
> 
>
> There is stream switch in demo application and only one stream is decoding
>
> at the same time. Stream will be switched per 50 frames. When swith,
>
> va-context will be destroied and created again,

This is the wrong usage of
> libva. The APP should only create a VA context for each stream,  and the
> life cycle of the VA context should be from the first frame to the last
> frame.

By "stream", the customer means a network stream contains serveral video clips.
The usages looks good to me, they create one VA context for one clip and then destory this context and create another VA context for next video clip in the same network stream.

The first frame will be always IDR. Haihao think it's reasonable usage so far. Haihao/yakui will look into more and response later. Thanks. --Clear

Hi, Clear/Long

    Will you please double check whether the usage scenario of test case is the same as what the customer debug? Or it is not the latest test case?
    
    I capture the trace log in my test and find that the vaCreateContext is called only once. This means that the three video streams are still sharing the same context. It is different with the usage described in comment #10/11.

Thanks.

Hi, Long/Clear
    Does the issue still exist after the customer updates the usage model?

Thanks.
    Yakui

Hi Yakui,

Yes, it's solved. Thanks!

Thanks,
Clear