[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.
.Geoff
More information about the mythtv-dev
mailing list