[FernetMenta]

From timing its not the big difference if I use SW rendering,

Don't mix this up. Never ever use sw rendering. This mode will be removed soon. I was talking about sw decoding.

I'm lost :-( RenderMethod pixel-shader do not affects the decoding.
I have the possibility to select RenderMethod pixel-shader and / or disable H/W decoding.

I was sure that you mean RenderMethod pixel-shader (wich doesn't crash but has a black frame also)

Pixel-shaders != sw rendering. sw rendering is an ancient method that does yuv to rgb conversion in CPU. If you disable dxva and leave render method to auto, pixel shaders will be selected.

[peak3d]

a) Build up early new RenderManager at the time we detect the change
b) Build up early a new Renderer in RenderManager (not checked if it could make sense)
c) Build up early a new Processor in Renderer (not checked if it could make sense)
d) and some more

none of those would work. there can only be one renderer. video player thread should not be blocked in configure

But you have to keep track about the order of the displayed frames - At least the flushing of the buffered frames (from data before change) must be processed in renderer before the new ones will be touched.
Because of this I could think that letting the render find the best time to switch would be the best - and it doesn't block anymore if the new frames are simply pushed to it.

I could imagine this workflow:

- change is detected (some seconds before display) and the renderer preconfigures as much as it can (most things for initializing are available in hints)
- decoded frames are pushed to Renderer
- decoder detects the change and switches to the preconfigured processor or renderer or whatever is the best.

[FernetMenta]

you forgot that there can only be singe renderer at a given time. configuring renderer is instant.
why don't you try as I suggested. continue decoding while renderer plays out remaining frames. as soon as last frame comes to display you can feed renderer again.

[peak3d]

because I don't know where to put the decoded frames to.
Decode accesses direct renderer buffer, doesn't it?

[FernetMenta]

you could do in dxva decoder like vaapi and vdpau do:
https://github.com/xbmc/xbmc/blob/master...I.cpp#L767

they don't deliver pics (VC_PICTURE) as long as the buffers are not full:
https://github.com/xbmc/xbmc/blob/master...I.cpp#L825

This way decoder can do work while the videoplayer thread is blocked by renderer.

[peak3d]

thx, I'll look at it

[peak3d]

I have changed so far:

1.) Allocate one priority buffer in RenderManager to make sure that the last "old" frame (the one before Change message) has not to wait for RenderBuffers.
-> This leads to the fact, that initialization starts faster.

2.)- RenderManager::AddVideoPicture() will be called directly inside the lock scope of RenderManger::configure if a change occured
-> This removes the black frame thing

3.) Still 0.1 seconds gap. I looked deeper to the DTS / PTS of the video packets after the change:

P1.) 18:14:27:0871 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20020000.000000 - 20103416.666667 - 2
P2.) 18:14:27:0873 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20061708.333333 - 20270250.000000 - 6

First packet cannot produce a picture (2 = VC_BUFFER), but the second one (VC_BUFFER | VC_PICTURE).
But: the PTS of the of the second packet is far away from be displayed directly, its about 0.17 sec. behind the packet 1.

In later packets there will be PTS wich are closer to the first one (this is Packet 3).
P3 18:14:27:0944 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20103416.666667 - 20186833.333333 - 6

Im not professional in Mpeg, but what is with the first packet? Shouldn't this be displayed at 20103416.666667 after it was updated with packet 2?
Or is Packet 1 simply garbage?

[FernetMenta]

Im not professional in Mpeg, but what is with the first packet? Shouldn't this be displayed at 20103416.666667 after it was updated with packet 2?
Or is Packet 1 simply garbage?

I don't know where you put your logs. I guess before decoding. Due to b-frames packets going into decoder can have different ordering. Before decoding look at dts, after decoding at pts.

[peak3d]

currently I have 2 LogPositions in VideoPlayerVideo.cpp:

Process() behind:

int iDecoderState = m_pVideoCodec->Decode(pPacket->pData, pPacket->iSize, pPacket->dts, pPacket->pts);

OutputPicture() before:

m_renderManager.FlipPage(CThread::m_bStop, (iCurrentClock + iSleepTime) / DVD_TIME_BASE, pts_org, -1, mDisplayField);

And yes, it is now visible that the main problem is not directly on Change, but at around the time of the packet 2:

Code:

18:51:48:0746 T:9820   DEBUG: CRenderManager::Configure - 3
18:51:48:0752 T:3784   DEBUG: CPullupCorrection: pattern lost on diff 83417.000000, number of losses 1
18:51:48:0753 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
18:51:48:0756 T:3784   DEBUG: Previous line repeats 1 times.
18:51:48:0757 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20103416.666667 - 20186833.333333 - 6
18:51:48:0758 T:9820   DEBUG: CWinShader::LoadEffect - loading shader special://xbmc/system/shaders/yuv2rgb_d3d.fx
18:51:48:0760 T:3784   DEBUG: CVideoPlayerVideo::Flipping: 20103416.000000
18:51:48:0761 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
18:51:48:0762 T:3784   DEBUG: Previous line repeats 1 times.
18:51:48:0763 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20145125.000000 - 20145125.000000 - 2
18:51:48:0764 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
18:51:48:0765 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20186833.333333 - 20228541.666667 - 2
18:51:48:0766 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
18:51:48:0767 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20228541.666667 - 20437083.333333 - 6
18:51:48:0770 T:3784   DEBUG: CVideoPlayerVideo::Flipping: 20186833.000000
18:51:48:0771 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: -19.128222, Bufferlevel: 2, Gain: 0.043417
18:51:48:0773 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20270250.000000 - 20353666.666667 - 6
18:51:48:0800 T:3784   DEBUG: CVideoPlayerVideo::Flipping: 20270250.000000
18:51:48:0801 T:3784   DEBUG: CVideoPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: 0.169801, Bufferlevel: 2, Gain: 0.043417
->18:51:48:0802 T:3784   DEBUG: CVideoPlayerVideo::Decoding 20311958.333333 - 20311958.333333 - 6
->18:51:48:0970 T:3784   DEBUG: CVideoPlayerVideo::Flipping: 20311958.000000

This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs

[FernetMenta]

This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs

Did you buffer the frames in decoder as I suggested?

[peak3d]

This is the .1 second Im searching for. The packet is decoded but has to wait for renderbuffers 0.17 secs

Did you buffer the frames in decoder as I suggested?

I'll do this next - I spend the day searching for the black frame.

What I still don't understand: What is with the first packet (of the second part):
18:14:27:0871 T:19556 DEBUG: CVideoPlayerVideo:ecoding 20020000.000000 - 20103416.666667 - 2 (=VC_BUFFER)
??

This is the one wich should go directly after the last of the first part of the video.

Is it really lost? What is with the 1753 Byte of data in this first packet?

[peak3d]

I need onother thing clear before I start buffering:

For me it seems that the number of RenderBuffers are not sufficient for thie initial sequence.
The freeze occurs after all te change stuff is done,

Simpy buffering would not solve the problem with 2 Renderbuffers available
I also have to sort them, is this right?

[Edit:] Forget this, there is a buffer for it - but I found a sleeptime just before the freeze with 0.169 secs

[FernetMenta]

Is it really lost? What is with the 1753 Byte of data in this first packet?

why lost? you won't get a pic for every packet you put into decoder. packets are reordered and frames have references to others. btw: dxva does not have drain implemented. that means that you don't get the last frames out of decoder as we get from sw decoder, vaapi, vdpau or mmal.
that is why dxva gets deactivated for DVDs that can contain still frames. You need to squeeze out remaining frames after the last frame went into decoder.

[peak3d]

1.) This means: on initialization there are for- and backward jumps - but if the decoder is filled then it produces ordered frames (all regarding PTS)?

2.) Is it right that I cannot call Decoder::GetPicture() during Render-reconfiguring because the memory applied to an DVDImage is physically the memory allocated from the Renderbuffer?
-> Its decoder memory, you don't have to answer this

3.) How many Image Buffers can I allocate in Renderer with common Hardware?

[FernetMenta]

1.) This means: on initialization there are for- and backward jumps - but if the decoder is filled then it produces ordered frames (all regarding PTS)?

Wrong. PTS never jumps after decoder (GetPicture)

2.) Is it right that I cannot call Decoder::GetPicture() during Render-reconfiguring because the memory applied to an DVDImage is physically the memory allocated from the Renderbuffer?
-> Its decoder memory, you don't have to answer this

Wrong. Either a pic is copied into render buffers or a ref counted surface flows from decoder to renderer. re-configure of renderer would then release the surfaces.

3.) How many Image Buffers can I allocate in Renderer with common Hardware?

[/quote]

depends on GPU mem but I doubt you would ever need more than 5