[FernetMenta]

- I placed a DRAIN message into the message_queue instead applying your patch to avoid same code redundancies

I prefer my change. 7 line of duplicate is not an issue but it gives more control over behaviour.

[peak3d]

Sorry, I already found the solution - it was because because the initial packet was send twice, once on Open() and again if the stream starts.

For now this initialization part is removed and it's working correct.

But its only a few lines code to activate it again - right now DXVA will be initialized on time the change appears and cost on my P7 about 7ms.
This is unfortunately enough to drop one more frame.


Nevertheless HW decoding produces more frames at the end of part 1 than SW decoding.

[FernetMenta]

But its only a few lines code to activate it again - right now DXVA will be initialized on time the change appears and cost on my P7 about 7ms.
This is unfortunately enough to drop one more frame.

I don't think this is critical if decoder supports buffering like the ones I named. hw accelerators work asynchronous. You can feed a couple of packets to keep it busy, then drain and reconfigure renderer. DXVA is not ready for this use case, yet.

Nevertheless HW decoding produces more frames at the end of part 1 than SW decoding.

Nobody has implemented proper drain for DXVA yet. What you get when trying to drain DXVA is more or less undefined. I already mentioned that we have DXVA disabled for DVDs because it does not handle it correctly.

[FernetMenta]

I will do the required changes to renderer over the weekend. That's not trivial for someone not knowing exactly how the various parts work together.

- first video thread needs to request render thread to do the actual configure (there we currently lose 100ms because of timeout)
- render thread does configure in frame move
- no dirty region should be signalled by GUIWindowFullScreen -> avoid flipping of front/back buffers

[peak3d]

I will do the required changes to renderer over the weekend. That's not trivial for someone not knowing exactly how the various parts work together.

- first video thread needs to request render thread to do the actual configure (there we currently lose 100ms because of timeout)
- render thread does configure in frame move
- no dirty region should be signalled by GUIWindowFullScreen -> avoid flipping of front/back buffers

I have not figured out who adds the dirty regions - I tried. But for sure it would be a benefit because the first frame of the second part is displayed without respecting the presenttime.
I bet its too early.

For the part decoding while waiting for unfinished I had implemented an pragmatic solution (without the need of more threads:

- RenderManager::configure() returns busy (directly without waiting) when trying to reconfigure and there are frames to process
- VideoThread continues and processes (decodes) the nect packets
- If RenderManager gets an picture wich does not fit to the current active configuration, build up a new buffer and store the picture (up to 8 or so)
- if finally RenerManager::configure() succeds because all old frames are done, begin restacking the new frames.

This would be a solution independent from decoder - it would work for all of them.

What do you think?

[peak3d]

Another thing:

I could easily add 2 seconds of video in front of the second part, wich means that there would be an overlap of these 2 seconds.
Kodi would have to find a good timestamp when to switch. Theoretically there are ~5 seconds (buffered).

Good thing would be that It solves differences between the Decoders as we don't have to care anymore about draining and I / B / P frames.
- Run through the second part until there is an image from decoder
- play the first part until this PTS is hit
- continue with the second part

I just checked the change on a less powerfull arm device (odroid xu3 with MFC decoder)
I have to check what frames are put out or if drain is supported, but it looks not really nice so far....

[FernetMenta]

I did some optimizations to configure of renderer: https://github.com/FernetMenta/xbmc/comm...0b34adcb5a
Now configure/reconfigure is done instantly after buffers have been drained and without rendering an empty frame.

[peak3d]

I did some optimizations to configure of renderer: https://github.com/FernetMenta/xbmc/comm...0b34adcb5a
Now configure/reconfigure is done instantly after buffers have been drained and without rendering an empty frame.

Great! I'll give it a try.

Using my current test video there should normally not a single "hurry" because one frame is simply missing.
This means, that there are 80ms time to do the switch (and we are in this area) - I'll try to figure out the "why" after I have my debug output for the MFC device.

B.t.w.: There is a bug in the code I PR'ed, I called Aquire() to a message item in the video message queue when in Peek and this leads to the result that videos hang at the end (waitUntilEmpty())

[FernetMenta]

can you share a sample for testing?

[peak3d]

https://www.dropbox.com/sh/0tbmofg68ouf3...Jat5Ja?lst=
There is the file muxed.mov

But you have to patch ffmpeg with the patch attached to the PR:

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

[FernetMenta]

the remaining problem was draining the codec. for the case filters were active it did not drain properly. actually there's 5 or 6 frames coming out. again, dxva won't work.
https://github.com/FernetMenta/xbmc/comm...4d70e89753

I also improved handling of stream changes:
https://github.com/FernetMenta/xbmc/comm...82183f83df

with my master branch on OSX with sw decoding you sample plays almost smooth. There is this 83ms gap that causes a slight stutter.

You need to fix your ffmpeg change. avcodec_string must not crash

[peak3d]

the remaining problem was draining the codec. for the case filters were active it did not drain properly. actually there's 5 or 6 frames coming out. again, dxva won't work.
https://github.com/FernetMenta/xbmc/comm...4d70e89753

I also improved handling of stream changes:
https://github.com/FernetMenta/xbmc/comm...82183f83df

Perfect news!

You need to fix your ffmpeg change. avcodec_string must not crash

OK, I'll copy the new initialization data into the existing AV streams.