1201274 - Investigate waiting for video frames to resolve after seeking

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Matt Woodrow (:mattwoodrow)]

DXVA video frames aren't necessarily ready to use when they are returned from the decoder (and we've initiated the colour conversion copy).

Instead we use D3D9SurfaceImage::IsValid() to block up to 10ms on this finishing, and reports whether it was successful or not.

We have code in MDSM to detect the failure case, call NotifyCorruptFrame, and potentially disable DXVA if it happens too frequently. This is aimed at detecting bad video cards, and stopping us from using hardware decoding on them.

Seeking (including implicit seeks caused by a resolution switch with MSE) can cause us to decode a large number of frames (from the last sync point up to the seek point) instantaneously. We discard all of these frames, and then expect the ones we want to use to be ready within the original 10ms window. If this doesn't happen then we end up disabling DXVA on otherwise good hardware.

I think we want to treat seeking as a special case, and not include it in the corrupt frame statistics so that we avoid this fallback.

The right solution is probably to add a way to ask the Image to wait for a specified timeout rather than letting it pick. That way we can wait on the 'first' frame after a seek indefinitely (within reason) and remain paused until it resolves.

We'd need a way to MediaSourceReader to notify MDSM that a frame is a 'seek' frame when we switch resolutions so that MDSM knows to pause (or remain paused) and wait on that frame to be fully ready.

The other option would be to move the waiting code into the readers, and only return frames that are ready and valid.

For now I'm just increasing the threshold for fallback in bug 1198202, but doing better would be nice :)

Comment 1

[Jean-Yves Avenard [:jya]]

MediaSourceReader is no longer used..
Though the idea I guess remains the same.

Comment 2

[Jean-Yves Avenard [:jya]]

The MDSM already have all the information it needs to know if a frame is a seek frame or not, simply because it knows if a frame needs to be dropped or not.

Comment 3

[Matt Woodrow (:mattwoodrow)]

(In reply to [PTO Until 02/Sep] Jean-Yves Avenard [:jya] from comment #1)
> MediaSourceReader is no longer used..
> Though the idea I guess remains the same.

Right, sorry, still have the old names stuck in my head.

(In reply to [PTO Until 02/Sep] Jean-Yves Avenard [:jya] from comment #2)
> The MDSM already have all the information it needs to know if a frame is a
> seek frame or not, simply because it knows if a frame needs to be dropped or
> not.

That's a good point, we could make the wait duration a multiple of the number of frames we dropped.

Comment 4

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3