[FernetMenta]

This is something you want to include in your environment: https://github.com/FernetMenta/xbmc/comm...38a81543b5

It drains decoder on stream change. Note than DXVA has not implemented this yet.

[peak3d]

Thanx for your quick answers, I really appreciate it.

I added the DTS/PTS values from m_Picture in VideoPlayerVideo:rocessDecoderOutput() directly after GetPicture() and as you said the PTS are ordered.

But: I don't see the reason of:

>CalcDropRequirement - dropped in decoder, Sleeptime: -19.212250, Bufferlevel: 2, Gain: 0.043417
and (most important)
> CalcDropRequirement - dropped in decoder, Sleeptime: 0.137959, Bufferlevel: 2, Gain: 0.043417 (this leads to the freeze)

I have still the feeling that there is some other (simpler) reason for the freeze than the lack of unbuffered decoder output.

Code:

8:15:31:0482 T:10364   DEBUG: CVideoPlayerVideo::Flipping: 19978291.333333
08:15:31:0487 T:10364   DEBUG: DXVA::CDecoder::~CDecoder - destructing decoder, 10BA5AD8
08:15:31:0492 T:10364   DEBUG: DXVA::CSurfaceContext::~CSurfaceContext - destructing surface context
08:15:31:0494 T:10364  NOTICE: DXVA::CDecoder::Close - closing decoder
08:15:31:0496 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20020000.000000 - 20103416.666667 - 2
08:15:31:0497 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20061708.333333 - 20270250.000000 - 6
08:15:31:0498 T:10364   DEBUG: CVideoPlayerVideo::GetPicture 20061708.333333 - 20061708.000000
08:15:31:0499 T:10364   DEBUG: CRenderManager::Configure - change configuration. 512x288. display: 512x288. framerate: 0.00. format: DXVA
08:15:31:0500 T:10364 WARNING: CRenderManager::Configure - wait for unfinished start
08:15:31:0518 T:10364 WARNING: CRenderManager::Configure - wait for unfinished end
08:15:31:0520 T:20012   DEBUG: CRenderManager::DeleteRenderer - deleting renderer
08:15:31:0523 T:20012   DEBUG: CWinRenderer::SelectRenderMethod: Requested render method: 4
08:15:31:0524 T:20012   DEBUG: CWinShader::LoadEffect - loading shader special://xbmc/system/shaders/testshader.fx
08:15:31:0532 T:20012   DEBUG: CWinRenderer::SelectRenderMethod: Selected render method 1: Pixel Shaders
08:15:31:0535 T:20012   DEBUG: created video buffer 0
08:15:31:0538 T:20012   DEBUG: created video buffer 1
08:15:31:0540 T:20012   DEBUG: created video buffer 2
08:15:31:0541 T:20012   DEBUG: created video buffer 3
08:15:31:0542 T:20012   DEBUG: CRenderManager::Configure - 3
08:15:31:0551 T:10364   DEBUG: CPullupCorrection: pattern lost on diff 83417.000000, number of losses 1
08:15:31:0553 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
08:15:31:0556 T:10364   DEBUG: Previous line repeats 1 times.
08:15:31:0558 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20103416.666667 - 20186833.333333 - 6
08:15:31:0560 T:10364   DEBUG: CVideoPlayerVideo::GetPicture 20103416.666667 - 20103416.000000
08:15:31:0561 T:20012   DEBUG: CWinShader::LoadEffect - loading shader special://xbmc/system/shaders/yuv2rgb_d3d.fx
08:15:31:0564 T:10364   DEBUG: CVideoPlayerVideo::Flipping: 20103416.000000
08:15:31:0566 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
08:15:31:0567 T:10364   DEBUG: Previous line repeats 1 times.
08:15:31:0568 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20145125.000000 - 20145125.000000 - 2
08:15:31:0569 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
08:15:31:0570 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20186833.333333 - 20228541.666667 - 2
08:15:31:0571 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
08:15:31:0573 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20228541.666667 - 20437083.333333 - 6
08:15:31:0574 T:10364   DEBUG: CVideoPlayerVideo::GetPicture 20228541.666667 - 20186833.000000
08:15:31:0577 T:10364   DEBUG: CVideoPlayerVideo::Flipping: 20186833.000000
08:15:31:0578 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: -19.212250, Bufferlevel: 2, Gain: 0.043417
08:15:31:0580 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20270250.000000 - 20353666.666667 - 6
08:15:31:0581 T:10364   DEBUG: CVideoPlayerVideo::GetPicture 20270250.000000 - 20270250.000000
08:15:31:0622 T:10364   DEBUG: CVideoPlayerVideo::Flipping: 20270250.000000
08:15:31:0623 T:10364   DEBUG: CVideoPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: 0.137959, Bufferlevel: 2, Gain: 0.043417
08:15:31:0624 T:10364   DEBUG: CVideoPlayerVideo::Decoding 20311958.333333 - 20311958.333333 - 6
08:15:31:0625 T:10364   DEBUG: CVideoPlayerVideo::GetPicture 20311958.333333 - 20311958.000000
08:15:31:0763 T:10364   DEBUG: CVideoPlayerVideo::Flipping: 20311958.000000

Edit: I think it was because I have resetted the pullupCorrection in OpenStream() when stream changes - I disabled this and now it looks much better.
Edit2: The CalcDropRequirement messages are gone but the freeze is still present :-(

[FernetMenta]

as already mentioned a couple of times. you won't get the last frames out of dxva decoder unless to implement drain for it. what you are currently doing is to kill a couple of frames with destruction of dxva decoder.

[peak3d]

I still don't see any problem on decoder side: Refering to the log above there is only one frame lost between old and new stream:

Last old frame: Flipping: 19978291.333333
First new frame : GetPicture 20061708.333333 - 20061708.000000


Afterwards the decoder puts out all new frames on time, but then the 5-th decoded image of the new frame waits 0.14 secs to be inserted into the Renderer.

08:15:31:0625 T:10364 DEBUG: CVideoPlayerVideo::GetPicture 20311958.333333 - 20311958.000000
08:15:31:0763 T:10364 DEBUG: CVideoPlayerVideo::Flipping: 20311958.000000

But somehow I have the feeling that I haven't understood something basic on this topic, really sorry for annoying you!

[FernetMenta]

I still don't see any problem on decoder side: Refering to the log above there is only one frame lost between old and new stream:

If you ignore the little things, you'll never get it right. Why don't you try with dxva disabled?

[peak3d]

DXVA is not used on Render side as all - it is Pixel-Shader (CopyFromDXVA is used in Renderer).
I use DXVA for decoding because it seems to works fine.

Disabling DXVA Decoder (no DXVA anymore at all) leads to the same problem, only with a longer freeze:

10:41:47:0765 T:3080 DEBUG: CVideoPlayerVideo::GetPicture 20603916.666667 - 20228541.000000
10:41:47:0999 T:3080 DEBUG: CVideoPlayerVideo::Flipping: 20228541.000000

[FernetMenta]

I was always referring to DXVA _decoder_. Believe it or not, it is not able to drain. Did you apply my patch for draining on stream change? Further DXVA in combination with pixel shaders is a bad idea because copying from dxva surface to the buffers used by pixel shaders does not perform well.

[FernetMenta]

here is another one you want to add: https://github.com/FernetMenta/xbmc/comm...dbed59e3d3

[FernetMenta]

next you need to request the render thread for an extra cycle doing Configure without calling Flip on gfx context. be aware that the render thread waits in FrameWait. it needs to break the waiting and do the configure.

[peak3d]

sorry, just yet read,

I finally got the place of the gap: its:

void CRenderManager::WaitPresentTime(double presenttime)
.....

if(fps <= 0)
{
/* smooth video not enabled */
CDVDClock::WaitAbsoluteClock(presenttime * DVD_TIME_BASE);
return;
}

Edit: This is the main thread and it sleeps for 496 msecs currently .
If it is not interrupted (I'll look for it), then the render buffers will not be freed.....

Edit2: Now I see what you mean why draining is necessary - tooks long, I know.....

I'll look now at the hints you gave above.....

[peak3d]

I applied both patches, 2 frames were drained and the freeze is shorter now. Thanks for this!
There is still a gap of decoded PTS times between the two parts, but I think this comes from the data I pass.

I'll check this now and maybe add some data to one of the parts to get the gap closed.

[peak3d]

Do you know what:

DXVA on my system drains more frames then FFMPEG decoder.

With DXVA I'm coming to the decoded PTS wich fits to the second part!

There is also a difference in the initial sequence of the second part:
FFmpeg needs 6 packets before the first frame is available, DXVA only 2.

Edit: To be more precise: DXVA drains 1 frame, ffmpeg 2 frames.
But DXVA produces 4 more frames at the end of the first stream part.

[peak3d]

I'll cleanup my code now and try a PR afterwards.

How should we continue with the other (initial issue), that ffmepg doesn't pass the DXVA format in GetFormat()?
You may remember, that I had an extra call to Decode to properly setup the (DXVA) decoder on time the stream change is read.

a.) Put it into VideoPlayerVideo
b.) Try to find the place in ffmpeg
c.)

[peak3d]

- I removed the initial decode call to avoid unnecessary discussions
- I placed a DRAIN message into the message_queue instead applying your patch to avoid same code redundancies

The commit confused the complete discussion we had before :-(

PR is: https://github.com/xbmc/xbmc/pull/8830

Thanx again for your support!

[FernetMenta]

There is also a difference in the initial sequence of the second part:
FFmpeg needs 6 packets before the first frame is available, DXVA only 2.

If this is the case, something goes wrong. dxva hw accelerator is fed by mmpeg and it's ffmpeg parser to decide when a frame is complete. dxva only does the actual decoding of an entire frame.