1. No user installed addons are supported, python or otherwise.
2. No, they really are not supported.
3. They are not coming back
4. Read from 1. again

Any mention of illegal streaming sites, addons or any pirated material will not be tolerated. This is not democracy and any offenders will be banned and posts deleted immediately without warning.

Other than that, we hope you enjoy MrMC so far and we welcome any input and feedback you might have.

Team MrMC.

Issue with jump seek

tvOS Video playback support subforum
Post Reply
Boulder
Posts: 15
Joined: 20 Mar 2018, 07:46

Issue with jump seek

Post by Boulder » 31 Mar 2018, 17:08

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.

User avatar
davilla
Team MrMC
Posts: 3539
Joined: 26 Oct 2015, 17:01

Re: Issue with jump seek

Post by davilla » 31 Mar 2018, 18:48

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
Posts: 15
Joined: 20 Mar 2018, 07:46

Re: Issue with jump seek

Post by Boulder » 01 Apr 2018, 09:44

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.

User avatar
davilla
Team MrMC
Posts: 3539
Joined: 26 Oct 2015, 17:01

Re: Issue with jump seek

Post by davilla » 01 Apr 2018, 12:48

Boulder wrote:
01 Apr 2018, 09:44
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
Posts: 15
Joined: 20 Mar 2018, 07:46

Re: Issue with jump seek

Post by Boulder » 27 Apr 2018, 18:51

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

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 4 guests