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.mak...@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

_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to