- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1280x720 NV12 format video captured from HDMI capture card is send to H264 encoder. If we set encoding size not 1280x720 (such as 960x540), After Continue encoding 429484 frames, GraphEdit prompts "The Graph cound not chang state".
We use tracer and get 300MB log file. Attache is part of log file (Start log, middle-time log, around 429484 frame log). Please help.
BTW, we modify H264 encoder to support ICQ (RateControlMethod=UNKNOWN(9) ).
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We found:
If no resize used in H264 encoder, the encoder can work for a long time.
If resize used, the encoder can only encoding about 429484 (429480~429484) frames then failed.
We try other ratecontrol (AVBR), same bug appeared.
This troubles us for one month.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In above picture, I compare MSDK log with/withou resize.
In the left, no resize used, the encoder can continue work forever (working for many days).
In the right, 1280x720 resize to 960x540(we also try other size), the encoder continue work only 429484 frames( for 30Hz framerate,only 3.97 hours) then failed.
We wonder if resize bug cause encoder failed?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I use msdk orignal H264 encoder, same bug apperaed at 429484 frames.
My CPU is i3 4330 (CPU G1880 has same bug), Win7 32bit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I compare the encoder process of frame 429484 with other frame (from analyzer(my)_1.log). If red color notes can provide some hints?
MFX_ERR_ABORTED:The specified asynchronous function aborted due to data dependency on a previous asynchronous function that did not complete.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We modify avshws.dll (Source filter) to let it output 320x240@167Hz (No HDMI capture hardware need).
To install the Avshws, run the following command at CMD:(Please change E:\ to the actual path where the folder is)
"E:\devcon.exe install E:\avshws.inf AVSHWS"
The Operating System is Win7 32bit.
Use graph as follow. Setting encoder size to 1280x720. After run graph about 45 minuts, frame 429484 reached. Then graph stopped and MFX_ERR_ABORTED appeared in analyzer file.
We try this graph at two machines and got same results. One machine is G1880 the other is I5 3570K, both WIN 7 32bit.
Waiting Intel's debug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By using above graph, we do more tests under intel Core CPU. The results are:
G1880(haswell) failed at frame 429484
I3 4330(haswell) failed at frame 429484
I5 3570K(IVY) falied at frame 429484
I3 2310(Sandy) OK
What can we do next ?
Wish intel engineers try and debug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The sample DirectShow filters are not intended to be used for 'production' applications and may contain incomplete implementations for some usage cases, however we will certainly looking this finding further.
Can you provide information on the specific graphics driver being used on the failing systems? (Can you send the output of the "mediasdk_sys_analyzer" tool that is in the <install dir>\tools\mediasdk_sys_analyzer director of the "Media SDK 2014 for Clients"?)
On the newer platforms, the "VPP" resize operation is performed differently than on the older Intel(r) 2nd Generation Core processor. While the drivers themselves have been tested extensively, it is still unclear if the issue you are seeing is (only) an issue with the DirectShow sample filter usage of VPP, or if it is something in the drivers themselves. We are working to reproduce your findings. Thank you for your patience.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Tony for your care.
The failling system driver is 2014/3/11 version 10.18.10.3496
Attachment is analyzer log file. For file size reduced, I only recode the parts arround frame 429484.
I compare frame 429484 with other frame and found the differ (red color notes in floor #7).
BTW, avshws(souce filter) is designed to produce 320x240 color bar. After encoder & decode, render display varies with CPU. That is:
For sandy CPU, render display color bar(It's OK)
For ivy&haswell CPU, render display green screen(Should be color bar)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good news:
We update HD graphics driver to version 10.18.10.3621. By using above graph, it continues to work more than 2 hours (far exceed 429484 frames).
We will do more tests and report the results.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After one week test, I am sure that resize bug is fixed under new driver 10.18.10.3621.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page