Opened 17 years ago
Closed 17 years ago
#3046 closed defect (fixed)
Bogus position map causes fast forward locks in frontend after [12645]
Reported by: | anonymous | Owned by: | Janne Grunau |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | mpeg12.c |
Cc: | Stuart Auchterlonie | Ticket locked: | no |
Description
Pressing FF when viewing recorded programmes hangs the frontend:
2007-02-04 23:50:36.664 Dec: DoFastForward(2995 (2971), don't discard frames) 2007-02-04 23:50:36.664 AFD: SeekReset(3006, 0, do flush, don't discard) 2007-02-04 23:50:36.664 AFD: SeekReset() flushing [mpeg2video @ 0xb7551728]current_picture not initalized 2007-02-04 23:50:36.703 AFD Error: Unknown decoding error 2007-02-04 23:50:36.714 Avg read interval was 182 msec. 64K block size 2007-02-04 23:50:36.742 Avg read interval was 197 msec. 96K block size 2007-02-04 23:50:36.758 Avg read interval was 197 msec. 128K block size 2007-02-04 23:50:36.774 Avg read interval was 197 msec. 160K block size 2007-02-04 23:50:36.790 Avg read interval was 197 msec. 192K block size 2007-02-04 23:50:36.807 Avg read interval was 197 msec. 224K block size 2007-02-04 23:50:38.454 NVP: Play( 10.0, normal 0, unpause audio 1) 2007-02-04 23:50:41.140 NVP: prebuffering pause 2007-02-04 23:50:41.140 NVP: Waiting for prebuffer.. 0 AAAAAAAAAAAAAAAAAAAAAUAAAAAAAAA
The error condition appears to be:
[mpeg2video @ 0xb7551728]current_picture not initalized
I have no idea what causes this but to restore mythtv FF functionality you can backout FFMPEG libavcodec update in revision 7256 => 7538 as per the patch attached.
l8r
Attachments (3)
Change History (14)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
Cc: | Stuart Auchterlonie added |
---|
Changed 17 years ago by
Attachment: | mythtv hang.txt added |
---|
comment:3 Changed 17 years ago by
Same problem here; occurs with ffwd, rewind, and skipping back or forward. Log attached (very reproducible, but does not happen every time)
comment:4 Changed 17 years ago by
Owner: | changed from Isaac Richards to Janne Grunau |
---|
comment:5 Changed 17 years ago by
I get the same problems here; best I can tell this started after the ffmpeg sync in [12645] (as suggested in the OP).
comment:6 Changed 17 years ago by
This is a known and producible issue which the devs are working to fix. Please can we have no more "me too" posts.
comment:7 Changed 17 years ago by
Milestone: | unknown → 0.21 |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
a bogus position map causes this error. It looks like the key frame detection in the dvbrecorder isn't compatible to libavcodec.
A user job with following command line mythtranscode --buildindex --chanid %CHANID% --starttime %STARTTIME% should fix it. You could run mythtranscode of course also directly.
This doesn't seem to be a recent problem. I can reproduce it with older recordings.
closing this as duplicate of #799
comment:8 Changed 17 years ago by
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
Summary: | fast forward causes frontend to hang in 12709 → Bogus position map causes fast forward locks in frontend after [12645] |
DTVRecorder::HandleKeyFrame?() doesn't consider buffered packets when writing the position to the position map.
I'll commit it a simple fix soon. It's unfortunately not fully correct since it doesn't handle start codes spanning two TS packets correctly.
I'm not sure if this is a valid case. It is at least a unlikely case. The offsets calculated by DTVRecorder and libav* match with my fix applied.
comment:9 Changed 17 years ago by
(In [12819]) Refs #3046. Include buffered packets in the position map offset.
This should fix the "current_picture uninitialized" and "first frame is no key frame" libavcodec seeking errors for new recordings.
To fix old recordings you have to rebuild the position map. Please use the command in http://svn.mythtv.org/trac/ticket/3046#comment:7.
To fix the lookup I need backtraces since I can't reproduce it.
comment:10 Changed 17 years ago by
I've found the cause of the infinite loop. The explanation takes longer than the fix.
When ffmpeg detects the error it returns -1 and AvFormatDecoder::GetFrame? stores this in the "ret" variable. It then tests "ret" and sets "have_err" to true but leaves "ret" as -1. The loop clears "have_err" but again leaves "ret" unchanged. If the next packet is a subtitle packet which doesn't alter "ret" but sets "len" to zero intending this to skip the packet there is a problem at the end when it subtracts ret from len. Since ret is negative this sets len to 1. The loop tests for len being greater than zero and so doesn't exit leading to an infinite loop.
The fix is simply to set ret to zero after setting have_err.
David.
Changed 17 years ago by
Attachment: | avformat.patch added |
---|
comment:11 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I've tried out the patch attached to this ticket and this solves instability issues seen during FF, browsing the media library (select recording to watch), and issues when editing a recording. THX!!! (I was getting desperate).