Opened 14 years ago

Closed 14 years ago

#827 closed defect (fixed)

XvMC and general FF-REW >3x problem

Reported by: marco.coli@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

immediately after Daniel closed #797, I switched from my longlasting 8120 to latest SVN. I tried, I think, seven versions, and all have, for new DVB recordings, the following problems:

  • During playback sometimes the stream freezes. It seems to pause (but no OSD signal this). Pressing two times pause (one time to go to "real" pause, the second one to exit pause) unblock it.
  • No ff/rew is possible with speed > 3. Doing this cause strange jumps into stream, freezes, and in some cases segfaults of frontend

Attached frontend log with -v playback. In the log I started playback a recording. Immediately image freezes, so I use the "pause" trick. For 2 other times it happens the same. After, I try to ff some times. If you need to see the stream, it is available at http://hi-cad.homelinux.org/download/7530_20051217201500.mpg

Attachments (2)

mythfrlog.gz (30.5 KB) - added by marco.coli@… 14 years ago.
mythfrontend.log.gz (134.9 KB) - added by adeffs@… 14 years ago.
log file showing output of recording with improper ff/rw

Download all attachments as: .zip

Change History (13)

Changed 14 years ago by marco.coli@…

Attachment: mythfrlog.gz added

comment:1 Changed 14 years ago by stuart@…

N.B. These may be two seperate issues as I have seen the ffw/rew bug but not the freezing.

comment:2 Changed 14 years ago by abostock@…

I'm seeing this as well and I seems to be a problem with the recordings themselves. Playing back any older recordings and doing a ffw works fine (I've just updated from "pre new livetv" to svn 8307)

comment:3 Changed 14 years ago by adeffs@…

Just checked and I have this issue as well. SVN 8306

It behaves like the time I edited one of my DVB recordings with ProjectX and forgot to rebuild the see table with mythcommflag. The FF/RW gets blocky and shows streaking and does not update the image correctly.

I've attached my log output, I didn't bother editing it, so just look near the end. I played a recent recording that had the issue and then an older recording without the issue.

Changed 14 years ago by adeffs@…

Attachment: mythfrontend.log.gz added

log file showing output of recording with improper ff/rw

comment:4 Changed 14 years ago by adeffs@…

nevermind, after looking at it the output for the "bad" recordings was obvious so I edited. I can provide a full log if needed.

comment:5 Changed 14 years ago by anonymous

Owner: changed from Isaac Richards to danielk

comment:6 Changed 14 years ago by danielk

So it looks like this is really 2 problems, not enough frames are being reserved in XvMC mode, and there is some problem with the fast forward implementation not freeing frames in all playback modes. It has nothing to do with recording, so far as I can tell. But the problem may have been made more apparent by prebuffering changes for the LiveTV changes.

I'll look at the fast forward code first; since that effects all playback modes.

comment:7 Changed 14 years ago by danielk

Summary: Problem on FF-REW and other playback issues on DVB recsXvMC and general FF-REW >3x problem

comment:8 Changed 14 years ago by abostock@…

Would you like the logs from my frontend as well then?

I'm not using XvMC and fast forwarding is only broken on recordings made since updating to a recent svn version. As I said all recordings made with my previous "pre new livetv" svn checkout are fast forwarding without any issues at all.

Ash.

comment:9 Changed 14 years ago by danielk

Ashley, upon further investigation this may be have been effected by keyframe detection changes in the DTVRecorder, at least in Fast Forward >3x mode.

comment:10 Changed 14 years ago by adeffs@…

I don't have XvMC (it doesn't actually work for me...), i just forgot to set it back to standard when I was testing. It looks to be more like a mythcommflagg issue since the older shows work even with the new SVN playing them back

comment:11 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8350]) Fixes #827. This fixes two major problems with FF/REW > 3x, and some minor problems.

The two major problems had to do with not throwing away some cached data after a seek, and leaving frames in limbo.

The first resulted in ffmpeg/libmpeg2 decoding errors; which we generally recovered from, but left a lot of junk in the debugging output and slowed down the decoding. This was fixed by decoupling freeing bogus data and freeing frames (the bogus data was being freed after a regular seek.) Basically a new param 'discardFrames' has been added to SeekReset?().

The second major problem left a frame in limbo after each seek, this caused major problems for XvMC and some less serious problems for XVideo output. This was fixed by adding a new method to VideoBuffers?, DeLimboFrame?() which is called when av_release_frame releases a frame, which is now called after a SeekReset? for partially decoded frame. This frame leaves frames we've already put in 'U'sed alone, but moves 'L'imboed frames to 'A'vailable.

This fix does not fix libmpeg2 leaking frames, only ffmpeg; I don't quite understand how libmpeg2 is supposed to be freeing frames. The lack of this call in the proper place may be the reason why preview screen grabs don't work with libmpeg2. libmpeg2 appears to still basically work with FF/REW > 3x, but doesn't fully decode the frames and pauses whenever the limbo frames add up too much, but they eventually get purged.

There were also some minor problems with non-exact seeking sometimes jumping backward in FF mode, and with frame-by-frame seeking grabbing frames and actually decoding the video when it didn't have to. These are also fixed by this commit. And 'Normal' and 'FFREW' GetFrame? has been seperated in the NVP for better readability, and simpler logic.

Note: See TracTickets for help on using tickets.