Opened 7 years ago

Closed 7 years ago

#11304 closed Bug Report - General (Fixed)

Judder and incorrect playback timer when FPS changes

Reported by: Brian <knappster_1@…> Owned by: Jim Stichnoth
Priority: minor Milestone: 0.27
Component: MythTV - Video Playback Version: 0.25.2
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I recently added an HDHomerun Prime and found that when I watch some content on cable channels in HD, I get judder and the recording lengths are incorrect (until the recording completes at which point it seems to self-correct). It seems to happen on 1080i recordings when the FPS changes (show is 24 fps, some commercials are 30 fps). To fix the judder, I have to exit the recording and start playing from the bookmark again. It seems to play smoothly until the next commercial. It also happens on live TV.

Example:
(1) 8:00 pm - Burn Notice begins recording on USA HD (1080i 2 hour recording)
(2) 9:00 pm - I begin watching from the beginning of the recording. Total length of recording reports approx. 50 minutes (should be 60 mins)
(3) First commercial break - Skip forward past commercials, now there is judder in playback
(4) Exit to "Watch Recordings Menu" - Play from Bookmark
(5) Playback is fine until next commercial break
(6) Repeat steps (4) & (5) with every commercial break until finished watching
(7) When the end of the recording is reached, it is at 1:41 of 2:01.

I then went back to Live TV and watched part of a rebroadcast and turned on the Playback Data on the frontend. I noticed that when the show was playing the FPS was 24 (jumped around between 23-25). When the commercials came up, some were the same, others were 29.9 FPS.

FWIW, this seems to be related to an incredibly old ticket #1941, which was closed due to being a duplicate of ticket #799, which seemed slightly different and has since been fixed/closed.

I am using LinHES R7.4 (arch linux, Mythtv 0.25-2). I would be happy to provide more information if it can help. I have not seen this issue on the local channels, which I have watched in HD for the last 2 years with the original HDHomerun. I have only just recently gotten the HDHomerun prime so I don't know if the issue was there with previous versions of myth, too.

Attachments (3)

judder-24fps(livetv).txt (105.9 KB) - added by Brian <knappster_1@…> 7 years ago.
nojudder-24fps(recorded).txt (41.4 KB) - added by Brian <knappster_1@…> 7 years ago.
nojudder-29fps(livetv).txt (78.6 KB) - added by Brian <knappster_1@…> 7 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by Jim Stichnoth

Component: MythTV - GeneralMythTV - Video Playback
Milestone: unknown0.27
Owner: set to Jim Stichnoth
Status: newaccepted

Currently MythTV playback assumes a fixed frame rate for the purpose of seeking, displaying position, and in some cases displaying duration. There is work in progress that will allow for proper display and seeking in variable frame rate recordings.

The judder is a separate issue. It would help a lot if you could provide a link to a small sample that demonstrates the problem. It's likely related to the ffmpeg code, and a resync has happened for 0.26 that could possibly have fixed it.

comment:2 Changed 7 years ago by Brian <knappster_1@…>

I'm sorry, but this problem continues to evolve. When I go back to the recording I referenced in my original post, I have not seen any judder. I have also recorded a 2 min clip on Comedy Central and when I watched it live, there was judder. When I went back in to watch the recording, it is not producing it. Will it still be useful for you if I produce a link to a clip? I hesitate because it is 233 MB and does not seem to produce the fault on playback. Maybe this is only a problem with Live TV or playing back a recording while it is still recording? I'm going to be away until after Christmas, so I will pick back up then.

comment:3 Changed 7 years ago by Jim Stichnoth

There are known issues with judder and playback of in-progress recordings, including Live TV. One workaround (assuming this is the same issue) is to pause a few seconds and then resume playback, staying at least 5-10 seconds from "real-time" to avoid buffer starvation.

Let's focus this ticket on the incorrect reported duration for varying framerate recordings. No sample is needed for that. At least two related tickets: #10104 #10623

comment:4 Changed 7 years ago by Brian <knappster_1@…>

I appreciate your responsiveness, you guys do a tremendous job.

I would like to clarify a couple things mentioned in your last comment. The workaround you mentioned does not help with the judder issue I am having. First of all, the recording was 60 minutes ahead when I started to watch it, so I was nowhere near real-time. I even tried to pause it 10 seconds after one of the commercial breaks and it did not improve the judder. I have looked in the logs but did not see anything helpful. Is there something I can do to give you more definitive data on this?

With regards to the incorrect reported duration, of the two tickets you posted, I would say it is more like #10104 because the time was not "wildly inaccurate" as reported by #10623. It also reports the correct total length once the recording is completed, but it does not follow the correct time during playback. I have not attempted mythcommflag --rebuild because I am trying to keep everything unchanged for testing. In my opinion, it is exactly like #1941. If it is counting time by frames and there are 24 fps instead of 30, that is a reduction of about 20%. That would make a 120 minute recording look like it was only 96 minutes. If some of the commercials are at 30 fps, that might explain why the 121 minute recording gets to the end after only 101 minutes on the OSD.

Changed 7 years ago by Brian <knappster_1@…>

Attachment: judder-24fps(livetv).txt added

Changed 7 years ago by Brian <knappster_1@…>

Changed 7 years ago by Brian <knappster_1@…>

Attachment: nojudder-29fps(livetv).txt added

comment:5 Changed 7 years ago by Brian <knappster_1@…>

I just spent some more time verifying that the judder with LiveTV does not matter if I am 10 seconds behind or not. I ran mythfrontend -v playback and piped the output to text files. The one titled: judder-24fps(livetv).txt is when I experienced judder playing a 24fps movie on livetv (1080i).

nojudder-24fps(recorded).txt is the same file played back from the recordings page.

nojudder-29fps(livetv).txt is a different channel playing a 30fps show on livetv (1080i).

The file names are meant to be descriptive (the only one with judder was the 24fps video on live tv. Also note that both livetv files may log another channel briefly before switching to the program in question.

I am hoping that this may help shed some light on my situation.

comment:6 Changed 7 years ago by Brian <knappster_1@…>

Following up on this, I have tried the following:

  1. Increasing resolution to 1920x1080
  2. Configured RTC to be used for vsync instead of usleep
  3. Tried every on/off combination of Sync to Vblank in nvidia-settings
  4. Added a second Hard drive to offload Live TV onto to rule out I/O bottlenecks.
  5. Increased / Decreased HD Ringbuffer Size
  6. Tried different nvidia drivers.
  7. Tried pause, skip forward, skip backward, jump forward, jump backward.
  8. Forced cpufreq to keep CPU freq maxed.

It still happened and it would only happen when watching live/actively recording tv 24fps videos in 1080i. Once the recording completes, playback is fine so it is very difficult to even test, because I cannot play the same clip more than once. I was unable to change the from rate on my TV to see if 50 Hz would improve things, so I finally broke down and took the 9500 GT from my desktop computer, switched from Standard ffmpeg with xv-blit to VDPAU High Quality in the hardware profiles and everything plays back perfectly now. In fact, now that I have seen video playback with VDPAU, I may not want to go back. I may try the 9500GT with Bob deinterlacing just to see if it is a problem with the deinterlacer or something else.

comment:7 Changed 7 years ago by Jim Stichnoth

Resolution: Fixed
Status: acceptedclosed

The issue of incorrect position/duration in variable framerate recordings has been fixed in Master by 49dbed5be0729b04a5f0fd0426a32fceb2dd7935. Unfortunately, it includes a myth protocol change, and cannot be backported.

The issue of stuttering during playback of in-progress recordings is a separate issue. Please open a new ticket if that still affects you.

Note: See TracTickets for help on using tickets.