Issue with jump seek

[Boulder]

I've experienced this issue with Kodi earlier (https://trac.kodi.tv/ticket/16911), but it seems to be in MrMC as well. I've been testing remuxed video playback over the gigabit network (with NFS) and jump seeking or simply seeking a lot in the playback menu when the video is paused, causes the video to freeze for a long time while audio continues. Then after some time, the video frame is updated but it's just a still frame being shown. Then after a while, video begins normal playback. These remuxes were from the original BD so the keyframe distance is not long.

Here's a debug log output, it's quite long as I tested two cases but the latter part has this issue: https://pastebin.com/a2PEehgZ . If you need anything else, just let me know.

[davilla]

MrMC has that fix in it, and I don't see any indication of it in log.

do see DEBUG: NFS: chunks: r/w 32768/32768' which is a small chunk size.

have a sample we can play with ?

[Boulder]

Doing some more testing with a smaller video file, I noticed that it has a similar behaviour and setting chunk size to 65536 makes it less apparent (I thought that 32K was the maximum supported). So I guess that it's network related and no need to investigate this one any further.

On a sidenote, doing the 8x rewind sometimes acts up a bit. It seems to resume from the point where the decoder was able to produce a picture on the screen.. difficult to explain but for example, I started rewinding - the video updated every now and then. At some point the updates began to occur less often. Then I stopped rewinding and the video jumped to point around 00:27:30, which was where the last update occurred. Then I tried rewinding again to around 00:26:00 but during rewind, the screen didn't update. When resuming, the video jumped back to 00:27:30. This happened multiple times. I was able to rewind back only when I did it long enough for the screen to update, otherwise it would always jump to 00:27:30. All this could also be network related but it would be nice to resume wherever the rewind ended, maybe pausing until the decoder is actually able to start outputting something on the screen.

[davilla]

Doing some more testing with a smaller video file, I noticed that it has a similar behaviour and setting chunk size to 65536 makes it less apparent (I thought that 32K was the maximum supported). So I guess that it's network related and no need to investigate this one any further.

On a sidenote, doing the 8x rewind sometimes acts up a bit. It seems to resume from the point where the decoder was able to produce a picture on the screen.. difficult to explain but for example, I started rewinding - the video updated every now and then. At some point the updates began to occur less often. Then I stopped rewinding and the video jumped to point around 00:27:30, which was where the last update occurred. Then I tried rewinding again to around 00:26:00 but during rewind, the screen didn't update. When resuming, the video jumped back to 00:27:30. This happened multiple times. I was able to rewind back only when I did it long enough for the screen to update, otherwise it would always jump to 00:27:30. All this could also be network related but it would be nice to resume wherever the rewind ended, maybe pausing until the decoder is actually able to start outputting something on the screen.

Rewinding is always problematic. Todays modern codecs (h264, h265) are just not designed to run backwards. Things like keyframes matter and encoder groups get silly thinking less keyframes == smaller file size == good but for things like seeking and rewinding, they matter.

Think of it this way, when you play forward, you are creating picture frames that are a composite of previous (or future frames) frames. Every now and then, a frame that is complete is encountered.

When you rewind, have to seek back, to a key frame, or you get incomplete frames (macro blocking). It all gets rather tricky.

NFS can handle large chunk sizes. As can SMB.

[Boulder]

I've now returned to this issue. I tried watching a BD M2TS file over the NFS share I have set up. The playback started fine, then I paused the video, swiped to fast forward around 10 minutes and pressed to resume. What happened was that the video froze with the paused frame looking a bit blocky on the screen. The audio continued. After a while, I paused again and noticed that the progress bar was around 2 minutes into the video instead of 10 that I chose. Then I swiped again and tried to jump forward some more, and at this point, the buffering indicator appeared and it went from 0 to 100 many times and repeated this without the video ever resuming. In fact, it's still doing the same as I write this some minutes later.

This is the log file to see, it covers both cases.

https://pastebin.com/43JDuNRm