I've run across a condition where EncodeFrameAsync starts returning MFX_WRN_DEVICE_BUSY and it never gets unbusy. In my app (based on the multi transcode sample) this ends up creating an endless loop in EncodeOneFrame(...).
I can reproduce consistently when transcoding "29.97" soft telecined content while changing the framerate to 59.97. It works fine when converting interlaced 29.97 to 59.97 progressive.
Is this a driver issue or something that I'm missing?
Thanks for sharing your findings. As far as I know this is not a known issue.
Can you please share your complete configuration. You can fetch this using the Media SDK tracer tool.
Please also share your machine config, e.g. CPU part, driver version etc.
Thanks for sharing your workload configuration. I just ran a transcode workload with the same configuration here locally and I do not see any issues.
Can you please share what platform you are using and the graphics driver version.
Also, do you see the issue immediately or does it occur after a specific number of frames have been processed?
I'm trying to reproduce on similar system with same drivers, and so far I have not seen an issue. Not sure if there may be something different about the content you have?
Can you provide the options you are using for your application and/or any changes you have made (or do you see the issue w/ unmodified sample_multi_transcode appcliatons?).
It may also be helpful to use the mfx_tracer tool application to capture a log of what parameters are actually getting sent to Media SK API? (Please let me know if you need help using tool).
Thanks. I ran the tracer before (output is a couple posts up), do you need it done differently? I can reproduce on another HSW system so I don't think it's specific to my development machine. The full source code for my application is available on sourceforge, and the binary can be downloaded from there as well. If you run it on a soft telecined VOB where the framerate is detected at 29.97 it will try to create an output file based on the rendered framerate (59.97). When running in dx11 mode (default on w8+ machines) it exhibits this issue. If you force it to run in dx9 mode (via the -hw switch) it works correctly.
The binary includes a simple GUI that can be used to generate a cmd line, if you select a VOB file that matches this criteria and don't change anything else it will create the cmd line that you need (I did that on the HSW system mentioned earlier with the binary on sourceforge). You cannot reproduce with the OOTB sample_transcode because it does not support positive FRC.