Opened 17 years ago
Closed 13 years ago
#3001 closed task (Won't Fix)
MPEG-4 decode errors as of [12645]
Reported by: | bjm | Owned by: | Janne Grunau |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - Video Playback | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
As of [12645] a regression has occurred in mythfrontend where playback of recorded TV shows will flash broken frames at an average of more than one per minute. The frames will have large blocks of misplaced color and other such general mishandled frame artifacts. Mythfrontend shows error messages from the ffmpeg library similar to:
[mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left B5BD00, score= -3121) [mpeg4 @ 0xb766f6e8]concealing 930 DC, 930 AC, 930 MV errors [mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left 844148, score= -5081) [mpeg4 @ 0xb766f6e8]concealing 930 DC, 930 AC, 930 MV errors [mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left C01C25, score= -5456) [mpeg4 @ 0xb766f6e8]concealing 930 DC, 930 AC, 930 MV errors [mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left 84CD46, score= -7178) [mpeg4 @ 0xb766f6e8]concealing 930 DC, 930 AC, 930 MV errors [mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left 431428, score= -8286) [mpeg4 @ 0xb766f6e8]concealing 930 DC, 930 AC, 930 MV errors [mpeg4 @ 0xb766f6e8]slice end not reached but screenspace end (-9 left 614CD8, score= -8430)
A post [12645] frontend has these errors for recordings at different resolutions and bitrates for files recorded both before and after [12645]. A pre [12645] mythfrontend does not have these errors for files recorded either before or after [12645].
Attachments (1)
Change History (19)
comment:1 Changed 17 years ago by
Owner: | changed from Isaac Richards to Janne Grunau |
---|
comment:3 Changed 17 years ago by
janne, could you address this or get ijr's help? Else this ffmpeg update will need to be reverted.
danielk, this 1 minute was a broad scale rather than an avg arrival rate. I neglected to mention that the amount of motion affected the frequency. I don't use any of the four checkbox encoding options.
I first saw this on a basketball game where this would happen 2 or more times per minute sometimes in clusters of several in a few seconds. Stationary scenes rarely has these errors but it dose seem to happen.
The error in decoding a frame seems to be consistent. When a flash appears or a message is logged, you can pause, "<" to go back by seconds before the bad frame then "->" (right arrow) to frame advance to the broken frame. The message will repeat each time the frame is drawn and the same artifacts will appear.
In a test right now, I had a case where the error message appeared but there were no visible artifacts that I could find. However, other frames, usually during high motion, can be spectacularly broken.
Changed 17 years ago by
Attachment: | 3001_revert_ffmpeg_6942_and_6953.diff added |
---|
comment:4 Changed 17 years ago by
Milestone: | unknown → 0.21 |
---|
Bruce, 3001_revert_ffmpeg_6942_and_6953.diff fixes the playback issue in my sample.
I'll commit it after I've successfully tested your samples. Any feedback from you is appreciated.
comment:5 Changed 17 years ago by
This patch appear to fix the problem.
If you are referring to the samples I uploaded to Isaac, ffmpeg-err.nuv does not report an error at 0:56 with this patch and there are no artifacts after the flash bulb goes off.
For mpeg4clip.nuv, there is no error at ~0:30 and no artifacts as Josh Heytvelt runs up court after the free throw. Playing the full clip reports no errors whereas there are six errors without this patch.
comment:6 Changed 17 years ago by
comment:7 Changed 17 years ago by
Priority: | major → minor |
---|
comment:8 Changed 16 years ago by
Milestone: | 0.21 → unknown |
---|
comment:9 Changed 15 years ago by
Status: | new → assigned |
---|---|
Type: | defect → task |
comment:10 Changed 15 years ago by
comment:11 Changed 15 years ago by
According to Janne, the above is not correct, so unfortunately this ticket remains open.
comment:12 Changed 14 years ago by
Component: | mythtv → MythTV - Video Playback |
---|
Still an ongoing problem?
comment:14 Changed 14 years ago by
Milestone: | unknown → 0.24 |
---|
comment:15 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:16 Changed 13 years ago by
Milestone: | 0.24 → 0.25 |
---|---|
Resolution: | fixed |
Status: | closed → new |
comment:17 Changed 13 years ago by
Status: | new → assigned |
---|
comment:18 Changed 13 years ago by
Milestone: | 0.25 → unknown |
---|---|
Resolution: | → Won't Fix |
Status: | assigned → closed |
This ticket is now over four years old, it's about an upstream bug playing a now little used format and I can't see active developers taking an interest in it. If there is sufficient interest in seeing this bug fixed, even assuming that it can still be reproduced in head/trunk/master then please re-open the ticket but before doing so verify that ffplay does not exhibit the problem. If it's reproducible with ffplay then file it as a bug upstream with ffmpeg.
I didn't see the corrupted frame, but I saw the error message:
The context is there just to show that this didn't happen every minute, so it may take a little longer to reproduce on some systems. I didn't get the error in 10 minutes with the default MPEG-4 settings, but only after I enabled all the extra compression options.