Regression: back and forward seek problems

[Peter Bennett <pgbennett@…>]

I recently upgraded from 0.26.0+fixes.20130131.28144cd to 0.26.0+fixes.20130308.77259c5. After the upgrade, seek forward and back (using arrow keys) during playback are not working well. Most of the time they work but sometimes

1. On a 1080i recording from DVB or firewire a seek sometimes causes the playback to freeze for 5 to 10 seconds before resuming.
2. On a transcoded 720p recording (H264 mkv file) sometimes a seek forward 1 minute actually goes back 5 or 10 minutes.

These issues occur on two frontends, both using VDPAU. One is 32bit, one is 64bit. I never had these issues before the recent upgrade.

[Jim Stichnoth]

Could you attach a mythfrontend log with "-v playback" and indicate the timestamp range where the problem is occurring?

[jbfunk05@…]

After the exact same upgrade, I am also newly experiencing the described seeking problems. I will upload a -v playback log when I have a chance. I just wanted to note for now that more than one user is experiencing this issue.

[Peter Bennett <pgbennett@…>]

It appears that the problem with 1080i DVB recordings is happening only on recordings that were made after the upgrade.

I did some tests with one such recording, starting playback and jumping back and forward. In the attached frontend.log, there were slowdowns in seek operations at the following times:

20:29:02, 20:29:11, 20:29:46; 20:30:01, 20:30:11.

The slowness seems to affect certain regions of the video, in other words when it is slow seeking at a particular part of the video, it is always slow seeking at that part.

[Jim Stichnoth]

The mythfrontend.log attachment appears to contain logs for 3 separate runs of mythfrontend (search for "Enabled verbose msgs:"), the last two of which don't have "-v playback", so the potentially interesting detail is missing from the logs.

[Peter Bennett <pgbennett@…>]

Sorry about that. Here is a new file mythfrontend2.log, using -v playback.

There is a slow back seek at 21:09:58.

[Jim Stichnoth]

It looks like some keyframe entries may be "missing" from the seektable. The log shows that there are 1192 seektable entries for 107819 frames, or about 1 keyframe every 3 seconds on average. When doing the seek at log timestamp 21:09:58, the player wants to seek to frame 12748, and the nearest surrounding keyframes are at frames 12375 and 12825, which are 450 frames or 15 seconds apart.

(To seek to a particular frame, the player has to first seek to the nearest preceding keyframe, then seek forward one frame at a time until it reaches the destination frame. In this case it had to seek forward 373 frames, which could take significant time.)

To help narrow down the problem, could you try rebuilding the seektable via "mythcommflag --rebuild" and see if the problem is still there? I'm especially interested in how this log line changes after rebuilding:

decoderbase.cpp:384 (SyncPositionMap) Dec: SyncPositionMap, new totframes: 107819, new length: 3597, posMap size: 1192

[Peter Bennett <pgbennett@…>]

I first re-tested it to make sure the delay was still happening. In that show a big delay always happened when pressing left arrow from a playing time of 08:02.

Then I ran this on the backend:

mythcommflag --rebuild --chanid 2764 --starttime 20130316040000 > rebuild.log

That took 2 minutes. I have the log of that in case you need it.

I ran the frontend again. This time there is no delay when pressing left arrow from a playing time of 08:02. It goes back instantaneously. It seems the problem has gone away.

See attached log file mythfrontend_130321_172021.log of the succesful playback. The left arrow was pressed at time of 17:20:21 at the place that used to be slow.

It is possible that there are delays in a different part of the file now. However I spent some time after this arrowing back and forth in the episode, and I cannot find any place where it is slow now.

[Jim Stichnoth]

Dec: SyncPositionMap, new totframes: 108194, new length: 3610, posMap size: 7267

Very interesting - after the mythcommflag seektable rebuild, the number of identified keyframes jumped from 1192 to 7267. The keyframes appear every half second on average, which seems more reasonable for a broadcast recording. This makes it much more likely to be a regression in the recorder's keyframe identification.

The seek problem for older h.264 transcoded files should be a different issue. "git diff 28144cd 77259c5" shows a few h.264 related changes that could be related. This should probably go into a separate ticket. In the meantime, it would be good to know whether the seek error is repeatable. One thing to try is to let it play without seeking for a while, say 10 minutes, and then see if the first seek is believable, compared to the accuracy of multiple successive seeks.

[Peter Bennett <pgbennett@…>]

Testing the transcoded file. I think perhaps the fact that it is 720p 60fps may be relevant.

Start playing from the beginning. Let it play for 10 minutes. Press I and the info shows 5 minutes 23 seconds. Press forward arrow and it actually goes backwards for some distance and now if you press I the time shows 6 minutes 23 seconds. I don't really know where it is in the file since the time is off, but it is definitely a few minutes backwards.

Start playing from the beginning again. After 1 minute press I and the time shows 0 minutes 33 seconds. Continue playing for another minute (2 minutes per my watch), press I and the time shows 0 minutes 59 seconds.

[jpoet]

After first keyframe, allow keyframes without payload start

[jpoet]

Please try the attached allow-keyframe-without-payload-start.patch. If that doesn't fix the problem, I will have to come up with a patch which adds some more debugging...

[Peter Bennett <pgbennett@…>]

I rebuilt with the patch and installed it last night. After that a number of programs were recorded. I chose one that had the seek problem in a previous episode. Playing it, the seek problem seems to be fixed. I am unable to find a slow seek anywhere in the file. Log is attached (mythfrontend_130325_2100.log)

[blm-ubunet@…]

This patch solves the slow seeking issues in (closed) ticket 11435. Thanks..

[John Patrick Poet <jpoet@…>]

In c1147b634ad9977d3bb480121b300ed92376b9a7/mythtv:

Allow more than one keyframe per payload.

See 69cd78b40 for fixes/0.26
See edefeb6f4 for 0.27-pre

Fixes #11459