MediaTranscoding sample fails when target is 2160p60

I wanted to cross-post this issue here because I think the problem is Media Foundation related.

https://github.com/microsoft/Windows-universal-samples/issues/1200

The MediaTranscoding sample shows a red "unknown failure" error when I try to transcode to UHD 2160p60 on an Intel machine without Quick Sync Video and with an Nvidia GPU. UHD 2160p60 transcoding succeeds on Intel hardware with Quick Sync Video.

Repro steps:

1. Build the MediaTranscoding sample (I built the C# version).
2. Run the sample on a machine with an Intel CPU without Quick Sync Video. I used a Core i7-5960X with an Nvidia GeForce GTX 980 Ti.
3. Select scenario #2 (Transcode with custom settings).
4. Select any source video file.
5. Enter Width=3840, Height=2160, Frame Rate=60
6. Select an output file.
7. Click the Transcode button.

You'll get a red "unknown failure" error.

If you change the target frame rate from 60 to 30, this scenario will succeed.

If you run this scenario on a Surface Pro it will succeed at both 60 and 30 frames per second. I used a Surface Pro LTE from mid 2018 that has an Intel Core i5-7300U with Quick Sync Video. I've also tried several other Intel processors with Quick Sync Video and they also work.

Perhaps this is some kind of platform bug. Or perhaps it's some kind of Intel and/or Nvidia driver bug. For what it's worth, I installed the latest driver from Nvidia (445.87). I am running Windows 10.0.18363.815.

I captured a trace with WPR and it showed one thing that might be a clue:

EventName: Microsoft-Windows-Runtime-Media/WinRTTranscode_PrepareTranscode_Task/Stop
Payload: ErrorCode="-1,072,861,856" FormattedMessage="PrepareTranscode operation 0x29ed6283fe0{Object} ended. -1,072,861,856{ErrorCode} "

That error code happens to be MF_E_TRANSFORM_TYPE_NOT_SET. The Media Foundation doc page for the H.264 encoder says this:

The output type must be set before the input type. Until the output type is set, the encoder's IMFTransform::SetInputType method returns MF_E_TRANSFORM_TYPE_NOT_SET.

So maybe there's a bug in how the OS sets up the graph when transcoding to 59.94 fps.