Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 19 months ago

Closed 14 months ago

#11159 closed Bug Report - General (Fixed)

Playback of HD-PVR recordings unwatchable after 0.26 upgrade

Reported by: skd5aner <skd5aner@…> Owned by: danielk
Priority: critical Milestone: 0.27
Component: MythTV - Video Playback Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: yes

Description

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.

Attachments (6)

mythfrontend.20121008190531.5058.log (62.6 KB) - added by skd5aner <skd5aner@…> 19 months ago.
-v playback of a sample of the first 50MB of an impacted recording
mythfrontend.20121009224615.494.log (668.5 KB) - added by skd5aner <skd5aner@…> 19 months ago.
new logs with -v playback,timestamp,libav --log-level=debug
11159screen.png (197.0 KB) - added by jyavenard 16 months ago.
11159.patch (3.1 KB) - added by jyavenard 16 months ago.
Fix against master
11159-026.patch (3.1 KB) - added by jyavenard 16 months ago.
Fix against fixes/0.26
11159.026.patch (1.6 KB) - added by jyavenard 14 months ago.
Fix for fixes/0.26

Download all attachments as: .zip

Change History (29)

Changed 19 months ago by skd5aner <skd5aner@…>

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

comment:1 Changed 19 months ago by 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

Changed 19 months ago by skd5aner <skd5aner@…>

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

comment:2 Changed 19 months ago by 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.

comment:3 Changed 18 months ago by 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.

comment:4 Changed 16 months ago by stuartm

  • Component changed from MythTV - General to MythTV - Video Playback
  • Milestone changed from unknown to 0.27
  • Priority changed from minor to critical

comment:5 Changed 16 months ago by jyavenard

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

Changed 16 months ago by jyavenard

comment:6 Changed 16 months ago by 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.

comment:7 Changed 16 months ago by jyavenard

comment:8 Changed 16 months ago by jyavenard

Changed 16 months ago by jyavenard

Fix against master

Changed 16 months ago by jyavenard

Fix against fixes/0.26

comment:9 Changed 16 months ago by 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.

comment:10 Changed 16 months ago by 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..

comment:11 follow-up: Changed 16 months ago by 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.

comment:12 follow-up: Changed 16 months ago by 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.

comment:13 in reply to: ↑ 11 Changed 16 months ago by jyavenard

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...

Last edited 16 months ago by jyavenard (previous) (diff)

comment:14 in reply to: ↑ 12 Changed 16 months ago by jyavenard

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

comment:15 Changed 16 months ago by warpme@…

jya, is there any preferable place to upload sample ?

comment:16 Changed 15 months ago by danielk

  • Owner set to danielk
  • Status changed from new to accepted

comment:17 Changed 15 months ago by 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.

comment:18 Changed 15 months ago by 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.

comment:19 follow-up: Changed 15 months ago by 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.

comment:20 in reply to: ↑ 19 Changed 15 months ago by 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.

comment:21 Changed 15 months ago by jyavenard

  • Ticket locked set

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

comment:22 Changed 15 months ago by stuartm

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

Changed 14 months ago by jyavenard

Fix for fixes/0.26

comment:23 Changed 14 months ago by jyavenard

  • Resolution set to Fixed
  • Status changed from accepted to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.