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

Reply via email to