Playback of HD-PVR recordings unwatchable after 0.26 upgrade

[skd5aner <skd5aner@…>]

I've got an HD-PVR (used for 3+ years) attached to a cable STB. Immediately after upgrading from 0.25-fixes to 0.26-fixes, playback of any h.264 recordings from the HD-PVR are unwatchable with the video stuttering badly. This involves playback of recordings made both prior to the upgrade and after the upgrade.

The best way to describe it is extremely jittery playback, where frames freeze and skip constantly. Occasionally (5-10% of the time?) I can start the recording, exit a recording, and start the recording again at the bookmark and it'll start to play fine - but it takes a lot of tries usually for a successfully playback, if it will ever even do so. All of my QAM MPEG2 recordings playback successfully. I've tried using VDPAU and OpenGL, with the same impact.

Since ~50% of my recordings come from my HD-PVR, this has made mythtv unusable. My theory (and John Poet's as well) is that the last ffmpeg sync is less robust in handling content from the hd-pvr.

Logs to come shortly. Please let me know if there's anything else I can provide.

[skd5aner <skd5aner@…>]

-v playback of a sample of the first 50MB of an impacted recording

[skd5aner <skd5aner@…>]

I've uploaded the log (-v playback). Also, I've sent a 50MB sample of one of the impacted recordings to stuartm. If you are a dev and want to help troubleshoot, please reach out to him and he'll let you know how to get the file.

Also, as an FYI, the HD-PVR recording profile is set to the following (for Default Profile): Low Resolution - Avg- 7000 kb/s, Max- 8500 kb/s Medium Resolution - Avg- 11500 kb/s, Max- 17000 kb/s High Resolution - Avg- 13500 kb/s, Max- 20200 kb/s

[skd5aner <skd5aner@…>]

new logs with -v playback,timestamp,libav --log-level=debug

[skd5aner <skd5aner@…>]

Uploaded a new log with -v playback,timestamp,libav --loglevel=debug per taylorr. During playback, with VDPAU High Quality, I see the following in htop (dual core):

mythlogserver ~40%
mythlogserver ~35%
mythfrontend ~26%
mythfrontend ~6%

Playback data shows:
Storage to Buffer: ~250Mbps
Buffer to Decoder: ~5.5Mbps
Available Buffer: 99% of 16Mb
Video: 1280x720@59.94fps

A/V Sync: ~-0.42
FPS: ~59.99+-0.02
Frames decoded/free: 4/2

When I set the playback profile to normal, all HD-PVR recordings seem to play back ok.

[jerry.baum@…]

I had this issue as well using opengl renderer. HD recording playback is unwatchable (and sadly VAAPI seems to have a boatload of issues so its not usable either).

Made me revert back to 0.25.

Will provide logs once I have the time to update and test again.

[JYA]

For the record, neither Quicktime, ffplay, VLC 2.1 nor mplayer are playing this file properly. Between those four, you either get garbage or a static image with ESPNH SportsCenter? - Press SEL for enhanced

[skd5aner <skd5aner@…>]

I can confirm that it plays back successfully in MythTV 0.25-fixes and VLC 1.1.10 (which is an older version. However, it does crash Windows Media Player hard - v11.0.6002.18311.

[JYA]

Bug was reported upstream: ​https://ffmpeg.org/trac/ffmpeg/ticket/2050

[JYA]

New bug report upstream: ​https://ffmpeg.org/trac/ffmpeg/ticket/2062

[JYA]

Fix against master

[JYA]

Fix against fixes/0.26

[skd5aner <skd5aner@…>]

I'm extremely happy to report that the patch for 0.26-fixes seems to have fixed the issue. I've tested about a dozen or so recordings, all of which typically exhibit the issue, as well as the sample I've submitted and everything plays back beautifully. Thank you so much jya.

[blm-ubunet@…]

VDPAU & 0.26+fixes. This patch restores 0.26+fixes to be able to play "dd cut & concatenated" TS files. Without patch the discontinuities at cut points caused frame jitter & crazy mix of old & new frames..

[blm-ubunet@…]

Have to take that back..it fixes cut&paste TS streams but plays one channel (Prime SD 576 25fps) with very high jitter & 18fps. This problem channel is lower bitrate & has one audio stream & no subs.

The workaround for cut TS playback is to seek forward/back after discontinuity.

[warpme@…]

Sorry posting here as I'm not original submitter, but this patch is definitelly good direction, so I hope JYA find this info usefull. I tested patch on 0.26-fixes with backported from master ffmpeg1.0. Findings:

+it solves issue of crazy mix of old & new frames in lossless_cut converted recordings which have cut lists;

+it makes livetv better as without this patch - on some channels - after changing to new channel I have 1-3sec of stuttering audio. With this patch there is rare 0.5-1sec audio silence but no any stuttering;

-it has problem with wrong fps on selected tv channels/recordings. In such case reported fps is 17-18fps and playback is jerky.

This effect is exactly the same like after backporting #d34833f2e (seems to be the same code change) so I'm sure current master has the same issue. If needed I'll be more than happy to provide samples for further problem debugging.

[JYA]

Replying to blm-ubunet@…:

Have to take that back..it fixes cut&paste TS streams but plays one channel (Prime SD 576 25fps) with very high jitter & 18fps. This problem channel is lower bitrate & has one audio stream & no subs.

The workaround for cut TS playback is to seek forward/back after discontinuity.

Ffmpeg doesn't support change of resolution in a H264 stream when using multi-threaded decoding. Multi threaded decoding was introduced in FFmpeg last year, after mythtv 0.25 was released and before 0.26.

This issue has been fixed in ffmpeg master a few weeks ago only.

Mythtv now uses ffmpeg 1.0 stable branch and will not get that fix until ffmpeg release a new stable version.

No tool based on ffmpeg before that change will play such file...

[JYA]

Replying to warpme@…:

-it has problem with wrong fps on selected tv channels/recordings. In such case reported fps is 17-18fps and playback is jerky.

Provide some samples, without it, there's no way we can investigate...

This effect is exactly the same like after backporting #d34833f2e (seems to be the same code change) so I'm sure current master has the same issue. If needed I'll be more than happy to provide samples for further problem debugging.

Sorry, but I don't follow what you are doing, what you have back ported or patched...

Use master as a base, it's too difficult to work with fork like you do

[warpme@…]

jya, is there any preferable place to upload sample ?

[blm-ubunet@…]

Replying to comment #14 JYA. (ffmpeg changes) Good news for US TV.. My cut TS file was from one recording & there were no changes in video size or framerate. Actually the original recording does not play perfect in 0.26+fixes/VLC1.1.13/ffplay (git today); there are micro audio glitches/pitch changes. Only noticeable in music.

[tycholursen@…]

This temporary fix causes stuttering for me in both fixes/0.26 as well as master. I was discussing it the other day with stichnot on irc, but did not come up with something useful yet. However, reverting the commit solves my stuttering problems.

[blm-ubunet@…]

I can induce a similar frame stutter/order-mix behaviour in 0.26+fixes without this patch, in any H264 recording by:.
Use cut-list editor & seek about frame "1" & 3nd keyframe by frame & keyframe. Before long the frame indexing is messed up & any seeking/playback has messed up all frame sequences.
It appears like keyframe indexing is offset.

[tycholursen@…]

Replying to blm-ubunet@…:

I can induce a similar frame stutter/order-mix behaviour in 0.26+fixes without this patch, in any H264 recording by:.
Use cut-list editor & seek about frame "1" & 3nd keyframe by frame & keyframe. Before long the frame indexing is messed up & any seeking/playback has messed up all frame sequences.
It appears like keyframe indexing is offset.

I don't know if we are talking about the same issue. In fact, I think not. With the patch I experience some stuttering, without it I don't. At all. Probably it's a side effect of the patch that is causing the stuttering in my case, or not... It could be related though.

[JYA]

It's not because you're suffering some issues that it's related to this one.

The fix is a temporary one, it only revert a minor change in ffmpeg on how reference frames are calculated

If you have a problem with playback, lodge another bug.

I lock this ticket, because it's impossible to follow things with everyone taking the liberty to comment with various issues not related to the original problem

[stuartm]

See #11356 where the temporary fix applied to master and -fixes is causing problems with BBC HD and BBC One HD recordings.

[JYA]

Fix for fixes/0.26

[JYA]

Fixed in [1c1076385f01619f0d0933f9f4fb8f5d1e80435b] (master) and [9aaccb0e199a21311d0200b7787b705e4a67ca87] (fixes/0.26)