If you haven't done so already, please bring this to Johns (author of softhddevice) at the vdrportal forum.
Thanks
On Wed, Dec 25, 2013 at 6:50 AM, Marko Mäkelä marko.makela@iki.fi wrote:
After upgrading to VDR 2.0, I got Softdevice to almost work (see the mail archive a couple of months ago). Sometimes it is showing garbage (really random noise) on the MGA350 OSD layer; I can live with that, as this box is only used for infrequent recordings.
The last annoying problem is that going to the next or previous I-frame when editing (buttons 4 and 6 on the remote control) are not updating the video screen at all. Only the edit mark is moving on the OSD layer. If I press Play, it will start playing from the current edit mark. So, it is possible but much more clumsy to cut recordings.
SoftDevice is overriding the method with this:
void cSoftDevice::StillPicture(const uchar *Data, int Length) { SOFTDEB("StillPicture...\n"); if (decoder) decoder->StillPicture((uchar *)Data,Length); }
It seems to me that mpeg2decoder.c in softdevice is creating a new thread every time I try to move editing mark, and calling cMpeg2Decoder::Action(). In gdb, it will fail as follows:
while(ThreadActive) { while (freezeMode && ThreadActive) usleep(50000);
BUFDEB("av_read_frame start\n"); if (useAVReadFrame) ret = av_read_frame(ic, &pkt); else ret = av_read_packet(ic, &pkt); if (ret < 0) { BUFDEB("cMpeg2Decoder Stream Error!\n"); if (ThreadActive) usleep(10000); continue; }useAVReadFrame=true, so it is calling av_read_frame(). That will block when running under gdb, like this:
#2 0xb68f83a9 in cSigTimer::Sleep (this=0xb2c121f4, timeoutUS=50000, lowLimitUS=0) at sync-timer.c:75 #3 0xb68f1cf0 in cMpeg2Decoder::read_packet (this=this@entry=0xb2c120f0, buf=buf@entry=0x87fc5b0 "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353 \004\024\277\004jhjG|] t$X", buf_size=buf_size@entry=10864) at mpeg2decoder.c:1128 #4 0xb68f1dcf in read_packet_RingBuffer (opaque=0xb2c120f0, buf=0x87fc5b0 "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353 \004\024\277\004jhjG|] t$X", buf_size=10864) at mpeg2decoder.c:1042 #5 0xb69140c9 in fill_buffer (s=s@entry=0x85ac040) at libavformat/aviobuf.c:319 #6 0xb6916ff7 in get_byte (s=0x85ac040) at libavformat/aviobuf.c:365 #7 get_byte (s=s@entry=0x85ac040) at libavformat/aviobuf.c:360 #8 0xb6958984 in find_next_start_code (header_state=0x8a075e0, size_ptr=<synthetic pointer>, pb=0x85ac040) at libavformat/mpeg.c:142 #9 mpegps_read_pes_header (s=s@entry=0x89f2080, ppos=ppos@entry=0xb10cc190, pstart_code=pstart_code@entry=0xb10cc160, ppts=ppts@entry=0xb10cc170, pdts=pdts@entry=0xb10cc180) at libavformat/mpeg.c:246 #10 0xb695933a in mpegps_read_packet (s=0x89f2080, pkt=0xb10cc290) at libavformat/mpeg.c:419 #11 0xb690c3b4 in av_read_packet (s=s@entry=0x89f2080, pkt=pkt@entry=0xb10cc290) at libavformat/utils.c:591 #12 0xb690ce8b in av_read_frame_internal (s=0x89f2080, pkt=0xb10cc304) at libavformat/utils.c:998 #13 0xb68f2527 in cMpeg2Decoder::Action (this=0xb2c120f0) at mpeg2decoder.c:1228
It will unblock when I hit 4 or 6 again, because the thread would be killed (ThreadActive=false) by this:
#0 cMpeg2Decoder::Stop (this=this@entry=0xb2c120f0, GetMutex=GetMutex@entry=false) at mpeg2decoder.c:1545 #1 0xb68f2cec in cMpeg2Decoder::Clear (this=0xb2c120f0) at mpeg2decoder.c:1655 #2 0xb68ea1b6 in Clear (this=0x83d3130) at softdevice.c:492 #3 cSoftDevice::Clear (this=0x83d3130) at softdevice.c:484 #4 0x080cf2da in cDvbPlayer::Empty() () #5 0x080cf7e9 in cDvbPlayer::Goto(int, bool) () #6 0x080d1303 in cDvbPlayerControl::Goto(int, bool) () #7 0x080fd676 in cReplayControl::MarkMove(bool) () #8 0x080fdcc6 in cReplayControl::ProcessKey(eKeys) () #9 0x080aac39 in main ()
I wonder why this worked in VDR 1.6 but no longer in VDR 2.0? Is it because Softdevice is expecting a PES packet here instead of TS, or is it something else?
Marko
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr