[mythtv] Fwd: [mythtv-commits] Re: Ticket #796: mythtranscode --mpeg2 won't work with ivtv/dbox2 recordings

Geoffrey Hausheer mythtv0368 at phracturedblue.com
Thu Dec 15 13:38:49 EST 2005

On 12/14/05, Michael Haaswrote:
>  2005-12-14 21:18:26.525 VID: B #:3 nb: 2 pts: 00:00:00.227 dts:
> 00:00:00.227
>  2005-12-14 21:18:26.526 Id:0 00:00:00.227 V:195 MP2: 199
>  Deadlock detected.  One buffer is full when
>  the other is empty!  Aborting

>  2005-12-14 21:28:29.207 VID: P #:5 nb: 2 pts: 00:00:00.320 dts:
> 00:00:00.200
>  2005-12-14 21:28:29.207 Id:0 00:00:00.320 V:196 MP2: 199 AC3: 199
>  Deadlock detected.  One buffer is full when
>  the other is empty!  Aborting

This makes no sense.  the buffers are all empty, so this should never
be able to happen.  The only case I can think of that would caus ethis
is if the video buffer was drastically undersized (there are 2 bypes
of buffers data buffers (contains the encoded frames), and index
buffers (contains info about the frame).  The deadlock code only
checks the index frames, as there should be a 1:1 correspondence
between index:data.

This could happen if the image resolution was incorrectly detected
(which doesn't appear to be the case).  you can try the following:  on
line 381 in mpeg2fix.cpp change the 'memset = ...'  line to be:
uint32_t memsize = 10000000;
that should give you plenty of bufer for your images.

I would like to see the stream itself, as I have no idea why it isn't
working correctly.  Please send me the 640x480 one.  The following
should work fine:
dd if=1067_20050909201000_20050909215500.nuv of=tmp.mpg bs=1024 count=4096

that'll generate a 4MB file, which should be plenty to debug the problem.
use dropload.com if you don't have a place to store the files on the web.


More information about the mythtv-dev mailing list