Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#574 closed defect (fixed)

libmpeg2 use distorts thumbnails

Reported by: anonymous Owned by: danielk
Priority: trivial Milestone: 0.19
Component: mythtv Version: head
Severity: low Keywords: thumbnail thumbnails pixellation distortion distorted
Cc: Ticket locked: no

Description

In 0.18.2svn, choosing libmpeg2 in Setup -> Setup -> TV Settings -> Playback will cause recorded_programs.php to generate thumbnails that contain two competing frames. The effect is that whichever frame draws your eye appears to be pixellated by the other competing frame. Turning libmpeg2 off and regenerating the thumbnails fixes the problem.

This has been experienced by other users, too: http://www.mail-archive.com/mythtv-users@mythtv.org/msg43726.html

If it's a libmpeg2 bug that can't be fixed within the scope of this project, perhaps the thumbnail generation mechanism could be changed to never use libmpeg2, even if it's been selected.

Change History (7)

comment:1 Changed 14 years ago by htpc@…

Also breaks in head.

Affects not only thumbnails, ff/rev, transcoding and previous are affected.

comment:2 Changed 14 years ago by danielk

(In [7834]) References #574. Don't free frame until we are done with it.

I thought this might be the cause for #574. But it is not.

My guess is that something is broken with seeking when using libmpeg2, so that it seeks too far into an I frame, and misses parts of the image.

Does this happen with both PVR-250 and DVB/ATSC recordings?

comment:3 Changed 14 years ago by willu.mailingLists@…

I get this with DVB recordings in Aus. For me, it only happens with the thumbnails generated by MythWeb, not the ones generated within MythFrontend. I haven't checked 7834 yet to see if it's fixed.

comment:4 Changed 14 years ago by anonymous

Thumbnails generation seems to be fixed now on my system.

Not sure how to explain this, but the last few lines will differ some of the time when watching, ff or rev transcoded recordings (e.g. when the scene changes).

But overall it's much better now. thanks.:P

comment:5 Changed 14 years ago by danielk

Milestone: 0.19
Owner: changed from Isaac Richards to danielk
Version: head

comment:6 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8213]) Fixes #574.

libmpeg2 seems to be delaying an I-frame block decodes if it can't do them in a certain time and just displaying what it has so far. The fix is to simply not use it for generating previews. Someone who knows more about libmpeg2 could perhaps disable this feature instead, but it is probably useful during playback, so this would be disabled for previews only anyway so forcing ffmpeg use for previews is probably just as good a solution.

comment:7 Changed 14 years ago by danielk

(In [8426]) References #868. References #574.

Fixes a bug with libmpeg2 decoding where we would report a frame as available for viewing before we got a STATE_SLICE with a display_fbuf. This would result in very blocky output after a seek to a keyframe. This fixes the blockyness for low-res PS streams, and reduces it for high-res TS stream. This also releases frames when libmpeg2 is done with them, which should mean less wackyness in low buffer situations (see [8425].)

This bug was documented as a possible problem in the libmpeg2 decoder loop. But it doesn't cause problems during normal playback, only when seeking to I frames, or frames that come shortly after them.

Note: See TracTickets for help on using tickets.